Closed Bug 994882 Opened 10 years ago Closed 10 years ago

[UX] Get Windows users on old/unsupported Firefox versions onto modern versions

Categories

(Firefox :: General, enhancement)

enhancement
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 32

People

(Reporter: benjamin, Assigned: jboriss)

References

Details

(Whiteboard: [ux] p=8 s=it-32c-31a-30b.1 [qa-])

Attachments

(1 file, 2 obsolete files)

UX design work for bug 928173. For users who are using an old/unsupported Firefox, we want to:

* get those users to a modern Firefox
* ask those users if they knew they were out of date and collect preferences and log data to help distinguish some cases:
** The user intentionally disabled updates
** The user unknowingly disabled updates
** Updates are enabled but not working, and then see if we can figure out why

There are two different ways we're planning on deploying this:

* as an addon hotfix for users of existing versions of Firefox
* built into the product moving forward

The hotfix is the clear priority here, but I'm hoping we can use the same basic UX design for both cases.
Flags: firefox-backlog+
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #0)
> ** Updates are enabled but not working, and then see if we can figure out why

just as a side note, last year I saw a system where automatic updates were not working, it was a remote system that I couldn't access, we were unable to figure the issue remotely (there's still a bug filed for that I think). Though, opening the about window allowed to update Firefox properly. I filed bug 837300 suggesting that simple workaround. That bug is sort-of a dupe of this broader scope one now.
Can we ask users why they were out of date *after* we have updated them?
We can and we have. We've run snippet surveys on several older versions and found that between 50-70% of users are out of date, don't know they are out of date, are admins on their computers and want to be up to date. So running surveys after users update is feasible, but we may not receive much useful information since most users aren't even aware they were outdated to begin with.
Assignee: nobody → jboriss
Status: NEW → ASSIGNED
Whiteboard: p=8 s=it-31c-30a-29b.3 [qa-]
Summary: Outdated-Firefox UX design → [UX] Outdated-Firefox UX design
Whiteboard: p=8 s=it-31c-30a-29b.3 [qa-] → [ux] p=8 s=it-31c-30a-29b.3 [qa-]
Summary: [UX] Outdated-Firefox UX design → [UX] Get Windows users on old/unsupported Firefox versions onto modern versions
Will there be a followup to do the same for other OS's? At least for Mac?
Wireframe attached for feedback, showing two versions: one "pre-downloading" the installer in the background, and one not pre-downloading the installer.

Both begin by prompting the user to upgrade.  This could be done as a dialog on opening Firefox on about:home (as shown), or in a stand-alone in-content page.  My worry with the in-content page is that it would be unclear that it was coming from Firefox, which in the case of installs is fairly important.  We could also do this as a drop-down yellow-bar notification, but it's both spoofable and doesn't have much space for a question with multiple answers.

If the user has redirected about:home, we could open a new tab when the user launches Firefox to display the dialog.

The top version, #1, assumes the quite optimistic premise that we could download Australis in the background and skip the installer entirely, cutting down to the bare minimum actions the use needs to perform to get on the train: clicking the Windows Permission prompt.

The bottom version, #2, assumes we could not download Australis in the background but could pare down the installer by removing the setup screen.  

For these users entering Australis-land, my fellow designer Zhenshuo Fang has designed a great "welcoming" experience, so it's likely we won't need to make a separate flow for these out-of-date users.

Both #1 and #2 are light on gathering data.  Asking these users to complete a survey or opt in to telemetry comes with hard tradeoffs for users who either have decided they don't like the direction Firefox is going in or are experiencing some problem updating.  The latter is about to encounter a huge UI change, which is why we focus Australis first-run on getting users comfortable rather than asking for data.  

If there's data so important that we should make this tradeoff, we should talk about what that is and when we could get it with the least possible risk.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #4)
> Will there be a followup to do the same for other OS's? At least for Mac?

Absolutely - bsmedberg suggested starting with Windows because it was the larger problem.  Do we have numbers on this?
The data is there it and would need to be analyzed.
I think we should have more emphasis on data collection. We don't need to survey these users (although surveying the "no" users would be useful), as we've already surveyed thousands of out of date users. We do want to gather the logs referenced in bug 928173, which aren't included in telemetry. We'd like to get them from users who do end up updating as we think they will be a significant portion of the audience for this hotfix (most users want to be up to date).

Also, by "Australis" I assume you mean "Latest Firefox" not Firefox 29 right? Depending on when this hotfix goes live it may be after 29 is released and I'd like to make sure we update to the latest version at the time this is launched.
(In reply to Tyler Downer [:Tyler] from comment #7)
> I think we should have more emphasis on data collection. We don't need to
> survey these users (although surveying the "no" users would be useful), as
> we've already surveyed thousands of out of date users. We do want to gather
> the logs referenced in bug 928173, which aren't included in telemetry. We'd
> like to get them from users who do end up updating as we think they will be
> a significant portion of the audience for this hotfix (most users want to be
> up to date).
> 
> Also, by "Australis" I assume you mean "Latest Firefox" not Firefox 29
> right? Depending on when this hotfix goes live it may be after 29 is
> released and I'd like to make sure we update to the latest version at the
> time this is launched.

Ah, the logs are the more important, then?  Could we have them sent via the installation process - perhaps via a checkmark that defaults to sending these logs to Mozilla?  

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #6)
> The data is there it and would need to be analyzed.

Rob, could I have you comment on the feasibility of #1, the "ideal," flow described in https://bug994882.bugzilla.mozilla.org/attachment.cgi?id=8408698?  In particular, do we have some ability to skip the installation pages for these users (other than the Windows-required permission prompt)?
Flags: needinfo?(robert.strong.bugs)
Yes logs are the more important piece of data here. In fact, We've decided to not survey users at the time of this hotfix. So we can go ahead and just go forward without surveys for the time being.
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #8)
> (In reply to Tyler Downer [:Tyler] from comment #7)
> > I think we should have more emphasis on data collection. We don't need to
> > survey these users (although surveying the "no" users would be useful), as
> > we've already surveyed thousands of out of date users. We do want to gather
> > the logs referenced in bug 928173, which aren't included in telemetry. We'd
> > like to get them from users who do end up updating as we think they will be
> > a significant portion of the audience for this hotfix (most users want to be
> > up to date).
> > 
> > Also, by "Australis" I assume you mean "Latest Firefox" not Firefox 29
> > right? Depending on when this hotfix goes live it may be after 29 is
> > released and I'd like to make sure we update to the latest version at the
> > time this is launched.
> 
> Ah, the logs are the more important, then?  Could we have them sent via the
> installation process - perhaps via a checkmark that defaults to sending
> these logs to Mozilla?
The UI in the installer would need to be rewritten and I would think it would be easier via the add-on hotfix ui.
  
> 
> (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from
> comment #6)
> > The data is there it and would need to be analyzed.
> 
> Rob, could I have you comment on the feasibility of #1, the "ideal," flow
> described in
> https://bug994882.bugzilla.mozilla.org/attachment.cgi?id=8408698?  In
> particular, do we have some ability to skip the installation pages for these
> users (other than the Windows-required permission prompt)?
Not with the stub at present and the download phase would need some type of ui. The complete installer would need to be rewritten.

Also, I don't think we can have a checkbox for sending the logs in the installer and '#1, the "ideal," flow'.

I'll try to come up with more detailed possibilities towards what is optimal over the next couple of days.
Flags: needinfo?(robert.strong.bugs)
UI feedback so far:

We shouldn't have the "never ask again" button. We should keep pestering people on old versions permanently, at least once a week and maybe once a day.

I very much like the idea in the #1 of getting the download done before we show the user anything. rstrong said that the main reason to use the stub installer was that it handled Firefox already running better. Is that something we could either 1) port to the non-stub installer or 2) give the stub installer a pre-downloaded thing to work with?

Boriss, what would the behavior be if the user clicks away from the doorhanger? Could we be more aggressive and make this a dialog, perhaps even modal?


I think I'd be ok with a default-checked "We noticed problems with automatic update. [X] Send Mozilla my update logs to help fix the problem." or somesuch. I'd even put that on the original doorhanger. If it were possible, the main thing that I want to know from users is whether they knew that they were out of date or had any comments that might help us diagnose things that we found in their update log. But I really don't see a good place to hang that UI which wouldn't be annoying.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> UI feedback so far:
> I very much like the idea in the #1 of getting the download done before we
> show the user anything. rstrong said that the main reason to use the stub
> installer was that it handled Firefox already running better. Is that
> something we could either 1) port to the non-stub installer or 2) give the
> stub installer a pre-downloaded thing to work with?

From the user's perspective, is there much difference between the non-stub installer and regular installer?  We can default to whatever is easiest here.  Once users are in installer mode, we'll have to rely on what we'll be showing them.

> Boriss, what would the behavior be if the user clicks away from the
> doorhanger? Could we be more aggressive and make this a dialog, perhaps even
> modal?

The icon that spawned the doorhanger would still exist in the URL bar, and clicking it would re-show the UI.  Like the other dialogs.  Treating this one differently has a high risk of seeming inconsistent - if we're literally showing this thing every week or two, that should be plenty.
(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #12)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> > UI feedback so far:
> > I very much like the idea in the #1 of getting the download done before we
> > show the user anything. rstrong said that the main reason to use the stub
> > installer was that it handled Firefox already running better. Is that
> > something we could either 1) port to the non-stub installer or 2) give the
> > stub installer a pre-downloaded thing to work with?
> 
> From the user's perspective, is there much difference between the non-stub
> installer and regular installer?  We can default to whatever is easiest
> here.  Once users are in installer mode, we'll have to rely on what we'll be
> showing them.
The experience using the stub requires the user to wait for the download. I will be working on making the full installer handle files in use soon and this will get that portion of the ideal workflow where there is no ui displayed for the installer itself. You will still have the UAC dialog of course.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> UI feedback so far:
> 
> We shouldn't have the "never ask again" button. We should keep pestering
> people on old versions permanently, at least once a week and maybe once a
> day.
> 
> I very much like the idea in the #1 of getting the download done before we
> show the user anything. rstrong said that the main reason to use the stub
> installer was that it handled Firefox already running better. Is that
> something we could either 1) port to the non-stub installer or 2) give the
> stub installer a pre-downloaded thing to work with?
> 
> Boriss, what would the behavior be if the user clicks away from the
> doorhanger? Could we be more aggressive and make this a dialog, perhaps even
> modal?
> 
> 
> I think I'd be ok with a default-checked "We noticed problems with automatic
> update. [X] Send Mozilla my update logs to help fix the problem." or
> somesuch. I'd even put that on the original doorhanger. If it were possible,
> the main thing that I want to know from users is whether they knew that they
> were out of date or had any comments that might help us diagnose things that
> we found in their update log. But I really don't see a good place to hang
> that UI which wouldn't be annoying.

Are there any parts of that update log that we could see which would be aligned with our privacy without asking users?

I ask because I worry that including that checkbox on this doorhanger will lead to less people upgrade, because:

1. Analysis paralysis.  Adding an additional option can make users less likely to make the more important decision (to upgrade).
2. More cluttered panel may make users less inclined to read/understand what is being asked (that they upgrade) and more likely to just skip it
3. Asking users at this phase indicates that we're having upgrade problems, leading to potentially lower confidence in us being "trusted" to upgrade them to a better version of Firefox
The only identifiable info / prvacy concern that I know of are file paths and it should be possible to strip those before sending.
It is not possible to collect any data without an opt-in unless

1) we show the user the data we're collecting, currently through the about:healthreport interface
and 2) we can show a direct user benefit to collecting the data

I'm comfortable with #2 in this case, since we're clearly using their data to fix the update experience. But we'd still need to do some extra work to get this into the healthreport UI.
Whiteboard: [ux] p=8 s=it-31c-30a-29b.3 [qa-] → [ux] p=8 s=it-32c-31a-30b.1 [qa-]
rstrong, I had a conversation with Boriss this morning and I was just experimenting with the silent mode of the full installer. Steps:

* Have Firefox 9.0 installed at "C:\Program Files (x86)\Mozilla Firefox Release".
* Run Firefox 9
* download the Firefox 29 full installer
* Create an install.ini file with

[Install]
InstallDirectoryPath=C:\Program Files (x86)\Mozilla Firefox Release

* Run the installer.exe /INI=c:/builds/debugging-builds/install.ini

The installer unpacks silently/prompts for privileges/runs and returns exit code 0 but it doesn't appear to have successfully installed into that directory. So I have a couple questions:

* Did the installer actually fail? Or is the install staged someplace and would install on next Firefox or Windows reboot?
* Is failure expected in this case?
* Should the exit code of the installer reflect that?
* Is there an .ini or command-line flag which would direct the installer to prompt-close Firefox?
Flags: needinfo?(robert.strong.bugs)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #17)
> rstrong, I had a conversation with Boriss this morning and I was just
> experimenting with the silent mode of the full installer. Steps:
> 
> * Have Firefox 9.0 installed at "C:\Program Files (x86)\Mozilla Firefox
> Release".
> * Run Firefox 9
> * download the Firefox 29 full installer
> * Create an install.ini file with
> 
> [Install]
> InstallDirectoryPath=C:\Program Files (x86)\Mozilla Firefox Release
> 
> * Run the installer.exe /INI=c:/builds/debugging-builds/install.ini
> 
> The installer unpacks silently/prompts for privileges/runs and returns exit
> code 0 but it doesn't appear to have successfully installed into that
> directory. So I have a couple questions:
> 
> * Did the installer actually fail? Or is the install staged someplace and
> would install on next Firefox or Windows reboot?
It failed. For silent installs the process executing currently needs to elevate the installer process.

> * Is failure expected in this case?
See above.

> * Should the exit code of the installer reflect that?
I don't recall for this instance.

> * Is there an .ini or command-line flag which would direct the installer to
> prompt-close Firefox?
No.

The code is going to have to be modified for this bug's use case vs. the admin silent install and I'll post in this bug as soon as I have something for you.
Flags: needinfo?(robert.strong.bugs)
BTW: one of the things I am working on is making it so requiring the caller for this use case doesn't have to use the runas verb and ShellExecuteEx as is required today for silent installs and similar to
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp#2819
In short, the exit code is bogus. The exit code comes from the 7-Zip self-extracting archive which launches the installer which also launches another instance of the installer on Win Vista and above when elevation is required. One way around this is to check if the install.log in the install directory has been updated.

The patch in bug 1004168 makes it so we move the files out of the way before we install even if Firefox is running. You don't need to close Firefox and after the install completes all you need to do is restart.

For the ini file you will need to add
[Install]
PreventRebootRequired=true

You should also add the following so you don't add shortcuts the user hasn't already added
[Install]
QuickLaunchShortcut=false
DesktopShortcut=false
StartMenuShortcuts=false

I think it would be a good thing to also add
MaintenanceService=true

For WinXP we don't try to elevate since it doesn't have the same elevation method as Windows Vista and above so the user should run the installer themselves if they don't have write access to the install directory or you can specify an alternate install directory that the user does have write access to. If you do specify an alternative directory you should create shortcuts.

For Win Vista and above if the user doesn't have UAC turned on we don't try to elevate so the above for WinXP is also true.

For the above cases you could launch the installer using runas as noted in comment #19. Then if you get elevation cancelled you will know the install failed though it won't handle the case where the username and password provided don't have write access.

On WinVista and above we try to elevate even when the user is not a member of the admin group. If they don't supply an username and password that has write access we won't have write access to the install path and the install will fail.

There is probably more I haven't thought of and I will add them to this bug if I think of any.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #20)
>...
> On WinVista and above we try to elevate even when the user is not a member
> of the admin group. If they don't supply an username and password that has
> write access we won't have write access to the install path and the install
> will fail.
For clarity, the fail cases only fail when running silently and not when interactive.
After speaking with Benjamin, I’m attaching a new version of the wireframe.

The top version, #1, is the “ideal” state in which the next version of Firefox is downloaded silently, in the background, without any interaction from the user.  The installer is thus skipped entirely, giving users a fast track to upgrade.  Benjamin mentioned this may be possible, but he’d have to look into it & we’d need to talk to Rob.  This wireframe assumes it *is* possible.

The bottom version, #2 is the stub installer state, in which Firefox cannot be downloaded silently and instead must be prompted.  I’m recommending using the stub installer rather than the regular one so that we can show the user they are beginning the installation process as fast as possible.

The prompt to install, in #1 and #2, would show when the user starts Firefox, up to once a week, on about:home. If the user has changed their homepage from about:home, a new tab opens when they load Firefox that prompts them to install the new version (see B).

Both versions let the user delay the installation by a week by pressing “not now.”  I’m also recommending adding the option to turn off update notifications to about:config.  If a user doesn’t want to upgrade so much that they are willing to research what it will take to disable these, I feel we should respect his choice.

Next step, I'll be setting up a meeting with Rob & Benjamin to discuss feasibility, and particularly version #1 and version #2.
Attachment #8408698 - Attachment is obsolete: true
Jennifer, can you please include me on that meeting as well? thanks!
I don't understand why we care what the homepage is or what exactly is different about the design in the two branches.

If we can run the installer entirely silently, could we just run it as soon as it's downloaded? And only show the prompt if the user declines the UAC prompt?

Can we change the interval from a week to a day? I feel like a week is not very aggressive.
Attaching a slightly different wireframe after syncing up with Benjamin

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #24)
> I don't understand why we care what the homepage is or what exactly is
> different about the design in the two branches.

This is so we never show a permission panel on a website that's not generating it.  This is both for consistency and so users don't think that the Firefox they're being asked to install is coming from, say, espn.com.

> If we can run the installer entirely silently, could we just run it as soon
> as it's downloaded? And only show the prompt if the user declines the UAC
> prompt?

We could!  It might be scary, but I've been thinking about it and think you have a good point - this is definitely the "fewest clicks" way to get people over.

Here's what I'm proposing (and it's in the wireframe):

1. If we possibly can, we download Firefox in the background, silently.  When the user next launches Firefox, they see that lovely UAC prompt.  If they click Yes, they get new Firefox right away.  But if they click no...

2. If the user clicks no, we show a permission panel when the user launches Firefox or visits about:home or launches Firefox: up to once a day.

Once a day is pretty aggressive, but Smedberg reminded me that users can turn automatic updates off in Preferences to not see these messages again.
Attachment #8416961 - Attachment is obsolete: true
Great, thanks.

The bit that isn't in this picture, but that we discussed on the phone: if the installer fails through no fault of the user, we will automatically open a tab pointing to something on SUMO.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
Status: RESOLVED → VERIFIED
I've started implementing this UX in bug 1014194. Boriss was kind enough to clarify a few questions I had over IRC:

* It is acceptable if the notification has an "x" in the corner (to close it)
* Having a drop-down menu of choices (with install the selected/default) is acceptable (instead of two buttons)
* The notification should not disappear on its own
* The notification should behave like similar Firefox notifications

In code speak, Boriss effectively said it was OK to utilize the existing PopupNotification functionality instead of having to reinvent the wheel.
You need to log in before you can comment on or make changes to this bug.