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.