unity-design team mailing list archive

[Toki Tahmid <oxwivi@xxxxxxxxx>]

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
>