unity-design team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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

Luke Benstead wrote on 15/03/11 21:53:
>...
> Erm, I hate to point out the obvious, but why don't we just put the
> menu back in the windows and abandon appmenu as a failed experiment?
> Keep the title and window controls in the panel for maximized windows
> only (at least just for Natty).
> 
> I can already imagine the replies to this email, so let me save you
> guys the trouble:
> 
> 1. Someone will bring up Fitt's Law. Yes I know what it is. No, I
> don't think it should be used as an overriding reason to squash,
> overlap, and generally complicate a UI and shove it into an edge. I
> especially don't see why Fitt's law is so important for menu bars,
> when users get on perfectly fine with buttons, sliders, window resize
> grips and icons, and well, everything else.

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.

> 2. Someone will likely bring up the space saving of the global menu.
> Firstly, the global menu only saves vertical space on a maximized
> window, on non-maximized windows they only save on "chrome".

It also saves space whenever two or more windows are stacked vertically.

>                                                              By
> keeping the title in the panel for maximized windows, we are still
> saving 22px on Gnome 2, with the removal of the bottom panel that
> brings it up to 44px. It's about finding a balance of space saving vs
> usability and I really think we have shot past that balance point with
> the global menu.

"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.

> 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.

> I know I've brought it up before, but alongside the issues we are
> having fitting it into the panel with the title, it also brings issues
> with dual monitors, large resolutions and focus-follows-mouse. It
> doesn't fit all use cases.
>...

Dual monitors are not a problem (though if they're stacked vertically,
the bottom one loses its speed benefit). Large screens make the menus a
bit slower, but not nearly as slow as they would be inside windows. The
loss of focus-follows-mouse is a real tradeoff, though. (I've specified
how it could be made compatible, but no-one has been interested enough
to work on it yet.)

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

iEYEARECAAYFAk2B7wIACgkQ6PUxNfU6ecr/hgCfQmwbIB8XbywmWUL6zHOJRAI8
nMkAmwbgxluzK5tYZjwp0HOM9Ssl+xFR
=PTeU
-----END PGP SIGNATURE-----