unity-design team mailing list archive

[Ian Santopietro <isantop@xxxxxxxxx>]

What about flashing the menu with the title for the first, say, five seconds
that the window is open. That gives an indication as to where the menu is,
reduces visual clutter, and allows the user to get a quick preview of what
menu headers are available (File, Edit, etc.) without losing the supposed
benefit of the global menu. Perhaps a nice quick fading animation would help
keep this from being jarring.

On Thu, Mar 17, 2011 at 07:56, Luke Benstead <kazade@xxxxxxxxx> wrote:

> >> 1. Someone will bring up Fitt's Law. Yes I know what it is. No, I
> >> don't think it should be used as an overriding reason to squash,
> >> overlap, and generally complicate a UI and shove it into an edge. I
> >> especially don't see why Fitt's law is so important for menu bars,
> >> when users get on perfectly fine with buttons, sliders, window resize
> >> grips and icons, and well, everything else.
> >
> > That's looking at it backwards, I think. Screen edges are efficient
> > target areas for whatever is put there. Given that, what should they be
> > used for? Menus are used a lot, ergo, they're a good candidate to be
> > made more efficient.
>
> Last time I brought up the global menu, the I was pointed to an image
> of someones cursor-tracking while using an application and the fact
> that menu bars were NOT used much was used as argument for the global
> menu....
>
> >> 2. Someone will likely bring up the space saving of the global menu.
> >> Firstly, the global menu only saves vertical space on a maximized
> >> window, on non-maximized windows they only save on "chrome".
> >
> > It also saves space whenever two or more windows are stacked vertically.
> >
>
> Fair point, but uncommon.
>                                                           By
> >> keeping the title in the panel for maximized windows, we are still
> >> saving 22px on Gnome 2, with the removal of the bottom panel that
> >> brings it up to 44px. It's about finding a balance of space saving vs
> >> usability and I really think we have shot past that balance point with
> >> the global menu.
> >
> > "Space saving vs usability" is a false dichotomy. Space saving reduces
> > scrolling and memory load, which is part of efficiency, which is part of
> > usability.
> >
>
> Not always, this menu hiding thing is a perfect example. Hiding the
> menu saves space and as you've said yourself has made usability worse.
> There is a point when finding ways to save space will hinder
> usability. My opinion is that the global menu is just past that point,
> and your opinion is that it isn't.
>
> >> So, the question again raised is why exactly are we using a global
> >> menu?
> >
> > Benefits:
> > *   Much faster to use.
> > *   Saves vertical space.
> > *   Menus no longer need to be cramped by, or overflow beyond, the
> >    window width (e.g. Empathy, Gimp, Inkscape).
> > *   Menus no longer surprisingly open upwards when the window is near
> >    the bottom of the screen.
> > *   Allows the desktop to have the same menus as any other folder
> >    (which, in turn, will reduce the complexity of context menus).
> > *   In future, will allow dialogs to have "Edit", "Help" etc menus
> >    consistent with other windows.
> > *   In future, will allow visual unification of title bars and toolbars.
>
> 1. Really? Do we have recent usability studies to prove this across
> multiple resolutions? I know Apple did research into this a long time
> ago, but I don't think that this research upscales to the HD and
> widescreen resolutions we deal with today. Although hitting the target
> may be faster, I honestly believe that the context switch (determining
> which window is focused/focusing the right window) and mouse travel
> time outweigh this.
> 2. True
> 3. Unless of course we are putting window controls, dash buttons,
> indicators and window titles along with it, you'll still run out of
> space, granted it's less likely. I've also never noticed this to be a
> problem.
> 4. True, but really REALLY uncommon
> 5. Well, we did have the menu bar before which was almost exactly the
> same anyway
> 6. and 7. Well, OK.
>
> >> I know I've brought it up before, but alongside the issues we are
> >> having fitting it into the panel with the title, it also brings issues
> >> with dual monitors, large resolutions and focus-follows-mouse. It
> >> doesn't fit all use cases.
> >>...
> >
> > Dual monitors are not a problem (though if they're stacked vertically,
> > the bottom one loses its speed benefit). Large screens make the menus a
> > bit slower, but not nearly as slow as they would be inside windows. The
> > loss of focus-follows-mouse is a real tradeoff, though. (I've specified
> > how it could be made compatible, but no-one has been interested enough
> > to work on it yet.)
> >
>
> I don't agree that dual monitors / large resolutions aren't a problem.
> I've used appmenu with dual monitors and the detachment from the menu
> is a real issue. Take a look at this animated gif:
> http://www.omgubuntu.co.uk/wp-content/uploads/2011/02/lo-appmenu.gif
> That isn't even a large screen and still the user stops to click the
> correct window before going to the menu. That does not happen without
> global menus and the mouse distance to travel is less.
>
> Just to clarify, I am totally in favour of the global menu on small,
> netbook size screens. Because on small screens you are a.) nearly
> always operating fullscreen windows and b.) limited on vertical space.
> On large screens with multiple small windows and ample vertical space,
> I don't think it fits.
>
> Luke.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Ian Santopietro
CEO - Prodigy Games

"Eala Earendel enlga beorohtast
 Ofer middangeard monnum sended"

Pa gur yv y porthaur?

Public GPG key (RSA):
http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x412F52DB1BBF1234