unity-design team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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

giff gill wrote on 05/04/11 18:32:
>...
> But I have to say, that's interesting. Unity was initially designed
> with netbook formfactor and user case in mind and later extended to
> the desktop. Still the fundamental design was kept 1:1, the same
> design for different form factors.

I'm not sure (I can't find the specification), but I think there may be
some small differences in how the launcher behaves on netbooks.

> One of my points is that I do not think a global menubar makes much
> sense on a large monitor (20" and up).

Some of its benefits (faster, saves space, more predictable direction)
lessen but don't go away entirely. The other benefits stay the same.

>...
>> It is much easier to reopen a tab you closed recently, or to return to
>> a page you visited a few minutes ago, or to clear all browsing data,
>> in Chrome for Mac than in Chrome for Windows. Why? Because the Mac
>> version has a menu bar with items for those functions, while the
>> Windows version does not.
> 
> But there's the Fitt's Law trade-off. What do people access more often?

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

> What if Chrome had two buttons instead of one, that equals about the
> information density and depth of the Mac menu layout.

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

>...
>> Actually, I'm pretty sure the Back button has that honor.
> 
> I guess so, I have a five button mouse so I use that but statistically
> you are most likely right. So what would a clever UI developer do?
> Simple, put the back-button next to the first tab at the top of the
> screen. (MS Ribbon has something very similar where you can put the
> undo function into the title-bar). The plain menubar doesn't allow
> that.

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.

>>> A "fallback" menu" so it doesn't look stupid?
>> 
>> Not just for that, of course. :-) It will also make the editing
>> functions (Cut, Copy, Paste) more accessible when the keyboard is
>> further away then the mouse is.
> 
> The context menu is even closer. So is a menu directly in the window in
> multi-window mode.

I was referring to the proximity of the input device, not the target
area. :-)

>> Over time, as more programs fill in the menu bar, it will solve other
>> design problems too. For example, for years Gnome has had a problem
>> with how to make changes in settings windows undoable. Where to put
>> the Undo command? With a menu bar, the answer is obvious: "Edit" >
>> "Undo".
> 
> They either already have a menubar directly in the window now and this
> doesn't help solving anything

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.

>                               or they now get a menubar with a single
> relevant function

It would also contain the standard suite of editing commands (Cut, Copy,
Paste, Delete, Select All).

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

>> 1.  Exploration -- the menu hierarchy acts as a map for understanding
>>     what features are available in an application, even if some of
>>     them are also available elsewhere.
>> 3.  Teaching -- the menus act as cheat sheets for the keyboard
>>     shortcuts.
> 
> Who said there shouldn't be an equivalent to these necessary UI
> functions? Firefox and Chrome both have a menu-button that fulfills
> these tasks.

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.

>> 2.  Familiarity -- it can be easier to remember that "Print" is always
>>     in the "File" menu for any application where it's available at
>>     all, than to remember where (or whether) the Print button is in
>>     each application.
> 
> The UI should be consistent were it makes sense (i.e. helps the user
> get things done) but not for a blind sake of consistency.
> 
> I think like in your paste example from MS if an application has a
> dedicated print button it will be uses more frequently than a nested
> print command. Likewise I don't care at all as long as ctrl-p works
> (give me consistent keyboard shortcuts and I'm happy).

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.

>...
> However, having no main menu always in the same place doesn't
> automatically mean a total mess and inconsistency. Take a look at the
> OS X first party software. Yes, they do have a menu but I argue that's
> too more for legacy reasons than a deliberate choice at this point.
> As you might be aware OS X.next will introduce a new fullscreen mode
> similar to what iOS apps look. No menubar there and it's apparently
> what users want and what sells apps.

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.

>...
> UX consistency is much more than a global menu and Linux with all it's
> different toolkits and separate developer communities is far from
> achieving what a walled garden can today.

Toolkit proliferation is certainly a big problem. For example, it's made
implementing the global menu bar four or five times as difficult as it
should have been.

>> That's great, but people like you are rare and special. For many
>> people, remembering more than the most basic keyboard shortcuts is too
>> much bother. And for many, drag and drop is rather difficult (which is
>> why Mac menus themselves no longer require dragging, and why Windows
>> and Ubuntu menus never have).
> 
> About drag and drop, Finder does not support cut and paste, the
> quickest way to move stuff around is by opening two windows side by
> side and dragging and dropping files and folders with the mouse. Very
> common user case, not that I'm particularly fond of this behaviour.

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.

>...
>>> Given that menubars are becoming a legacy paradigm I wonder if it's
>>> such a great idea, when designing a new UI from scratch in 2011 one
>>> should make that menubar a prominent and static, always on, no way to
>>> opt out, no way to replace with more fitting things like tabs on top
>>> element.
>> ...
>> That's just an appeal to novelty.
> 
> I have my eyes on iOS and OS X lion and what I'm seeing there is a
> trend not just temporary gimmickry.
>...

The menu bar remains present in Lion. As for iOS, I think it is a
mistake to interpret a necessary aspect of interface design for
successful phones and tablets as if it is part of a trend in interface
design for notebook and desktop PCs.

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

iEYEARECAAYFAk2dleEACgkQ6PUxNfU6ecqtQgCg0KzS02toTf0UGRrFBc4VNkC8
9Y0AnioEc8QOYympGHMVj8a1aKZyZNNh
=4BRi
-----END PGP SIGNATURE-----