Blender User Interface Proposal (or something)
1. What this is all about
Since Blender has now become a community based project, I also decided to harass people by sharing my perverted views. The intent of this draft is to define what would make (or already makes) a good Blender UI and how this could be implemented. I wish to get proposals what could be done and how it could be made. If this paper evolves enough it could be used (well, maybe) by implementors of future Blender versions.
So, here you go, the First Draft :)
2. Interface design goals
Interface should be accessible both to newcomers and people with disabilities. This requires that same things could be done many ways. Eg. everything can be done just by using a pointing device with menus. As I see, it is quite impossible to use this kind of program with just a keyboard, or at least it would be very slow.
Interface should embrace an experienced user by providing ways to do things faster. It should not restrict the speed of the user: eg. usually all kind of eye-candy, like animation in menus, is a bad thing. It comes to the way and restricts user from achieving his/her goals at the maximum speed.
2.3 Consistency (related to both Accessibility and Speed)
Interface needs to be consistent. It needs to have a logic, either some general logic as usual in windowed programs, or a logic of its own. Same kind of things should happen in a same way all over the program.
2.4 Customisation (related to all above)
Users always know best what their needs are. Interface needs to allow reasonable amount of customisation in order to suit the specific needs of an individual. This does not include eye-candy. But it includes things like the possibility to change general feel of an interface, eg. hotkeys to emulate some other application. Also it includes a limited way to change the look of an interface; for example font color, font size depending on your screen resolution etc.
3. Methods to achieve goals
3.1 Modular structure
I propose a moded program structure where there would be different modes for different things while the interfaces to these modes would be same. In other words: whatever the data, user can visualize it the way he/she wants.
This approach can also be a plus for actual programming, since actual Blender could only be a module loader and modules can be developed differently from each other as long as they are compatible with Blender itself. Modules could be loaded differently, eg. user could choose to leave game-engine out just by editing startup list.
3.11 Modes needed
- Geometry: mesh and surface editing etc., includes geometry transformations in time.
Handles: how things look, how things transform.
- Scene: objects, lights, camera
Handles: how things connect, how things transform in time, how it renders.
- Material: compositing textures, adjusting properties etc.
Handles: look of objects (in time)
- Logic: scripts and things related
Handles: how things interact
3.12 Visualisation of data
Different modes can be visualised in a different ways. Here are the most needed.
To be used for Geometry and Scene.
To be used for Geometry (eg. how bones are connected), Scene (how scene is build), Material (how things are chained to form a material) and Logic (how script is constructed). This approach allows almost anyone with a proper mindset to build, possibly very complicated, structures to solve a problem.
To be used for Geometry (transformations in time), for Scene, for Material (animated materials), for Logic (frame-based actions).
To be used for Geometry (ascii representation of an object), for Logic (pure-code). Can also be used to show and edit whole Scene or Material.
Btw. XML fileformat could prove to be useful allowing off-blender generation and easy saving / converting from / to other programs.
UI needs to tell the user what it is doing, what user is doing and what user has done. And do it clearly.
Menus (or rather, pie-menus) that are adaptive to the current task and list only things that are possible to do. In geometry-editing it would list only things that are possible to perform.
Fast adaptive pie-menus could also make big button panels unneeded and therefore free up screenspace for actual work: editing, animating etc.
3.5 Strict ruleset hotkeys
Hotkeys are usually implemented by following natural language: e for edit and so forth. This is easy to learn but it's also quite slow to use as keys are not physically arranged in suitable way. And soon it becomes impossible to find keys suitable for an action.
The other solution is to make hotkeys totally artificial by defining a strict logical and coherent ruleset: q would always mean edit, w move or something very similar regardless of the mode in use and so forth.
This may be slower to learn but faster to use, as keys can be physically arranged for minimum hand movement. Internal logic should stay consistent.
Ps. the latter solution can also be tied to pie-menus. Q would be equivalent to a pie-menu entry at clock 12, W at clock 1, E at clock 2 etc. This can be useful but it can also render hotkeys unworkable if there is a new entry in the middle of the menu.
If you feel all of this was filled with stupidity you are probably right, as it is very much IMHO and written fast by an ignorant person. Enjoy :)
Last edited by alt on Wed Dec 18, 2002 10:26 pm; edited 1 time in total
There are some good ideas in there. However I think in a toolbox marking menu, it's a better idea to show all available options, with the non-relevant ones 'grayed out' or somehow shown to be inactive (i.e. not adaptive). An interface that is constantly changing on the user makes its hard for that user to build a conceptual map of the system and find out where all the different options/functions are (see Microsoft's horrible band-aid solution to all the hundred of options in Office - semi-arbtrarily hiding options from the user so that the menus change from time to time). Having a system that changes on the user leads to a feeling of helplessness and uncertainty , when the goal should be to have the user in control at all times.
Having a consistent set of menus is also much faster, because a user's brain can use spatial memory as well as linguistic. i.e. instead of having to look through the menus to find a particular word, after enough use of consistent menus, a user will be able to remember the physical location of the option in the menu and move the mouse there pre-emptively, even if he/she hasn't finished reading the text labels. Incidentally, this is part of the argument for pie menus - using the brain's powerful capability for spatial memory (which works best with angles rather than lists).
Yes, I thought of separating actions into two menus by their range of influence.
Something like this (though the logic could be better):
General menu (system-wide)
- actions that are system wide or affect all data (like load, save, clear or changing interface settings from list-menus to pie-menus :)
Tool menu (subsystem-wide)
- actions that are possible to do in that subsystem to modify data (eg. flowchart editing)
- actions that are the same or follow the same logical ruleset would be placed to same places in every menu to increase speed and help learning (like grab)