1098416 - Investigate/mitigate decrease in reload/refresh button usage since Firefox 4 redesign

Status: RESOLVED WONTFIX

(Firefox :: Theme, defect)

Description

[Matt Brubeck (:mbrubeck)]

From this thread on firefox-dev: https://mail.mozilla.org/pipermail/firefox-dev/2014-November/002375.html

> The clickable area on perhaps the most clicked button on the
> interface, the Go/Refresh/Stop button, is actually very small.

I was curious about whether this button is indeed the most clicked button on the interface, so I looked back at the 2010 and 2012 Firefox Heatmap studies:

https://heatmap.mozillalabs.com/
https://blog.mozilla.org/ux/2012/06/firefox-heatmap-study-2012-results-are-in/

71% of users in the 2010 study clicked the reload button, making it the #5 most-used main UI element.  The average number of clicks per user is higher than any other toolbar button besides "Back" and "New Tab."

40% of users in the 2012 study clicked the reload button.  Unlike the 2010 study, this was done after the reload button was moved inside the address bar by default, in Firefox 4.0.

So this data at least seems to support the claim that the size/location of the button makes users less likely to discover or use it, even though it was previously heavily used.

The UX team actually redesigned of this button as part of Australis, but the new design was not implemented in time for Firefox 29, and it's still awaiting implementation (bug 1040804).

Bug 941667 would also mitigate some of the problem, without requiring any visual design changes.

Comment 1

[:Gijs (out for now; he/him)]

"correlation != causation"

The refresh button's position is not exactly the only thing that changed between the 2010 and 2012 survey...

Comment 2

[Ben]

I have done a mockup of an alternative Refresh button design that should fully mitigate the drop-off – see new attachments on Bug 1040804.

Comment 5

[u123541]

Sorry; but I don't feel my bug 1119821(ergonomics) is a duplicate of this one or 1040804 which is only about image style.  See bug 1119821 for more...

Comment 6

[u123541]

[I've been asked to comment here]
The initial comment above claims a reduction in the use of the reload/refresh button since it was moved.  I normally have around 500 tabs open over 9-12 windows and have not noticed any reduction in my usage of that button.  Rather, I have noticed is a growing irritation at having to "seek & find" it since it's not in a logical location IMO.  Does the above study indicate any other anomalies in change of button use?  For instance, when the reload/refresh was moved, was there an increase in back+forward, or other? Depending on the pages, it can be just as convenient to hit back, then forward to do a refresh than hunt for and put extra miles on the mouse to get at this misplaced button.

Nailing the reload/refresh at the right of the URL has been the #1 aggravation for me, ahead of "tab crashed" and big spinners that don't get out of the way, even when the page HAS loaded.

Comment 7

[Matt]

I have been using this plugin to fix this bug since FF 29 launched: https://github.com/darktrojan/buttonsback

The problem is that it doesn't play nice with other plugins, so I can't use it at work (frequent browser crashes are no good). Removing customizability of the location of the reload/stop button in the Australis interface is a massive regression for UX. The heatmap data posted by Matt above sure seems to support that.

Comment 8

[Ben]

(In reply to Matt from comment #7)
> Removing customizability of the location of the reload/stop button in the Australis interface is a
> massive regression for UX.

Matt, I agree.  Note that as well as no longer being able to customize the location of the combined Go/Reload/Stop button it is also no longer possible to move Reload and Stop out of the Location bar so that they become two discrete, large, rectangular buttons which are always available to the user (ie not having to hit a combined button once to stop and again to reload).  This wasn't a very discoverable feature, as you had to reverse the order of the two buttons, but it was very handy once you knew of it.

You may like to put in an enhancement bug request to bring back these capabilities, as what's under discussion is only making the combined button larger and taking it just outside the Location Bar but still locked to the right-hand side.

Note that although some browsers have Reload on the left of their address bar Firefox has had it to the right by default for a very long time.  If you're switching a lot between browsers I can see how that would make having it to the right an ongoing issue for you - and others - and a good argument to mention if you post the bug.

Comment 9

[sworddragon2]

> You may like to put in an enhancement bug request to bring back these capabilities, as what's under
> discussion is only making the combined button larger and taking it just outside the Location Bar but
> still locked to the right-hand side.

Since #940280 is a duplicate of this I want to remember of it (as it suggests to change the position of the reload button to the left at default).

Comment 10

[Ben]

(In reply to sworddragon2 from comment #9)
> Since #940280 is a duplicate of this I want to remember of it (as it
> suggests to change the position of the reload button to the left at default).

I don't see it makes any sense to move the default position left of the Location Bar.  Reload, which has been in its present position for years, is used ad-hoc.  It is now combined with Go, and it makes perfect sense for Go to be just right of the Location Bar, in the same way it's logical for the Search button to be right of the Search Bar.

But those who want the ability to customise it should be able to, as before.  If someone wants this, they should add an enhancement bug and post the bug number here.  The ability to customise is relevant to this bug because, as already noted, the customised Reload button was a lot bigger than the current one (ie the same size as Home).  However, this bug is primarily about increasing the size of the current Go/Stop/Reload and making it clearer to users it is a clickable button.

Comment 11

[u123541]

> But those who want the ability to customise it should be able to, as before.  If someone wants this, they should add an enhancement bug and post the bug number here.

bug 1122291 2015-01-15
bug 1119821 2015-01-09 
bug 942443 2013-11-23
bug 940078 2013-11-18
https://bugzilla.mozilla.org/buglist.cgi?bug_id=940342%2C940497%2C1003069%2C1005479%2C1027796&list_id=11997803

Need more?

Somewhere in an old bug I don't recall, even suggested that the toolbars could be totally user configurable...  maybe something like another level of abstraction which uses the browser's css, script, rendering, etc. features.

Stop/reload usage can never be eliminated; the real (overarching) issue is "action button" configurability -- whether it be location, size, visibility, color, ...

Comment 12

[Ben]

Thanks.  Bug 940078 is the relevant bug, then.  I disagree that that bug constitutes a Wontfix.  Go/Stop/Reload had been built into the Location Bar for some time, and this didn't prevent customisation of Stop and Reload.  In general customisation within Firefox has *increased* recently, with the ability, for instance, to move buttons to the Menu drop-down; you can even move the whole Search Bar to the Menu!  So preventing customisation of Stop and Reload when the coding existed and the positions of these matter deeply to some users seems like a mistake.  If users are constantly switching between Firefox and another browser (perhaps at work where there's no choice of browser) where the button positions differ obviously they're never going to have an easy time getting used to Firefox's default locations.  The argument (see Bug 755598) that there's a saving in developer maintenance resources doesn't stack up, partly because of this issue of other browsers and partly because Mozilla Firefox is supposed to be 'Made with a mission to put you first' and supposedly 'Works the way you do'.

If someone feels strongly that Bug 940078 should be reopened they should contact the devs via https://wiki.mozilla.org/Firefox/firefox-dev giving a reasoned case.

Comment 14

[Matt Brubeck (:mbrubeck)]

Photon bug 1363485 essentially undid the Australis changes to the reload button, so this is no longer relevant.