← Back to team overview

unity-design team mailing list archive

Re: Menu bar integrated in title bar in Unity

 

On Fri, Feb 18, 2011 at 18:39, Paul Sladen <ubuntu@xxxxxxxxxxxxxxx> wrote:

> On Fri, 18 Feb 2011, Luke Benstead wrote:
> > On 18 February 2011 13:23, Andrew Laignel <a.laignel@xxxxxxxxxxxxx>
> wrote:
> > >
> https://wiki.mozilla.org/File:Firefox-4-Mockup-i06-%28Win7%29-%28Aero%29-%28TabsTop%29.png*cough*
> > Err... yeah, like that :)
>
> These kinds of menus are okay for very seldomly-used ones---such as
> those in a browser, or an instant messaging application---but I've
> never been particularly keen on them for menus that actually have to
> be *used* (word-processor, drawing application, ...).
>

that's a very good distinction!
I wouldn't want a menu bar on a calculator, i'd just want the calculator and
a button for the settings dialog.
The calculator window could then morph in place into a settings dialog, or
dim it's UI and overlay it with a transparent settings page..


>
> My understanding is that humans remember grids: across, then down.
>

yes, that's an ability learnt in primary school, it's not to my knowledge
that we're born with it.
Some languages are not read like that, they are read vertically first, then
horizontally.

We're born with an abstract pattern memory: the simpler the pattern, the
easier to memorize.


> When that type of vertical menu is: down, down, down, ... the instant
> positional memory is not there.


good point. That's why i would recommend to open a horizontal menubar, when
the AppMenu is evoked via ALT or via clicking the AppName button

My best regular example of this is
> the huge right-click menu in GIMP.  After a decade of near-daily use I
> still don't have a mental model of what that menu looks like, other
> than knowing that the option I want is "somewhere" in 2-3 layers of
> side-ways shuffling.
>

which is ok, if you use that option once in a while.
If you use the option frequently, it should have an accessible and logical
interaction path.


>
> Admittedly I quite happily used the similiarly ballooning side-ways
> menus in RiscOS for several years prior to that; compare:
>
>  http://i.ytimg.com/vi/RLXilJdXGMo/0.jpg (RiscOS !Draw)
>  http://math.hws.edu/eck/cs120/f02/lab4/gimp_menus.gif (GIMP)
>


thanks for the screenshots ;)

As a rule one can say: every submenu is a workaround to a design problem.
The best design is instantaneous, the best menu is a menu that doesn't
exist, the best UI is a UI that doesn't exist.
Once we add a layer, level or "page" to a UI, we know that we're adding
complexity, and complexity is what makes a UI difficult to use.

The only type of complexity that makes a UI easier to use is the complexity
that is supported by native human intuition, and that is something we don't
discuss here so much unfortunately..

References