[Bf-funboard] Buttons organisation guidelines

[Matt Ebb]

Firstly I apologise for my recent quietness, I've had a lot of thoughts and
ideas about these things but not enough time to heavily participate in these
discussions :( Too much work, not enough sleep....

One other thing - it would be nice to try and segment these discussions a
bit. Working out the text labels and visual design issues is somewhat of a
separate issue to the organisation. It helps not to mix things up too much
as it confuses the issue at hand.

So far, there's been lots of talk about 'no that button should go there',
but it's all very caught up in details. I feel it would be best to take a
step back and look at the bigger picture. If we can work out some general
rules/guidelines/philosophy that we can then apply to the window spaces and
panels consistently, I feel it would make life much easier for not only now,
but in the future when new buttons are inevitably added. We can design a
beautifully laid out and fitting panel now, but what happens in 2.31 or 2.32
when we need more buttons? Ton mentioned recently that (including menus)
there are over 1700 different buttons in Blender. We can't keep nit-picking
over what button should be next to what, for the rest of Blender's life
every time something changes - it's just too time consuming and diverts
attention from other important cool stuff! :)

So, here are some of my initial thoughts on this matter, going back to the
original idea of clearly defining 'contexts' within Blender:

As mentioned in the initial 2.3 UI doc, Blender contains these various
contexts that the user works in:
1. Current project or scene
2. Current window type (aka space)
3. Current 'indicated' data (active object, material, ipo, etc)
4. Current mode
5. Current selection and 'active' item (vertices, faces, strips, etc)

The layout of the panels are mainly concerned with levels 4 and 5 (level 3
can sometimes determine what 'tab' or set of panels are currently shown, but
not really the layout of the panels and buttons themselves)

Different buttons are accessible and relevant to different modes and
selections. There is also another distinction of buttons which are related
to settings (like subsurf level) and which are related to actions or tools
(like subdivide). Generally, the settings will act on the entire ObData or
Object (like a mesh), while the tools will act on a selection within that
obData (like vertex). I'd include buttons like the remove doubles limit in
the 'tools/actions'. Of course there are exceptions, but that seems to be to
be the general logic. Communicating these differences through the
positioning of the buttons will help to make the interface less random, and
more predictable (giving a feeling of being in control).

So my initial proposal. in grouping these buttons together:
1* Try to keep panels mode-specific. i.e: don't mix buttons that are
dependent on different modes
2* Try to keep panels specific to either tools or settings

We can come up with guidelines for organising these panels within the
window, for example:
* Panels containing settings go towards the left/bottom side, Panels
containing Actions towards the right/top side
(this is a bit similar to how the < 2.3 editbuttons are laid out)

Another example for this could be in organising the Render buttons - The
settings (that control settings in the Scene datablock) such as the output
paths, file types, rendering effects) could be organised on the left, while
the actions such as Render, Anim, Play would fit nicely on the right side.
This also fits nicely with a workflow progression from left to right (1. set
up the file paths, 2. choose your effects, 3. render), rather than having to
dart back and forwards all over the screen as we currently have to.

When it's not possible to cleanly separate buttons into different panels, we
can at least try to group things that way within the panel, so for example
in the mesh vertex weighting groups, the buttons to set rename, creating
new, delete vertex groups is a setting that acts on the mesh ObData, but the
buttons to assign or remove vertices to the vertex groups are tools that act
upon the current selected verts. So under this scheme, the group
name/selector, 'New' and 'Delete' would be grouped together, while 'Select',
'Deselect', 'Weight: ', 'Assign' and 'Remove' would be grouped together.

We can even come up with guidelines for how to do this, such as:
* When panels must contain mixed settings and actions, organise the actions
at the top of the panel and settings at the bottom

Anyway, I've written a hell of a lot and it would be nice to have some
feedback on or additions to these guidelines. Please ask questions if you
have any - I fear some of this may be hard to understand since I'm so tired
:( In any case, without a nice structured design to base things on,
quibbling over specific buttons will be futile in the long run, so this is
something that needs to be adressed.

Cheers

Matt