Re: [Ayatana] why global menubar/application menu isn't such a great idea

[giff gill <giffgilll@xxxxxxxxxxx>]

I've given the whole thing some more thought and I want to share my some
observations.

About consistency:

A "forced" menubar for every application has a certain benefit, it
forces developers to some extent to use at least one element in their
application that follows a universal paradigm. But only to some extent.

I noticed that the great thing about the OS X menubar isn't that it's
always in the same place (it actually isn't, depending on how long the
application name the "File" entry starts in different places). It's that
different functions are always at exactly the same spot inside the
hierarchical menu. Take the "Preferences" arguably one of the most
accessed menu entries. In all OS X applications that have one it's at
exactly the same spot (and it has the same keyboard combination!). Now
compare that to Linux: Is it preferences, settings or options? Is it in
the Edit menu, or Tools or was it Settings? Or even: Is it Quit, Close
or Exit? The unity menubar is not going to solve this. "First party"
Unity/GNOME applications got it right but once you install additional
(especially non gtk) software it quickly becomes very inconsistent. My
point is, the menubar doesn't guarantee consistency, you need a strict
and clear HIG and the cooperation and will of the developers.

The menuless Windows applications show how it should not be done. They
follow 3 or 4 different guidelines that mostly make sense on their own
(though the Wordpad/Paint Ribbon UI really is pretty bad, especially in
regards keyboard/accessibility support and complexity vs
functionality...) Then we have applications like Opera and Firefox that
kind of copy new paradigms from MS but still manage to do their own
thing only adding to the inconsistency.

But all things considered it isn't that much of a problem, Windows 7 is
well received and was lauded for being easier to use than XP (for new
users at least) which had a pretty consistent menu based UX. In geneal
the reduced set of exposed options works in favour of usability despite
inconsistent paradigms and sometimes usability is improved because of
the inconsistency as applications can make more dynamic use of screen
estate and can choose more fitting layouts than the traditional
title+menu+tool+status-bar.

It would be nice to have a more consistent UI in a post menu-driven
interface design but I'd argue it already is better that what we had
before. (I know, Office Ribbon probably has just as many haters as fans
but when looking at IE6 vs IE9 or even Chrome it's obvious.)

OK, enough about Windows. It's a given that pretty much all graphical
applications still have and need a hierarchical text based menu. But as
we see with Chromium and Firefox they don't need a full, always visible
menubar that takes up precious vertical space or gets in the way of
Fitts's Law.

As stated previously in the discussion the main function of the menu is
to discover functions and to use it as a keyboard cheat-sheet. This
function to me implies that it does not have to be a static interface
element but is more of an integrated learning and help interface that
you will need at the start of the learning curve but later on you might
want to rely on other controls that are faster and more integrated in
the workflow.

I think one-button menus can be just as consistent and useful (I'm only
talking about the case of simpler, low denisity applications) as long as
they follow a consistent hierarchy. In Windows 7 the alt key often
brings up a menu, sometimes as a full bar that slides in, in Media
Player it's like a context menu. Both works for me, the problem really
is if they can't make up their mind what functions should be put into
what top level labels. The hidden alt key is of course no good in terms
of discoverability, something like the big Chrome and shiny Ribbon top
left "start menu" buttons however is.

Unity top panel overflow:

This is already a problem now with the application menu and the
indicator applets. I've seen screenshots of 1024 wide displays where
menus and info area overlap. This is specially a problem with languages
other than English and large applications like GIMP and if people start
adding more indicator items. (I had this problem even on a 1280 screen
in OS X which lacks this obvious feature.)

If the tabs on top model makes it into Unity this too is something we'd
need to think about. The most obvious solution would be to deflate that
area and only show the clock and little battery and wifi status icons
for example, when you click on that it expands and covers menu
entries/tabs, hitting super key/home button could expand it as well.

About the future :)

Unity today is mostly a replacement for Metacity and the GNOME panels.
It still uses GNOME system settings, its file manager and many other
tools that follow GNOME HIGs and paradigms that are decades old.

I think this is going to change, it has to change to move the Unity
concept along. I also think that the menubar will play a less important
role in the future, Chrome OS, iOS and Android (Honeycomb) are the best
proof I can offer. I'm convinced a dynamic and flexible approach to the
panel bar will win in the long run.