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

Matthew Paul Thomas <[email protected]>
Newsgroups gmane.comp.gnome.usability
Organization Canonical Ltd
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Peters wrote on 30/07/10 21:05:
>...
> GNOME 3 comes out next year. With it comes many new technologies
> including the Application Menu, a message tray for non-system
> applications, and GTK+ 3. The GNOME Shell design page
> <http://live.gnome.org/GnomeShell/Design> has an interesting page on
> the Application Menu (aka AppMenu)
> <http://live.gnome.org/GnomeShell/Design/Whiteboards/AppMenu>, a
> feature coming in GNOME Shell.

I think an application menu like that might have made sense in the
1980s, or even when it appeared in Mac OS X in 2000, but today it would
be an incoherent waste of space.

What sense does it make to have a menu that's labelled "Calculator" when
doing a calculation, "Banshee" when you're playing music, and "Empathy"
when you're chatting with friends -- but "Firefox" when you're writing
e-mail, "Firefox" when you're buying books, "Firefox" when you're
reading the news, "Firefox" when you're playing Farmville, "Firefox"
when you're posting on a Web forum, and "Firefox" when you're watching
Hulu? Not much sense at all.

>                        The menus that Chrome and Firefox and Opera and
> every other application with menus are often relevant to two different
> things at once: the window and the application.

In our user testing of Rhythmbox (results to be published real soon
now), one consistent result was that no-one understood the distinction
between "Close" and "Quit". In other words, they didn't distinguish
between the window and the application.

>                                                 The difference between
> the two is that there are some options, such as Open File, Print, or
> the View menu that only affect the current window, and some options
> such as Preferences, options for Add-Ons,

Preferences and add-ons are the strongest case for a menu that applies
to the application in general.

>                                           Bookmarks, (maybe) History,

Both of those are window-specific. (Modern Web browsers show a global
history in any "History" menu, but actually choosing any of the items
affects only the current window.)

> Help, Check for Updates, and About, that affect the entire program,
> meaning every open window.

"About" is a fair example. But "Help" should be context-sensitive
whenever possible -- showing help relevant to the window you choose it
from. And "Check For Updates" is, in Ubuntu and other Gnome-based OSes,
the job of the OS rather than the application.

>...
> tl;dr The GNOME Shell Application Menu is what should be utilized
> instead of mimicking Windows for the sake of being "shiny" or
> "familiar". Remember, you can't innovate and try to be completely
> familiar at the same time.
>...

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.

- -- 
Matthew Paul Thomas
http://mpt.net.nz/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxb70sACgkQ6PUxNfU6ecq3RwCdFXplkgW3X4e+6nOtKvY6w7rn
MN8AoJTEEVZtzCpgj5PrZ5iH/5Pyyi+C
=kQ5N
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.