Dev:Ref/Outdated/Proposals/UI/Info Architecture/Rationale
Rationale and Objectives
The release of Blender 2.30 brought a new way of organising buttons within Blender using _Panels_. Panels have a lot of potential for good organisation and workflow, however this has yet been largely unrealised. This project can be seen as a continuation and finalisation of the transition from past Blender versions to the panels system.
The most obvious reason for the introduction of panels was that we were quite frankly running out of room. As Blender's feature set has exploded over the last couple of years, so have the UI control needed to operate them. Nearly every Blender user can agree that its 'dashboard' approach of keeping UI controls available and in the buttons window, rather than hidden in layers of menus and popup windows is a positive thing, however with plenty of new buttons, it's obvious that not all of them can be on the screen at one time. In theory, panels can help with this - by grouping and organising functionality, users can hide and collapse away what buttons they are not interested in at the time, keeping an overview of the relevant tools.
In practice, this has not really happened so far (up to and including 2.36) - due to the enormous amount of work and time constraints involved, the current panels' layout are largely a straight copy of Blender's previous 'monolithic' layout, which doesn't work that well. In 2.36, particularly in contexts such as the render context, buttons are so spread out over the entire window that doing what should be a straightforward task such as setting up a render takes a round trip backwards and forwards all over the buttons window. Not only does this require an excessive amount of mouse-hunting and scan-reading, searching around the screen, but it makes it difficult to hide things that are not interesting. Closing a panel to hide away some buttons that a user's not interested in would also hide away completely unrelated buttons, which a user may have wanted to keep open. Since the layout has been ported over, and not been designed to fit within the panels system, there's a lot of inefficient use of space. A good example of this is in the Material context, where setting up textures requires constant flicking back and forwards between the Texture/Map Input/Map To panels, even though each panel has a lot of useful space that could be consolidated.
Another positive aspect of the panels in theory is that they can provide a logical framework for organising functionality, that developers can follow when adding new features. In practice, many of Blender's button contexts are the result of years of evolution and growth, but without codified (or even implied) guidelines for what functionality should be where. In many cases, UI controls have just been added where there was empty space, regardless of how logical it was, or of the visual or psychological effects of their placement there. Since the <=2.36 panels have just chopped up the existing windows into smaller groups, this problem has remained. There is no clear organisation to follow, so the same old habits continue, to the detriment of usability.
Related to this problem is the current problem of lack of visual organisation. There are no guidelines or rules for how buttons should be laid out, for how buttons should be aligned, for what sizes they should be, and so on. As a corollary, this leads to a lack of direction for a user looking for something - there are few consistent places for a user to start searching for things, there are few consistent yet subtle structures that help the interface feel predictable and understandable. This has led to an incredibly messy layout that not only adds a lot of unnecessary visual noise, but also makes Blender feel a lot more difficult and confusing than it really is, or should be. Especially when finding new or rarely-used buttons or features users will have to scour all over the window, hunting without much of a sense of where to find something.
A final issue with the current buttons window is in the language used as labels. Currently, the interface is full of obscure and obtuse abbreviations. Many of them don't make any sense to both CG newbies and people experienced in other applications. Well, they don't make much sense to me either, but I guess I'm used to it now ;). Better chosen terminology can help make Blender a lot more easily understandable, especially for non-native English speakers, who may not see the connection between an abbreviated word and the word it represents. Excessive abbreviation may also make skim-reading slower, since language is read by looking at the shape of the words themselves, rather than by iterating through each character that's stuck together.
So, what can we do about it? These are some of our aims:
Research the contents of Blenders buttons windows and create a new information architecture
- Breaking down functionality into small parts, categorising functionality by sequence of workflow, by Blender's internal structure, by similarity of tasks performed, etc
- Design an organisational structure that links these parts together logically and efficiently
- Provide guidelines for this new organisation that can be followed and extended upon coherently by new development
Design new panel layouts
- With clearly structured visual organisation, easier wayfinding and less visual distraction
- Laid out to reduce hunting around with the mouse
- Grouped to allow hiding uninteresting functionality
- With a more consistent layout that works with the panels, not against them
- Using the available space more efficiently and condensing the amount of panels needed
- Updating language to be clearer and easier to skim-read, preferably with similar or less characters/words
-- MattEbb - 04 Jan 2005
-- Notes from Tripdragon--
I would just like to add in a few notes to the 'dashboard' method. Being a user of the Motion Dashboard app, I need to add in the common useage of the little tool.
From the on set of the 'dashboard' it always contains the same options in it per filter or behavior currently selected in the effects layer window. The options that are available in the 'dashboard' are desided by the software maker and are not editable, but they are the most common and over used of the tools options and adjustments for the effect. Sometimes it is enough and sometimes it is not. When there are not enough options in the 'dashboard' a small "i" icon is at the top right of the dashboard window that will open up the full window that has every available slider and option created for the current effect.
In addition to this window the title bar name has a drop down that will let you select which ever effect is on the object and it will change to that 'dashboard'.
-- What all of this amounts to is a real power to have full screen editing of the scene, and just one floating window for most all needed effect options.
What does this mean for blender? Blender works very well as a full screen editing tool and a shortcut key command to hop back into several windows view for access to menus again.
How Blenders floating menu could be used better is just simply following simple methods by adding in more modes and preset 'dashboards' for the current key tool that is active or whichever mode that the user is in. Example: edit mode, instead of a huge list of loc, rot, size sliders, more useful artistic tools could be in, like extrude, scale, or selection style for loops rings, create face .... Oh so many.. But you get the picture, just find out what is most used for current modes and streamline them in. The fall back will always be as we have now, the full featured menus and hot key popups.
Note< I am not requesting anything here nor am I stating that Apples Motion 'dashborad' tool be copied it has flaws as well, but is very robust and useful for it's job. ^v^--Tripdragon Nov 05
