[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] [Usability] The Future of Window Borders, Menu Bars, and More

On 08/07/2010 08:46 AM, Matthew Paul Thomas wrote:
...

Or to put it another way: The Gnome Shell application menu mimicks the
Mac OS X application menu almost exactly. It may seem "shiny" or
"familiar" to those designers who use a Mac, but it is obsolete today
and ignores the historical context that led Apple to introduce it in
the first place.

Have you even /looked/ at the page detailing the menu
<http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu>,

Yes, that's why I'm writing.


                                                               or even
/tried/ the work-in-progress menu? It doesn't mimic the menu. In fact
there are /several/ differences. Mainly, Mac's menu bar has every
single menu bar option, while GNOME's only has those relevant to the
application

That's not relevant. We were discussing the app menu, not the menu bar
as a whole.
Sorry, got confused for a minute.
            to reduce confusion among new users and making the desktop
seem more integrated and organized.

Those are new claims that you're making without evidence.


                                    Therefore, it isn't "familiar" to
Mac developers because it works in a totally different way (drop-down
instead of immediately accessible, yet taking up less space).

They are both pull-down menus, taking up almost exactly the same amount
of space. The biggest difference is that the Gnome version uses the
application icon (in quite a stylish way), while the Mac version does not.


                                                              It
doesn't ignore any historical context; the page detailing the menu as
well as the design document are very, very detailed and instead of
directly moving forward, they're simply taking a step back, looking at
what they have, and how they can improve it for everybody. That's not
just people who are used to GNOME, or people used to other OSs, or
people without visual or mental problems, or "power users", but
everybody they can. You'd be amazed at the level of detail they're
approaching this project with and the questions they ask while doing
so.
...

These are examples of what I meant by giving historical context for a
design:
<http://design.canonical.com/2010/04/notification-area/>
<http://design.canonical.com/2010/05/menu-bar/>

In contrast,
<http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu> (and the
equivalent section of
<http://people.gnome.org/~mccann/shell/design/GNOME_Shell-20091114.pdf>)
doesn't even mention the Mac application menu, let alone Nextstep or the
Microsoft Office button. Of course, the Gnome Shell designers are under
no obligation to explain the similarities and differences, but I think
if they did, it would substantially improve their designs.
GNOME does take it into context, but they see the global menu bar that Mac uses as a bad thing. The reasoning behind them using an application menu, from what I can gather, is that if they used the entire global menu bar system that Mac uses, it would take too long to open menus. To open a menu for one window or for one application, you'd first have to select it and then move your mouse all the way to the top of the screen. While this reduces aiming slightly, it takes longer to do, thus the GNOME design team (if I remember correctly) hates it. They do, however, see value in the application menu portion. Here's two usage examples:

1) A user uses an instant messenger, such as Pidgin. The instant messenger has a different menu bar on the conversation window compared to the buddy list. The options on the conversation window only affect the currently active conversation, while the menu bar on the "buddy list" has options that affect both the window and the application as a whole. If you only have the conversation window open, or the buddy list window is on another workspace or minimized, you can still access "entire-application options" from the conversation window by using the Application Menu. Things such as smiley settings, preferences, plugins, enabling or disabling accounts, or the help function could be moved to the application menu.

2) After clicking a "malto:" link in your web browser, a composer window for your email program opens. The menu bar for your composer window compared to the main window is different, but the main window isn't open. The Application Menu would still allow for you to open your preferences, account information, add-on settings, and so on. The rest of the menu bar items will stay there.

3) Suppose that somebody opens a program in Wine. Windows applications natively don't support the Application Menu, so the Application Menu could instead be populated with Wine-related options such as a shortcut to open "winecfg".

So GNOME Shell's application menu has the following benefits, as I have pointed out earlier:
  • Options that affect the entire application will always be in the same place, so you don't have to dig through every menu bar option to know where they are (and applications are very inconsistent at this).
  • It easily allows you to see which application you currently have focused.
  • It allows you to close all windows belonging to the application quickly and easily.
  • It's always in one place for consistency, so familiar users can use the system without needing to re-learn the way it functions or where things are located.
  • It allows access to entire-application-related functions from any window belonging to the application, no matter where the other windows are.
The Application Menu, I argue, is less confusing and more functional than what we have for these reasons.

Back on topic, should there be a "Firefox Button" on Linux? Absolutely not:
  • It's inconsistent with other GNOME programs.
  • It's inconsistent with the GNOME Human Interface Guidelines.
  • The window border is customizable and buttons can go on both sides, in any order. There is no definite place for the button to go, making it inconsistent once again.
  • It would require users to learn an application-specific behavior that does not apply to any other GNOME application, which is again inconsistent.
  • Firefox's developers have said themselves that Firefox should try its best to blend in to the operating system it's compiled for. On Windows, this button is consistent with Windows' (rather odd) functionality set and guidelines. On Mac, it uses its menu bar and looks like a native Mac application. On Linux, it blends in with GNOME by taking colors and style from GTK; adding the Firefox Button to the GNOME builds would only make it even more inconsistent with GNOME.
The only positive thing about the Firefox Button is that it saves a lot of vertical space. As an option, the Firefox Button might work, but only for the users that explicitly enable it. By default, being consistent with GNOME, using the standard menu bar and Application Menu of GNOME Shell when it detects it is the best solution, from my point of view.

    - Ryan Peters