jewelfox: A portrait of a foxgryphon with a beak, black fur, magenta hair, fox ears, and a neckband with a large jewel on it. (Default)
[personal profile] jewelfox
GNOME 3 introduced what I think is a really cool concept: The global application menu.



As you can see, it's clean and modern, and reminiscent of Android's menu button. It just has a ton of problems right now.
  1. It's not discoverable. It looks like a Windows XP style taskbar entry. Those only have the option to close the window or perform window functions like maximizing. And sure enough, "Quit" is the only option available in most apps which run on GNOME, or even on earlier versions of core GNOME apps.

  2. It's not complete. Core GNOME apps like Totem and Web have so many menu options that they don't all fit in the "app menu." Because of this, they use either a classic Windows-style menu bar or a "Chrome wrench" style menu button (which is now a core GTK+ widget).



  3. It's inconsistent. I'm not aware of any design document explaining when to use what, and my understanding of how it works keeps getting broken. For instance, I'm used to the app menu replacing a Windows-style menu bar, so when I saw that Totem had the latter I ended up driving myself to frustration trying to find its Preferences dialog, before clicking on the app menu and finding it there.
The only guideline I'm aware of is that in multi-window apps, the app menu is supposed to apply to all of them, while the Chrome-style menu button is supposed to be for the one window. But I only heard that second-hand.

Where and when did we explain our design decisions to GNOME users and developers? How many of them are aware?

Un-breaking the app menu

Here's my proposal for how to make it work, based on the expectations I formed while using and developing with it.
  1. Explain the app menu to users. Every modern OS has a friendly introduction which explains the most basic, non-obvious concepts. For GNOME, this could be as simple as a single-screen "Welcome to GNOME" app, which helpfully points out the Activities screen, notification bar, and app menu.

  2. The app menu has the most basic options. An app always has one, and it always has the core, global functions in it: "About," "Preferences," and "Quit."

  3. Other menus have All The Options. People who are used to them expect that a Windows-style menu bar, or a Chrome wrench style menu button, will have a complete listing of the app's functionality. If an app has either of these (and modern GNOME apps should prefer the GTK+ menu button to space-eating Windows-style menus), it will contain all of that app's options, including the ones in the app menu. This makes GNOME more accessible and less frustrating.
But why have an app menu at all, then? Because it's a better way of doing things. It's simpler for users and developers, it's much more attractive and elegant, it's easy to remember once you've been shown, and it echoes the functionality of a modern OS (Android) in much the same way that GNOME's legacy menus mimic those of a legacy OS (pre-Windows 8).

Plus, it makes the apps themselves look much cleaner and take up less room on small screens.

Ideally, the App Menu will contain all of a given app's functionality. This is the assumption new GNOME apps (like Documents) are building on, and the one certain existing apps (like Empathy) are adopting.

The App Menu is the future that we are transitioning towards. Let's make it as painless as possible for users and developers, by adopting guidelines that get rid of frustration.
From: [identity profile] adamwill.id.fedoraproject.org
Just a note on your point #2, I don't think this is correct:

"Core GNOME apps like Totem and Web have so many menu options that they don't all fit in the "app menu.""

As I understood it, the design is rather that *global* options - things that affect the app as a whole - go in the 'system menu', while *local* options - things that only affect the specific window - happen in the window. In your example, this distinction seems to be observed correctly ('New Window' is in the global menu, but 'New Tab' is in the local one...'Close' is in the local menu, 'Quit' is in the global one).

Now I'm not sure this is a great design, myself, and maybe you agree, but in case you weren't aware what the design actually was, I think that's it. :)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawlB9BQB0DCqsPVNJ7kkNBbJi3BvcUZak6w
It's about time someone pointed out the issues with the GNOME global menu. However, I don't think the way they are implemented now is a good idea. Taking stuff from existing menus and putting them in the global menu confuses users, as they expect all functionality to be in menus. Global menus should either be complete or have shortcuts to frequently used options found in the traditional menus.

Submenus

Date: 2013-01-03 02:45 pm (UTC)
From: [identity profile] davidw617 [launchpad.net]
My biggest complaint about the GNOME menus is when there are too many options. Submenus are bad for a lot of reasons discoverablity and fine motor control being two of them. I consider long lists even worse though. I still use my netbook (1024x576 resolution) a lot so long lists are especially painful for me. In both of these situations I would prefer an old style menu.

And, you are righth that consistency is important. Suppose that we get all the core GNOME apps to be consistent with the use of this menu. Is that enough? Very few people are going to be running only core GNOME apps on their system. Are other, frequently used apps going to be patched for consistency? Because honestly, for me consistency across the applications that I use is more important than consistency across the GNOME apps.

Date: 2013-01-03 06:21 pm (UTC)
From: [identity profile] pbrobinson.id.fedoraproject.org
It's also very confusing in a multi screen config. If the app isn't running on the primary screen the menu is on a different screen to the application or the window which I've found tends to confuse users

focus-follows-mouse breakage

Date: 2013-01-04 12:50 am (UTC)
From: [personal profile] ldamerow
I really hope that moving the menu to the top bar will be optional. It's not really possible to have reliable focus-follows-mouse in a desktop with a global app menu--moving the mouse to the global app menu is likely to touch and focus other windows, changing the menu before you can reach it.

Large screen usage

Date: 2013-01-04 01:54 am (UTC)
From: [personal profile] roojs
You mention that this

"it makes the apps themselves look much cleaner and take up less room on small screens."

Unfortunately, the reverse is true on large screens (3800x1024) up.. having the menu for an window on the right monitor lower bottom, appearing on the left monitor top, is extremely poor UI design. This 'feature' really should be disabled by default on dual screen systems, and needs a configurable (Even via gconf) way to enable/disable.

It's good to see the issue getting some discussion, as there is a sense sometimes that these changes are done rather quietly (eg. without a good old blog bike-shedding session...)

About us

Furry, fantasy, and fanfiction writer. Miniatures hobbyist, Mi'qote White Mage, 4E DM. Windows gamer, fangirl, and developer. Pronouns she/her, they/their.

Transfemale plurality, otherkin, fictive. Polyamorous pansexual. Proud introvert. Inari worshiper; xenotheist.

We wrote Jewelfox's Otherkin FAQ.

Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 31st, 2014 08:16 am
Powered by Dreamwidth Studios