unity-design team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luke Benstead wrote on 17/03/11 13:56:
>...
>> That's looking at it backwards, I think. Screen edges are efficient
>> target areas for whatever is put there. Given that, what should they
>> be used for? Menus are used a lot, ergo, they're a good candidate to
>> be made more efficient.
>
> Last time I brought up the global menu, the I was pointed to an image
> of someones cursor-tracking while using an application and the fact
> that menu bars were NOT used much was used as argument for the global
> menu....

That would have been a strange argument. In any case, how often menus
are used varies widely depending on the application, and partly on the
user, so eye-tracking of one user using one application won't tell you much.

>...
>> "Space saving vs usability" is a false dichotomy. Space saving reduces
>> scrolling and memory load, which is part of efficiency, which is part
>> of usability.
>
> Not always, this menu hiding thing is a perfect example. Hiding the
> menu saves space and as you've said yourself has made usability worse.

No, hiding the menus doesn't save space.

> There is a point when finding ways to save space will hinder
> usability. My opinion is that the global menu is just past that point,
> and your opinion is that it isn't.

That is also a false dichotomy. A global menu bar with menus hidden by
default, and no global menu bar at all, are not the only two choices.

>>> So, the question again raised is why exactly are we using a global
>>> menu?
>>
>> Benefits:
>> *   Much faster to use.
>> *   Saves vertical space.
>> *   Menus no longer need to be cramped by, or overflow beyond, the
>>     window width (e.g. Empathy, Gimp, Inkscape).
>> *   Menus no longer surprisingly open upwards when the window is near
>>     the bottom of the screen.
>> *   Allows the desktop to have the same menus as any other folder
>>     (which, in turn, will reduce the complexity of context menus).
>> *   In future, will allow dialogs to have "Edit", "Help" etc menus
>>     consistent with other windows.
>> *   In future, will allow visual unification of title bars and
>>     toolbars.
>
> 1. Really? Do we have recent usability studies to prove this across
> multiple resolutions? I know Apple did research into this a long time
> ago, but I don't think that this research upscales to the HD and
> widescreen resolutions we deal with today.

Whether a screen is HD makes no difference to the target distance, and a
widescreen aspect ratio makes barely any difference to the target
distance. The physical size of the display does make a difference, but
while desktop displays have been getting larger, since 2008 desktops
have been outnumbered by notebooks that necessarily have small screens.

>                                            Although hitting the target
> may be faster, I honestly believe that the context switch (determining
> which window is focused/focusing the right window) and mouse travel
> time outweigh this.

The cost of context switching is amortized over the number of times you
use the menus in that window before switching to another window. And
mouse travel time is the very thing that's faster in the first place; it
can't outweigh itself.

> 2. True
> 3. Unless of course we are putting window controls, dash buttons,
> indicators and window titles along with it, you'll still run out of
> space, granted it's less likely. I've also never noticed this to be a
> problem.

A few years ago, for example, Gimp's Toolbox window had a cryptic "Xtns"
menu simply because calling it "Extensions" would have made the window
too wide.
<http://lists.xcf.berkeley.edu/lists/gimp-developer/2006-March/015344.html>

Gimp has since solved that problem by introducing a dummy window to
contain its menus when no documents are open. But the cure has been
worse than the disease: for example, it means that clicking the close
button in the only open document window doesn't close the window.

With a global menu bar, the Toolbox window could have the full set of
Gimp menus without disrupting its layout, and the dummy window wouldn't
be necessary at all.

>...
> I don't agree that dual monitors / large resolutions aren't a problem.
> I've used appmenu with dual monitors and the detachment from the menu
> is a real issue. Take a look at this animated gif:
> http://www.omgubuntu.co.uk/wp-content/uploads/2011/02/lo-appmenu.gif
> That isn't even a large screen and still the user stops to click the
> correct window before going to the menu. That does not happen without
> global menus

That's the context switching you already mentioned, which has nothing to
do with either dual monitors or large resolutions.

>              and the mouse distance to travel is less.
>...

Yes, but travel time is slower.

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

iEYEARECAAYFAk2DiNcACgkQ6PUxNfU6ecp78ACfUtoE56hFVR+Bws8akU8mpma3
KYwAnA6e8xXgrZGu4EqHtcDiBwXNo3wj
=vg5K
-----END PGP SIGNATURE-----