Closed Bug 1690858 Opened 3 years ago Closed 3 years ago

Reintroduce Safe Mode toggle to Help menu with a new set of labels

Categories

(Firefox :: Menus, defect, P1)

defect

Tracking

()

VERIFIED FIXED
87 Branch
Tracking Status
firefox87 + verified

People

(Reporter: bj, Assigned: emmamalysz)

References

(Blocks 1 open bug)

Details

(Whiteboard: [proton-hamburger-menu])

Attachments

(1 file)

The Restart with Add-ons Disabled / Restart with Add-ons Enabled menu items were removed from the Help menu in bug 1689632. These menu items should be restored.

This is the most useful element of the Help menu. I use it regularly to investigate issues that appear in Nightly, and it is the first thing I suggest to someone who is having a Nightly, Beta, or Firefox Release issue (and I don't recommend anything else in the Firefox menus to anyone). The only item in the Help menu I use more often is Help/About to see if the next Nightly is ready.

If you want to keep the menu the current size, Check for updates... is a duplicate of About Nightly.

(And shouldn't About Nightly have three dots as it creates a window?)

Whiteboard: [proton-hamburger-menu]

We're going to reintroduce this item, but we're going to change the string:

When not in Safe Mode, the string should be:

Restart in Troubleshoot Mode

When in Safe Mode, the string should be:

Restart With Troubleshoot Mode Off

Note that we're going to want strings for this both in menubar.ftl and appmenu.ftl, since these entries will both be in the global menubar, as well as the Help subview.

https://phabricator.services.mozilla.com/D103489 can be used for inspiration on what to put back and how.

Summary: Add Restart with Add-ons Disabled back into Help Menu → Reintroduce Safe Mode toggle to Help menu with a new set of labels
Assignee: nobody → emalysz

I'll flag the issue to Meridel in the deck, as IIRC they weren't part of the original deck.

Can we think of alternatives to troubleshoot?

  • That's a word that exist only in English, and results in awfully long translation ("Problem solutions"). You can get an idea here.
  • As far as I can tell, we never used "Troubleshoot mode" before, we only have the concept of "Safe mode".

Rough translation in Italian:

  • Riavvia in modalità risoluzione dei problemi
  • Riavvia disattivando la modalità risoluzione dei problemi
Flags: needinfo?(mwalkington)

I think Romain will approve my recommendation that we don't make changes and de-scope this, but I'd like to know: could we use "Troubleshoot Mode" in En-locales and give guidance to localizers about selecting a term that is similar? Ex: Use something that communicates "Fix" or "Diagnostic" Mode?

Flags: needinfo?(mwalkington) → needinfo?(francesco.lodolo)

(In reply to Meridel from comment #4)

I think Romain will approve my recommendation THAT we don't make changes and de-scope this, but I'd like to know: could we use "Troubleshoot Mode" in En-locales and give guidance to localizers about selecting a term that is similar? Ex: Use something that communicates "Fix" or "Diagnostic" Mode?

I think there's a risk when it comes to user expectation, e.g. trying to find a menu in your localized build, knowing the English command (because you're following some guide or article online), and viceversa. Also, it kind of raises the question: if "Diagnostic Mode" is a good option for localized versions, why wouldn't it be for English as well?

To be clear, locales will come up with a valid translation for Troubleshoot Mode (they already have one for "troubleshooting"), we just need to account that it's going to be extremely long. For titles and descriptions it's not a concern, for menu and buttons it is.
Are we OK with a menu item as long as Riavvia disattivando la modalità risoluzione dei problemi? Can we ensure that it's not going to be truncated? If the answer is yes for both questions, then I don't have an issue with using it.

Flags: needinfo?(francesco.lodolo)

Side though: maybe we could call this "Troubleshoot Mode", but avoid calling it out explicitly in menu items? Unfortunately I can't really come with useful ideas for them.

Restart in Troubleshoot Mode -> Troubleshoot issues, or just Troubleshoot mode (I assume there's a confirmation dialog showing up, explains that the browser will be restarted, and how?)
Restart With Troubleshoot Mode Off -> Restart normally

Regarding the right term for English: I don't think "Diagnostic Mode" is a good label for EN-locales because 'diagnose' is associated with medical illness while 'troubleshoot' is more general to problem-solving. The two are not synonymous.

Regarding risk to user expectation: How significant is the risk? Is there a way to close the gap for other locales by using hover text on this menu item?

Regarding the issue of length: Since this menu items triggers a modal, yes we COULD shorten this to simply:
Turn Troubleshoot Mode on
Turn Troubleshoot Mode off

Flags: needinfo?(francesco.lodolo)

(In reply to Meridel from comment #7)

Regarding the right term for English: I don't think "Diagnostic Mode" is a good label for EN-locales because 'diagnose' is associated with medical illness while 'troubleshoot' is more general to problem-solving. The two are not synonymous.

I expect other locales to be in a similar situation, although I feel like diagnostic is often used in technical fields (e.g. engines, hardware).

Regarding risk to user expectation: How significant is the risk? Is there a way to close the gap for other locales by using hover text on this menu item?

Sorry, I don't think I can answer that. I think only user research in languages other than English could help measuring that risk. From a technical point of view, I'm not sure a tooltip is always available (e.g. I don't see them in macOS, but I don't know if it's a choice on our side or a platform constraint).

Regarding the issue of length: Since this menu items triggers a modal, yes we COULD shorten this to simply: Troubleshoot Mode/Turn Troubleshoot Mode off

I'd be OK with that solution.

Flags: needinfo?(francesco.lodolo)

To be clear, you are okay with Troubleshoot Mode/Turn Troubleshoot Mode off in terms of fixing length concerns, but do you maintain the term itself "Troubleshoot Mode" remains very problematic for localization?

Flags: needinfo?(francesco.lodolo)

(In reply to Meridel from comment #9)

To be clear, you are okay with Troubleshoot Mode/Turn Troubleshoot Mode off in terms of fixing length concerns, but do you maintain the term itself "Troubleshoot Mode" remains very problematic for localization?

Yes, I'm OK with using Troubleshoot Mode and Turn Troubleshoot Mode off as menu items. The second is going to be quite long, but I'm OK with taking the risk, also for sake of moving this forward (for what it's worth, I agree that safe mode is really confusing).

"Troubleshoot Mode" is only problematic in terms of length, not content. It's important to keep it in mind when used in menus or buttons, to avoid combining it with two many other words. In other parts of the UI, like a dialog title or a description, it's not a concern at all.

Flags: needinfo?(francesco.lodolo)

For documentation purposes (please correct me if I got something wrong here):

Length is no longer a concern because we have a new max-width now in the hamburger menu, which is improved from what it is used to be. The menu will now show all items without truncation.

We can move ahead with these new labels:
Turn Troubleshoot Mode on
Turn Troubleshoot Mode off

A final question: should we add alt-text to these items non-En locales who may experience the disconnect you mentioned ("I think there's a risk when it comes to user expectation, e.g. trying to find a menu in your localized build, knowing the English command (because you're following some guide or article online), and viceversa."). There is precedent in the hamburger menu today (see the Zoom controls) to include alt text to clarify a label.

Flags: needinfo?(francesco.lodolo)

Sorry, there is indeed a disconnect, as it's clear from re-reading all the current messages now. It depends on the fact that I commented based on the initial comment/proposal, and missed that it was edited (you can notice it in the quotes).

The initial proposal was:

  • Troubleshoot Mode
  • Turn Troubleshoot Mode off

That's the one I was agreeing to, the reasons being:

  • 99% (well, the vast majority) of the users will only see the first label, which is long but reasonable. We could drop "Restart" or "Turn off", because it's followed by a dialog asking for user confirmation, and telling them that the browser is going to restart and disable things.
  • Once the user is in Troubleshoot Mode, we display the long label Turn Troubleshoot Mode off. Again, it's exposed to a smaller number of users, so I'm OK with taking some more risks on truncation.

"Turn Troubleshoot Mode on" will be always displayed in standard mode, and I have a lot more concerns about that length.

Disconnect

That's only going to happen if we use "Troubleshoot Mode" for en-*, and suggest other locales to use a different term (e.g. "Diagnostic Mode"). If we're not going with that solution, then let's ignore the problem completely for sake of clarity, and since it can't be easily measured.

Large menus

Quoting from your last comment

Length is no longer a concern because we have a new max-width now in the hamburger menu,
which is improved from what it is used to be. The menu will now show all items without truncation.

Length it's still a concern:

  • This patch it's adding the menu items in two places, the system menu and the app menu. We control the width of the app menu, but I don't know how much control we have on system menus. I'd expect them to adapt to the longest label automatically, but we're talking about a lot of different platform combinations (especially Linux flavors). The same applies to using tooltips to clarify truncations: we control app menu, I'm not sure they're an option for system menus.
  • I feel like the scope on the app menu is larger than just figuring out the best copy for English and localization. To avoid potential churn, I'd prefer UX and product to explicitly sign off on a mock-up of the app menu which is significantly larger than planned, because it needs to fit a label that it's +70% than English. Also, this specific string is displayed in a subpanel: what's the expectation? A subpanel could dynamically increase or decrease the width of the app menu? Determining it beforehand, and adapt the entire appmenu might not be a viable technical option.
Flags: needinfo?(francesco.lodolo)

I wonder if it makes sense to go with something like "Restart in Safe Mode / Exit Safe Mode"?

This suggestion is based on the fact that both Apple and Microsoft calls these modes "safe mode", eg:

Indeed, so does Mozilla's support pages:

https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

In Android too, "safe mode" is widely used, eg:

I believe that because this language is widely used and recognized to perform this function (for example, this bug references it), even for international device manufacturers, that this should be easier to localize and recognizable for power users and beginners alike.

(In reply to Asif Youssuff from comment #13)

I wonder if it makes sense to go with something like "Restart in Safe Mode / Exit Safe Mode"?

This suggestion is based on the fact that both Apple and Microsoft calls these modes "safe mode", eg:

The problem is that our "safe mode" isn't like those other "safe mode"s, and referring to it like that in fact regularly confuses e.g. bug reporters because they think we're asking them to restart their OS - and when they do, they find it makes no difference to how Firefox works.

Even when it doesn't confuse (because perhaps technical users are familiar with this other "safe mode" terminology, but others are not), "safe" implies something that it is not - Firefox is not "safer" (in the broad sense) in safe mode, and for a privacy-focused product, not making promises you can't keep is pretty important. This is also why we don't refer to it as "safe mode" in the product already, as discussed in e.g. the original comment in bug 542122. The internal terminology is "safe mode" because that's what got used by the engineers at the time when implementing it (when it was arguably more accurate than it is today, because of the difference in power/impact that add-ons had on whether Firefox was even able to start).

If we instead tell users to "restart with add-ons disabled", they complain that (a) they don't want to try that or (b) they already tried disabling all their add-ons and that didn't help either (because they're unaware that Firefox's safe mode does other stuff besides disabling add-ons).

As for our own support pages - that's what it's called right now, the point of the discussion in this bug is about renaming the feature... we would have to update the support pages to match.

Thanks for clarifying, Flod!

I think there are two separate issues to sort through:

1. Re-labeling "Restart with add-ons disabled/enabled" as "Troubleshoot Mode/Turn Troubleshoot Mode Off" — I know character count is not the rule to apply for broader decisions about how to handle component width and length, but for purposes of just this label I did a sloppy Google Translate and see the German translation (not localization) is 20 characters for "Troubleshoot Mode" vs 41 characters for "Restart with Add-ons Disabled". Does this mean the new label is generally shorter and would be better? (assumes we use the same term in all locales, and pursue the alt text solution if needed).

2. Decision to expand menus to accommodate largest menu item— I think this is something you, Emanuela, and I can discuss next week, and then take mock to PM for approval?

Flags: needinfo?(francesco.lodolo)
Status: NEW → ASSIGNED

(In reply to Meridel from comment #15)

1. Re-labeling "Restart with add-ons disabled/enabled" as "Troubleshoot Mode/Turn Troubleshoot Mode Off" — I know character count is not the rule to apply for broader decisions about how to handle component width and length, but for purposes of just this label I did a sloppy Google Translate and see the German translation (not localization) is 20 characters for "Troubleshoot Mode" vs 41 characters for "Restart with Add-ons Disabled". Does this mean the new label is generally shorter and would be better? (assumes we use the same term in all locales, and pursue the alt text solution if needed).

Indeed. If we use "Troubleshoot Mode" for the "normal" menu, it's likely going to be shorter for several locales, because the length of "troubleshoot" is compensated by the removal of all other words. Wild guessing for French and German, based on existing strings.

German: Mit deaktivierten Add-ons neu starten… -> Fehlerbehebungsmodus

French: Redémarrer avec les modules désactivés… -> Mode de dépannage

Italian: Riavvia disattivando i componenti aggiuntivi… -> Modalità risoluzione problemi

The previous string was also hard, because "Add-ons" is one complicated word. In French, for example, it's Modules complémentaires. Here they compromised by dropping the second part, because the translation was already too long.

2. Decision to expand menus to accommodate largest menu item— I think this is something you, Emanuela, and I can discuss next week, and then take mock to PM for approval?

Yes, absolutely.

Flags: needinfo?(francesco.lodolo)

[Tracking Requested - why for this release]:
Given the changes here were from 87 we should try to avoid changing this once in 87 and then again in 88, so asking for tracking for 87.

Severity: -- → S3
Priority: -- → P1

We're quickly approaching soft freeze and uplift. I'm going to suggest we re-use the old labels for now so that we can get the menuitem back in for 87 without introducing more string churn than necessary.

I'll then file a new bug to land new labels when we settle on them.

Pushed by emalysz@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4028bb6872d3
add safemode toggle to help menu r=mconley,fluent-reviewers,flod
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

Verified - Fixed in Beta 87.0b4 and latest Nightly 88.0a1 (2021-03-01) using Win10, MacOS 10.15 and Ubuntu 18.04.

Status: RESOLVED → VERIFIED

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up on needinfos) from comment #18)

I'm going to suggest we re-use the old labels for now so that we can get the menuitem back in for 87 without introducing more string churn than necessary.

I'll then file a new bug to land new labels when we settle on them.

See also bug 1693092.

See Also: → 1693092

I believe we are in alignment but want to confirm. You are okay with these strings, yes?

Troubleshoot Mode
Turn Troubleshoot Mode off

Flags: needinfo?(francesco.lodolo)

Flod and I are aligned on the strings. These are the final:

When the mode is OFF: Troubleshoot Mode
After user has turned it ON: Turn Troubleshoot Mode off

Flags: needinfo?(francesco.lodolo)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: