Closed Bug 508684 Opened 14 years ago Closed 14 years ago
Add Ability to Change "Firefox as your default browser" and inform of upgrade on Summary step
184.84 KB, image/png
6.79 KB, patch
|Details | Diff | Splinter Review|
8.13 KB, patch
|Details | Diff | Splinter Review|
11.08 KB, patch
|Details | Diff | Splinter Review|
For the Windows installer, on the "Summary" step, where we say, "Firefox will be set as your default browser", we should add an option for users to modify this setting (e.g., by instructing them to hit the back button, or by adding a "change" button). Discussion on this request can be found here: http://blog.mozilla.com/metrics/2009/08/03/more-changes-coming-to-the-firefox-installer/.
Some options include: 1) only mention being default once (so they aren't confused by a combination of first a question and then a statement) 2) ask as a question in both locations using a checkbox 3) defer the default question to after the first run experience. The user will have more information to make an informed decision at that point anyway, but the downside is that the dialog gets in their way as they are leaving the application Overall we shouldn't give them instructions to change the setting when we could just give them the setting itself. So for instance I prefer option 2 compared to a sentence instructing them to go back. These choices of course all have huge implications for retention and ethical considerations (express setup, etc.)
Summary: Add Ability to Change "Firefox as your default browser" on Summary step → Add Ability to Change "Firefox as your default browser" and inform of upgrade on Summary step
To fix this we're going to move the "Use Firefox as my default web browser" checkbox to the summary page and change the button text from Install to Upgrade. Though we could provide info regarding the version they are upgrading from / to it seems that for the majority of users this would just be extraneous info the user would at best ignore and at worst would have to parse.
I'm going to file a follow up bug to attempt reduce the overall number of steps in the install process wizard.
Filed follow up bug 513414 to see if we can streamline the install.
This shows the four states of the UI without the two additional states for the next button (e.g. Install or Upgrade and already verbally reviewed by beltzner). screenshot 1 - can set as default and a reboot may be required screenshot 2 - can set as default and no reboot required screenshot 3 - can't set as default (e.g. no permissions to set required registry keys or already default) and a reboot may be required screenshot 4 - can't set as default (e.g. no permissions to set required registry keys or already default) and no reboot required Alex, I reused the existing strings but perhaps they could be better... can I get a string review from you?
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #397802 - Flags: ui-review?(faaborg)
(In reply to comment #7) > Created an attachment (id=397914) [details] > patch for 1.9.2 and trunk Does write access to HKLM tie directly to our ability to register (even under HKCU) as the default browser? + ; Check is Firefox is already the handle One minor comment nit - "is" -> "if"
(In reply to comment #9) > (In reply to comment #7) > > Created an attachment (id=397914) [details] [details] > > patch for 1.9.2 and trunk > > Does write access to HKLM tie directly to our ability to register (even under > HKCU) as the default browser? Though we can set the handler keys via HKCU write access to HKLM is necessary for setting as the StartMenuInternet client and I would prefer just letting the app set this via helper.exe when in this is the case. BTW: on Vista and above we try to elevate when setting as default from the app. Fixed the typo
Comment on attachment 397914 [details] [diff] [review] patch for 1.9.2 and trunk WFM
Attachment #397914 - Flags: review?(jmathies) → review+
carrying forward review. Fixed typo, added localization note, and changed UpgradeBtn to UPGRADE_BUTTON to be consistent in custom.properties
Comment on attachment 397802 [details] Summary page screenshots (doesn't include upgrade button) Alex, besides strings if you could also provide input as to control placement it would be appreciated. It might make more sense to put the only question on this page as the first item for example.
Comment on attachment 397802 [details] Summary page screenshots (doesn't include upgrade button) looks good, perhaps Web should be capitalized since it is a proper noun? (we aren't totally consistent about that in the product).
Attachment #397802 - Flags: ui-review?(faaborg) → ui-review+
Attachment #398065 - Flags: approval1.9.2+
Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/131543cad782
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Added one comment fix
Attachment #398742 - Flags: review+
Pushed to mozilla-1.9.2 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/b07689c3cfbd
Verified fixed on the 1.9.2 branch using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090908 Namoroka/3.6a2pre (.NET CLR 3.5.30729). I verified the fix by performing a new install of Namoroka and verifying that the checkbox is on the summary page as well as verifying the upgrade verbiage performing an install after FF is already installed.
Attachment #397916 - Flags: approval18.104.22.168?
Comment on attachment 397916 [details] [diff] [review] 1.9.1 patch - no l10n impact 22.214.171.124 won't ship until until mid-late October. 1.9.2 will ship shortly after (November). We can just pick this up in 1.9.2. If I'm missing the severity of this, feel free to renominate for approval with full rationale.
Attachment #397916 - Flags: approval126.96.36.199? → approval188.8.131.52-
Comment on attachment 397916 [details] [diff] [review] 1.9.1 patch - no l10n impact Well, this fixes one of the problems discovered by the install survey and getting it in earlier than later will allow us to tune 1.9.2 based on user feedback if necessary. The patch on trunk / 1.9.2 has baked for a while now without regressions and the patch for 1.9.1 is just a subset of the trunk / 1.9.2 patch. I'd really like to get this landed otherwise we'll have to wait months before taking additional steps to improve the install process.
Attachment #397916 - Flags: approval184.108.40.206- → approval220.127.116.11?
The current installer UI ("Use Firefox as my default browser") is turning away IE users who want to download/install Firefox for the first time. This seems like a change we'd want to get in (and measure its actual impact) ASAP.
I find this change to be a little confusing. When I'm installing something, I don't expect the "summary" dialog to have more options that I haven't seen before. There should always be at least one dialog with no options in case the user accidentally double-clicks "Next ->".
Though I agree with the summary page having options (will be fixed in bug 513414) having a summary step doesn't fix the double click problem in the case where the next step is the summary step and with a wizard which should replace next with install per MS wizard design.
Attachment #397916 - Flags: approval18.104.22.168? → approval22.214.171.124+
Comment on attachment 397916 [details] [diff] [review] 1.9.1 patch - no l10n impact Approved for 126.96.36.199, a=dveditz
Pushed to mozilla-1.9.1 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a66a244b5173 this only fixes the "Add Ability to Change 'Firefox as your default browser' on Summary step" on 1.9.1 so it wouldn't affect l10n also made one comment typo fix in the checkin
You need to log in before you can comment on or make changes to this bug.