unity-design team mailing list archive

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

On Fri, Jun 17, 2011 at 01:08, Stefanos A. <stapostol@xxxxxxxxx> wrote:

> Matthew, I love your idea. With little twist:


loving the idea, too.
i wouldn't make it that humble tho, proper fields, perhaps the size of
browser tabs, would make sense to me for each menu ( View, Go, Edit ...)

- unmaximized windows get a menu "button" that displays (drops down?) the
> menu when clicked.
>


this idea feels good, too.
Until today, i have been unable to figure out what appmenus are actually
really gonna be needed for in the future of "interface". A11y perhaps? A
blind person is unlikely to be using Gimp or Blender, whereas both
applications are good examples of context-menu lived app-menu functionality.
Perhaps appmenus can be of interest to people who use only a keyboard, yes
that would make sense. But obviously our interaction hardware is aiming at
immediacy, correspondence, rather than symbolic crypticism or text-driven
menu-isms.

I've also been thinking that "interface" is becoming more complex, but
that's only true if you look at it from the code point of view. To the human
naive perception, interface is becoming simpler, it corresponds more and
more with the actual content, i.e. the sense realms we are trying to connect
with.

So a menu-button would be a good step towards making the interface
perceptively simpler.
Maybe this is a good opportunity to rethink the role of the the Context Menu
Button on our desktop computer keyboards. Pressing it should at least
visualize those *context relevant,* usually panel-lived menus, which might
be hidden in the model you describe.