← Back to team overview

unity-design team mailing list archive

Re: Global menu in Oneiric Ocelot (11.10)

 

On Fri, May 27, 2011 at 1:16 AM, Jo-Erlend Schinstad
<joerlend.schinstad@xxxxxxxxx> wrote:
> On 26. mai 2011 22:53, Ed Lin wrote:
>>
>> enough to warrant that spot. The top panel is misused as place to get
>
> Why do you say it's misused?

Because it's the most valuable space anywhere on the screen to put
interface elements
(horizontal panels have the advantage of suiting text better, they are
the larger screen eges and the top has the advantage over the bottom
that it's where already most of the controls are, where people start
looking for them, usually where the mouse needs to travel less far and
usually it's got the better viewing angle)


> No. Terminal windows were only meant as examples of small
> windows. I often have two text editors on top of each other
> so that I can read from one and write with another without
> having to switch contexts, for instance. In some cases, using
> a tabbed interface is quite nice, but in others, it's much better
> to see everything without having to switch back and forth.

You can only do that on large monitors, 25 px (or something like that)
don't matter *that much*.


> Yes, there might be a few exceptions, which is why I proposed
> making it possible to choose not to use the global menu for
> a single application/window. But it seem very unlikely to me that
> you would ever have a complex application like you're describing
> as a small window. Apps like that tend to be maximized, at least
> vertically, because of those very toolbars that you mention. You
> made a point of that yourself earlier. That means it would almost
> always still be a short distance between the menu and toolbar.

gedit has two bars, nautilus three, pretty much all windows have more
than just the menu, except terminal.

> [woops]
>> (This has also implications with Fitts's Law, if D, the distance to
>>
>> the target, is really small as in this typical case the in-window menu
>> is definitely faster to access on larger monitors)
>
> Regarding the mouse travel to the menu and back, I think that's
> a very interesting point. Would you ever use an apps menu and
> use the mouse for anything else at the same time? That's
> unlikely. So perhaps it would be possible to teleport the mouse
> pointer to the menu when you press alt and back again when
> you're done with the menus? I've never tested anything like
> that, but it might be worth testing.

How would you do that? With the keyboard? Then you'd just use the
already available keyboard shortcuts.

> That's easily answered. The toolbars are filled with the most
> common actions. The menus contains all the other things,
> the much less common actions. The calculator, for instance,
> does indeed have a help menu. How often do _you_ use it?
> It has some other menus too, but I only ever use the one to
> change modes. And I do that from time to time, but not nearly
> often enough for it to warrant a toolbar. So you see, there
> is a big difference between hiding the menu and hiding the
> toolbars. Granted, some applications provide a toolbar filled with
> uncommon actions, just to have a toolbar. That's wrong, and
> certainly both annoying and distracting, but that must be
> fixed in each application. The toolbars should only ever contain
> tools you do want available at all times. The rest should be
> placed in menus and tucked away for when you want them.
>
> I'm not saying that nothing can be done to improve toolbars,
> but I think it's a very different issue.

You got one thing backwards then: The most frequently used items
should be put at the screen edge

>> *Actually I think I know the answer:
>> it's done before, we know it will work
>> it's easier from a technical as well as from a design point of view
>> Doesn't sound like the best reasons to me and I prefer not having a
>> feature to having a broken feature any day.
>
> You were wrong. The fact that it has been done before, would
> never be my answer to anything. That would be an insane
> argument, having in mind all the insane things people have
> done in the past.

Not yours, but whoever is responsible for the more stupid ideas of Unity 1.0...

> It is for these reasons:

I'll reply with the current Unity menu in mind, not the a Mac OS like menu...

> * It gives the desktop a much less technical feel.
an illusion
> * You would never need to read the title of a window and use
>   its menus at the same time.
that's not the point, the point is new users don't even know where the
menu is and old users are slowed down.

> * It conserves space on your screen.
No it absolutely doesn't - the hover thing that is, I've already
explained that several times now) Apart form that it only conserves
space when you tile two or more windows (of the same app) above each
other. This so far is THE ONLY advantage of the menubar.

> * It reduces duplicate information.
it also reduces non-duplicate information (apps opened side by side)

> * It is more aesthetically pleasing.
Yes, at the cost of usability.

> * And (I almost forgot this one, actually): I do think it's more
>  consistent to always have the menus at the same place.

It's less consistent to have system level and application level
elements within the same panel.
It's less consistent to have a menu that always changes depending on
which window you are in (it should be obvious, but it isn't to
inexperience users)

>
> Hope you had fun. :)

Yeah, as always. Though I'm getting a bit tired repeating all that stuff.

> Jo-Erlend Schinstad
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>



Follow ups

References