[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ayatana] Understanding the menu problem.
On Fri, May 27, 2011 at 2:45 PM, Jo-Erlend Schinstad
<joerlend.schinstad@xxxxxxxxx> wrote:
> When a window is maximized, the menu and window buttons are moved
> to the top panel and the window title shares space with the window menu,
> displaying the menu when you hover and the title when you don't.
> I don' think I've read any arguments against this. Are there any?
Basically yes. With the one exception that some apps maximized might
benefit from a different layout (e.g. tabs on top).
The second idea was to make the app and window title and the menu
always visible side by side (see OS X or some mockups posted here).
> Pros:
> * Having a menu next to the screen edge makes it easier to hit with the
> mouse according to Fitts' Law.
This only applies to a menu that is visible all the times.
> * Hiding the menu when you're not using it, makes the desktop feel less
> cluttered and technical.
this applies less if the menu is visible all the times...
> * When the menu is always located at the same place, it's easier for
> users to find it.
Usability testing has shown repeatedly that this is not the case, at
least not if the menu is hidden. Even then, this directly conflicts
with your con point 4 below.
> Cons:
> * Having a hidden global menu for a window that is not maximized,
> makes it difficult to find, specially for new users.
see above, a better con would be that the menu is confusing to some
users (it changes if you click on the desktop for example) and the
ugly maximized window behind windowed window case.
> * If the window is far away from the top panel, then you have to make
> a long mouse-journey to get to the menu.
This is not a given. We've analyzed this theoretically based on
Fitts's Law but only came to the conclusion that we needed to test
this. It's very much possible that even on a 30" the global menu is
faster to access under a few conditions: the user is able and willing
to quickly accelerate the mouse (laziness and inertia as I called it),
he doesn't constantly switch between a few applications, he doesn't
after executing a command from the menu immediately have to click on a
small target within the window and finally: he actually uses the menu
at all and not just keyboard shortcuts and in-window buttons in which
case he'd benefit more from having controls he actually accesses at
the screen edge. IMO this kind of makes the whole speed argument moot
and leaves clutter and screen estate savings for tiled windows as the
only pros. The first is problematic because it only hides complexity
not solve the actual problem, the second is not a very common user
case...
> * If you use "focus follows pointer", then you can focus a different
> window
> on your way to the menu, changing the menu before you get there.
This can be ignored, it's a corner case that doesn't apply to the
general user base. We should first focus on making the interface work
right in its default configuration.
> * The global menu itself creates a mental disconnection between the
> window and its menu, whether its hidden or not.
For example on a busy desktop with many open apps you first need to
leave the window, search through the menu and then search for the
window.
> Have I missed something, or is that pretty much it?
Yes, multi-tasking, tabs on top and the problem of useless fall back
menus that are just there for the sake of "consistency".
> Next. What is the main reason for wanting the global menu in the first
> place? Is it to conserve screen space and remove clutter, or is is it more
> about Fitts' Law and similar considerations?
The former, Fitts's Law does not apply to hidden targets and in modern
apps menus aren't very frequently accessed to warrant this special
position.
> What exactly are the current plans?
Good question.
Thanks for the post, it forced me to recap everything and serves as a
good summary which was badly needed. Hope I haven't left out anything
important.