Naming the Tools menu
Alex Faaborg
about the 3.7 and 4.0 UI: while the distinction of having one button
to act on the current page and one button to act on the browser as a
whole is both conceptually very pure and gives the benefits of
external consistency, we aren't entirely sure what we should name the
buttons.
One thing we are sure of is that the buttons should use language,
instead of icons. This is particularly important because it enables
users to describe chains of actions both verbally and in text. For
instance, "Page > Print." If you switch to using iconic symbols
(Safari, Chrome, Office Orb) you get into "the menu formally known as
prince" territory.
So if we look at possible command chains, I wonder if "Firefox" might
be a better name than the somewhat generic "Tools"
Tools > New Window
Tools > Private Browsing
--------------------------------
Tools > Open File
Tools > History
Tools > Recent History
Tools > Clear Recent History
--------------------------------
Tools > Menu Bar
Tools > Bookmarks Toolbar
Tools > Status Bar
Tools > Sidebar
--------------------------------
Tools > Downloads
Tools > Add-ons
--------------------------------
Tools > About
Tools > Check for Updates
--------------------------------
Tools > Options
--------------------------------
Tools > Exit
Versus:
Firefox > New Window
Firefox > Private Browsing
--------------------------------
Firefox > Open File
Firefox > History
Firefox > Recent History
Firefox > Clear Recent History
--------------------------------
Firefox > Menu Bar
Firefox > Bookmarks Toolbar
Firefox > Status Bar
Firefox > Sidebar
--------------------------------
Firefox > Downloads
Firefox > Add-ons
--------------------------------
Firefox > About
Firefox > Check for Updates
--------------------------------
Firefox > Options
--------------------------------
Firefox > Exit
Possible reasons to not do this include:
1) We lose the external consistency win of using the same terminology
from our most prominent competitor
2) Having a button named Firefox inside of an application named
Firefox feels perhaps a little too meta, or recursive, or sort of
Russian stacking doll like. Kind of hard to explain. Although to be
fair we do see this approach in other interfaces like the TiVo button,
or the Office Orb.
3) There is a localization impact in that the term Firefox doesn't
technically localize. In fact I don't think we even allow
translations into other character sets (for instance bug 397632). So
having a brand name in the UI that isn't in the correct language might
feel odd for some locals.
-other reasons?
Overall though I think that this might be the best name for the
browser level menu.
-Alex
John J Barton
> I would like to branch this specific discussion out of the mean thread
> about the 3.7 and 4.0 UI: while the distinction of having one button to
> act on the current page and one button to act on the browser as a whole
> is both conceptually very pure and gives the benefits of external
> consistency, we aren't entirely sure what we should name the buttons.
I lost the context however. Above the discussion seems to be "Two
buttons, what to call them". Below it seems to be "replace Tools with
Firefox". I guess you did not get back to the second button?
>
> One thing we are sure of is that the buttons should use language,
> instead of icons. This is particularly important because it enables
> users to describe chains of actions both verbally and in text. For
> instance, "Page > Print." If you switch to using iconic symbols
> (Safari, Chrome, Office Orb) you get into "the menu formally known as
> prince" territory.
+1 For Firebug I always have to say
"Firebug Icon Menu (upper left) > Options".
yuk.
>
> So if we look at possible command chains, I wonder if "Firefox" might be
> a better name than the somewhat generic "Tools"
...
> 2) Having a button named Firefox inside of an application named Firefox
> feels perhaps a little too meta, or recursive, or sort of Russian
> stacking doll like. Kind of hard to explain. Although to be fair we do
> see this approach in other interfaces like the TiVo button, or the
> Office Orb.
I don't think is an abstract concern, but very real. For example how do
I currently tell Firebug users to use the Firefox tools menu, eg:
Firefox > Tools > Firebug > Open In New Window
That becomes:
Firefox > Firefox > Firebug > Open In New Window
oops.
> Overall though I think that this might be the best name for the browser
> level menu.
How about "Browser" for the browser level menu ;-).
jjb
Alexander Limi
has a "Firefox" menu. Having to explain "which Firefox menu" to a Mac user
doesn't sound like a good option
The alternative is to make the Firefox menu on OS X the same as the Firefox
menu on other platforms, but live in the standard OS X location. This means
we don't have it on the toolbar. This has its own problems (should history
and bookmarks still be top-level menus on the Mac? I'd say yes.) etc.
Switchers between Windows/Mac will have to endure some differences, which
might be OK.
--
Alexander Limi · Firefox User Experience · http://limi.net
On Fri, Sep 18, 2009 at 4:39 PM, Alex Faaborg <faa...@mozilla.com> wrote:
> I would like to branch this specific discussion out of the mean thread
> about the 3.7 and 4.0 UI: while the distinction of having one button to act
> on the current page and one button to act on the browser as a whole is both
> conceptually very pure and gives the benefits of external consistency, we
> aren't entirely sure what we should name the buttons.
>
> One thing we are sure of is that the buttons should use language, instead
> of icons. This is particularly important because it enables users to
> describe chains of actions both verbally and in text. For instance, "Page >
> Print." If you switch to using iconic symbols (Safari, Chrome, Office Orb)
> you get into "the menu formally known as prince" territory.
>
> So if we look at possible command chains, I wonder if "Firefox" might be a
> better name than the somewhat generic "Tools"
>
> 2) Having a button named Firefox inside of an application named Firefox
> feels perhaps a little too meta, or recursive, or sort of Russian stacking
> doll like. Kind of hard to explain. Although to be fair we do see this
> approach in other interfaces like the TiVo button, or the Office Orb.
>
> 3) There is a localization impact in that the term Firefox doesn't
> technically localize. In fact I don't think we even allow translations into
> other character sets (for instance bug 397632). So having a brand name in
> the UI that isn't in the correct language might feel odd for some locals.
>
> -other reasons?
>
> Overall though I think that this might be the best name for the browser
> level menu.
>
> -Alex
>
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Alex Faaborg
> buttons, what to call them". Below it seems to be "replace Tools
> with Firefox". I guess you did not get back to the second button?
I can't think of anything better than Page for Page. We could maybe
go with File given the contents, but people talk about Web pages, not
Web files, etc.
> For example how do I currently tell Firebug users to use the Firefox
> tools menu, eg:
Yeah, the phrase "go to Firefox" accidently resolves to "I'm already
there, now what."
> How about "Browser" for the browser level menu ;-)
I'm worried that more people know what Firefox (or IE) is than know
what a browser is. While I know this video [1] is hardly scientific,
I feel like by analogy we are at a state where people know terms like
Toyota or Ford, but not "car." For instance, a bunch of people name
drop Firefox in the video, but are still included in the 92% that are
missing the more generic terminology.
[1] http://www.youtube.com/watch?v=o4MwTvtyrUQ&feature=player_embedded
-Alex
Alex Faaborg
> Firefox menu on other platforms, but live in the standard OS X
> location.
Things like check for updates arguably should be placed in the OS X
Firefox menu anyway, right? Also, Safari places private browsing in
the Application's menu.
The weird stuff would be moving:
New Window (traditionally File menu)
Open File (traditionally File menu)
Downloads
Addons
History stuff (separate menu)
-alex
On Sep 18, 2009, at 5:34 PM, Alexander Limi wrote:
> The one place I can see this causing confusion is on OS X, since it
> already has a "Firefox" menu. Having to explain "which Firefox menu"
> to a Mac user doesn't sound like a good option
>
> The alternative is to make the Firefox menu on OS X the same as the
> Firefox menu on other platforms, but live in the standard OS X
> location. This means we don't have it on the toolbar. This has its
> own problems (should history and bookmarks still be top-level menus
> on the Mac? I'd say yes.) etc.
>
> Switchers between Windows/Mac will have to endure some differences,
> which might be OK.
>
> --
> Alexander Limi · Firefox User Experience · http://limi.net
>
>
>
> On Fri, Sep 18, 2009 at 4:39 PM, Alex Faaborg <faa...@mozilla.com>
> wrote:
> I would like to branch this specific discussion out of the mean
> thread about the 3.7 and 4.0 UI: while the distinction of having
> one button to act on the current page and one button to act on the
> browser as a whole is both conceptually very pure and gives the
> benefits of external consistency, we aren't entirely sure what we
> should name the buttons.
>
> One thing we are sure of is that the buttons should use language,
> instead of icons. This is particularly important because it enables
> users to describe chains of actions both verbally and in text. For
> instance, "Page > Print." If you switch to using iconic symbols
> (Safari, Chrome, Office Orb) you get into "the menu formally known
> as prince" territory.
>
> So if we look at possible command chains, I wonder if "Firefox"
> might be a better name than the somewhat generic "Tools"
>
> 2) Having a button named Firefox inside of an application named
> Firefox feels perhaps a little too meta, or recursive, or sort of
> Russian stacking doll like. Kind of hard to explain. Although to
> be fair we do see this approach in other interfaces like the TiVo
> button, or the Office Orb.
>
> 3) There is a localization impact in that the term Firefox doesn't
> technically localize. In fact I don't think we even allow
> translations into other character sets (for instance bug 397632).
> So having a brand name in the UI that isn't in the correct language
> might feel odd for some locals.
>
> -other reasons?
>
> Overall though I think that this might be the best name for the
> browser level menu.
>
> -Alex
Axel Hecht
Looking at what current localizations do for "Tools",
http://mxr.mozilla.org/l10n-mozilla1.9.1/search?string=toolsMenu.label&find=browser/browser.dtd
I see a few locales that use "Extras", probably for compat reasons. Some
strings are also rather long compared to en-US "Tools".
The discussion on whether we allow transcribing Firefox or not is
tricky, but in practice, it happens. (The arabic logotype is different
as it's about the logo and mirroring that, too, IIRC).
Axel
Robert Kaiser
> The one place I can see this causing confusion is on OS X, since it already
> has a "Firefox" menu. Having to explain "which Firefox menu" to a Mac user
> doesn't sound like a good option
I don't think doing any of the changes discussed for Windows here makes
actual sense on OS X (and probably not even on Linux), esp. the hiding
of the menubar is nothing to discuss at all on OS X where the menubar is
there all the time as an OS feature in any case.
From all I see, we'll need to split ways between platforms in our main
Firefox UI, and this time for more than just icons.
Extension developers will not like that much, but if it makes things
more easily for the Firefox goal to be near to IE and integrate with
every design idea of the OS as well as in any way possible, it's the way
to go.
After all, we're not Netscape in the 90s any more that decided to stop
developing different UI for all the platforms. And, seriously, we have
the infrastructure to make things like the main window diverge while
keeping other parts at the same source code to not waste too much
developer time on OS-specific things. We can mix both ways to create the
ideal experience for novice and mass-market users everywhere.
Those advanced users who want consistency between the OSes more than
glassy looks can just try SeaMonkey after all. ;-)
Robert Kaiser
Jesper Kristensen
> The alternative is to make the Firefox menu on OS X the same as the Firefox
> menu on other platforms, but live in the standard OS X location. This means
> we don't have it on the toolbar. This has its own problems (should history
> and bookmarks still be top-level menus on the Mac? I'd say yes.) etc.
Does Mac OS users use the History menu more often than Windows users? I
am not a Mac user, so I don't know.
John J. Barton
...
>> How about "Browser" for the browser level menu ;-)
>
> I'm worried that more people know what Firefox (or IE) is than know what
> a browser is. While I know this video [1] is hardly scientific, I feel
> like by analogy we are at a state where people know terms like Toyota or
> Ford, but not "car." For instance, a bunch of people name drop Firefox
> in the video, but are still included in the 92% that are missing the
> more generic terminology.
>
> [1] http://www.youtube.com/watch?v=o4MwTvtyrUQ&feature=player_embedded
>
> -Alex
But the design guidance from that video is clear enough: eliminate both
buttons altogether because 92% of the users will never click on them. Or
perhaps the glass is half full: "ignore the 92% of users that don't
understand the details, these options target the 8% who drive adoption".
Maybe "Firefox" is ok: Firefox > Firefox-menu > New Window.
jjb
Gervase Markham
> So if we look at possible command chains, I wonder if "Firefox" might be
> a better name than the somewhat generic "Tools"
I think it's an important criteria to pick something which is easy to
describe, down a phone or in a web page.
Click the Firefox button" does have a number of possible resolutions,
including them clicking a copy of the Firefox logo, if one is present -
such as the one at the left end of the title bar (at least on my Linux
machine).
But I agree "Tools" is horrible. The "Tools" menu in e.g. the Mozilla
Suite was where you dumped things which didn't fit into any other menu.
Of the suggestions so far, I'd reluctantly pick "Browser" as fitting
best as a prefix of the menu items in that menu.
Gerv
Barry van Oudtshoorn
Actions->Print, Actions->Save, Actions->Quit and so on seem to parse
quite well.
Of course, it'd make sense to then 'verb' some of the menu entries --
for example, make "New window" into "Open new window", and "History"
into "View history".
Justin Dolske
> Of the suggestions so far, I'd reluctantly pick "Browser" as fitting
> best as a prefix of the menu items in that menu.
"Click the Browser button."
"Which one? Back?"
I think using this as a requirement for the button label is going to
fail no matter what's used.
Justin
Alexander Limi
;)
--
Alexander Limi · Firefox User Experience · http://limi.net
Martijn
> I would like to branch this specific discussion out of the mean thread about
> the 3.7 and 4.0 UI: while the distinction of having one button to act on
> the current page and one button to act on the browser as a whole is both
> conceptually very pure and gives the benefits of external consistency, we
> aren't entirely sure what we should name the buttons.
>
> icons. This is particularly important because it enables users to describe
> chains of actions both verbally and in text. For instance, "Page > Print."
> If you switch to using iconic symbols (Safari, Chrome, Office Orb) you get
> into "the menu formally known as prince" territory.
>
> better name than the somewhat generic "Tools"
>
> feels perhaps a little too meta, or recursive, or sort of Russian stacking
> doll like. Kind of hard to explain. Although to be fair we do see this
> approach in other interfaces like the TiVo button, or the Office Orb.
>
> technically localize. In fact I don't think we even allow translations into
> other character sets (for instance bug 397632). So having a brand name in
> the UI that isn't in the correct language might feel odd for some locals.
>
>
> Overall though I think that this might be the best name for the browser
> level menu.
In Internet Explorer this is called the "Extra" menu.
So I guess if you want to change the name, you should change it into that name.
But for the rest, I fail to see why you would want to change the name
at all. I think it would only confuse people, who are already using
Firefox.
Regards,
Martijn
> -Alex
>
>
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Gervase Markham
> How about naming it "Bikeshed"? Unique, catchy…
> ;)
Except that this isn't a bikeshed discussion, because what we call the
button is actually important. :-)
Gerv
David McRitchie
This whole restructuring is a big disservice.
Most of the items in my Tools menu come from extensions, and by combining
menus you make the problem much worse. Extensions also put items into
the other menus as well. The shaded two menu items take up one third
the space of my 8 menu items, which is only a small part of the menu bar.
I use "Menu Editor" to put items into logical order so by making very large
tools menu filled up with only Firefox stuff that is a disservice. Many
extensions specifically enhance items already in the tools menu by adding addition
related items.
Most of my menu bar has the expandable search bar, and
then I have additional extension related icons at the far right. My entire
toolbars take up two millimeters more space than your suggested layout
and I'm not hiding any toolbars. Modify the title bar, so it is like what
is seen in full screen mode (Windows Vista) and you could regain the 2mm
and have an extensive useable toolbars compared to suggested overall layout.
I have about 10 extension related toolbar buttons (most not shown in picture).
Picture of toolbars before and after, the menus have actually been
compressed horizontally since the picture was created.
http://userstyles.org/styles/9350
Furthermore I can put 60, 120, 240 items in the tabs bar and have
scrolling disabled, but can still identify icons and at least match an
icon to the drop down tabs list.
--
HTH,
David McRitchie, extensions I use are briefly documented on my site
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
David McRitchie
> be a better name than the somewhat generic "Tools"
Messing up the separation of functions to create several levels
to get to something destroys the whole purpose of having toolbars
and menus. You should keep with the old naming it was logically
created based on what other applications (not just browsers) use,
to it is logical and intuitive to someone with prior experience with
other applications.
As far as I can tell there is no logic to these changes, it is change for
the sake of change, or change to what IE has. Copying what IE has
at this point makes no sense whatsoever. Microsoft has destroyed
Microsoft Office with it's Office Ribbon and you want to copy that kind of garbage.
Making up a new hierarchy for menus and basically calling the "Tools"
menu item "Firefox" is the most illogical thing imaginable. So what
is Sea Monkey supposed to show, or Minefield, etc. That is not a
generic application type of menu name that would be cross application.
From the perspective of space all names should be short on the toolbars
themselves -- "Tools" is shorter than "Firefox". I do not want to see the other
menus rolled up into another menu item.
Robert Kaiser
> So what
> is Sea Monkey supposed to show, or Minefield, etc.
SeaMonkey will not go with this restructuring for now and has its own UI
in any case, so it can do what it wants, no matter what Firefox does.
The interesting point you bring up though is our changing brand names
for unofficial builds, a button that changes from "Minefield" to
"Kalkalpen" (or whatever the "Namoroka"-type code name will be for that
branch) to "Firefox" seems strange for a user. And names like "Gran
Paradiso" like we had in the past make UI significantly different due to
their length.
Robert Kaiser
Alex Faaborg
> names for unofficial builds, a button that changes from "Minefield"
> to "Kalkalpen" (or whatever the "Namoroka"-type code name will be
> for that branch) to "Firefox" seems strange for a user. And names
> like "Gran Paradiso" like we had in the past make UI significantly
> different due to their length.
I agree this is a problem, but we probably shouldn't let our codenames
take precendance over the design we think makes the most sense
(assuming "Firefox menu" has more advantages than disadvantages).
After all we can go for shorter codenames :)
For unbranded builds I would imagine we would just call the menu
Browser.
-Alex
Alex Faaborg
is that if we have tabs on top, the "Firefox menu" might be the only
place the term "Firefox" appears in the UI with a structure that
removes the app name and page title from the title bar. (similarly
you could look at this menu to know if you are running Kalkalpen or
Nahanni).
We aren't making a decision on the Firefox 4 UI for quiet awhile, but
still useful to think ahead.
-Alex
On Sep 22, 2009, at 10:35 AM, Robert Kaiser <ka...@kairo.at> wrote:
David Regev
> I would like to branch this specific discussion out of the mean thread
> about the 3.7 and 4.0 UI: while the distinction of having one button to act
> on the current page and one button to act on the browser as a whole is both
> conceptually very pure and gives the benefits of external consistency, we
> aren't entirely sure what we should name the buttons.
>
> One thing we are sure of is that the buttons should use language, instead
> of icons. This is particularly important because it enables users to
> describe chains of actions both verbally and in text. For instance, "Page >
> Print." If you switch to using iconic symbols (Safari, Chrome, Office Orb)
> you get into "the menu formally known as prince" territory.
>
Although I agree that this is a good goal, I have to wonder: is
troubleshooting over the phone or using only plain text the best use case
upon which the interface should be based? I can think of several reasons not
to do this:
1. The interface should be designed such that, ideally, you will not
often have to describe how to find a certain command. Moreover, once
Ubiquity/Taskfox is ubiquitous, describing how to enter these commands
should be trivial.
2. Having a separate Tools/whatever button produces redundancy. You have
one object representing the browser (the Firefox window icon) and one
separate object representing commands that act on the browser. Not only is
this conceptually inconsistent, but it also uses a significant amount of
space—space that many applications can use.
3. All platforms have or will soon have standardized application-level
menus. This includes OS X, Windows 7, and, in the near future, GNOME 3[1].
Instead of creating a fourth way, would it not be preferable to place the
application-level menu consistently with wherever it’s placed on each
platform?
That said, there is nothing wrong with having a Windows-7–style
application-level menu that is also labelled by default. (A parallel
argument could be made against having both an identity button and a Page
button.)
[1] Page 7 in
http://www.gnome.org/~mccann/shell/design/GNOME_Shell-20090705.pdf
David McRitchie
> take precendance over the design we think makes the most sense
> (assuming "Firefox menu" has more advantages than disadvantages).
> After all we can go for shorter codenames :)
The fact that one of the new menu buttons would be named "Firefox"
or other branding, is the very least of my points. So I have put the
3.7 mock-up, which just like IE8 hides the menu absolutely confusing
users, and compared it to continuation of the much more practical current
Firefox menus and toolbars. See ...
Toolbars -- http://www.mvps.org/dmcritchie/firefox/toolbars.htm
Extensions add a lot of items to menus, and/or toolbar buttons,
so you are absolutely correct that it is necessary to manage the menus.
But there is a big difference between a user managing menus with something
like "Menu Editor" and grabbing the carpet out from under everyone who
happens to use Vista by hiding the menus, and adding newly minted cruft.
that takes up valuable space with practically nothing in return.
When you want more space for material on a web page, there is full screen
view, especially if you have "AutoHide" extension and/or various extensions
and styles that hide toolbars and status bar until you move cursor up through
them. Since I don't like things moving around, I generally don't use the things
that move around depending on the cursor, but as styles they are easy to turn
on and off (At least if one sticks to Stylish 0.5.9, rather than upgrading to 1.*.*).