unity-design team mailing list archive

[giff gill <giffgilll@xxxxxxxxxxx>]

On 4/7/2011 12:45 PM, Matthew Paul Thomas wrote:
> 
> Some of its benefits (faster, saves space, more predictable direction)
> lessen but don't go away entirely. The other benefits stay the same.

You didn't mention it introduces drawbacks as well. From my experience
using GNOME, OS X and Windows on the same 22" screen with very similar
tasks the global menubar is worse and not worth the benefits. I'm not
even sure what benefits you have in mind here.

Space
There is non saved, in fact some space is wasted if you were nitpicking.
Title bar and menubar are separate anyway in window mode. As long as the
window isn't as wide as the screen the global menu takes up space at the
top that is unneeded and unused (anything left of the Help menu). The
only space saving I can think of is if you stack windows on top of each
other, something I almost never do and I don't think that's a common
scenario outside tiling WMs.

More predictable location
I'd argue the contrary. Realitve to the mouse position probably
somewhere inside the window of the active application an in-window menu
is always at the same place. Not so the global menu in conjunction with
movable windows.
I don't think that's much of a difference anyway. Muscle memory _inside_
the menu (how far down you move) is more important.

Speed
Here it depends. If the window is near the top menubar (in the same
"focus area" as I called it - you don't have to move eyes/head from the
active window to the menu) the global menu is easier to hit.
This is not the case when the currently active area is somewhere down at
the right side of the screen. Also if you want to access a menu of a
non-active application it is with certainty slower.

What other benefits are there?


 > In a browser, the tabs, sure. But most other windows don't even have
tabs.

I agree, but does that mean we should negate these applications the
advantage of tabs on top? The main argument against this is consistency
but I argued previously why I don't think that's going to be a problem,
and if it is I'm convinced it's worth the trade off.


> The "History" menu alone is deeper and more information-dense than the
> spanner menu is.

The one-button Chrome menu only has a link to "History", no menu
beneath. It opens the a new "History" tab which is the layout you are
supposed to use, with search, details, scrollbar and all. Or make use of
the address box which searches the history as well.

A two button menulayout of Chrome 10 would consist of two completely
flat menus with 15 and 10 entries respectively, I'd argue the classic
Firefox menu bar with 7 top level menu labels with sub-entries ranging
from 4 to 11 and 8 sub-sub menus is slower, denser and less user
friendly and by extension slower to use. Don't have access to a Mac
version of Chrome right now and I imagine it's simpler but I doubt much
better than a two button in-window layout that it warrants reducing the
area available for web content by 20/24 pixels on a typical 576 high
netbook screen (with now way to opt out except full fullscreen) AND use
that area for infrequent accessed functions as opposed to the most
frequently accessed "bar" of the browser.


> I've long wondered why browsers don't make the Back button a narrow
> strip down the left edge of the screen. That would both be much faster
> to use *and* make visual sense.

Oh, but that wouldn't work on Unity. Familiar problem? :P
Opera uses that are for sliding in their left panel.


> The reason they haven't had menus up till now is, rather mundanely, that
> menus inside a dialog-like window look weird. Menus in a global menu bar
> don't.
> 
>>                   which would be a waste of space and cumbersome to use
>> because it's nested. A dedicated single button is faster and more
>> discoverable and ctrl+z could have implemented a long time ago without
>> changing anything in the UI.
> 
> The reason for not having a dedicated single button was, again
> mundanely, that there was no consistent place to put it.
> 

I see that and it makes sense but it doesn't strike me as a particular
elegant or a reason for the use of a global menubar.

There is no reason not to design these GNOME system settings in a way
that allows such functions right from the main window in a logical and
more discoverable way than a menu where you first have to look through
if it even has that functions. Long term users might even never bother
to look and just assume nothing has changed and from my experience
really novice Mac users don't look through the menu either. If an
obvious and main function doesn't have a nice big icon on the window
they assume it's not there.



> What's the keyboard shortcut for going into full-screen mode in Chrome?
> And what are the keyboard shortcuts for making text smaller or larger?
> The menu-button can't tell you, because it's cramming multiple menu
> items into the same row, because it's trying to get by with a single menu.

Fullscreen is no issue because it tells you right after you clicked on
it how to get back (both via mouse and via keyboard shortcut). Learn as
you go, pretty nifty solution.
I think the missing keyboard shortcuts for zooming is an oversight, it
could at least be tooltip inside the menu. But then people who do use
keyboard shortcuts already know these standard combination anyway. It's
a problem for completely new computer users and I agree that this is
nothing we should copy. In Chrome OS they have a separate cheat sheet
function so I guess that's the true reason they don't bother.
Also if you click on Help in the menu and enter "Zoom", this is the
first result:
http://www.google.com/support/chrome/bin/answer.py?answer=96810
Still doesn't tell you about Ctrl+0 though. I also have to add neither
classic menu nor any other solution tells you about scroll wheel+ctrl
for example.

The Firefox single menu button got the same issue, or even worse. It
does not only not expose all keyboard shortcuts, it doesn't even expose
all commands and functions available. But you can always hit the alt key
and get the full classic menubar if you have to look something up.

IMO the ideal setup for the two browsers would be a "?" or "Menu" button
that slides in a menu bar and the wrench menu or possible two buttons
with functions that are actually needed to access via menu (vs just
duplication), without any keyboard hints and preferably a simpler layout
than the two columns Firefox button menu or the nested IE9 menu.

I think that's best of both worlds. You get the full menu that isn't
overcrowded and you still get a nice clean interface that goes out of
your way and makes place for the actual content.

In any case I'd still prefer to have the menubar below the tabs.


> 
> That may work for Microsoft Office, decked out as it is with ribbons and
> buttons like a field marshal's uniform. But Ctrl+P working wouldn't
> inform you that, for example, iTunes has a "Print" function for printing
> CD covers. And putting a Print button, or even an all-in-one menubutton,
> inside a music player window would be ugly.

That's an interesting detail. But I think if you don't know that iTunes
has this feature you are never going to look into the File menu looking
for that function. Best thing happens is you discover it by accident. A
well designed application will ask you if you want to print a cover if
you just burned a CD. Users don't have to know that this function exists
until they actually need that function.

It's still nice to list it somewhere in the menu structure just for
completeness sake. But does the menubar have to be always visible, and
at the top for that? I also doubt an all in one button is ugly. Now we
are arguing taste I'm afraid but if you look at the iTunes interface
which already got tons of icons that no one complains about one more
wouldn't kill its usability.

I know I'm not representative but my favourite audio player is
foobar2000. It has a menubar but you can completely change the interface
to adapt it to your personal preferences, the menubar can be moved,
removed or reduced to a single button. It may not be the right choice
for a default audio player in an OS but it's certainly one of the more
popular Windows applications.
A global menubar would take away this total freedom over the interface
and layout of an application that you have in the non-free Windows. Hey,
isn't that what Linux is all about? (I know. Sorry, I will stop now.)


> In the videos I've seen, full-screen applications in Lion do not provide
> non-menu access to all the functions available in the menus. So either
> the menu bar will still be accessible in full-screen mode, or you need
> to exit full-screen mode to access the deeper functions.

Obviously I haven't used it yet but if it's intelligent I doubt the
menubar will slide in from the top when the mouse hits the screen edge
simply because of Fitts's Law and considering Apple's priorities for
aesthetic reasons as well. Considering how they think of usability and
their users having a simple mode that doesn't give you full access to
everything is a good thing in their book.
Not sure we should copy that...


> The Finder does "support" cut and paste, for the stuff that it actually
> edits, i.e. filenames. What you mean is, you can't move files using Cut
> and Paste, because that would be a mixed metaphor.
> <http://homepage.mac.com/bradster/iarchitect/explore.htm#EXP3> (But then
> Apple dithered and went halfway, allowing copying of files with Copy and
> Paste.) A better file manager could have "File" > "Move To..." and
> "File" > "Copy To..." commands, that didn't distort the clipboard
> metaphor *or* rely on drag and drop.

It's messed up and there is no good reason for this missing
functionality. Speaking of cut and paste, I think Unity finally "fixed"
the clipboard in Ubuntu. Select middle click still works like it used to
though, oh the inconsistencies again :)