[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ayatana] Design problem: Menus hidden by default in Unity
- To: Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>
- Subject: Re: [Ayatana] Design problem: Menus hidden by default in Unity
- From: Luke Benstead <kazade@xxxxxxxxx>
- Date: Thu, 17 Mar 2011 13:56:33 +0000
- Cc: ayatana <ayatana@xxxxxxxxxxxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AMGfBuRDYd1h+ZYPbRjG9/8r1TALr5rJAK0s4qv0d1E=; b=PuTGfV1RDzkwuhPrCw5OTPEJdiaM4IjzS8Hcqc11Lb1ZHabqGDEu8hRNbA2+WzBsar TAnyGeGYhTzhcXllKLFvn70qXrqdh+0NbfT7QAPrvTzuf5dI9gowzN+qGgcbB/rxfV/r zpZ9atn/w0P3vsYSwu7RY4cWfNpZisqt0iepE=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GFGzKmIlAwzN0Md/7LQJVgDlH4st5ZGYKZhPSD4c8aOp0vOkHenEJJIUMS9kfwYc8p EnMeR1U4y7yVMxhStTmN8twb/h76qbscLLH0y00q6wVYY9CZFp9ekd52AlLMQF384KzD +2GzyzcbpyhpC35LMyUEi1oLXd9xhPZaqEQHw=
- In-reply-to: <4D81EF02.1060000@canonical.com>
- List-archive: <http://lists.launchpad.net/ayatana>
- List-help: <https://help.launchpad.net/ListHelp>
- List-id: <ayatana.lists.launchpad.net>
- List-owner: <https://launchpad.net/~ayatana>
- List-post: <mailto:ayatana@lists.launchpad.net>
- List-subscribe: <https://launchpad.net/~ayatana>
- List-unsubscribe: <https://launchpad.net/~ayatana>
- References: <1300215119.5539.38.camel@laptop> <1300219985.1685.86.camel@Aspire-5670> <AANLkTikrVUBpsUi-80_cXAX1iJdffrW5b=FY7vWLPMhg@mail.gmail.com> <4D81EF02.1060000@canonical.com>
>> 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.