rstrong's blog
in search of ponies
How metrics helped improve the install experience…
September 1st, 2009 by rstrong
and gave me more time to spend with my pony
As mentioned on the Blog of Metrics we changed the installer in Bug 404541 so we always provide a suggested installation directory. When I implemented the ability to install as a non-admin user I wanted the user to decide where to install Firefox since locations outside of Program Files are suboptimal. I justified this in part by saying to myself that it was a small percentage of users and forgot / ignored what I often say myself… “a small percentage of our user base doesn’t mean it isn’t a large number of users”.
Also mentioned on the Blog of Metrics are a couple of more changes coming to the installer. After Bug 508684 lands we are going to ask if Firefox should be made the default browser on the Summary page since many people missed it on the Setup Type page. This will hopefully also land for Firefox 3.5.4 or 3.5.5 and for Firefox 3.6 we will also change the install button’s text to “Upgrade” when installing on top of an existing install which was another thing the install survey pointed out was confusing to users.
We are also going to workaround zombie firefox.exe processes in Bug 496207 by only prompting to close Firefox once and if it is still present during the installation require an OS reboot to complete the install by replacing the files that were in use. This is once again one of those instances where I believe it affects a very small percentage of users but affects a large number of users. The details as to why we can’t just kill the firefox.exe process, etc. are in Bug 496207.
I have to say that I am thrilled with the data provided by the install survey and wish similar data gathering techniques could be used throughout Firefox. Thanks go out to all involved and especially to Ken Kovash. My pony also thanks you.
Re bug 496207: are you saying there’s no way to tell if a Firefox process is a ‘zombie’ (and can only be killed) or is actually active and may have unsaved user data?
(You only assert in the bug that the Firefox process can’t be unconditionally killed (may lose data) and that we can’t focus its existing window.)
If it’s so, it’s surely counter-intuitive…
Why not simplify the installer radically? Just one Step with all the options.
Google Chromes installer is much simpler, you cant even cancel it!
There are plans to simplify it in Bug 513414. As to why not just do that instead the major reasons are: we also want the changes in Bug 508684 to land on Firefox 3.5.x and that won’t happen if there are string changes and Firefox 3.6 is a short release cycle so there might not be time to do it
Yes though there are other conditions it would need to handle that I didn’t mention such as -no-remote, multiple instances, etc. and I wouldn’t be surprised if there are other conditions it would need to handle as well. I am sure it is possible to figure out all of the conditions and write the NSIS code which would almost certainly require custom NSIS plugins to handle this but I am also sure it would take time away from other work that is considered higher value.
Windows 7 and Windows Installer 5.0 provide real per-user installation capabilities.
http://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx
You can sort of fudge it in Vista and XP by using ~/AppData/Local or the equivalent like Chrome does. Microsoft themselves use this for the ClickOnce installers.
So at least on Windows 7 and beyond the solution is simple.
For browsers and other apps that have entries under HKLM\Software\Clients things break for multi-user systems with this approach since they are system wide settings and the app is installed in the user’s profile. As of 3.5 our order of preference is 1. under Program Files, 2. in all users appdata, 3. under the current users appdata.
*edit* that should have been all users then current users local appdata
[...] Continue reading here: How metrics helped improve the install experience… at Robert … [...]
[...] The Firefox team is making one small UI change (mentioned in Rob Strong’s blog post) [...]
[...] The Firefox team is making one small UI change (mentioned in Rob Strong’s blog post) [...]