[Bf-funboard] Buttons organisation guidelines

The Fallen Weeble bf-funboard@blender.org
Wed, 15 Oct 2003 10:02:04 -0400


Good idea, and great suggestions!  Getting a set of guidelines
determined now will save us a lot of headache (now and in the future).
With a good set of guidelines established, well over half of the
discussions here wouldn't be happening.  It would be a (not necessarily
simple, but definitely more straight-forward) case of looking at a
UI element and asking the following questions:

1) What does it do?
2) Based on what it does, where does it categorically fit in terms of
the guidelines?
3) Now that we know where it belongs, how do we put it there.

We're jumping into the specifics far too quickly in these discussions,
and I think getting the guidelines down first will ultimately get things
done faster.  Now... on with the discussion...

On Wed, Oct 15, 2003 at 07:49:51PM +1000, Matt Ebb wrote:
-- <snip> -- 
> 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)

I like the way this works.  It's a good rule of thumb for users to
figure out the interface and it will make it easier for us to decide
where a given UI element should be placed.

> 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.

Very nice!  Are there other examples of where this workflow-based
arrangement can be applied?  It makes a lot of sense and can be easily
understood even on a subconcious level.  This is definitely a guideline
I'd be interested in having.

> 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

I like the consistancy that this has with the way the panels are
organized.  If there's anything we need, it's consistancy.

Now that I think about it, for the guidelines, I would suggest that we
also have a notion of what has priority.  What I mean is that if a UI
element can possibly placed in two different locations based on the
guidelines, then one guideline should have a greater importance than the
other.  For instance, if Random UI Element "Foo" can be placed on the
right because it comes at the end of the workflow (workflow placement),
but can also be placed on the left because it is a setting (consistancy
placement, for lack of a better name), we should be able to go the
guideline and see something a priority list of the kinds of placements
like so:

1) Consistancy
2) Workflow
3) Grouping
4) Something else
5) Blah

Based on that, Foo would be placed on the left because consistancy has a
higher priority than workflow (this can be debated, I'm just giving it
as an example for now).

Comments?