SV: Gimp-style menus

["Blad, John Erling" <john erling blad aftenposten no>]

> Just like to comment on the position of menu groups:
> the methods that affect the object are better placed on the top (near the
> mouse pointer), then the less frequent ones.

> My argument is based on the assumption that "object methods" are more
> frequently accessed than global actions.

> Also, if global actions are required frequently, toolbars are designed to
> speed up this process.

> Yuting

You should group logically inside a single menu pane. There is virtually
nothing to gain in speed by placing some items higher in the menu than others.
Infact if you don't group them logically you loose speed until the user learns
where they are.

Let's say you have 400 different objects with object methods and each uses
its own menu. You simply ***don't*** group by how frequent each method are.

This situation isn't really that uncommon at all. Look at the file manager
in Windoze. Each item have theire own popup menu (right click menu). In
each and every menu you have a "Properties.." item (My windoze is norwegian,
I belive the english term is properties). When I build web sites I use that one
*a lot* but someone have put it after items that changes for different objects
so I can't learn where the item is.. That's stupid.

So you should not only group logically but also according to how often a menu
item changes. If one logical group changes then you move it down in the menu pane.

Toolbars *can* be faster to use but that depends on the pointing device. A toolbar
is very annoying with a pen device for example.

There are also other constraints that can stop you from using a toolbar like the
screen area. Sometimes even a 2048x2048 haven't the necessary spare area.

The combination of a big screen and some pointing devices can also cause problems.
Toolbars and a big heavy roller ball on a 2048x2048 is sloooow..

John