unity-design team mailing list archive

[Jake Tolbert <crazybilly@xxxxxxxxx>]

On Thu, Feb 17, 2011 at 6:16 PM, Mitja Pagon <mitja.pagon@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> 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