RC1 review - too many clicks?
Jon
While it's easy to dismiss the feedback as a rant, it has a point, even if we don't use the One-Click term anymore.
I've purposely enabled more features in the fake installer so that we can review, move on, and get rid of this issue from the tracker.
1) Should a Full/Custom install page similar to the fake installer be included in RC1?
The only value I see is that it allows a smaller (i.e. - server style) install for those not needing/wanting the CHM documentation.
2) Should the install confirmation page in the fake installer be included in RC1?
Other than for debugging purposes, I see very little value in this page. If a user "trusts" the installer enough to start an install, how many are really going to want to pause and second guess what the installer is about to do? I think it's more important for us to build trust in the installer by rigorously testing to ensure the installer isn't taking too many liberties with the existing system, and the uninstaller leaves the system as it found it.
3) Should the PATH and file assoc mods be enabled by default and the current check box Task page removed from RC1?
Assuming we get comfortable with the PATH and file assoc code, I'm for removing the check box page and turning on PATH and file assoc by default *IF* we customize one of the pages to have an "Advanced..." button which pops up a page allowing one to disable these features. This would take more work, delay RC1, and conflict a bit with my "don't take too many liberties..." statement above. But let's face it, the current check box page is just ugly ;)
Thoughts?
Jon
p.s. - for a pretty cool installer check out http://www.jingproject.com/download/pc/ and just try a few pages out before cancelling it. That said, it's a pretty cool screencast tool so you might want to check it out with a free screencast.com account.
Luis Lavena
On Mon, Sep 28, 2009 at 4:54 PM, Jon <jon.f...@gmail.com> wrote:
> Luis has left this issue open on the bug tracker
> http://rubyforge.org/tracker/index.php?func=detail&aid=22347&group_id=167&atid=715
>
> While it's easy to dismiss the feedback as a rant, it has a point, even if
> we don't use the One-Click term anymore.
>
> I've purposely enabled more features in the fake installer so that we can
> review, move on, and get rid of this issue from the tracker.
>
> 1) Should a Full/Custom install page similar to the fake installer be
> included in RC1?
>
> The only value I see is that it allows a smaller (i.e. - server style)
> install for those not needing/wanting the CHM documentation.
>
You can still achieve that offering installation flags. Administrators
deploying installers to multiple computers are used to them, like /S,
/Q, etc.
>
> 2) Should the install confirmation page in the fake installer be included in
> RC1?
>
> Other than for debugging purposes, I see very little value in this page. If
> a user "trusts" the installer enough to start an install, how many are
> really going to want to pause and second guess what the installer is about
> to do? I think it's more important for us to build trust in the installer
> by rigorously testing to ensure the installer isn't taking too many
> liberties with the existing system, and the uninstaller leaves the system as
> it found it.
>
No value at all.
>
> 3) Should the PATH and file assoc mods be enabled by default and the current
> check box Task page removed from RC1?
>
> Assuming we get comfortable with the PATH and file assoc code, I'm for
> removing the check box page and turning on PATH and file assoc by default
> *IF* we customize one of the pages to have an "Advanced..." button which
> pops up a page allowing one to disable these features. This would take more
> work, delay RC1, and conflict a bit with my "don't take too many
> liberties..." statement above. But let's face it, the current check box
> page is just ugly ;)
>
No defaults. There is an issue with this and users installing multiple
versions of Ruby (like we do, 1.8.6 and 1.9.1)
Changing the associations, the PATH and things will make a lot of bug
reports crawl into our tracker...
> Thoughts?
I would rather pay to get someone with InnoSetup experience to code a
custom installer pages so we get "Advanced" options and less clicks.
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Jon
> 1) Should a Full/Custom install page similar to the fake installer beYou can still achieve that offering installation flags. Administrators
> included in RC1?
>
> The only value I see is that it allows a smaller (i.e. - server style)
> install for those not needing/wanting the CHM documentation.
>
deploying installers to multiple computers are used to them, like /S,
/Q, etc.
>
> 3) Should the PATH and file assoc mods be enabled by default and the current
> check box Task page removed from RC1?
>
No defaults. There is an issue with this and users installing multiple
versions of Ruby (like we do, 1.8.6 and 1.9.1)
Changing the associations, the PATH and things will make a lot of bug
reports crawl into our tracker...
> Thoughts?
I would rather pay to get someone with InnoSetup experience to code a
custom installer pages so we get "Advanced" options and less clicks.
Gordon Thiesfeld
>
>> > 1) Should a Full/Custom install page similar to the fake installer be
>> > included in RC1?
>> >
>> > The only value I see is that it allows a smaller (i.e. - server style)
>> > install for those not needing/wanting the CHM documentation.
>> >
>>
>> You can still achieve that offering installation flags. Administrators
>> deploying installers to multiple computers are used to them, like /S,
>> /Q, etc.
>>
>
> I'll look into it and make the appropriate mods.
This is already cooked into Inno Setup. I just tried it out with the
fake installer, like this:
FakeRubyInstaller_1.9.1-p243_27-Sep-09T2159.exe /silent /SILENT
/TASKS="modifypath,associatefiles" /COMPONENTS="main,doc"
Of course, it wasn't really a silent install, because of the debugging
message boxes, but it could be completely automated very easily in
this way.
You can specify the install directory, tasks, components, etc. This
might make a good wiki entry, showing different setup scenarios and
how they would be achieved. Here's a list of Inno's setup parameters.
http://unattended.sourceforge.net/InnoSetup_Switches_ExitCodes.html
>
>>
>> >
>> > 3) Should the PATH and file assoc mods be enabled by default and the
>> > current
>> > check box Task page removed from RC1?
>> >
>
>
> [..snip..]
>
>>
>> No defaults. There is an issue with this and users installing multiple
>> versions of Ruby (like we do, 1.8.6 and 1.9.1)
>>
>> Changing the associations, the PATH and things will make a lot of bug
>> reports crawl into our tracker...
>>
>
> Agreed. Defaulting to "enabled" has too many downsides and not enough
> upsides.
>
>>
>> > Thoughts?
>>
>> I would rather pay to get someone with InnoSetup experience to code a
>> custom installer pages so we get "Advanced" options and less clicks.
>
> This may not be that difficult from what I'm finding doing the PATH and
> assoc coding. Let's discuss *after* we get RC1 pushed out the door! :)
> What we need now is testing, testing, testing, testing of the PATH and assoc
> code on XP, Vista, and 7 in both 32 and 64-bit flavors and multiple
> scenarios like...install RubyInstaller, tweak the order of your path
> statements, uninstall RubyInstaller, and validate the uninstaller didn't
> modify your tweaked PATH order.
I had been working on testing using Virtualbox and RSpec, but life has
been keeping me pretty busy. That, and the release of rvm has driven
me to spend more time on pik than I can really afford. ;-)
Gordon Thiesfeld
> FakeRubyInstaller_1.9.1-p243_27-Sep-09T2159.exe /silent /SILENT
> /TASKS="modifypath,associatefiles" /COMPONENTS="main,doc"
There should just be one /SILENT. I got a little cut/paste happy.
Jon
This is already cooked into Inno Setup. I just tried it out with the
On Tue, Sep 29, 2009 at 2:51 PM, Jon <jon.f...@gmail.com> wrote:
>
>> > 1) Should a Full/Custom install page similar to the fake installer be
>> > included in RC1?
>> >
>> > The only value I see is that it allows a smaller (i.e. - server style)
>> > install for those not needing/wanting the CHM documentation.
>> >
>>
>> You can still achieve that offering installation flags. Administrators
>> deploying installers to multiple computers are used to them, like /S,
>> /Q, etc.
>>
>
> I'll look into it and make the appropriate mods.
fake installer, like this:
FakeRubyInstaller_1.9.1-p243_27-Sep-09T2159.exe /silent /SILENT
/TASKS="modifypath,associatefiles" /COMPONENTS="main,doc"
Great! When we merge the appropriate stuff from the fake installer back in, we'll just need to ensure the version specific .iss's have the "doc" component label where needed.
Of course, it wasn't really a silent install, because of the debugging
message boxes, but it could be completely automated very easily in
this way.
:)
>> > 3) Should the PATH and file assoc mods be enabled by default and the
>> > current
>> > check box Task page removed from RC1?
>> >
> [..snip..]I had been working on testing using Virtualbox and RSpec, but life has
>
>>
>> No defaults. There is an issue with this and users installing multiple
>> versions of Ruby (like we do, 1.8.6 and 1.9.1)
>>
>> Changing the associations, the PATH and things will make a lot of bug
>> reports crawl into our tracker...
>>
>
> Agreed. Defaulting to "enabled" has too many downsides and not enough
> upsides.
>
>>
>> > Thoughts?
>>
>> I would rather pay to get someone with InnoSetup experience to code a
>> custom installer pages so we get "Advanced" options and less clicks.
>
> This may not be that difficult from what I'm finding doing the PATH and
> assoc coding. Let's discuss *after* we get RC1 pushed out the door! :)
> What we need now is testing, testing, testing, testing of the PATH and assoc
> code on XP, Vista, and 7 in both 32 and 64-bit flavors and multiple
> scenarios like...install RubyInstaller, tweak the order of your path
> statements, uninstall RubyInstaller, and validate the uninstaller didn't
> modify your tweaked PATH order.
been keeping me pretty busy. That, and the release of rvm has driven
me to spend more time on pik than I can really afford. ;-)
Nice...it will be interesting to see what you find in the different configs. We probably should be following your lead, suck it up, and start writing RSpec's along the way, and I bet even system() will play OK with the "reg query" stuff to better automate scanning the registry for installer/uninstaller mess ups. Oh, and I wanted an excuse to start playing with Thor a bit more :(
Gordon Thiesfeld
>
> Nice...it will be interesting to see what you find in the different
> configs. We probably should be following your lead, suck it up, and start
> writing RSpec's along the way, and I bet even system() will play OK with the
> "reg query" stuff to better automate scanning the registry for
> installer/uninstaller mess ups. Oh, and I wanted an excuse to start playing
> with Thor a bit more :(
>
You can use win32/registry from the stdlib. Here's the Drb spec code
I was playing around with.
http://pastie.org/private/eoi7p3q8c9a3dksnd4fxw
It's pretty basic at this point, but allows for using system() to run
the installer, you can check for existence of files and shortcuts, and
read registry keys. The drb_server.exe would run on the VM. The
specs would run locally on the developer's workstation. Maybe someone
can turn this into something useful, or at least get some ideas from
it.
Jon
Luis Lavena
While it warns, it hasn't been deprecated in 1.9.2
Sent from mobile.
On Sep 29, 2009 11:49 PM, "Jon" <jon.f...@gmail.com> wrote:On Tue, Sep 29, 2009 at 5:28 PM, Gordon Thiesfeld <gthie...@gmail.com> wrote: > > > On Tue, Sep ...