unity-design team mailing list archive

[Ian Santopietro <isantop@xxxxxxxxx>]

The reasoning for the global menu bar isn't just about saving screen space.
It's also about reduction of UI chrome to provide an interface that looks
cleaner and simpler. Mouse travel distance *is* irrelevant since mouse
acceleration allows for great travel distances from short, twitchy
movements. It is also easy to hit the menu, as it's on a screen edge and
easy to hit vertically. I work with a *trackpad* on a very large monitor,
and of all if the pointing issues I have, the only serious one is when I
need to aim in two dimensions.

This brings to the real flaw with the global menu. As it's hidden by
default, users don't know what to aim at, thus forcing them to stop and
re-aim at the menu they want to use. This is the real speed killer with the
current global menu implementation. A better solution would be to have the
global menu visible by default.

In the current implementation, there is a way to disable the global menu.
This should be easier to configure for users that don't want the global
menu. Also, I think adding an option to keep the current behavior would be
good, as I'm sure some people like the lack of visual clutter it provides.
On May 18, 2011 2:54 PM, "Niklas Rosenqvist" <niklas.s.rosenqvist@xxxxxxxxx>
wrote:
> Sorry people for accidentally sending duplicates, here is the real
version:
>
> 2011/5/18 Bazon <bazonbloch@xxxxxxxx>
>> i could also imagine a window grip button
>> for moving the window when the whole title bar is occupied by menus for
>> moving the window.
>
> Without testing I just get the feeling that this would be ineffective
since
> I know that I much more often move a window than go to it's menu. A small
> grip will probably be annoying to always find with your cursor. The whole
> title bar provides a much easier and faster way of rearranging windows.
>
> I made some sketching on this and came up with a mockup which you can find
> here:
> http://i.imgur.com/f8q2c.png
>
> The three top images is describing the solution we've talked about and the
> fourth image is an extension of the implementation we've discussed. This
> implementation is possible today thanks to a plugin, but it would be sweet
> to have it natively.
>
> 2011/5/18 Niklas Rosenqvist <niklas.s.rosenqvist@xxxxxxxxx>
>
>> 2011/5/18 Bazon <bazonbloch@xxxxxxxx>
>> > i could also imagine a window grip button
>> > for moving the window when the whole title bar is occupied by menus for
>> > moving the window.
>>
>> Without testing I just get the feeling that this would be ineffective
since
>> I know that I much more often move a window than go to it's menu. A small
>> grip will probably be annoying to always find with your cursor. The whole
>> title bar provides a much easier and faster way of rearranging windows.
>>
>> I made some sketching on this and came up with a mockup which you can
find
>> here:
>> http://i.imgur.com/f8q2c.png
>>
>> The three top images is describing the solution we've talked about and
the
>> fourth image is an extension of the implementation we've discussed. This
>> implementation is possible today thanks to a plugin, but it would be
sweet
>> to have it natively.
>>
>> 2011/5/18 Bazon <bazonbloch@xxxxxxxx>
>>
>>> Am Mittwoch, den 18.05.2011, 15:15 +0200 schrieb Niklas Rosenqvist:
>>> > Or to avoid movement, switch between titles and menus in the
>>> > titlebars.
>>>
>>> I like that idea:
>>> Consistent (menu/title toggle as for maximized window now, than simply
>>> for all windows)
>>> and contextual (it's clear where every menu belongs to).
>>>
>>>
>>>
>>> Additionally to the before mentioned idea of a menu/title toggle button
>>> next to the window controls, i could also imagine a window grip button
>>> for moving the window when the whole title bar is occupied by menus for
>>> moving the window.
>>>
>>>
>>
>>