Closed Bug 610561 Opened 14 years ago Closed 14 years ago

Shrink the Firefox button to a single silhouette icon when tabs are at the screen edge

Categories

(Firefox :: Theme, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: faaborg, Unassigned)

References

Details

(Keywords: icon)

Attachments

(1 file)

Once bug 572160 has landed, when the window is maximized and tabs are placed at the top screen, in to conserve space in the tab strip we should collapse the Firefox button down to a single 16x16 silhouette icon.  There is no need for a down area in this state (button should be the same width as an app tab or the new tab button).

This button should also be flush with both the top and left screen edges.
Stephen: we'll need a better icon for this (my mockup is a super rough example of a Firefox silhouette)
Keywords: icon
Frank points out that the close button still draws the right edge when maximized, so I guess we should still draw the left edge of the Firefox button (even though you can target it by touching the left screen edge).
I know I'm a tad late here, but are the gains really that huge? Yes you create some extra room on the tab strip. The equivalent of around 80px. But you also lose much of click area of the menu. Data shows that the menu is widely used and netbooks make up a minority of installations. Surely we'd like to keep prominence on the Firefox button and it's usability. Even if only in the initial 4.0 release. Perhaps making it smaller on maximising should come later, once we've introduced it and users have got used to it. Or perhaps at such a time, the idea may be to only shrink the button if there's tab overflow.

Do we have any data available yet on how users are using the minefield button compared to the menu bar compared to the tab bar? This should definitely be taken into consideration. 

Power users and even netbook users that aren't power users will inevitably be able to install an extension that will shrink the button for them.
>But you also lose much of click area of the menu.

by touching the top and left screen edge click area goes goes to infinity + infinity.  In terms of discoverabily, we did make it bright orange :)
(In reply to comment #6)
> >But you also lose much of click area of the menu.
> 
> by touching the top and left screen edge click area goes goes to infinity +
> infinity.  In terms of discoverabily, we did make it bright orange :)

I must admit that I'm very weary about making the button so small, especially
for entry users who will be reliant on it for the simplest of tasks. I
absolutely see the theory behind the decision. But in all reality, how many
users bounce of the edge of the screen as opposed to aiming directly for the
middle of an object? I for example have had my  tabs at the screen-edge thanks
to a stylish script for around a week or so now and never do I go for the top
edge of the tabs, but rather the bottom? Is there any way of checking where the
button is being clicked with Test Pilot?
(In reply to comment #7)
> But in all reality, how many
> users bounce of the edge of the screen as opposed to aiming directly for the
> middle of an object?

Regardless of where they aim, users move the cursor until the button lights up. Just look at how the Start menu button behaves. You jam your mouse to the corner, and before you adjust it back to the button, you notice that the button has lit up, so you just click it.
Depends on: 610506
I agree with Paul[sabret00the] - this seems more like a desirable setting for power users. As mentioned before on the previous thread, creating a non-describable button like this will create a support nightmare, especially given that most Windows users use a maximized browser window by default.
(In reply to comment #9)
> given that most Windows users use a maximized browser window by default.

This matches my experience. If we do this, I think we need to be aware of the full button likely becoming the exception and the shrunken button becoming the norm that people would see most of the time.
Component: General → Theme
No longer depends on: 610506
QA Contact: general → theme
My concern here is the potential confusion caused by the button changing its appearance in maximised mode. I think it's the kind of inconsistent UI which might confuse novice users. Perhaps the button could shrink quite conspicuously through an animation to mitigate this?

Extending the button target to the screen edge is definitely a good idea. This is how the 'orb' button in MS Office works, in addition to the Windows controls on the other three corners of the screen.
Well I think you only need to look at the evolution of Office from 2007 to 2010 to see that graphical buttons (orbs) were a disaster for them, hence the lessons learned of the text buttons into 2010. It makes no sense to dismiss those lessons that were learned for free. After all, it was based on those lessons that we went with the implementation of the Firefox button as is.
Depends on: 572160
While I agree that the orb didn't work at all, it also didn't really have a name (other than the secret name of "the orb"), and most people didn't know that it featured the office logo (which is itself rather abstract).  So they had a lot of stuff going against them in addition to general problem of using imagery instead of language.  Anyway, the saving of space doesn't seem to be worth the cost either way, setting to wontfix.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Even though this is WONTFIX, I want to point out there is a really nice FF silhouette image, MIT licensed @ http://raphaeljs.com/icons/. Might be useful to someone :-)
The padding within the Firefox button may be reduced to gain some visual space. It should not be so wide IMO.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: