← Back to team overview

unity-design team mailing list archive

Re: Unity Mockup v3

 

2011/5/24 GonzO Rodrigue <worlord668@xxxxxxxxx>

> On Tue, May 24, 2011 at 12:20 PM, Henrik Peytz <henrik.peytz@xxxxxxxxx>
>  wrote:
>
>
>
>> As for "always-visible-vs-menu-toggler", well, I just happen to like
>> getting rid of menus that go unused; consider it an extra feature, you
>> wouldn't have to use it, just keep the menus enabled.
>
>
> I argue the logic here should be reversed.
>
> To the new-ish and/or first time and/or inexperienced user, having to
> discover menus is a terrible, terrible idea.
>
> If you want them hidden just because you like them hidden aesthetically,
> then you should enable the "hide menus behind a button" option, but it
> certainly should not be the default.
>
>
I'm sorry I didn't flesh this one out more. What you're saying is what I had
in mind, I don't intend to have the menus hidden by default, simply having
an option that allows the user to hide them.



> If you place the menus next to the title, then you run the risk of not
>> being able to drag a window
>
>
> I thought we already covered this: all or part of the title would remain on
> the bar, and serve as a drag-handle.
>
> Or, the Opera/Firefox idea (application title serves as menus).
>

It is an interesting idea, and I, as a poweruser would probably welcome it
as I could easily get used to it, but it's a major break (not from Windows,
not from OSX, but the WIMP-convention itself) from what new users would
expect. Also, if you can only move the window with a drag-handle on, say,
the  utmost left part of the title-bar, then you've cut yourself off from
putting the window anywhere before 0 on the x-axis of your monitor. It
doesn't really matter where you put the drag-handle, you'd always be limited
to only moving the window to a place where the drag-handle is visible, which
is one of the reasons we use the whole length of the titlebar to move stuff
across platforms.

Follow ups

References