1620536 - "Import from another browser" menu adds noise and scroll bar to the app menu

Status: RESOLVED FIXED

(Firefox :: Menus, defect, P1)

Description

[Serge]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

Recently a new button "Import from another browser" was added to the root of App/Hamburger button.

Expected results:

An additional button in the root of the menu makes it too crowded. Taking into account that this functionality is not used daily, moving it to "Help" sub-menu

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Matthew N. [:MattN]]

I kinda agree and was surprised UX wanted this so prominent. It annoys me on Windows when the Exit item at the bottom requires scrolling in my VM. Mardak, care you relay UX's thoughts?

Maybe it could go under Library or More?

Comment 3

[Ed Lee :Mardak]

Pretty sure Bryan intended it to be directly inside the app menu to make it easier for new users to find:
https://mozilla.invisionapp.com/share/QCW68066D2X

Aaron, should we change this behavior? I guess maybe somehow it could be only shown for profiles under some profile age?

Comment 4

[Dão Gottwald [:dao]]

[Tracking Requested - why for this release]:

(In reply to Ed Lee :Mardak from comment #3)

Pretty sure Bryan intended it to be directly inside the app menu to make it easier for new users to find:

This is an understandable sentiment but it's getting out of hand. We've recently added "Privacy Protections", "Logins and Passwords" and "What's New" as top-level items. We need some oversight here so the menu doesn't become an unstructured mess, making it harder for users to find anything.

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #2)

It annoys me on Windows when the Exit item at the bottom requires scrolling in my VM.

This is particularly bad. I have a Lenovo X1 Carbon with a native resolution of 2560x1440 and a default scaling factor of 200% on Windows 10, and I get the scroll bar in a maximized window.

Comment 5

[Serge]

Hi,
I totally agree with the previous comment.
The concept of adding new items to the root menu becomes questionable.
Right now I'm forced to hide some new items via CSS to be able to reduce that noise.
To be specific:
"Privacy Protections" >> duplicated, it is accessible via URL bar shield icon ("Show report"), but guess this can be treated as a personal preference
"Logins and Passwords" >> OK, this one is actually useful
"What's New" >> IMHO it would better fit in Help submenu, at least it goes away after first click on it.
"Import from another browser" >> again it is a duplicate, because according to https://bugzilla.mozilla.org/show_bug.cgi?id=1620536#c3 it will be present in "Library - Bookmarks"

Comment 6

[Aaron Benson]

I'm inclined to move this to the Help menu because this is likely a one-time use item and I’m not really comfortable with having transient menu items. It’s also going into the Library so we could track engagement there, too.

IIRC in the savant study we ran which measured where people were clicking in the browser, the Help menu saw a lot of attention.

I think Ed is investigating the feasibility of moving it..

Comment 7

[Ed Lee :Mardak]

At a glance, looks like there's some code to copy over items from the Help menubar menu into the Help app menu Help view:
https://searchfox.org/mozilla-central/rev/2fd8ffcf087bc59a8e5c962965bbb7bf230bcd28/browser/components/customizableui/content/panelUI.js#719-753

So there's probably some work in getting the icon to show up in both places and some reworking with the command invoked.

Comment 8

[Matthew N. [:MattN]]

Help seems like the wrong place IMO. "More" or "Library" seem more appropriate.

Comment 9

[Dão Gottwald [:dao]]

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #8)

Help seems like the wrong place IMO.

I think it makes sense there for new users along with "Firefox Tour" and "What's New", which I think we should move in a followup.

"More" or "Library" seem more appropriate.

"More" seems much more random, and as I understand it it will be added under "Library" independently (i.e. there will be a duplicate).

Comment 10

[Dão Gottwald [:dao]]

Attachment: Bug 1620536 - Move "Import from Another Browser" to the Help menu. r=Mardak

Comment 11

[Dão Gottwald [:dao]]

This has l10n impact so we'll either need to uplift with hacks or not have the menu item in 75. Do we need this in 75?

Comment 12

[Ed Lee :Mardak]

Product doesn't have a strong opinion on having it be available from app menu in 75 then having it be in the Help menu in 76. It could be interesting to observe telemetry differences among Firefox 74, 75, and 76 if all 3 have different locations.

Overall the point of making it more visible is to improve firefox growth with people easily getting their data from the browser they installed from.

Comment 13

[Serge]

How often do people switch browsers and migrate their data?
I do beleive 2-3 times max. In this case what the point in distracting/frustrationg all other users that are already with Firefox.
Previous comments clearly clearly proven why placing that item in root is a bad idea.
There are better places for it.
To be specific, if we want to introduce import feature for the newcomers in quickest way this item can be placed in "Tour guide".

Comment 14

[Dão Gottwald [:dao]]

(In reply to Ed Lee :Mardak from comment #12)

Product doesn't have a strong opinion on having it be available from app menu in 75 then having it be in the Help menu in 76. It could be interesting to observe telemetry differences among Firefox 74, 75, and 76 if all 3 have different locations.

I don't think keeping the current location in 75 is an option since it makes the menu overflow with popular hardware and default settings. Pretty sure this doesn't meet our quality standards? If we want to experiment with this, we should do that with a smaller population rather than all users.

Overall the point of making it more visible is to improve firefox growth with people easily getting their data from the browser they installed from.

I understand but this bug is about how the menu item affects the UI around it. We need to consider the implications beyond the goals of the feature itself.

Comment 15

[Mike de Boer [:mikedeboer]]

I agree with Dão here that we need to move forward on this bug and ensure that Fx75 receives the same treatment.

Comment 16

[Julien Cristau [:jcristau]]

Alright, tracking this for 75. I guess if no other solution is agreed next week we can back out bug 1618346 from beta.

Comment 17

[Dão Gottwald [:dao]]

If we end up backing out bug 1618346 from beta, should we also remove the then obsolete appmenuitem-import-from-another-browser string or leave it in place?

Comment 18

[Francesco Lodolo [:flod]]

I would back out the patch as-is, including the string.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ade0beef6b2d
Move "Import from Another Browser" to the Help menu. r=Mardak,fluent-reviewers,flod

Comment 20

[Matthew N. [:MattN]]

(In reply to Dão Gottwald [::dao] from comment #9)

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #8)

Help seems like the wrong place IMO.

I think it makes sense there for new users along with "Firefox Tour" and "What's New", which I think we should move in a followup.

I don't think it fits along side those two… those fit in Help IMO but an action to Import does not. That is normally in the File menu in a traditional menu.

Note that because we don't have bug 737804, it's not uncommon for users to repeatedly import (logins) as a form of one-way Sync. We have the telemetry data to show how common this is but there is no query analyzing that yet.

Comment 21

[Dão Gottwald [:dao]]

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #20)

(In reply to Dão Gottwald [::dao] from comment #9)

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #8)

Help seems like the wrong place IMO.

I think it makes sense there for new users along with "Firefox Tour" and "What's New", which I think we should move in a followup.

I don't think it fits along side those two… those fit in Help IMO but an action to Import does not. That is normally in the File menu in a traditional menu.

Well, it's still in the traditional File menu and I have no strong opinion on bug 1622239; we could wontfix that.

Note that because we don't have bug 737804, it's not uncommon for users to repeatedly import (logins) as a form of one-way Sync. We have the telemetry data to show how common this is but there is no query analyzing that yet.

We have a dedicated Sync panel so there's opportunity to do something there. I think it makes sense to have redundancy for different use cases.

Comment 22

[Matthew N. [:MattN]]

(In reply to Dão Gottwald [::dao] from comment #21)

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #20)

(In reply to Dão Gottwald [::dao] from comment #9)

(In reply to Matthew N. [:MattN] (PM me if request are blocking you) from comment #8)

Help seems like the wrong place IMO.

I think it makes sense there for new users along with "Firefox Tour" and "What's New", which I think we should move in a followup.

I don't think it fits along side those two… those fit in Help IMO but an action to Import does not. That is normally in the File menu in a traditional menu.

Well, it's still in the traditional File menu and I have no strong opinion on bug 1622239; we could wontfix that.

Having it in the traditional Help menu at all isn't expected IMO. The duplication just makes it worse. Can we find any other popular applications that have import in the Help menu?

Note that because we don't have bug 737804, it's not uncommon for users to repeatedly import (logins) as a form of one-way Sync. We have the telemetry data to show how common this is but there is no query analyzing that yet.

We have a dedicated Sync panel so there's opportunity to do something there. I think it makes sense to have redundancy for different use cases.

Firefox Sync has nothing to do with syncing with other browsers though… I'm not sure why we would want to start conflating the two.

Comment 23

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/ade0beef6b2d

Comment 24

[Meridel [:meridel]]

Content strategy weighing in with thoughts on the information architecture, broken into two phases.

Phase 1: Short-term solution for the issue of app menu length and location of “Import”

Recommendation:

Keep Import Settings in the first level of the hamburger/App Menu, and move it beneath “Print,” as part of the Open File/Save Page As/Print section. This is a short- term solution, and we should pursue more work in a phase 2 to determine the best location(s) to surface Import in product to meet user and business goals.

Justification:

While overall length of the app menu should to be considered, it’s really not the primary issue here: we can’t control the size of a user’s window to know how much scrolling they are in fact doing, or how much they’ll tolerate. Moreover, users are willing to scroll (one of the easiest interactions there is) and click, as long as the ‘information scent’ is high: if they think they’re on the right path to find what they’re looking for—i.e. the info is in a logical place— they’re willing to continue until they find it.

‘Information scent’ is a relatively new concept which the Nielsen Norman Group (https://www.nngroup.com/articles/ia-questions-navigation-menus/) defines as: “the extent to which users can predict what they will find if they pursue a certain path through a website.” Thus, in order to have high “information scent,” we should group “Import” settings with related content. In the context of the app menu, the most related content would be the section with “Open File,” “Save Page As,” and “Print,” because these, like “Import,” are all actions the user can take. Grouping Import Settings here in the app menu is also consistent with how we already group it near these same related items in the File menu today.

Alternate placement ideas:
-Help: I don’t think this is the right home. “Help” is typically a place for information-seeking, not task completion.
-Library: Also including it here makes sense (at least for now) because there is related content—namely, the user can import the things contained in the Library...(whether "Library" works as a label is another matter. Other browsers don't do as much nesting. In Chrome and Brave, for example, you see Bookmarks > Import...).
-Moving it to a submenu of the app menu at all: I assume adding Import to the app menu was about surfacing a feature that can drive retention more prominently so I’m inclined to keep it in the app menu’s first tier, for now, until we can address the second, larger issue described below.

An additional note on length of app menu: we are on the upper range, and certainly much longer than Chrome. For comparison, here are the number of app items for a sampling of browsers:
Firefox: 22
Brave: 22
Opera: 21 (+ a lot of other IA noise)
Edge: 15
Chrome: 14

Phase 2: How do we best position Import to meet user and business goals?

We should consider whether the app menu is the right place for Import at all. These other browsers all follow the same pattern—we are outliers, and use different nomenclature (we have “Preferences” instead of “Settings"):

Chrome:
App menu > Settings link off> Import
App menu > Bookmarks > Import
Chrome menu > Import

Edge
App menu > Settings link off > Import
App menu > Favorites > Import
Edge menu > Import

Brave
App menu > Settings link off> Import
App menu > Bookmarks > Import
Brave menu > Import

Firefox
App Menu > Import
App Menu > Library > Import
File > Import
No access point in Firefox/Browser Menu or in Preferences (our version of Settings)

We should think about whether we are surfacing Import in the right spots. We might consider:

1. Adding Import to Preferences — This would follow patterns from other browsers, and we can associate Import with related content in a logical way. For example, Import is something a new user would do in the early stages of browser usage. Following that logic, other browsers include Import in the first section of their Settings as “Getting Started” or “Google and You.”

2. Renaming ‘Preferences’ to ‘Settings’ — Do users expect to find things like Import under “Preferences,” or does “Preferences” connote customization only, and not customization + task completion?

3. Including Import in the Firefox Menu — rather than the File menu*. Thinking of mental models here, if each time you open a browser window, it is a single instance of Firefox, and you want to make a change to Firefox globally (like importing settings), you might think to do this via a global Browser control like the Browser menu.

I will add phase 2 to our UX Debt Ledger, and I think it should be considered in the User Journey’s team work to make Import settings more discoverable—for example, in the onboarding tour, it would be nice to be able to point users to an easy-to-remember place to adjust Import later on, like Preferences/Settings, as other browsers do. Adding Jim here as an FYI.

Comment 25

[Dão Gottwald [:dao]]

(In reply to Meridel from comment #24)

Justification:

While overall length of the app menu should to be considered, it’s really not the primary issue here:

I don't understand this. This is what this bug was filed on, so it's exactly the primary issue here.

we can’t control the size of a user’s window

We can't control the size of a user's window, but we know popular screen resolutions. We can and should make informed decisions based on this.

to know how much scrolling they are in fact doing, or how much they’ll tolerate. Moreover, users are willing to scroll (one of the easiest interactions there is) and click, as long as the ‘information scent’ is high: if they think they’re on the right path to find what they’re looking for—i.e. the info is in a logical place— they’re willing to continue until they find it.

I don't think this is necessarily true, it depends on what kind of UI we're dealing with. Overflowing menus isn't something that most users will be well familiar with. History and bookmarks menus in Firefox are exceptions but many average users likely won't hit these.

Alternate placement ideas:
-Help: I don’t think this is the right home. “Help” is typically a place for information-seeking, not task completion.

This doesn't seem to be true, or we've apparently been violating it for a long time, as none of these fall under information seeking: Submit Feedback..., Restart With Add-ons Disabled..., Report Deceptive Site...

2. Renaming ‘Preferences’ to ‘Settings’ — Do users expect to find things like Import under “Preferences,” or does “Preferences” connote customization only, and not customization + task completion?

This is bug 1399502 for Windows.

Comment 26

[Meridel [:meridel]]

Ultimately, we want users to find the information they're seeking. If the shortest possible menu length is our goal for this, our approach should be to assess, out of all the items, which make the most sense to be visible (on the first level) or hidden (via a submenu or overflow).

We risk confusing the user more in the future if our approach is to just hide the newest items as they are added, particularly under submenus that don't share related content.

How about we do the following?

1. Can PM or design state the maximum # of menu items we should aim for (even if it is the current number)?
2. Based on this maximum, I can recommend (in consult with PM) what the primary level 1 content should be.

Comment 27

[Julien Cristau [:jcristau]]

For 75 it sounds like backing out bug 1618346 is the most realistic short term solution (anything else is likely to involve l10n changes)?
I'll plan to do that today or tomorrow.

Comment 28

[Dão Gottwald [:dao]]

(In reply to Julien Cristau [:jcristau] from comment #27)

For 75 it sounds like backing out bug 1618346 is the most realistic short term solution (anything else is likely to involve l10n changes)?

Yeah, I think that makes sense.

Comment 29

[Ed Lee :Mardak]

(In reply to Julien Cristau [:jcristau] from comment #27)

For 75 it sounds like backing out bug 1618346 is the most realistic short term solution (anything else is likely to involve l10n changes)?

An alternative is comment 24 of moving the item below Print and/or accept the "regression" as scrolling is "one of the easiest interactions there is." Neither of those have l10n changes. A new patch will be needed for anything not just wontfixing this bug for 75.

Comment 30

[Dão Gottwald [:dao]]

(In reply to Ed Lee :Mardak from comment #29)

(In reply to Julien Cristau [:jcristau] from comment #27)

For 75 it sounds like backing out bug 1618346 is the most realistic short term solution (anything else is likely to involve l10n changes)?

accept the "regression" as scrolling is "one of the easiest interactions there is."

Scrolling is notoriously cumbersome on many Windows and Linux laptops. And as pointed out earlier I don't think users generally expect menu popups and particularly this kind of main app menu to overflow, so this violates the principle of least surprise. With modern, more subtle scrollbar styles, it's easy to miss that something is even overflowing in the first place when you don't expect it.

Comment 31

[Dão Gottwald [:dao]]

Also note that this would disproportionately affect unsavvy users who tend to have cheap hardware (e.g. low-res screens and bad trackpads).

Comment 32

[Ed Lee :Mardak]

If the concern is "unsavvy" users, UX content strategy perspective on the information architecture in comment 24 does seem to align with helping these users find useful-to-them items such as Import vs moving out some other item that "More-savvy" users would be able to find elsewhere.

Product has reiterated as in comment 12 that beta 75 should be fine with whatever engineering opinions.

How much should be reverted where then if we go down that path?

Comment 33

[Dão Gottwald [:dao]]

(In reply to Ed Lee :Mardak from comment #32)

If the concern is "unsavvy" users, UX content strategy perspective on the information architecture in comment 24 does seem to align with helping these users find useful-to-them items such as Import vs moving out some other item that "More-savvy" users would be able to find elsewhere.

Most top-level items are potentially useful to those users. Overflowing unexpectedly moves some of these items out of the view which is precisely the problem here. Meridel is on the right track in comment 26 -- we need a holistic view and not just focus on the importance of latest addition.

Comment 34

[Cristina Coroiu [:ccoroiu]]

This is perma failing on beta, https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunning%2Cpending%2Crunnable&searchStr=browser-chrome&selectedJob=294116766.

As per Comment 29, a new patch is needed for fixing this.

Comment 35

[Julien Cristau [:jcristau]]

Marking as fixed in beta by the backout.

Comment 36

[Stefan Hindli [:stefan_hindli]]

:mardak can you please take a look at these failures: https://treeherder.mozilla.org/#/jobs?repo=mozilla-beta&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&selectedJob=294384473 ?

This seems to be still permafailing.

Comment 37

[Ed Lee :Mardak]

Yup a patch needs to fix the beta test failure because the original patch shouldn't have reverted as-is as noted in comment 34.

Comment 39

[Intermittent Failures Robot]

29 failures in 873 pushes (0.033 failures/push) were associated with this bug yesterday.

Repository breakdown:

• mozilla-beta: 29

Platform breakdown:

• windows7-32-devedition: 25
• windows10-64-shippable-qr: 1
• windows10-64-shippable: 1
• windows7-32-shippable: 1
• macosx1014-64-shippable: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1620536&startday=2020-03-23&endday=2020-03-23&tree=all

Comment 40

[Intermittent Failures Robot]

29 failures in 4773 pushes (0.006 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-beta: 29

Platform breakdown:

• windows7-32-devedition: 25
• windows10-64-shippable-qr: 1
• windows10-64-shippable: 1
• windows7-32-shippable: 1
• macosx1014-64-shippable: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1620536&startday=2020-03-23&endday=2020-03-29&tree=all