[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] Ideas for Unity Design Tweaks



I like the idea, but we need some sort of suggestive button so that new users can tell that it's related to the menu. But I think mouse over would be better than a click. And I very much support the idea of left alignment for all the menus (maximised or otherwise).

On 29 April 2011 19:03, Ed Lin <edlin280@xxxxxxxxx> wrote:
There are several problems with this:

Drag-click on a menu: on current menus, even with the firefox button
one can press the mouse, the menu appears, move the mouse over desired
entry, release. This is quicker than click, move, click again.
Even if you don't do that, this is a very common user case: you try to
hit a menu entry (top level i.e. File, Edit..) only to realize you
missed, you don't release yet but simple move the presses cursor over
the correct entry. This can't be discerned from a horizontal title-bar
drag.

Second problem: this will result in flickering or a lot of GUI noise
so to speak. This isn't only an aesthetic issue.

Third: people still don't know when to use single and when to use
double-click. They'll try to double click on a menu only to end up
maximizing the window.

How would you like this?
Put a single menu button into the titlebar, right upper corner would
be free but the left side would be better. I'd probably favor one on
the left of the toolbar/tabbar/whaterver below. Click it once and a
horizontal menubar appears temporarily between the tool/tab/*bar and
the title bar, click it twice and it stays.

On Fri, Apr 29, 2011 at 3:58 PM, Toki Tahmid <oxwivi@xxxxxxxxx> wrote:
> In case of C, a double-click is usually too fast for anything to show.
>
> I'm against the idea of wrapping to a new line, it won't look good and if
> the first menu was accidentally invoked, it'd add to the hassle to have to
> close it and then select the menu in the second row.
>
> On 29 April 2011 17:48, Anthony Scire <aaaantoine@xxxxxxxxx> wrote:
>>
>> On Fri, Apr 29, 2011 at 9:12 AM, Toki Tahmid <oxwivi@xxxxxxxxx> wrote:
>> > @Ed, thank you for the lengthy explanation to Fitts' Law.
>> >
>> > That was a mistake, I meant to say horizontally, didn't notice till now.
>> > Anyway, as I mentioned multiple times on other message threads, I
>> > suggest
>> > the placement of menu on title bars of the windows. Unlike the current
>> > menu,
>> > it shouldn't be completely hidden, but slightly faded which would fade
>> > in on
>> > mouse over. IMO, this way will be functionally and aesthetically better.
>> > Windows which currently open small could be wider be default to
>> > accommodate
>> > the menus, and allow some sort of scrolling if deliberately made
>> > smaller. I
>> > won't deny that this idea does pose a problem of dragging, but despite
>> > not
>> > coming up with a suitable solution*, I still want to push forward with
>> > menu-on-title-bar.
>>
>> There are two actions I expect from a title bar.
>> 1. Click and drag to move.
>> 2. Double-click to maximize.
>>
>> (Also, I guess right-clicking for advanced options is nice, too.)
>>
>> Anyway, I don't see why a menu bar built into the title bar -- in the
>> way that you suggest -- should interfere with any of these actions.
>> Consider the following use cases.
>>
>> A. User wants to access one of the drop down menus via mouse.
>> 1. User spots partially concealed drop-down menu title in the window's
>> title bar.
>> 2. User moves the cursor to the drop-down menu.
>> 3. User clicks.  The menu expands when the click is released.
>> 4. User moves the cursor down into the menu and looks for whatever
>> function he has in mind... and so forth.
>>
>> B. User wants to move the window via mouse.
>> 1. User moves the mouse cursor to the title bar.
>> 2. User clicks and drags.  The window moves.
>> 3. User releases the mouse.  If the window was moved more than -- say
>> -- a few pixels from its original spot, or if the mouse button was
>> held down for longer than 2 seconds, then the menu will not expand.
>>
>> C. User wants to maximize by hitting the much larger target (Title
>> Bar) rather than the tiny window control (the Maximize button).
>> 1. User moves the mouse cursor to the title bar.
>> 2. User clicks a first time. On release, the menu expands as described
>> in Use Case A.
>> 3. User clicks a second time, as the second half of the double-click.
>> The menu closes (as a second click on the menu is expected to do), and
>> the window maximizes.
>>
>> I'm sure some accessibility issues will arise from this, but my point
>> is that this should be possible.
>>
>> If the menu bar extends beyond the width of the window, it should wrap
>> to a new line.  Which, in effect, will make the title bar larger.
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ayatana
>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp