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

Re: [Ayatana] Ideas for Unity Design Tweaks



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