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
>
>
_______________________________________________
Mailing list:
https://launchpad.net/~ayatana
Post to :
ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe :
https://launchpad.net/~ayatana
More help :
https://help.launchpad.net/ListHelp