Re: [Ayatana] Menu bar integrated in title bar in Unity

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

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..