unity-design team mailing list archive

[Ed Lin <edlin280@xxxxxxxxx>]

On Thu, May 26, 2011 at 7:28 PM, Jo-Erlend Schinstad
<joerlend.schinstad@xxxxxxxxx> wrote:

> Thank you. Yes, I'll be happy to describe that, of course.
>

Thank you for that detailed reply! To sum it up:
- you don't use menus frequently so you prefer not having them clutter
your screen
- you often tile windows above each other, a global menu saves vertical space

This is a very interesting, it indicates that the top screen edge is
often "wasted" for interface elements that aren't used frequently
enough to warrant that spot. The top panel is misused as place to get
things out of the way.

The second point seems to be more of a special case, it's mostly about
terminal windows I understand? Browsers have tabs, file managers have
split panes, tabs and usually you never have that many opened, text
editor windows usually aren't stacked above each other because you
want to maximize their vertical geometry. Terminals are different
because you want to keep them all visible in case any need user input,
finished a task and so on. I say special case because working with
multiple terminals mostly done by the so called "powerusers" and I'd
tend to think they don't really use the terminal menu all that often
(if they even use gnome-terminal and not urxvt...)

Sorry if this sounds confusing but basically this setup recreates a
MDI application using the WM and panel. You could just as well have a
maximized window open with one set of controls and multiple shells
which can be rearranged (tabbed, tiled, maximized). You probably also
aren't interested in selecting a single terminal and bring that to the
foreground (via window switcher, spread view or launcher icon) because
the title as well as the thumbnails are quite nondescript. You always
switch to "the terminal application (window)".
One "solution" would be to extend the tabbing on gnome-terminal to a
full MDI application...

The terminal is also a special case because it has no toolbars, all
its controls are in the one menu, this makes separating the menu from
the window very clean and logical, on other apps with multiple rows of
GUI controls, the global menu would appear more arbitrary.
Here's an example based on my own testing: Open an unfamiliar app, you
need a certain function, first you'll probably go through the controls
available within the window, you can't find what you are looking for,
ah, right the menu, search again, in a completely different place
(This has also implications with Fitts's Law, if D, the distance to
the target, is really small as in this typical case the in-window menu
is definitely faster to access on larger monitors)

I also have another "solution" as well, just something to think about
briefly: You all know GIMP, it has main windows for content and then
it has toolboxes. We could have a "terminal toolbox" (actually a menu
box which you can put on the screen edge) and then get the same result
as with the global menu. But with gedit for example you could put the
menu and the toolbar both to the screen edge. I'm not promoting that
as an actual idea for Unity but lets imagine our desktops would be
single tasking (a single app but multiple windows) and this could
actually make sense. In a multi-tasking environment it would only add
to the shortcomings of the global menu. But it would improve the
mentioned calmness of the interface: You could really have windows
with nothing but the content, the necessary tools would fade in only
and whenever you actually need them.

If you want a tl;dr:
Very good points but if the goal is reducing clutter and maximizing
screen estate for actual content (and some Fitts's Law for good
measure) why the menu? Why *just* the menu, why not something else*?
Colorful Toolboxes with sometimes tasteless icons are far more
noisy... And as said, the hover behavior has to go  so that would
weaken the first argument (it could stay as an option though).

*Actually I think I know the answer:
it's done before, we know it will work
it's easier from a technical as well as from a design point of view
Doesn't sound like the best reasons to me and I prefer not having a
feature to having a broken feature any day.