Blender 3d workflow is very good once you have understood its oddities, most agree on this. However the interface itself, even if not really bad, is not quite up to this level of quality and should be improved in many ways, often little details but very importants.
First have a look at : www.shadeless.dk/ui/ Monkeyboi had already put a lot of reflexion in that and his proposals are mostly pertinent.
However, I think that an approach at an higher level is required. I will take its analysis as is, just emphasing points where mine differ.
I will refer to views instead of windows for what's drawn in the main window, it's clearer and will be needed if blender ever support multi-window (which is a needed feature).
With the release of the preview version of Blender 2.30, its interface has improved very dramatically. In fact, this is the biggest UI improvement in the history of Blender (at least since it became public). Lots of things have been improved. Lets take a look at what has been done UI-wise in 2.30:
These are all fantastic things that improve Blender as a whole. However, there is still lots of things that can still be done to improve the following things. These include improving :
To do this, we need a set of rules to follow. These are from the 2.30 UI proposal doc:
All this is true, but lack IMHO some of the main points :
- UI work should focus on Constitency, flexibility and modeless steps.
- GUI need quite some work for :
- the UI (user interface) is the way the user interact with the software, it does not matter if you hitted a menu, a shortcut or a button, what counts is what happens after. Here the importants point are Constitency, flexibility and modeless steps. Mostly, UI will include mouse steps.
There is work to do in this part, but as good workflow already exist it's more improving than correcting design flaws (although latters are there too).
- GUI is graphical representation of the User Interface, but also the more general window layout. As such its role is to present user information and getting input.
Blender use different 14 types of views for each task, each having its own header with GUI and menu stuff. Headers can be displayed or not and the user can rearrange, add or remove views at will (with restrictions only in the way things can be splitted or joined)
That quite a lot but the button view is the most important (in GUI terms), as actions and setting user feedback are presented here. To further added complexity this one is subdivided is six button sets, 2 of them having 8 sub-sets. Each present a serie of panels which are context sensitive. It's pretty obvious that any GUI improvement should focus first on this due to its importance and size.
The other very important one is the info view whose header act also as window menu bar. its role being special, its handling should too IMHO.
Shortcuts are not part of the GUI but allow as the name suggest to speed actions by avoiding the GUI part.
That means that shortcuts (or graphical elements called by a shortcut) should be never the only method to do something. Ideally all should be in menus, but in any case access must be granted at least via the button or info view.
As signaled blender window can be splitted at will in many views, there is few things to improve there, except two points I feel important :
- The info view having a special role, It should be always available.
I feel that this one position should be restricted to top of window with only the ability to be hidden by grabbing it under the bar. To unhide it, grabbing too at the window bar. this will allow to remove a view from view menu as bonus.
- I agree with MonkeyBoi that button view header, and only this one, should be put in vertical position when the view is on the side.
its mockup : www.shadeless.dk/ui/verticalheaders.jpg shows clearly that's this is the only solution to have all buttons visible.
Missing from it, there is the menu item panels that can be switched to an icon.
The frame counter could have a vertical version where arrows are above and under the frame number.
There is also changes to do on the buttons themselves but more on that later.
in any view a button or menu item which is not available or authorised on current selection must be disabled. Standard practice is to present it greyed out.
- Info view
As said this view has a special role. When deployed it hosts the users preferences, but its most important use is as menu bar.
There is 3 parts in it :
- menus :
* "file" item seems fine and dont call for comments except adding a preference entry : www.shadeless.dk/ui/Preferences.htm
* "add" is more than a bit odd, it does not fit at this level (the most general one), or imho should at least be replaced by a "toolbox" entry which comprise it.
* "timeline" fits in, it's general enough, but an entry should be added to lock things at a particular frame, for those who are not making an animation
* "game" is fine too
* "render" miss one entry : "toggle render buffer" (J)
* "Help" is underpopulated for now
- screen and scene popup buttons : they fit certainly there but the widgets should be improved, see below.
- info fields
this field give some statistics, I second Monkeyboi proposal : www.shadeless.dk/ui/object_info.htm
UI changes in the preference part of it are secondary.
- BUTTON VIEW
All happens here, thats why this view is so important.
I will discuss of specific placement of button later, but I want first to make some general remarks.
* header
- first we have the panel menu which is the only one here. To /blend/ with the rest, an icon menu would be better and it will allow the view to be put vertically.
- then we have an iconized set selector with subsets available sometimes.
this selector allow to present different context sensitive panels in the view main area
- finally a frame counter.
One problem is that the position of the frame counter changes when subsets button icons appear and disappear. Its not good and a simple way of solving that is to simply put it before the iconized selector. adding a lock just beside would help too, I think. An alternate system would be to have all sets and subsets visible at all time, disabled if needed. This would although clobber a bit the interface.
Secondly icons are not clear. this will not worry experienced users but can disturb newcomers. The worst ones are logic and edit ones. There is also problem in the higlight and state logic but we will deal with this in widget part.
The most important point is to disable non available modes or submodes when needed such as lamp texture submode when no lamp is selected or radio panels when radiosity is not enabled in render panels.
the logic set is so different from the others, that IMHO, it should be promoted at the view rank. It's graphics should also the same as other views or sets.
* panels
each panel present a number of buttons and input fields. If some buttons are misplaced, the first point to consider is the general layout. Actually there is no common design and many different sizes and grouping are used which lead to almost empty or very messy panels. grouping is made by gluing buttons together which can be confusing and reduce legibility. labelling is also non consistent.
For me, a legible layout has the following requirements :
- legible widgets (see below)
- good feedback to user
- button never touch themselves but are grouped via a border or background shades. A border has the advantage of allowing making a title to the group.
- clobbering is reduced by a two level system where button controlling less used settings give access to a secondary panel (like edge setting button). the usual rational to having all buton accessible at first level for speed reasons does not stand for seldom used settings.
- layout is fixed on a standard grid and sizes are standards (2 or 3 sizes max)
for maximum flexibility a 6 or 7 collumns grid is the best choice imho, with standard button size at 2 collumns, at the exception of path fields
- non usable buttons are disabled rather than removed from panel.
- only full groups are allowed to be made invisible as appropriate.
- WIDGETS
One problem of blender interface is that different widgets have not enough graphic differences. Latest trend is to use color, but you should never rely on color only. As buttons are OGL drawn, we must however keep them simple.
first lets do a review of the different kinds of controls :
- global momentary push button (eg Render button)
- selection momentary push button (eg most of the edit buttons)
- action momentary push button (eg vertex groups ones)
- settings toggle
- settings 3 state toggle (eg Nor in textures)
- settings toggle controlling subgroup
- radio buttons
- choice popups (shaders types)
- editable list popups
- menus popups
- value fields
- value fields with arrows
- path fields
- sliders
- color block
- popup panels (edges settings)
- ancilliary small buttons
- some special controls (like layers)
icons or icons+text versions of thoses exist too.
all controls should have normal, highlighted and disabled states. A mouse over state is also needed
the first thing is to differenciate push, settings, radio and field types. This must be a GRAPHIC difference, not only color.
One easy way is to use radius of edges:
- push could have round edges
- setting squared with rounded corners
- fields squared
a radio button is a setting button with a modificator identifying it's radio. All radio of a given groups are linked in a visual way.
following diagram shows an example of different kinds of button in all states. I have used HSV to make the differences between states.