[Bf-funboard] Expanding the menus - proposals

Ton Roosendaal bf-funboard@blender.org
Sat, 9 Aug 2003 15:42:16 +0200


Great analysis work, with looking at xsi & maya. Feels good to know  
that they're fighting the same topics as we do! :)

The three proposals mentioned in this mail are very hard to choose  
from... although I think the third one is most confusing. Is "add  
strip" for the sequencer located in the top bar? And more of these  
questions... If we cannot find a very coherent & predictable rule for  
where menu items can be found, we better not choose for '3'.

You also deliberately choose not to propose the XSI variant, with about  
everything   in the main menu? I also think that would be a mess...

 From a 'how Blender works' perspective, the 2nd option could work  
fine... but you don't mention the main 'con', and that's that window  
headers currently draw a 'toolbar', which now easily disappears out of  
sight... OTH, quite some of the toolbar options can be relocated to a  
pull down menu.
This variant also could be combined with a new *vertical* toolbar,  
which is something I thought of before... in the horizontal bar the  
main window-related options can stick (like full-window, but also  
'browse datablock'). The vertical one is restricted to toolbar icons,  
user-defined available, and can even be constructed based at  

The first option is something I still like, for simplicity. There are  
'cons' too, but I don't agree with two of Matt's:
- another 'mode' to worry about: I don't think this system will work  
counter-intuitive for anyone. You'll notice, while working, almost  
immediately that this functionality exists. It's not as bad as 'edit  
mode' or 'vertex paint mode', where you actually can get stuck.
- programming it is piece of cake, and I'll happily help with such  
stuff (also for the other proposals of course!)
Most obvious 'con' is this extra click... which can be annoying when  
you've pressed a material button or so, and then want to add a new  
object in a 3d window.

So... didn't make up my mind really on it. Maybe we can clarify the  
discussion by putting a few general definitions and guidelines in place:

- always show all options that exist, preferably grey-ed out when not  
- the location of items in a menu is fixed, no MS 'hide' feature
- pull down menus are not (or minimally) context sensitive
- pull down menus don't (or minimally) visualize 'state' or data  

- always show available 'window manager' options (Space type, full, etc)
- toolbar style icons for visualizing 'Space' related state & options

- context-sensitive visualization of data, options, and presenting  
- the context is defined by the current scene, the active data block as  
indicated in its window header, and the mode.

- context-sensitive display of (all) available tools and actions (no  
- the context is defined by current mode, selection, and/or active item

- messy: a global list of keys, space-related keys, mode related (as is  
- we could think over how to make this configurable

Or, in the light of these three interface paradigms:
1. Easy to learn:
- now much better assisted by pulldown menus and toolbox
- problem: is 'add material' and 'show material editor' a pulldown  
2. Easy to use:
- we still have our hotkeys!
- a toolbox will prove to be powerful too
3. Easy to make:
- I don't see any coding problems for the proposals

Now we've got a few major problems left!!!

The evil modes:
Modes are considered to be against 'good interface design' rules... and  
I can understand that. Although Blender attempted to nicely separate  
functionality in the individual window types ('spaces'), they also  
relate to each other, sending signals around and even sharing data...  
for example:
- Object EditMode gives different buttons in ButtonsWindow
- VertexPaint/FaceSelect affect ButtonsWindow as well
- Activate an Object, changes the IpoWindow
- etc
Plus; the modes block off editing options, which can feel illogical for  
a user.

Lack of button/interface space:
- IpoWindow buttons are in... ButtonsWindow!
- 3DWindow buttons (lens, backimage) too, but in a confusing different  
- we still don't have an animation frame slider... where!?
- the current buttons system layout is totally inflexible
- temporal button panels like the NKey (for object) should become  

Continuing this evaluation, we should distinguish the contexts or  
"Mental Models' for the Blender interface, which a user has to be aware  
of to work with Blender:

- Current window type (space)
- Current 'indicated' data (scene, material, ipo, etc)
- Current mode
- Current selection and 'active' item (face, strip, bone, etc)

A definition of 'context sensitivity' has to to take account for these  
four aspects. I can imagine we define the first context (window) as  
being acceptable for a user to 'learn by guessing', and therefore  
accept pulldown menus being relative to this context. Which makes  
Matt's first 2 options both acceptable.

The latter three contexts should be strictly applied on for the rest of  
the interface... which hopefully can be looked at in designing a new  
'toolbox', and by re-doing the current ButtonsWindow system. With the  
currently existing modes still evidently the biggest troublemakers...


(sorry for the long text, didn't intend it!)

On Saturday, Aug 9, 2003, at 11:19 Europe/Amsterdam, Matt Ebb wrote:

> Ok, I've written up a list of feasible proposals for the functionality  
> of
> the menus. Each of them would be possible and 'not too bad', but I  
> prefer
> the 3rd, for the reasons I've mentioned.
> Have a look here: http://mke3.net:9000/blender/ui/menus/proposals_1/
> and let me know what you think.
> Cheers
> Matt
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard
Ton Roosendaal  Blender Foundation ton@blender.org