Re: [Ayatana] 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

_______________________________________________
usability mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/usability