1365491 - Rewrite the application update UI doorhanger messages to be more friendly

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, enhancement)

Description

[Bram Pitoyo [:bram]]

Needinfo Michelle for her advice and feedback.

Current UI
==========
https://mozilla.invisionapp.com/share/Y776FIBWS

A survey of “Restart to Update” UIs
===================================
https://docs.google.com/presentation/d/1o2I90I8SgIpIvSobTHtMriqsGO_nOmULljyrFCrprvY/edit


Old Strings vs Proposed Strings
===============================


Condition #1
------------
A new update is available and the user has opted into manual updates.


Old:

<title>A new Firefox update is available</title>

Update your Firefox for the latest in speed and privacy. [See what’s new].

[Not Now] [Download Update]


New:

<title>A new version of Firefox is ready for you.</title>

It’s faster and more secure. Get it now by downloading. [See what’s new].

[Not Now] [Download Update]


Condition #2
------------
Download failed, user prompted to proceed with full download.


Old:

<title>Firefox can’t update to the latest version</title>

Download a fresh copy of Firefox and we’ll help you to install it. [See what’s new].

[Not Now] [Download Firefox]


New:

<title>Sorry. We can’t update Firefox to a new version.</title>

This is usually caused by {xyz - is there a common reason we can use here? Question for engineers}. You can try downloading a fresh copy of Firefox. It might fix this problem.

[Not Now] [Download Firefox]


Condition #3
------------
A user has not restarted for 8 days after an update has been received.


Old:

<title>Restart Firefox to apply the update</title>

After a quick restart, Firefox will restore all your open tabs and windows.

[Not Now] [Restart and Restore]


New:

<title>A new version of Firefox is ready for you.</title>

It’s faster and more secure. Get it now by restarting Firefox. It’s quick, and we’ll restore all your tabs afterwards.

[Not Now] [Restart Firefox]

Comment 1

[Alex Thayer [:alexical] (she/her)]

(In reply to Bram Pitoyo [:bram] from comment #0)
> <title>Sorry. We can’t update Firefox to a new version.</title>
> 
> This is usually caused by {xyz - is there a common reason we can use here?
> Question for engineers}. You can try downloading a fresh copy of Firefox. It
> might fix this problem.
> 
> [Not Now] [Download Firefox]

If we're going to provide common reasons, I think it will feel a bit silly if we discard information that we already have about what failed. For instance, if we said something related to their internet connection when the code knows that it was a privilege elevation failure, this might end up confusing the user more than if we hadn't provided any information at all.

The categories of failures that cause us to show the manual update that I think we have, as far as a user is concerned, are:

- Check failure
- Download failure
- Elevation failure
- Unknown failure

rstrong, do you know what the most common causes for any of these might be? I imagine elevation failure is fairly straightforward, but what about download/check failure and unknown?

Comment 2

[Robert Strong (they/them - no direct email)]

There are quite a few "common" reasons for failure and it will take some time to provide those. I'll do so when I am able to.

Comment 3

[Robert Strong (they/them - no direct email)]

(In reply to Doug Thayer [:dthayer] from comment #1)
> <snip>
> - Check failure
This is typically caused by proxies and walled gardens. Keep in mind that the background check has to fail 10 times consecutively before this is shown.

> - Download failure
This is typically caused by proxies and walled gardens. When downloading a partial update this will automatically fallback to downloading a complete update before failing/

> - Elevation failure
The user cancelling elevation.

> - Unknown failure
Not sure what this represents. Can you provide a link to any UI code where this hits?

Comment 4

[Robert Strong (they/them - no direct email)]

Keep in mind that the first to are "typically" and there are actually a very large variety of causes so any messaging that is added regarding the cause needs to be clear that it is just a typical cause.

For example, take a look at the "Out of date, of concern client last update check extended error code (check phase)" on the Firefox Application Update Out Of Date Dashboard
https://telemetry.mozilla.org/update-orphaning/

Those are the errors recorded by telemetry for the last check error encountered by a client. The client would have to encounter 10 consecutive errors with no successes before being notified of a check error. You can see the number of clients that are notified in code 22 in the graph immediately above the graph I mentioned above. We are also adding fallbacks for several of these states as time permits.

Comment 5

[Robert Strong (they/them - no direct email)]

Forgot to mention that the background checks occur every 12 hours and keep track across browser sessions.

So, if...
Firefox is launched and a background check happens around 10 AM
Firefox is exited before 10 PM
and Firefox is launched the next day around 5 PM then the background check will happen soon (a few minutes to let tasks performed by Firefox to complete) after launching around 5 PM.

Comment 6

[Alex Thayer [:alexical] (she/her)]

Ah, on revisiting I'm realizing the "unknown" categorization was my own, and probably due more to my own ignorance of the causes that bring us down that code path than anything deeper. In any case here's the link to where it occurs:

http://searchfox.org/mozilla-central/rev/f55349994fdac101d121b11dac769f3f17fbec4b/toolkit/mozapps/update/nsUpdateService.js#1078

Comment 7

[Robert Strong (they/them - no direct email)]

I'll take a look at the unknown cases next week to see what can be done with them.

Comment 8

[Robert Strong (they/them - no direct email)]

So the "unknown" cases is when all of the fallbacks haven't been able to rectify a failure and ask the user to manually install.

Bram, there will be a code freeze the last week before nightly is merged to beta so if the strings are going to be changed the strings will need to be finalized in the next few days. Shall we just go with the strings in comment #0?

Comment 9

[mheubusch]

Hi Bram - Sorry I've been neglecting the NI on this.  I'm trying to understand why we are changing this copy. Do you know the back ground for the user story: 

Firefox's update notifications make me feel that I’m bad and doing something I’m not supposed to. 

Is that the result of user testing or feedback from SUMO?  If so, can you point me to the rationale for "make me feel bad" and "doing something I'm not supposed to", because the copy recommendations definitely seem more cheerful but I'm concerned that they are less informative and harder to parse, and don't know that will solve for negative sentiment. Also, what is the business goal the copy changes are trying to solve? 


Robert - can you hold off on making the change to the strings until Bram and I can discuss?

Comment 10

[Bram Pitoyo [:bram]]

Hi Michelle,

The background for the user story comes with two big caveats:

1. It was a scenario experienced by a Nightly user. This project focuses on release users.
2. On Nightly, you get the warning after having not restarted for 24 hours, instead of after 5 days. Consequently, many Nightly users will see this message, and many will complain. On release, we don’t expect to get many feedback because so few people will see it.

(The reason why we notify our Nightly users every 24 hours was because Nightly updates are delivered every day [instead of every 6 weeks]. We want to make sure that every Nightly users are up to date, so we show the restart message every 24 hours, too.)


Onwards to the scenario. The story I heard was:

> I run Nightly, but I don’t restart every day. Why do Firefox make me feel like I’m doing something I’m not supposed to, if I am not restarting every day?


This scenario, I think, has a larger implication that applies to the update messaging in general:

> 1. Having to wait and briefly lose progress sucks. Sometimes it’s necessary, but it shouldn’t be necessarily all the time (as is the case on Nightly).
> 2. Currently, the message doesn’t make users want to go through the process (restarting, restoring tabs) to get this update.


So the goal with the rewrite was twofold:

1. Not focus so much on what the users did wrong (“Restart to apply this update” --> “A new version is ready for you”)
2. Make the update something that’s desirable to get (“Get it now by downloading”, “Get it now by restarting”.


I’d also like to pose 2 alternatives to rewriting strings.


Alternative #1
--------------
Don’t rewrite. Leave behaviours as is. Our Nightly users are pros, and they should be okay with restarting their browsers every day, and getting a nudge if they don’t.

Alternative #2
--------------
Don’t rewrite. Instead, modify the length of time-to-notification, so that Nightly users don’t see the “Restart and update” notification unless they haven’t restarted for 5 days, instead of 24 hours.

The consequences: we may see more Nightly users lagging in versions (I don’t know whether this will be true or not), but it won’t be annoying to that population.


That wraps up the context, the solution and the alternatives. I’m open to ideas. What do you think?

Comment 11

[mheubusch]

Hi Bram - I think the Alternative 1 you propose above (Don’t rewrite. Leave behaviours as is. Our Nightly users are pros, and they should be okay with restarting their browsers every day, and getting a nudge if they don’t.) is the one that makes most sense.  

Not only are our Nightly users pros, they are using a product that promises updates every day.  If a user opts for manual updates or lets an open session run for more than a few days, I think it behooves us to remind them.  

If we have additional evidence beyond this one anecdote we might want to consider messaging users in the manual update cohort that allowing Firefox to install updates automatically will keep them current for better performance and security. We have added messaging to that effect in the updates section of preferences planned for 56 (which should be landing in nightly soon).  If we can detect that a user is on manual updates when they pave over or update, we could even consider making this message part of onboarding, if it is an issue with a big impact on release users.

Comment 12

[Bram Pitoyo [:bram]]

Thanks for the advice, Michelle. It sounds like our Preferences will already be updated with a stronger message that offers the benefit of keeping Firefox on auto-update.

Decision: let’s not update this string until we know for sure that the old string causes a widespread problem in the release population.

I’ll WONTFIX this bug.