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.