On Thu, Feb 17, 2011 at 6:16 PM, Mitja Pagon <mitja.pa...@inueni.com> wrote:
> > Now Unity Desktop integrates (and hide) the menu bar in the upper panel > both for the maximized windows and unmaximized ones. > > This is the reasons according to Mark Shuttleworth: > «One of the design goals of Unity is to reduce the clutter of the desktop, > another is to use space more efficiently. > > We hide the menu by default in Unity because the menu provides no useful > information to which you can refer just by looking at it, but it puts a lot > of detail on the screen which is visual clutter. So, we’ve taken the view > that the menu is there if you need it (by moving the mouse to it or pressing > Alt) but otherwise isn’t in your view. > > I very much doubt that is the actual reason, as despite what you think or > believe, menus actually do provide important information to the user. Also, > menus won't be going away anytime soon, but more on that latter. I would > speculate, that auto-hide behavior is a consequence of the decision to merge > window title and controls with the top panel for maximized windows, as > having all those and also the indicators in the panel at the same time would > be to cluttered and against the "design goals". > > Frankly it's a decision I really don't get. By hiding the menu they have > negated one of the main benefits of a global menu, which is the fact that it > can be quickly and easily accessed. If the menu is hidden it's not as easily > targeted and it requires extra hand movement and also more cognitive power > to accomplish, yes the Alt key can show the menu, but that is neither > obvious or easily discoverable (I for one didn't know that until I read it > in your email). > > What are the actual advantages of this decision also eludes me. The stated > goal is to reduce desktop clutter, but I don't get the logic. What they are > essentially doing is gaining some 24px of vertical space at the expense of > visually cluttering the top panel, without any obvious benefits. I might > make some sense on small screens (sub 10") where space is limited, it > however makes little sense on larger screens. There are some other > drawbacks, like not being touch friendly, but enough for now. > > > Many modern applications are doing without a menu altogether, so in our > view, this is a step towards the future, and it will encourage application > developers to think about their interfaces and make them more usable by > design rather than depending on the crutch of a menu.» > > While there are applications that don't have a need for a full blown menus, > that doesn't mean that there is no future for menus in user interfaces. For > applications rich in functionality (like GIMP, Inkscape, ...) it would be > hard to present all of that functionality without using menus as it would > result in a lot of visual clutter. > > > Why not integrate (and hide) the menu bar in the title bar instead for > ummaximized windows? > > What are the benefits of this approach and are they greater then any > possible negative implications it might have on the user experience and > usability as a whole. It's important to ask yourself those questions when > designing any user interaction. > > Right now I don't see any such benefits in your proposal and at the same > time you yourself listed below, some of the negative implications your > proposal will have (Issues you pointed out and the added complexity needed > to work around them). > > I'll let you draw your own conclusions. > > > I have realized a simple mockup that shows my idea. The menu bar will be > show only if the menu is over the title bar. > > However, there are some implementation issues: > - if the menu bar is shown in the title bar, how do I use it to > drag/maximize/unmaximise the window? > - what about if the menu bar is bigger than the title bar? > > The second is not a real problem: the classic Gnome cut the menu bar if it > is bigger than the windows. For the first problem there are different > solutions. For example we can use the left button mouse for use the menu bar > and the right button mouse for use the title bar (drag, maximize/unmaximized > with double click). Or we can add another window control that allows us to > drop the windows. > > > _______________________________________________ > Mailing list: https://launchpad.net/~ayatana > Post to : ayatana@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ayatana > More help : https://help.launchpad.net/ListHelp > > While I tend to agree that this doesn't solve the clutter problem (and in fact the mockups make it seem worse), I think the IDEA of this is really pretty cool--wasting vertical screen space on a (usually half empty) menu bar and a (usually 80% empty) title bar has always driven me crazy on every machine with a screen smaller than 1600 x n00. Interestingly, the gnome2 global menu works very similar to this, albeit in the panel: it begins the menu with the title of the window on the left. Windows could follow a similar pattern which would solve the clutter apparent in the mockups. The apparent benefits are: 1. removing space wasted by window chrome, leaving more space for the data the user is actually interested in 2. collecting all meta information about the window in a single bar attached to the window itself. Sure, dragging windows is an immediate problem, but I don't think it's an unsolvable one--I can imagine some sort of 'click here to drag' target. In short, I think the idea is an appealing alternative to the current models (global menu vs a single button ala Chrome) for solving the titlebar/menubar waste-of-space problem and one worth exploring. -- Peaces, Jake
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
