On Thu, May 19, 2011 at 10:03 AM, Ralph Green <sira...@gmail.com> wrote: > 2. MPT seems to think the global menu is quicker, even on large > screens. That is certainly not my experience. ... The > question is how typical am I? > 3. Why do people keep referring to Fitt's law. It does not apply to > 2 dimensions, as best as I can tell. Shouldn't the discussion be > about steering law? > Ralph
Fitts's Law is the best measurement we've got for the concrete problem. For what it describes it is absolutely accurate and helpful. However it's only part of the equation and sometimes this is forgotten. A button on the screen edge is faster to access than a button anywhere else on the screen, except directly beneath the mouse pointer. This applies universally to everyone who knows how to use a mouse and uses proper acceleration. If it doesn't for you, "you are doing it wrong", the testing or the mousing ;) The "Law" does not take into account following issues that all apply to the Unity menubar in particular: 1) The target has to be visible before you start moving the mouse, otherwise the advantage is lost or it's even slower than an alternative. By implementing the menu the way it was released in Natty the Unity design team lost any right to invoke speed as an argument! 2) The menu is "context sensitive", you need to be in the correct application, sometimes even window (e.g. GIMP), one simple click in GNOME 2 can now mean 2 clicks and a lot of mouse traveling. 3) On really large monitors (~26" and up) the menu can appear outside your field of vision. In this case Fitts's Law still applies to corners which you can hit without looking but for other targets on the screen edge the advantage diminishes compared to targets within your field of vision that aren't on a screen edge. 4) Already mentioned: What about "traveling" back? The content you are working on is not on a screen edge. Together with point 3) imagine this: A large monitor, many windows tiled and overlapping, you move your eyes away from the window you are working it, go into the menu, now you are looking for the entry, you might not even know what exactly it's called. This distracts you, you loose focus of what you were doing previously. Now, having found the desired entry you wonder where your window is... This may take a split second or much longer depending on how computer "literate" someone is. In any case it adds to the mentioned factors. That's only the speed of access aspect. Besides that we have to deal with a lot more factors like discoverability and predictability. The fact that the menu is hidden by default and status dependent means here it's worse than what we had before. The behavior is confusing to many users (based on my own OS X menubar usability testing, in Unity it can only be worse). All reasons why the current implementation of the Unity application menu needs to be ditched -by default (at least on desktops). Here are some of the arguments that came up in favor of it: It saves screen estate. A: No, it doesn't. In maximized state there is no reason an application needs a title bar and a menubar, but you don't need a global menu for that! Take Chrome: It has two bars: tab and location bar, Unity in fact adds a third which is useless and wastes space. For apps that don't have such feature there is no reason the current Unity implementation couldn't be adapted but of course only for maximized windows. This leaves windows stacked on top of each other, a global menu would save on bar per additional window. How often do you do that on small wide-screens (on large screens it doesn't really matter anyway)? It's more consistent. A: Or how to call forcing developers/apps to make use of a 30 year of paradigm a feature... Admittedly, it's the best argument I heard, in fact the only I could take seriously. A consistent menu layout is desirable. Same functions in different applications should be in the same place. But you can do that with per-window menus as well. You can't force devs to write consistent and logical interfaces anyway. Not all applications need a menu. You know, the best interface is one that doesn't exist. The next best thing is an interface a user doesn't even notice it exists. Whatever, let's slap on a menubar for good measures with a set of useless "fallback" entries so Unity doesn't look "stupid". For many complex applications a menu is a great solution, there are alternatives as well to look into (like a more search/command driven interface à la OS X menu search). For other applications the menu is often misused for feature creep or as an excuse to write a good interface that helps you get things done quickly instead of having to go through pedestrian nested menus. The static menubar/panel on top prevents devs from making more innovative use of that space (Chrome being the the most cited example). Ultimately it can be interpreted as a clutching to antiquated traditions that prevent and deny progress in the user experience. There can be more said about it and there's been written a lot on the list already. There's nothing really new to see here and I'm repeating myself as well. The thing is, we are going in circles. I don't see how any progress in this matter can be achieved. Could we get a somewhat official word back as in "Yes we consider these changes for Oneiric" or "definitely no". Or should we take it to launchpad? _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
