1405382 - [photon] By default, sidebar button and sidebar are at opposite ends of the window

Status: RESOLVED WORKSFORME

(Firefox :: Toolbars and Customization, defect, P4)

Description

[Matt Brubeck (:mbrubeck)]

The new "Photon" UI in Firefox 57 adds a "Show sidebars" button to the toolbar by default.  The default location of the button is at the right end of the toolbar, while the default location for sidebars is on the left side of the window.  This causes problems for two of our usability principles [1].

* Natural Mapping: Clicking the button requires focusing attention on one part of the screen, but it has an effect on a distant region of the screen.

* Efficiency: Clicking the button to open the sidebar leaves the mouse in the wrong location for using the sidebar, with potentially a very long distance to traverse.

Both problems are especially bad in maximized windows on wide screens.  The Firefox Hardware Survey shows a growing percentage of our users' displays are at least 1920 pixels wide.

Moving the sidebar button to the left has its own problems (it doesn't really belong with the navigation buttons).  Could we move the default sidebar location to the right, instead?

[1]: http://uxmag.com/articles/quantifying-usability

Comment 1

[Brian Grinstead [:bgrins]]

(In reply to Matt Brubeck (:mbrubeck) from comment #0)
> Moving the sidebar button to the left has its own problems (it doesn't
> really belong with the navigation buttons).  Could we move the default
> sidebar location to the right, instead?

FWIW that was the original plan in Bug 1355331 but we ended up backing it out and instead providing an option to switch sides (due to complaints and it breaking Tab Center). We could reconsider changing the default now since Tab Center is retired, and there's an option to move it back

Comment 2

[:Gijs (he/him)]

Bryan/Aaron, thoughts?

I *think* this is just a default pref flip, so if we're convinced we should do it, then we could.

The major downsides I can come up with off-hand are:

- breaking habit for frequent sidebar users / keyboard users (but pref flip)
- gets occluded by the overflow/hamburger panels when those are opened
- will need significant testing to ensure we haven't dropped any balls somewhere (in terms of accidentally not relying on the pref but on the default state being on the other side today)

Comment 3

[Aaron Benson]

Brian is correct that the main concern over moving the sidebar panel to the right-hand side was that this would negatively impacted Tab Center. I also agree with Matt that placing the sidebar toolbar item on the left-hand side doesn't really work. Now that we have the ability to move the sidebar position, I'd be in favor of making the right-hand position the default.

Comment 4

[:Gijs (he/him)]

(In reply to Aaron Benson from comment #3)
> Brian is correct that the main concern over moving the sidebar panel to the
> right-hand side was that this would negatively impacted Tab Center.

I mean, it'll still negatively impact sidebar-tabs add-ons if/when/where people expect the vertical tabs to be on the left side... I'd be nervous about landing this type of change in 57 now, because we'll change the location of the tabs "from under" people, without a clear reason for the change. That is, even if this bug as filed makes sense to me, we don't provide that rationale to users so to them it'll look arbitrary ("why are my tabs now on the other side?").


> agree with Matt that placing the sidebar toolbar item on the left-hand side
> doesn't really work. Now that we have the ability to move the sidebar
> position, I'd be in favor of making the right-hand position the default.


I see a few ways forward:

- try to land this in time for 57 and hope people cope (though some of the sidebar stuff has already landed for 56 and people may be using it there, plus beta/nightly usage where we maybe care less because people should be used to this on the pre-release channels)

- land it in 58 with some kind of one-off notification hanging from the sidebar menu (short thing going "hey, the sidebar is now here by default, you can switch it back to the other side if you want"). This is significantly more work but would probably ease the transition. We can't uplift this for 57.

- land a change to make the sidebar side pref a sticky_pref in 57 beta N, and land a change to change the default in beta N + 1/2/3/whatever. This would mean existing users who get the intermediate beta would keep their sidebars in the same place, but we'd change the default.

Thoughts? Am I overthinking this? Who owns making a decision here?

Comment 5

[Brian Grinstead [:bgrins]]

(In reply to :Gijs from comment #4)
> - land a change to make the sidebar side pref a sticky_pref in 57 beta N,
> and land a change to change the default in beta N + 1/2/3/whatever. This
> would mean existing users who get the intermediate beta would keep their
> sidebars in the same place, but we'd change the default.

I don't think this would have the intended effect. AIUI the sticky_pref would only do this if:

1) we had different defaults across channels
2) a user switches from left to right and back to left after receiving beta N but before beta N+1. If it got converted to a sticky_pref in beta N and you never touched it, the change in the default would still affect you. Maybe there's a way to work around that by force-setting the pref in addition to making it sticky in a migration beta N.

Even so, if we wanted to make the change in 57 then I don't think we should do any special casing for beta, since we should match the same (if surprising) behavior that release users are about to see.

> Thoughts? Am I overthinking this? Who owns making a decision here?

Another option would be to flip the default (sidebar.position_start=false) but also special case people who have already opened the sidebar in a migration (set sidebar.position_start=true).

Comment 6

[Brian Grinstead [:bgrins]]

(In reply to :Gijs from comment #4)
> (In reply to Aaron Benson from comment #3)
> > Brian is correct that the main concern over moving the sidebar panel to the
> > right-hand side was that this would negatively impacted Tab Center.
> 
> I mean, it'll still negatively impact sidebar-tabs add-ons if/when/where
> people expect the vertical tabs to be on the left side

I agree that positioning on the right would likely be surprising for users installing a side-tab web extension

Comment 7

[bbell]

I say move the default position of sidebars, to the right side of the browser as they were intended to be during the Photon redesign (note icon). The only sidebar type that makes this not a slam dunk decision are sidebar tabs extensions, but their use is limited, and their users would have no problem picking the side they liked most. 

As for Icon placement. Reserving the left side of the toolbar for navigational elements/tools, and the right side for user content and app management was entirely intentional. 

If a user finds the current situation cumbersome, they can customize.

Comment 8

[Justin Dolske [:Dolske]]

(In reply to :Gijs from comment #4)

> - try to land this in time for 57 and hope people cope

We should not make this change in 57. Too late for such a significant change to UX.

No objection to trying this in 58/59, though I don't think there's any particular urgency here.

Comment 9

[:Gijs (he/him)]

(In reply to Brian Grinstead [:bgrins] from comment #5)
> (In reply to :Gijs from comment #4)
> > - land a change to make the sidebar side pref a sticky_pref in 57 beta N,
> > and land a change to change the default in beta N + 1/2/3/whatever. This
> > would mean existing users who get the intermediate beta would keep their
> > sidebars in the same place, but we'd change the default.
> 
> I don't think this would have the intended effect. AIUI the sticky_pref
> would only do this if:
> 
> 1) we had different defaults across channels
> 2) a user switches from left to right and back to left after receiving beta
> N but before beta N+1. If it got converted to a sticky_pref in beta N and
> you never touched it, the change in the default would still affect you.
> Maybe there's a way to work around that by force-setting the pref in
> addition to making it sticky in a migration beta N.

My understanding was that when saving prefs, any sticky prefs always get saved into the profile's prefs.js copy, irrespective of whether their state matches the default. On any given run, we always save prefs (because of telemetry and various other things that are guaranteed to write to prefs), so I thought this would work. It sounds like you're saying I'm wrong about how sticky prefs are saved. Is that right?

> > Thoughts? Am I overthinking this? Who owns making a decision here?
> 
> Another option would be to flip the default (sidebar.position_start=false)
> but also special case people who have already opened the sidebar in a
> migration (set sidebar.position_start=true).

Interesting. I guess we could determine whether the user had opened the sidebar by inspecting the XUL persistence store for a stored sidebarcommand. That sounds like it might actually be the simplest solution. I'll try to remember to come back to this after I come back from PTO (in November) if nobody beats me to it.

Comment 10

[Brian Grinstead [:bgrins]]

(In reply to :Gijs from comment #9)
> (In reply to Brian Grinstead [:bgrins] from comment #5)
> > (In reply to :Gijs from comment #4)
> > > - land a change to make the sidebar side pref a sticky_pref in 57 beta N,
> > > and land a change to change the default in beta N + 1/2/3/whatever. This
> > > would mean existing users who get the intermediate beta would keep their
> > > sidebars in the same place, but we'd change the default.
> > 
> > I don't think this would have the intended effect. AIUI the sticky_pref
> > would only do this if:
> > 
> > 1) we had different defaults across channels
> > 2) a user switches from left to right and back to left after receiving beta
> > N but before beta N+1. If it got converted to a sticky_pref in beta N and
> > you never touched it, the change in the default would still affect you.
> > Maybe there's a way to work around that by force-setting the pref in
> > addition to making it sticky in a migration beta N.
> 
> My understanding was that when saving prefs, any sticky prefs always get
> saved into the profile's prefs.js copy, irrespective of whether their state
> matches the default. On any given run, we always save prefs (because of
> telemetry and various other things that are guaranteed to write to prefs),
> so I thought this would work. It sounds like you're saying I'm wrong about
> how sticky prefs are saved. Is that right?

Yes, AIUI sticky_prefs are only written when a pref is changed. But the difference with a normal pref is that they are saved even if their changed value matches the default - at least that's how I read: https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/A_brief_guide_to_Mozilla_preferences#Sticky_Preferences.

I did a quick test to confirm:

1) In firefox.js, change: pref("extensions.logging.enabled", false) to sticky_pref("extensions.logging.enabled", false).
2) `./mach build faster && ./mach run`
3) Close the browser.
4) Change sticky_pref("extensions.logging.enabled", false) to sticky_pref("extensions.logging.enabled", true)
5) `./mach build faster && ./mach run`
6) Open about:config, extensions.logging.enabled matches the new default (true)

Where sticky_pref makes a difference is if you were to toggle extensions.logging.enabled twice in between steps 2 and 3, it will get written, even though it's false and matches the default.  This means in step 6 it won't match the new default anymore, it will still be false.

Comment 12

[Gregory Pappas [:gregp]]

Closing since the sidebar button was removed from default toolbar items in Proton