unity-design team mailing list archive

[Ed Lin <edlin280@xxxxxxxxx>]

Re Fitts's Law:
http://en.wikipedia.org/wiki/Fitts's_law#Success_and_implications

It's a formula to determine how fast a user can hit a interface
element with a pointer which mainly depends on the size of the target
and the traveling distance. Screen edges and especially corners are
the easiest places to hit because one could say the size there is
indefinite in one, in the case of corners in two directions. The
problem with the current implementation is that the target is
invisible so people (who know about the menu....) can throw the mouse
to the top but then they need to correct their movement (going left of
right) and the target suddenly becomes a lot smaller, net effect is
they slow down and the previous advantage is diminished. I also doubt
displaying the menu before the mouse hits the target could change that
(as I think Mark Shuttleworth suggested in the list) because they way
this works is you first focus on the target, then move the mouse
really quickly ("throw" it across the screen) if you need to wait for
the menu to blend in the user will of course slow down, again any
advantage is lost.

The second aspect is that menubar and associated window can be apart
relatively far on a desktop or high-res laptop. One first needs to
focus the upper screen edge and then either move the mouse-hand a
longer distance (which takes a few extra milliseconds) or really
quickly flick it to cross the screen. The problem with the latter
technique is that even if the target was visible it's too small to hit
without correcting the direction after hitting the upper screen edge.
These two arguments together mean that the menubar in it's current
implementation is worse in terms of Fitts's Law and speed of access
than what we had before and even if the mouse on hover was "fixed"
(which wouldn't cost you anything on a large monitor) it wouldn't be
faster to access on a large monitor. Add to that the fact that you
first need to focus a window before being able to use its menu and all
the other problems (but I think I'm repeating myself by now) and I see
no reason other than brand differentiation and marketing ("like OS X,
only free, runs everywhere and is better, who wouldn't love to use
that?") to keep it.

Toki Tahmid: I'm not sure what you mean by "vertically on the title
bar. The mockup already shows a vertical menu but I don't think that's
a solution in any case. It would work for the terminals or a browser
but not for LOffice, GIMP and similar applications and it wouldn't
work for my "eternal noob". I'd prefer having the classical menubar by
default but making it optionally hidden on a per application basis and
only show it when someone clicks on "menu icon" or hits the alt key.
Look at Windows Vista or 7, they made the menubar hidden by default in
most of their applications. This means modern and sometimes improved
interfaces and windows chrome can be reduces to maximize screen estate
but it's bad for discoverability and consistency. Power users and
minimalists prefer none visible, other use the menubar (using the
mouse of course) exclusively for all interaction with a GUI. I think
the approach outlined here is the only one that accommodates the
preferences of either extreme.


On Fri, Apr 29, 2011 at 9:39 AM, Toki Tahmid <oxwivi@xxxxxxxxx> wrote:
> @Anthony, great idea, though I don't see removing panel when no maximised
> windows doing much, and instead of a list on hover, I'd prefer a menu bar
> appear vertically on the title bar. Oh, and other system icons like mounted
> USB/partition smaller and statically fixed at the bottom would be great.
>
> @Ed, wondering for a while now, but what the hell is Fitts's Law? Menus on
> title bar, period.
>
> On 29 April 2011 09:15, Toki Tahmid <oxwivi@xxxxxxxxx> wrote:
>>
>> @Anthony, great idea, though I don't see removing panel when no maximised
>> windows doing much, and instead of a list on hover, I'd prefer a menu bar
>> appear vertically on the title bar. Oh, and other system icons like mounted
>> USB/partition smaller and statically fixed at the bottom would be great.
>>
>> @Ed, wondering for a while now, but what the hell is Fitts's Law? Menus on
>> title bar, period.
>>
>> On 29 April 2011 07:07, Ed Lin <edlin280@xxxxxxxxx> wrote:
>>>
>>> On Fri, Apr 29, 2011 at 12:10 AM, Evan Huus <eapache@xxxxxxxxx> wrote:
>>> > On Thu, Apr 28, 2011 at 4:27 PM, Anthony Scire <aaaantoine@xxxxxxxxx>
>>> > wrote:
>>>
>>> >> 2. The menu bar should, in some way, still be built into its window.
>>> >> The way I propose is to have a button appear on the title bar, a-la
>>> >> Firefox 4.  Hovering the mouse over this button will reveal the menu.
>>> >> Mouse actions on the "button" should be the same as any other part of
>>> >> the title bar, just that the mouse-over event will reveal the
>>> >> drop-down menus stacked vertically.  The label on the button should be
>>> >> the same as currently appears in the global menu bar, i.e. "Firefox
>>> >> Web Browser".  Then next to that, if the text is any different, the
>>> >> regular window title will appear.
>>> >>
>>> >> Hitting Alt should drop down this menu, as well.
>>> >
>>> > I'm not convinced about this. I know several people who aren't happy
>>> > with the FF4-style menus because it requires an extra click to access
>>> > anything (confused about the hover you mention - would the user have
>>> > to hover, wait, then move sideways without leaving the window to
>>> > access menus? seems finicky). Also, this would presumably face the
>>> > same discovery issues as the global menu does now, as documented in
>>> > the usability study.
>>> >
>>> > The current system is definitely a problem though.
>>> >
>>> Ah, the menubar again.
>>>
>>> Let me quickly outline the problem:
>>>
>>> There are very different kinds of users:
>>>
>>> #1 -the keyboard junkie:
>>> Never uses the mouse unless he has to, menubar must be accessible via
>>> keyboard. Most important function: It severs as a lookup table for all
>>> available combinations. After having used a particular application for
>>> a while and having memorized all relevant functions he'll prefer to
>>> keep the menubar hidden entirely. The placement of the menubar doesn't
>>> much matter that much to him. Making it optionally hidden and only
>>> showing it when pressing the alt key would be the perfect solution for
>>> this kind of user.
>>>
>>> #2-the eternal noob
>>> He loves nothing more than simple, predictable, repeatable and
>>> consistent. He doesn't care about speed and probably less about
>>> maximising screen estate. He'll use the menubar to cut and paste even
>>> though friends and family repeatedly explain how ctrl+x/v and even
>>> toolbar icons or the right-click context menu is so much faster. No,
>>> edit->paste is what he learned in his Windows Office 97 or earlier
>>> days and that's what he'll keep using till they rip the mouse from his
>>> cold, dead hands.
>>> The clear, simple, textual hierarchy gives him confidence and safety.
>>> So, don't mess with it! This includes replacing the menubar with a
>>> single menu button as proposed above.
>>>
>>> These are the two extremes I guess, there are many shades in between:
>>>
>>> #3-the hip
>>> he wants nice, flashy and modern. Usability comes second as longs the
>>> look is right He'll long for modern interfaces like he's used to from
>>> his smartphone and the modern browser he uses for facebook and youtube
>>> (there isn't much else he uses the computer for). He won't even notice
>>> if the menubar moves or is gone entirely as longs as the remaining
>>> interface is fun to use and exposes all required controls via nice
>>> buttons and icons.
>>>
>>> #4-the workaholic
>>> The OS and it's GUI are just another thing in the way of getting
>>> things done. Don't nag him while he's working! He'll work with a very
>>> few selected applications, email, word and a browser. On his portable
>>> device he wants to use all the screen estate for his work, not for
>>> fancy interface controls. Menubar or other interface elements, it
>>> doesn't really matter as longs as it gets the job done in the most
>>> efficient way. He'll complain loudly about any change but if it's for
>>> the better he'll soon calm down again and actually be very grateful.
>>> Give him a maximised Writer and Browser, no unnecessary bar and titles
>>> and he's happy.
>>> In his case the Firefox style menu button is a bad idea. It adds a
>>> whole additional hierarchy thereby increasing complexity and time to
>>> access typically by about one third, example: Edit->Paste would become
>>> Menu->Edit->Paste.
>>>
>>> Now let's see how we stack up.
>>> Unity improved things for the "hip" and the "workaholic". A new
>>> interface with Compiz effects and a certain Mac/iOS inspired look and
>>> feel is a win for the hipster. Compared to GNOME 2 Unity gets rid of
>>> three panels (60 pixels or so?) vertical space which results in more
>>> text/content visible for our workaholic.
>>> The keyboard junkie will appreciate the new keyboard friendly launcher
>>> and furthermore stay out of the menubar discussion that largely
>>> focuses on Fitts's Law and counting mouse clicks. Nothing he ever
>>> cared about. But why is it so prominently on the top of the screen if
>>> he never intends to make much use of it, why can't it be hidden as an
>>> option to maximise the rows visible in vim/emacs?
>>> As for our second guy: Doesn't look so good. Where is the menu gone? I
>>> can't find it! Up there you say? I still don't see anything.
>>> Also, if he uses a larger monitor he will no appreciate the longer
>>> traveling distance.
>>> Let me add here, the concept of a global menubar isn't only 20 odd
>>> years old and from a time where there was no multi-tasking! Back then
>>> monitors had less pixel than the average smartphone today!  Sorry, but
>>> that's how I feel about the global menubar.
>>>
>>> I believe with a menubar-in-windows we can make happy every one of our
>>> four friends here. Let's see:
>>>
>>> #1: If it's in the window it can be hidden on a per application basis.
>>> The average cli user likely doesn't need a graphical menu in his
>>> terminals, but he'll probably want on in GIMP which he fires up every
>>> other month. A global menubar doesn't give him that flexibility. Well,
>>> he could ignore it's there but then it takes up screen estate and
>>> takes up a valuable screen edge as pointed out here:
>>> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/749335
>>> Such "power user" also is a likely candidate for using multiple
>>> high-res monitors, virtual desktops and multiple windows on each of
>>> them. As it's been pointed out repeatedly the global menubar together
>>> with the app-centric launcher slows multi-tasking at that level down.
>>>
>>> #2: If the global menubar was an exact copy of OS X he'd be happy.
>>> After a year relearning where to look for the menu :P
>>> Sure, it's even more consistent and predictable to have the menu
>>> visible at the same spot all the time. But such users (going by my
>>> field tests on OS X) are typical examples of clicking the menubar
>>> while having the wrong window in focus. If you take this into account
>>> the advantage becomes less. First you alienate these creatures of
>>> habit and then the advantage is tarnished by introducing new
>>> "instability" and dynamic into the interface and thereby a source of
>>> error and frustration.
>>>
>>> #3: Frankly, this is 2011 and people don't care so much about what OS
>>> everyone is running anymore, they want to get on the internet as fast
>>> as possible and use their favorite web services. Having fluid
>>> animations, nice color schemes, good support for web standards and
>>> social media they already use and finally well designed applications
>>> for frequent multimedia and work related tasks is much more important
>>> than such changes in the OS design.
>>>
>>> The global menu is only going to be a hindrance when going further and
>>> getting Unity onto touch devices or at least further merging tablet
>>> and computer interface design and more importantly what applications
>>> are going to run on them. Having no menubar dictated from the OS means
>>> each app developer has full freedom over how his app will behave. It
>>> can be "hybrid", suited for both touch and keyboard/mouse, it can make
>>> use of all screen edges in full screen mode and no unnecessary legacy
>>> menus need to be coded specifically for Unity (the only Linux DE with
>>> a global menubar).
>>>
>>> #4: There is no reason why having the menu in the windows needs to
>>> take up more screen estate. A good example, less known, is WebPositive
>>> in Haiku (give it a try, it's a small download and runs nicely in
>>> Virtualbox - just change the NIC to Intel 82540EM). Haiku is based on
>>> BeOS and I think BeOS in parts was inspired by Mac may also have
>>> inspired some parts of OS X.
>>> The Haiku desktop on a high level is very similar to Unity in several
>>> aspects: the main menu is in an upper corner, the launcher is on a
>>> side, and application-centric, windows can hide (in the case of Haiku:
>>> overlap) the launcher to maximize the available screen estate and the
>>> close botton is on the left side.
>>>
>>> But each window has it's own menu and titlebar (which is only as large
>>> as it needs to be, a bit like a tab). If you click on maximize in
>>> WebPositive, the browser, it will maximize the main window, overlap
>>> the launcher and remove the the titlebar. Window controls are moved
>>> into the same bar as the menubar and the menu itself obeys Fitts's law
>>> (or could, I didn't check that).
>>> Basically it's exactly the same as Firefox maximized in Unity without
>>> the title in the panel which is redundant in a tabbed browser.
>>>
>>> To sum it up:
>>> Menubar hover is bad, without it no screen estate is saved (in usual
>>> window arrangements) leaving only Fitts's Law as an argument for it
>>> (which you can only bring into play once made the targets visible all
>>> the time). I counter with a range of four distinct user cases that
>>> should squarely cover the whole Ubuntu userbase where each of them
>>> ultimately benefits more from moving the menu back into the window.
>>> Additionally this fixes the awkward case of having a non-maximized
>>> window on top of a maximized one, resolves the mouse hover discussion,
>>> reduces Unity specific patches for 3rd party software, eases the
>>> transition from GNOME to Unity (still relevant for the next LTS
>>> upgrade, those guys care about stable in terms of GUI and interface
>>> changes too, especially when it comes to enterprise workstations) and
>>> a host of other complaints and issues that I missed, forgot or that
>>> are yet to be discovered.
>>>
>>> Please let me know what you think. I hope you are still open to
>>> discussions about such a pervasive changes to Unity.
>>>
>>> Regards,
>>> Ed Lin
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~ayatana
>>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ayatana
>>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>