[Bf-funboard] Expanding the menus - proposals
Ton Roosendaal
bf-funboard@blender.org
Sat, 9 Aug 2003 15:42:16 +0200
Hi,
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
user-preferences.
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:
PULL DOWN MENUS:
- always show all options that exist, preferably grey-ed out when not
effective
- 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
settings
BLENDER WINDOW HEADERS:
- always show available 'window manager' options (Space type, full, etc)
- toolbar style icons for visualizing 'Space' related state & options
BUTTONS WINDOW(s):
- context-sensitive visualization of data, options, and presenting
tools.
- the context is defined by the current scene, the active data block as
indicated in its window header, and the mode.
TOOLBOX:
- context-sensitive display of (all) available tools and actions (no
states)
- the context is defined by current mode, selection, and/or active item
HOTKEYS:
- messy: a global list of keys, space-related keys, mode related (as is
now)
- 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
option?
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
way.
- 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
persistant?
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...
-Ton-
(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
http://www.blender.org