Open Bug 1724700 Opened 3 years ago Updated 10 months ago

Replace update doorhangers with a pulsing hamburger menu badge

Categories

(Toolkit :: Application Update, enhancement, P3)

Firefox 90
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: lisamiller9891, Unassigned)

References

Details

(Whiteboard: [proton-door-hangers][proton-hamburger-menu])

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 OPR/77.0.4054.203

Steps to reproduce:

New update for Firefox is available

Actual results:

Prompt appears on top right for users to download or delay the update.

Expected results:

No prompt should appear. Instead, a Discord-like behavior should occur:

If automatic download is enabled:
The download occurs in the background and the user is unaware of it.
Once it is downloaded, a prominent, green arrow pointing up appears next to the three bars that open the menu. The arrow should be outright visible, and clicking it closes the browser and installs the update.

Current behavior is that a little dot appears on top of the three bars. Then the user has to manually click on the install button.

If automatic update is disabled, the arrow could be of a different color? And instead it transforms into a spinning/working indicator while the update downloads (no prompt for confirmation, encouraging updates). Once the update is done, clicking it again updates the browser.

If automatic update is enabled, the updates could also happen when opening the browser.

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Application Update
Product: Firefox → Toolkit

I'm a little confused about what you are asking for because your "Expected Results" description contains some things that we already do. Just so that we are all on the same page, let me give a brief description of how Firefox update works now:

  1. Firefox periodically checks if an update is available.
  2. If an update is found and automatic update downloads are not enabled, we display a doorhanger (a sort of popup) asking the user if they would like to download the update.
  3. If automatic update downloads are enabled or the user says yes to the update prompt, we download the update silently in the background.
  4. Once the update has been downloaded, we prepare it for installation.
  5. If the user does not restart the browser for a long period (default on the Release channel is 4 days from download completion), we show a badge over the hamburger menu button and "Update available - restart now" text within the hamburger menu.
  6. After even more time has passed (default on the Release channel is 8 days from download completion), we show a doorhanger requesting that the user restart.
  7. The user eventually shuts down Firefox (it doesn't matter how).
  8. On startup, we apply the update.

As far as I can tell, the only way that your "Expected Results" differ from this process are to replace the "green dot" badge with a "green arrow" badge and add a "spinning arrow" badge during download if automatic update downloads are disabled. Am I understanding correctly?

Flags: needinfo?(lisamiller9891)

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #3)

I'm a little confused about what you are asking for because your "Expected Results" description contains some things that we already do. Just so that we are all on the same page, let me give a brief description of how Firefox update works now:

  1. Firefox periodically checks if an update is available.
  2. If an update is found and automatic update downloads are not enabled, we display a doorhanger (a sort of popup) asking the user if they would like to download the update.
  3. If automatic update downloads are enabled or the user says yes to the update prompt, we download the update silently in the background.
  4. Once the update has been downloaded, we prepare it for installation.
  5. If the user does not restart the browser for a long period (default on the Release channel is 4 days from download completion), we show a badge over the hamburger menu button and "Update available - restart now" text within the hamburger menu.
  6. After even more time has passed (default on the Release channel is 8 days from download completion), we show a doorhanger requesting that the user restart.
  7. The user eventually shuts down Firefox (it doesn't matter how).
  8. On startup, we apply the update.

As far as I can tell, the only way that your "Expected Results" differ from this process are to replace the "green dot" badge with a "green arrow" badge and add a "spinning arrow" badge during download if automatic update downloads are disabled. Am I understanding correctly?

I was going to address your points one by one, but I think it's clearer if I go to the issue I believe exists:

1 - Doorhangers are annoying and intrusive. If I'm watching a youtube video I don't want to be nagged by my browser about an update. If I'm working on google docs or programming I don't want to lose focus and have to think about the download.
2 - The badge on the hamburger menu is practically hidden AND is ambiguous about its purpose. If you have an update ready and it needs to be applied, then show some firm and clear indication of it. Discord method: Show a clear, green arrow pointing up next to the hamburger. When clicked, the browser closes immediately and installs. Telegram method: Show a banner at the bottom or top of the browser saying "Restart to update" and when clicked it does just that. Both methods cannot be clicked away. Telegram method is ay more intrusive (but effective) and I mention it for completeness, I don't think it's a good method for a browser.

What I propose:
Get rid of both of these things. One is a pain in the ass (Try having 30 popups a month on nightly! And yes, I know that's why it's called nightly, it's still a pain), the other is not noticeable enough for the average user, who doesn't even know why the badge exists. AND if he clicks the hamburger to see what the badge is about, he WON'T be ready to update, I assure you, unless he already knows that the button is there (even if most people think it is to update, not everyone does). Most often he will be annoyed that it was just to update, won't be prepared to do so so out of the blue, will leave it for later - and forget.

Replace with:

When an update is available, show an arrow pointing up next to the hamburger menu. If downloads are automatic or if the user already downloaded the update, simply make the arrow green and when the user clicks it the browser restarts and applies the update.
In order to avoid outrages for the sudden restart, simply add a little popup when you hover that says "Update Ready!". This is exactly what Discord does, and it works like a charm. In a weird way, it cognitively makes you want to click it, so would be great for Firefox.

If automatic downloads are not enabled: Then I'm not sure. Discord downloads updates automatically always in the background, which I'm eh about, and Firefox would probably get a lot of backlash for... Though... you know, since updating would be ultimately the user's choice you could do it and just skip the step. Though it would mean the browser is updated no matter what when the browser is restarted / closed and opened. Maybe something to consider.
I thought that maybe the arrow could be yellow if its asking for authorization to download an update. Or it's still green but when clicked it transforms into a progress circle showing download progress, and when finished turns back into a green arrow, now pulsing (see next paragraph)

To remind the user about the update process, simply make the arrow glow intermittently with a neon green, as in, make it pulse. Maybe once an hour? Maybe every minute? This is more reliable than the popup (its constant, always visible), and less annoying (doesn't take away focus or screen space).

tl;dr other apps do updates better in my opinion, and current practices are either annoying or not visible/explicit enough.

Flags: needinfo?(lisamiller9891)

What you are describing would be changes to the Proton UI design, so I'll try to get the Proton team involved.

(In reply to L from comment #4)

One is a pain in the ass

To be completely frank, I want Firefox to be kind of aggressive about getting users' attention about updates. The internet is a pretty hostile place where running untrusted and malicious code is pretty common. I can appreciate that nobody likes being told to update, but I can nearly guarantee that making it easy to ignore updates will ultimately result in more harm to more people.

Try having 30 popups a month on nightly!

This is not the first bug that I've seen involving people that have automatic update downloads disabled on Nightly. I would like to understand this situation better, because it is a bit confusing to me. In the interest of understanding how people use our product, would you mind explaining to me the motivation behind doing this? If you want a version of Firefox that updates to use the very newest code every day, why do you want to be notified every time? I hope this question doesn't come off as rude; I am genuinely curious and I feel that better understanding our users will help me make the product better for them in the future.

Whiteboard: [proton-door-hangers][proton-hamburger-menu]

Given what you have told me so far, it occurs to me that you might be interested in this Enterprise Policy intended for power users: ManualAppUpdateOnly.

There is a bit more information about this in Bug 1653430, if you are interested.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #7)

Given what you have told me so far, it occurs to me that you might be interested in this Enterprise Policy intended for power users: ManualAppUpdateOnly.

There is a bit more information about this in Bug 1653430, if you are interested.
Ah, no worries, it's a pain but it's not something that drives me crazy. Like you said, it's intended to be aggressive!
But a pulsing green arrow or the like would also be aggressive in its own way, and be there always, not just once a day (for nightly at least).

Even if my particular suggestions suck, I have no doubt the process can be done better.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #6)

What you are describing would be changes to the Proton UI design, so I'll try to get the Proton team involved.

(In reply to L from comment #4)

One is a pain in the ass

Try having 30 popups a month on nightly!

This is not the first bug that I've seen involving people that have automatic update downloads disabled on Nightly. I would like to understand this situation better, because it is a bit confusing to me. In the interest of understanding how people use our product, would you mind explaining to me the motivation behind doing this? If you want a version of Firefox that updates to use the very newest code every day, why do you want to be notified every time? I hope this question doesn't come off as rude; I am genuinely curious and I feel that better understanding our users will help me make the product better for them in the future.
Hah, well, you might be surprised a bit by the answer.

First, the logo is cooler. I like it. Stuff like this may sound silly, but aesthetics do matter, and Firefox will always 1-up Chrome there. Nightly looks really cool. Massive point here: You ABSOLUTELY should give a distinct logo to Firefox Beta and Thunderbird Beta. I have never used FF Beta or TB Beta because the logo just looks like crap with the little "Beta" there. Who wants to use a browser with that sign?! Nightly however is its own beast. Guess I'll open a bug report for that, but seeing we were on the topic...

Second, Nightly is definitely "stable" for everyday use - in my opinion, and in my case. Yes, sometimes a bug here and there may appear, rarely pretty bad, but honestly I'll take being two months in the future relative to the average user of Firefox for a few minor inconvenience here and there.

Third, the change that updating from one day to the next can bring will be minimal for most days. Yes, changes accumulate, but I'd rather just update every 3 or 5 days than everyday, when an update won't have actual visible impact for the user. Not everyone who uses Nightly hunts for bugs! (Sorry to pile on different topics, but Beta and nightly should be visible for download from the main webpage, not hidden at the bottom or on another page... my two cents.)

Remember also that you must restart your browser to update, and how many people like doing that? And everyday?! So I just defer until I feel like it.

As for why "automatic downloads" disabled, well, because I don't want an update to download, only to have to re-download again when I open firefox because a newer update is out (e.g., you download update today, and in two days restart browser, now you're one day behind in updates. This is something I think could be "fixed" too, so if a newer update is available the current is purged and newer downloaded. Currently I do not think this is done). In fact, it sometimes happens that I restart and an update is applied, and if I go to "About Firefox" a new update starts to download. Yuck experience.

If you really want to psychoanalyse me, you could say I also just like the feeling of power. What if some horrible change happens, or some virus is somehow embedded in the latest update? (think Transmission: https://gizmodo.com/mac-bittorrent-client-transmission-gets-infected-with-m-1785957214) Not saying it's going to happen, or even that it could, but I like to be able to say no, do not download anything yet, let's wait a couple days.

I'll make bug reports for the two tangential issues I mentioned above and link them here.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #7)

Given what you have told me so far, it occurs to me that you might be interested in this Enterprise Policy intended for power users: ManualAppUpdateOnly.

There is a bit more information about this in Bug 1653430, if you are interested.

Whoops, I meant to thank you for this above, but I cut the line I guess.
It's not a big deal, the updates are annoying for three seconds, that's all, I don't really care about it. It can just be a better experience.

Created bug for creating new logo for Beta:
https://bugzilla.mozilla.org/show_bug.cgi?id=1725163

Created bug for showing Beta & Nightly more prominently on FF webpage:
https://bugzilla.mozilla.org/show_bug.cgi?id=1725168

Thanks for the feedback!

It turns out that the Proton team is no longer triaging these bugs, so I'll be making a determination for this bug.

(In reply to L from comment #8)

But a pulsing green arrow or the like would also be aggressive in its own way

I think that this is worth considering. I know that there are enough users that dislike doorhangers that I'm interested in entertaining the possibility. There might be reasons that we want to keep update doorhangers around, so it is possible that we would implement both interfaces and have a setting to choose between them.

First, the logo is cooler. I like it. Stuff like this may sound silly, but aesthetics do matter

I have to admit, I wasn't expecting this answer, but I thank you for your honesty. On this basis, I wonder if you might be interested in Firefox Developer Edition? Just a thought.

This is something I think could be "fixed" too, so if a newer update is available the current is purged and newer downloaded

I actually sort of fixed this in Bug 353804. Unfortunately, the impact is more limited than I would like. We only generate partial updates (where you only have to download the difference between the new version and the old version) for a couple of versions back. And I didn't think it was a good idea for sufficiently out-of-date copies of Firefox to be frequently downloading an entire new copy of Firefox. I've been meaning to talk to that team, actually, and ask how hard it would be to generate partial updates for more versions.


As I said, I am interested in this change but, unfortunately, no one on our team has time to work on this at the moment. So I'll be putting this in the backlog for now.

A note to anyone that wants to work on this bug: This is a big enough UI change that I cannot unilaterally make the decision to add this. If you want to work on this, let me know and we can talk to the relevant decision makers about signing off on this and deciding whether to:

  • switch entirely to this new interface,
  • add an option for this interface to the update settings, or
  • run an experiment to try the new interface out and see how it performs
Priority: -- → P3
Summary: Streamline Firefox updates, with less interaction from user → Replace update doorhangers with a pulsing hamburger menu badge

It seems unlikely to me that someone is using Nightly and does not know that the green app menu badges represent update notifications. The badges seem very reasonable to me — I've been disabling the popup prompts for like 2 years without any problems knowing when an update is available, personally. (and my eyesight is pretty bad)

That said, the icons could maybe be a little clearer. What I do with my custom theme is make the update-available badge a light green circle with a dark green down arrow ⬇ to signify that you need to download an update (this is with app.update.auto disabled of course). Then I make the update-restart badge the same icon but with a checkmark ✔ instead of a down arrow. Then I make the update-unsupported badge a dash on a yellow background, sort of like the ⛔ road sign? And the fxa-needs-authentication badge is a warning ⚠ icon. Well, this works great for me, so maybe I'll submit a patch for it. They're still 14x14 icons so they're not immune to visual accessibility issues. But that's why the update popup prompt exists, right?

We could add some kind of pref to make the badge display more dramatic. It's just difficult to think of what specifically that would be, if not a popup prompt. We can't change colors of big UI elements without causing theme problems or adding a new theme property, and most themes on AMO are rarely or never updated.

I have one possible idea. @Kirk I mentioned the idea of a transient hint before on phabricator, I don't think it's an ideal replacement for the popup prompt, but it could be a useful accompaniment to the badge for users who disable the prompt. I don't know if I would want it myself though. At the time the badge is set on the app menu button, it could dispatch a popup hint pointing to the app menu button that will disappear on its own after 10 seconds, like the ConfirmationHint. So a user who dislikes the interactive prompts could disable/delay them, and if they have trouble seeing the badge, they could supplement it with a transient, less-invasive popup hint.

Attached image update-available

Here's my update-available badge

Attached image update-restart

And here's update-restart...

(In reply to Shane Hughes [:aminomancer] from comment #15)

Created attachment 9260006 [details]
update-restart

And here's update-restart...

It's an improvement for sure, I'm not against it, but from a UI perspective the checkmark looks more like it's saying "job's done, you don't need to do anything else" rather than "download is done, restart is needed"

Eh, I don't think so, if the job was done and you didn't need to do anything else, wouldn't you expect there to be no badge at all? And anyone who's used Firefox knows you have to restart to finish an update. If they don't wanna restart, then I guess their job really is finished, at least until they restart naturally. But anyway, badges usually mean you're supposed to click the thing the badge is on. So either way it'll lead someone to the restart banner.

(In reply to Shane Hughes [:aminomancer] from comment #17)

Eh, I don't think so, if the job was done and you didn't need to do anything else, wouldn't you expect there to be no badge at all? And anyone who's used Firefox knows you have to restart to finish an update. If they don't wanna restart, then I guess their job really is finished, at least until they restart naturally. But anyway, badges usually mean you're supposed to click the thing the badge is on. So either way it'll lead someone to the restart banner.

Fair, though I still think it could be better if it was, say, a reboot button rather than a checkmark. You know, the round arrow that points to itself.
Just my two cents.

Yeah I had something like that a couple months ago. That's the icon I use for my app menu restart button script. But the dimensions just don't really work well for a circular badge. Especially with the other icons having a much lower profile in proportion to the green disk. Maybe there's another kind of icon that emblemizes restarting though.

And to be clear, if you're referring to the reload icon, I'm not sure it even has that association for everyone. Since Firefox doesn't use it to represent restarting anywhere afaik, and does use it to represent refreshing a page. So semantically it's not optimal either.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #12)

Thanks for the feedback!

It turns out that the Proton team is no longer triaging these bugs, so I'll be making a determination for this bug.

(In reply to L from comment #8)

But a pulsing green arrow or the like would also be aggressive in its own way

I think that this is worth considering. I know that there are enough users that dislike doorhangers that I'm interested in entertaining the possibility. There might be reasons that we want to keep update doorhangers around, so it is possible that we would implement both interfaces and have a setting to choose between them.

First, the logo is cooler. I like it. Stuff like this may sound silly, but aesthetics do matter

I have to admit, I wasn't expecting this answer, but I thank you for your honesty. On this basis, I wonder if you might be interested in Firefox Developer Edition? Just a thought.

This is something I think could be "fixed" too, so if a newer update is available the current is purged and newer downloaded

I actually sort of fixed this in Bug 353804. Unfortunately, the impact is more limited than I would like. We only generate partial updates (where you only have to download the difference between the new version and the old version) for a couple of versions back. And I didn't think it was a good idea for sufficiently out-of-date copies of Firefox to be frequently downloading an entire new copy of Firefox. I've been meaning to talk to that team, actually, and ask how hard it would be to generate partial updates for more versions.


As I said, I am interested in this change but, unfortunately, no one on our team has time to work on this at the moment. So I'll be putting this in the backlog for now.

A note to anyone that wants to work on this bug: This is a big enough UI change that I cannot unilaterally make the decision to add this. If you want to work on this, let me know and we can talk to the relevant decision makers about signing off on this and deciding whether to:

  • switch entirely to this new interface,
  • add an option for this interface to the update settings, or
  • run an experiment to try the new interface out and see how it performs

Kirk, have things changed since this post?
Not sure if it's worth making a connect.mozilla.org new idea post since this improvement bug is up, but then again this seems to have been forgotten.

(In reply to L from comment #20)

Kirk, have things changed since this post?

No, I don't really have any updates. The short version of the story is that we are constantly really busy. When there is time to work on stuff in our backlog, I typically choose to fix defects rather than work on enhancement requests. And that's not even getting into the fact that we would need UI approval for this, and they are really busy too.

Not sure if it's worth making a connect.mozilla.org new idea post since this improvement bug is up, but then again this seems to have been forgotten.

I'm not particularly familiar with connect.mozilla.org. But if you can either get a lot of people outside Mozilla excited about this or get the right people inside Mozilla excited about this, then there is a much higher chance that something will be done. Perhaps connect.mozilla.org can help with that?

(In reply to Robin Steuber (they/them) [:bytesized] from comment #21)

(In reply to L from comment #20)

Kirk, have things changed since this post?

No, I don't really have any updates. The short version of the story is that we are constantly really busy. When there is time to work on stuff in our backlog, I typically choose to fix defects rather than work on enhancement requests. And that's not even getting into the fact that we would need UI approval for this, and they are really busy too.

Not sure if it's worth making a connect.mozilla.org new idea post since this improvement bug is up, but then again this seems to have been forgotten.

I'm not particularly familiar with connect.mozilla.org. But if you can either get a lot of people outside Mozilla excited about this or get the right people inside Mozilla excited about this, then there is a much higher chance that something will be done. Perhaps connect.mozilla.org can help with that?

Hi! This is my yearly nagging to know if this might ever get an update. Cheers.. :p

(In reply to L from comment #22)

Hi! This is my yearly nagging to know if this might ever get an update. Cheers.. :p

There are three ways I can imagine this getting done:

  1. Every more serious issue is fixed. I doubt that this will happen because generally bugs are filed faster than we have the capability to fix them.
  2. Someone higher up at Mozilla picks up this change and decides that it should be prioritized. If I knew how to do this successfully, I have my own list of things that I would like to be prioritized.
  3. A volunteer submits a patch. It wouldn't be guaranteed to be merged and there would likely be a long back and forth process. But I have more ability to push for decisions to be made on an issue if someone outside our team is willing to do the work for us.

Sorry that I don't have better news. I'm always happy to help contributors get started if you or anyone else would like to submit a patch for this.

(In reply to Robin Steuber (they/them) [:bytesized] from comment #23)

(In reply to L from comment #22)

Hi! This is my yearly nagging to know if this might ever get an update. Cheers.. :p

There are three ways I can imagine this getting done:

  1. Every more serious issue is fixed. I doubt that this will happen because generally bugs are filed faster than we have the capability to fix them.
  2. Someone higher up at Mozilla picks up this change and decides that it should be prioritized. If I knew how to do this successfully, I have my own list of things that I would like to be prioritized.
  3. A volunteer submits a patch. It wouldn't be guaranteed to be merged and there would likely be a long back and forth process. But I have more ability to push for decisions to be made on an issue if someone outside our team is willing to do the work for us.

Sorry that I don't have better news. I'm always happy to help contributors get started if you or anyone else would like to submit a patch for this.

No problem, I appreciate that you take the time to reply in the first place.
It's a pity, since I've seen questionable features get implemented while better ideas get ignored.
Thanks again, and have a nice day.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: