unity-design team mailing list archive

[Ed Lin <edlin280@xxxxxxxxx>]

On Thu, May 19, 2011 at 10:03 AM, Ralph Green <sirable@xxxxxxxxx> wrote:
>  2. MPT seems to think the global menu is quicker, even on large
> screens.   That is certainly not my experience.  ... The
> question is how typical am I?
>  3. Why do people keep referring to Fitt's law.  It does not apply to
> 2 dimensions, as best as I can tell.  Shouldn't the discussion be
> about steering law?
> Ralph

Fitts's Law is the best measurement we've got for the concrete
problem. For what it describes it is absolutely accurate and helpful.
However it's only part of the equation and sometimes this is
forgotten.

A button on the screen edge is faster to access than a button anywhere
else on the screen, except directly beneath the mouse pointer. This
applies universally to everyone who knows how to use a mouse and uses
proper acceleration. If it doesn't for you, "you are doing it wrong",
the testing or the mousing ;)
The "Law" does not take into account following issues that all apply
to the Unity menubar in particular:

1) The target has to be visible before you start moving the mouse,
otherwise the advantage is lost or it's even slower than an
alternative. By implementing the menu the way it was released in Natty
the Unity design team lost any right to invoke speed as an argument!

2) The menu is "context sensitive", you need to be in the correct
application, sometimes even window (e.g. GIMP), one simple click in
GNOME 2 can now mean 2 clicks and a lot of mouse traveling.

3) On really large monitors (~26" and up) the menu can appear outside
your field of vision. In this case Fitts's Law still applies to
corners which you can hit without looking but for other targets on the
screen edge the advantage diminishes compared to targets within your
field of vision that aren't on a screen edge.

4) Already mentioned: What about "traveling" back? The content you are
working on is not on a screen edge. Together with point 3) imagine
this: A large monitor, many windows tiled and overlapping, you move
your eyes away from the window you are working it, go into the menu,
now you are looking for the entry, you might not even know what
exactly it's called. This distracts you, you loose focus of what you
were doing previously. Now, having found the desired entry you wonder
where your window is... This may take a split second or much longer
depending on how computer "literate" someone is. In any case it adds
to the mentioned factors.

That's only the speed of access aspect. Besides that we have to deal
with a lot more factors like discoverability and predictability. The
fact that the menu is hidden by default and status dependent means
here it's worse than what we had before. The behavior is confusing to
many users (based on my own OS X menubar usability testing, in Unity
it can only be worse).

All reasons why the current implementation of the Unity application
menu needs to be ditched -by default (at least on desktops). Here are
some of the arguments that came up in favor of it:

It saves screen estate.
A: No, it doesn't. In maximized state there is no reason an
application needs a title bar and a menubar, but you don't need a
global menu for that! Take Chrome: It has two bars: tab and location
bar, Unity in fact adds a third which is useless and wastes space. For
apps that don't have such feature there is no reason the current Unity
 implementation couldn't be adapted but of course only for maximized
windows.

This leaves windows stacked on top of each other, a global menu would
save on bar per additional window. How often do you do that on small
wide-screens (on large screens it doesn't really matter anyway)?

It's more consistent.
A: Or how to call forcing developers/apps to make use of a 30 year of
paradigm a feature...
Admittedly, it's the best argument I heard, in fact the only I could
take seriously.

A consistent menu layout is desirable. Same functions in different
applications should be in the same place. But you can do that with
per-window menus as well. You can't force devs to write consistent and
logical interfaces anyway. Not all applications need a menu. You know,
the best interface is one that doesn't exist. The next best thing is
an interface a user doesn't even notice it exists. Whatever, let's
slap on a menubar for good measures with a set of useless "fallback"
entries so Unity doesn't look "stupid".

For many complex applications a menu is a great solution, there are
alternatives as well to look into (like a more search/command driven
interface à la OS X menu search). For other applications the menu is
often misused for feature creep or as an excuse to write a good
interface that helps you get things done quickly instead of having to
go through pedestrian nested menus. The static menubar/panel on top
prevents devs from making more innovative use of that space (Chrome
being the the most cited example). Ultimately it can be interpreted as
a clutching to antiquated traditions that prevent and deny progress in
the user experience.

There can be more said about it and there's been written a lot on the
list already. There's nothing really new to see here and I'm repeating
myself as well. The thing is, we are going in circles. I don't see how
any progress in this matter can be achieved. Could we get a somewhat
official word back as in "Yes we consider these changes for Oneiric"
or "definitely no". Or should we take it to launchpad?