Closed Bug 1040804 Opened 10 years ago Closed 7 years ago

Implement the new Australis styling for the refresh/stop/go buttons

Categories

(Firefox :: Theme, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mmaslaney, Unassigned)

References

Details

(Whiteboard: [Australis])

Attachments

(9 files, 1 obsolete file)

No description provided.
Blocks: 1098416
Attached image FxRefresh2.png
This is a mock-up of a possible alternative approach to the button for Australis. Apologies if this goes against any protocols or etiquette! The idea here is to have a bigger button to make life easier for people using a mouse, touchpad or touchscreen, given that Heatmap data indicates it is frequently used. Re Bug 1098416 it would also make Refresh more discoverable, as the icon is larger and a darker gray. Mouseover color would be blue, as currently. The Go button would be dark gray going green; the Stop button would be dark gray going red. This retains the concept of not wanting to overly draw the eye. (And some webpages cycle between a rest state and refreshing quite a bit, which, for the previous attachment, would mean a red box appearing and disappearing regularly.) The ExtremeTech article on Australis calls it "as curvy as a curvy thing", so this treatment also seems compatible with that.
I like the design. Perhaps someone from UX can have a look?
Attached image FxButtons.png (obsolete) —
These are mockups of the button functioning as Go, Refresh and Stop. Each one shows the inactive state (ie not being interacted with) and the mouseover state. The Go symbol becomes a tick. This is to avoid having arrows on each end of the bar, making the right one look a bit like Forward. With a cross for Stop, a tick for Go also hopefully makes more sense, and the two symbols are well understood internationally. For new users it should be more intuitive. For existing users it is still green, in the same place, and accompanied by mouseover hint text. Go is only visible at the stage the user is preparing the address (or in a blank tab), so making the ‘inactive’ symbol dark green doesn't interfere with the aim of having a non-distracting neutral interface. The idea here is that at the point the URL is being worked on we want to point out to the user they can click on or touch Go. (The 2012 Heatmap data indicated only 18% of users clicking Go at all.) (NB. I misinterpreted the July 2014 attachments before - Stop during a page refresh would presumably be a gray X on an unbounded white background.)
Attached image FxButtons2.png
It occurred to me we don't need to be restrained to three states - inactive, mouseover, active (ie during the click) - for the Go button. There can also be a disabled state for when there is no text in the Location Bar. This is in pale gray in this replacement mockup, to match the disabled state of the Back button. As with other disabled buttons this helps the user by not distracting them with a button that doesn't do anything. In most instances (using a bookmark, Paste & Go, etc.) the user will go from seeing a pale gray tick to a brief red X to a dark gray refresh symbol; color is only used sparingly, and despite the button being larger it is unobtrusive. The Go/Refresh/Stop mouseover buttons are all now dark gray to match the others during mouseover. The Refresh graphic is now dark gray during mouseover instead of blue to be more in keeping with the July 2014 designs. NB. The green of the tick graphic is intended to look the same shade during states 2 and 3, but actually this is an optical illusion because the darker background is making the paler green look darker. Re disabling Go if the bar's empty, this needn't be a block to implementing the new design - could always start with a dark gray tick for the inactive Go button and deal with disabling the button later.
Attachment #8523531 - Attachment is obsolete: true
Correction: The user would go from seeing a pale gray tick to a brief DARK GRAY X to a dark gray refresh symbol (because the red is only for the mouseover state).
Attached image FxStates.png
An additional mockup to show the alternative button design in the four different states during typical use of the Location Bar to go to a page. It is intended to help visualize how the change to and from a dark green tick would help make all of the button's features more discoverable.
Thanks for these Ben. I'm going to needinfo some folks on our UX team for feedback.
Flags: needinfo?(sfranks)
Flags: needinfo?(philipp)
I'm not sure it needs to be as big a button as the back one. I feel like it will make the entire bar feel a little unbalanced. I'd like to see a smaller circle version, just to see how it looks. I do like the colouring though, and agree that we don't want to overly draw the eye (which this accomplishes).
Flags: needinfo?(sfranks)
Attached image FxButtonSizes.png
Here is a mockup with the size reduced. (Also previous version for comparison.) Yes, I think it may work better at the new size. This *does* reduce the clickable area, but the trick of extending that beyond the button as with Home, etc, could be used to counter that.
Attached image FxRoundButtons.png
This mockup shows the smaller round button used for both Reload and Search. This adds consistency. It removes the constant dark blue of the magnifier logo on an otherwise monochrome button bar, retains good discoverability and increases its clickable area. (It would simply change to a darker gray background like the other buttons on mouseover, with probably no benefit having a disabled state.) A larger gap is added between Location Bar and Search Bar. As well as helping visually this aids touch operation of Reload and the search engine selector. The down-arrow of the Location Bar is moved left for the same reason. The corners of the Search Bar are slightly blunted to be more in keeping with the curves.
Back over to sevaan
Flags: needinfo?(sfranks)
That looks awesome, Ben! Passing this to Shorlander for his thoughts.
Flags: needinfo?(sfranks) → needinfo?(shorlander)
While the round button in itself looks good, it introduces quite a lot of additional visual noise into the toolbar. Especially when the window is smaller and all those round buttons are closer together, it gets very busy. We should stick with the inline button and just increase the clickable area and add a hover effect (see Michaels mockups).
Flags: needinfo?(philipp)
Philipp, the background to this approach is that the inline button is small and doesn’t seem to have good discoverability, see the firefox-dev discussion here: https://mail.mozilla.org/pipermail/firefox-dev/2014-November/002375.html The Heatmap data from 2010 (pre change to the inline button) showed that it was the second most used Toolbar button by user percentage at 71% (and higher for Intermediate and Advanced users). By 2012 Heatmap data indicated use had dropped off to 40-45%, indicating a likely discoverability and/or useability issue caused by the new design. Note that the two latest mockups use a smaller button that extends only slightly above/below the Location Bar. I have not updated the one that shows the different button states but can do so if this would help. If you’re saying Go/Reload/Stop and Search would be more noticeable surely that’s a good thing? Also, if they are recognised by users as buttons it seems more likely users will try right-clicking (like with Back) and discover the context menu features being added by Bug 1104144 (that you were just commenting on); also possible additional items down the line, ie relating to the Location Bar’s search function. The other thing is that now Forward is hidden by default Back is kinda on its own as a round button. To me at least, the addition of two more (smaller) round buttons helps with the whole look of the Toolbar (see attachment 8532552 [details]). As for increasing the clickable area of the inline button that would certainly help but horizontally the two drop-downs being so close is limiting, and makes using Reload via touchscreen problematic.
Agree with Philipp in comment 15.
Flags: needinfo?(shorlander)
Well Bug 1098416 is a block to going ahead with this, and I don't see how a design that looks exactly the same as the old one until you mouseover does any mitigating of that issue at all. It was a problem created by design choices and it requires a design solution - if not the one I've put forward then another that aids discoverability and usage.
Attached image FxRectButtons.png
This is an alternate version with rectangular Go/Reload/Stop and Search buttons. It retains the main advantages of the round button approach - better discoverability, larger clickable area, more intuitive, more likely to be explored via right-clicking - but without extending buttons above/below the bars. Visually, the buttons are in keeping with the rectangular Forward button. Mouseover states would all have a darker gray background like the other Toolbar buttons. Stop would have a red cross, go a green tick and the rest would be dark gray on mouseover. It should fully mitigate Bug 1098416.
I like that approach much better than both the current implementation and your previous ‘circle’ treatment. I wonder what it would look like with right edge of the button rounded as if it was a clipped section of your original circle?
NB. The tick and cross logos should be a big smaller - forgot to scale them down from earlier ver! (In reply to Robin Whittleton from comment #20) > I like that approach much better than both the current implementation and > your previous ‘circle’ treatment. I wonder what it would look like with > right edge of the button rounded as if it was a clipped section of your > original circle? Button curves seem controversial (which is ironic given that Australis is all about the curves). Also, that would mean a semicircle next to the straight edge of the Search Bar. I think slightly blunting the 6 outer bar corners would probably work. (If that happened it would be nice for the mouseover rectangles of Home, etc, to also be blunted; again seems more in keeping with Australis, and it's surprising how much difference very subtle changes can make to the feel of a UI.)
Obsoleted by bug photon-visual, in particular bug 1363485.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: