[Bf-funboard] Buttons organisation guidelines
William Reynish
bf-funboard@blender.org
Wed, 15 Oct 2003 13:40:03 +0200 (CEST)
--0-222847739-1066218003=:14122
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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
Yes, that is probably a good idea
>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! :)
Well, will never, as far as I know be such a bit UI change as when 2.30 arrives. That is why it it important that we get the button placement right. Otherwise we end up with a new UI in 2.3 wich we would have to alter hevily again in 2.31. It is important that we get the placemenments right the first time.
>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
Well, that is the hard thing to do, unless you want to end up with a layout where groups of buttons don't relate to each other, that are only in the same group because it fits with the modes. But it would look nicer if all the buttons in a panel worked for a specific mode. This is a bit tricky to do. Maybe the main problem, is more in what things are possible in what modes. For example it is a bit silly that you can add, but not delete new Material Groups in object mode.
I do agree it would be quite cool if buttons for different modes could be put together: I'm just not sure what is the easiest to understand. The graying out of irrelevant buttons is certinately a thing that will make working with modes alot easier.
>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)
Well, what if a tool and a setting is related (they often are)? This means that when you wold want do change the Edge Settings, you would have to first reach out in one area to anable edges, and then, in a completely different area to alter the settings. This would make things much more confusing than the current setup in 2.28. You wouldn't know which settings related to wich actions, and even if it said so in the tooltip, it would be confusing. Actions and settings that are related to each other should be next to each other.
>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)
We could organise it so that the Render panel was placed far right and the same panel, as it alredy is, on the far left. This is not that important I don't think. I think alot of people would like the Render panel to be fairly in the middle.
>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.
Hmm.. I think Select/ Deselect fits better close to the New, Delete and renaming buttons, because it is then logocal that it selects the selected Vertex Group, which is exactly what is does!
>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
Again, I have to disagree. I think that buttons that are related to each other should be grouped together, not buttons that react in similar ways. I really think it would be very confusing to organise it so that all the actions were seppereated from the settings.
>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.
Yes, it would be good to have a general buttons layout philosophy. I propose a slightly different philosophy though:
1, All buttons that are related should be placed next to each other.
2, The buttons should be put into groups wherever possible so that the user would be able see what a specific function relates to. (for example evrything that has to to with how an object is displayed could be put in a Display box, like in this image: http://www.shadeless.dk/editbuttons2.jpg)
3, Then there is all the buisness of making a collapse system where you can minimise some settings, and the vertical layout idea, but I think we all agree that those are good ideas.
Regards, William (Monkeyboi)
------------
Yahoo! Mail - Gratis: 6 MB lagerplads, spamfilter og virusscan
--0-222847739-1066218003=:14122
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
<DIV>One other thing - it would be nice to try and segment these discussions <BR>a<BR>bit. Working out the text labels and visual design issues is somewhat <BR>of a<BR>separate issue to the organisation. It helps not to mix things up too <BR>much<BR>as it confuses the issue at hand.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR><BR>>So far, there's been lots of talk about 'no that button should go <BR>>there',<BR>>but it's all very caught up in details. I feel it would be best to take <BR>>a<BR>>step back and look at the bigger picture. If we can work out some <BR>>general<BR>>rules/guidelines/philosophy that we can then apply to the window >spaces and<BR>>panels consistently, I feel it would make life much easier for not only <BR>>now,<BR>>but in the future when new buttons are inevitably added. We can design<BR>>a<BR>>beautifully laid out and fitting panel now, but what happens in 2.31 or <BR>>2.32<BR>>when we need more buttons</DIV>
<DIV> </DIV>
<DIV>Yes, that is probably a good idea</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>>Ton mentioned recently that (including <BR>>menus)<BR>>there are over 1700 different buttons in Blender. We can't keep <BR>>nit-picking<BR>>over what button should be next to what, for the rest of Blender's life<BR>>every time something changes - it's just too time consuming and diverts<BR>>attention from other important cool stuff! :)<BR></DIV>
<DIV>Well, will never, as far as I know be such a bit UI change as when 2.30 arrives. That is why it it important that we get the button placement right. Otherwise we end up with a new UI in 2.3 wich we would have to alter hevily again in 2.31. It is important that we get the placemenments right the first time.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>>So, here are some of my initial thoughts on this matter, going back to <BR>>the<BR>>original idea of clearly defining 'contexts' within Blender:</DIV>
<DIV>><BR>>As mentioned in the initial 2.3 UI doc, Blender contains these various<BR>>contexts that the user works in:<BR>>1. Current project or scene<BR>>2. Current window type (aka space)<BR>>3. Current 'indicated' data (active object, material, ipo, etc)<BR>>4. Current mode<BR>>5. Current selection and 'active' item (vertices, faces, strips, etc)<BR><BR>>The layout of the panels are mainly concerned with levels 4 and 5 <BR>>(level 3<BR>>can sometimes determine what 'tab' or set of panels are currently <BR>>shown, but<BR>>not really the layout of the panels and buttons themselves)<BR>><BR>>Different buttons are accessible and relevant to different modes and<BR>>selections. There is also another distinction of buttons which are <BR>>related<BR>>to settings (like subsurf level) and which are related to actions or <BR>>tools<BR>>(like subdivide). Generally, the settings will act on the entire ObData <BR>>or<BR>>Object
(like a mesh), while the tools will act on a selection within <BR>>that<BR>>obData (like vertex). I'd include buttons like the remove doubles limit <BR>>in<BR>>the 'tools/actions'. Of course there are exceptions, but that seems to <BR>>be to<BR>>be the general logic. Communicating these differences through the<BR>>positioning of the buttons will help to make the interface less random, <BR>>and<BR>>more predictable (giving a feeling of being in control).<BR><BR>>So my initial proposal. in grouping these buttons together:<BR>>1* Try to keep panels mode-specific. i.e: don't mix buttons that are<BR>>dependent on different modes</DIV>
<DIV> </DIV>
<DIV>Well, that is the hard thing to do, unless you want to end up with a layout where groups of buttons don't relate to each other, that are only in the same group because it fits with the modes. But it would look nicer if all the buttons in a panel worked for a specific mode. This is a bit tricky to do. Maybe the main problem, is more in what things are possible in what modes. For example it is a bit silly that you can add, but not delete new Material Groups in object mode.</DIV>
<DIV> </DIV>
<DIV>I do agree it would be quite cool if buttons for different modes could be put together: I'm just not sure what is the easiest to understand. The graying out of irrelevant buttons is certinately a thing that will make working with modes alot easier. </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR>>2* Try to keep panels specific to either tools or settings><BR><BR>>We can come up with guidelines for organising these panels within the<BR>>window, for example:<BR>>* Panels containing settings go towards the left/bottom side, Panels<BR>>containing Actions towards the right/top side<BR>>(this is a bit similar to how the < 2.3 editbuttons are laid out)</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Well, what if a tool and a setting is related (they often are)? This means that when you wold want do change the Edge Settings, you would have to first reach out in one area to anable edges, and then, in a completely different area to alter the settings. This would make things much more confusing than the current setup in 2.28. You wouldn't know which settings related to wich actions, and even if it said so in the tooltip, it would be confusing. Actions and settings that are related to each other should be next to each other.</DIV>
<DIV> </DIV>
<DIV><BR><BR>>Another example for this could be in organising the Render buttons - <BR>>The<BR>>settings (that control settings in the Scene datablock) such as the <BR>>output<BR>>paths, file types, rendering effects) could be organised on the left, <BR>>while<BR>>the actions such as Render, Anim, Play would fit nicely on the right <BR>>side.<BR>>This also fits nicely with a workflow progression from left to right <BR>>(1. set<BR>>up the file paths, 2. choose your effects, 3. render)</DIV>
<DIV> </DIV>
<DIV>We could organise it so that the Render panel was placed far right and the same panel, as it alredy is, on the far left. This is not that important I don't think. I think alot of people would like the Render panel to be fairly in the middle.</DIV>
<DIV> </DIV>
<DIV><BR>>When it's not possible to cleanly separate buttons into different <BR>>panels, we<BR>>can at least try to group things that way within the panel, so for <BR>>example<BR>>in the mesh vertex weighting groups, the buttons to set rename, <BR>>creating<BR>>new, delete vertex groups is a setting that acts on the mesh ObData, <BR>>but the<BR>>buttons to assign or remove vertices to the vertex groups are tools <BR>>that act<BR>>upon the current selected verts. So under this scheme, the group<BR>>name/selector, 'New' and 'Delete' would be grouped together, while <BR>>'Select',<BR>>'Deselect', 'Weight: ', 'Assign' and 'Remove' would be grouped <BR>>together.<BR></DIV>
<DIV>Hmm.. I think Select/ Deselect fits better close to the New, Delete and renaming buttons, because it is then logocal that it selects the selected Vertex Group, which is exactly what is does!</DIV>
<DIV> </DIV>
<DIV><BR>>We can even come up with guidelines for how to do this, such as:<BR>>* When panels must contain mixed settings and actions, organise the <BR>>actions<BR>>at the top of the panel and settings at the bottom<BR></DIV>
<DIV>Again, I have to disagree. I think that buttons that are related to each other should be grouped together, not buttons that react in similar ways. I really think it would be very confusing to organise it so that all the actions were seppereated from the settings.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR>>Anyway, I've written a hell of a lot and it would be nice to have some<BR>>feedback on or additions to these guidelines. Please ask questions if <BR>>you<BR>>have any - I fear some of this may be hard to understand since I'm so <BR>>tired<BR>>:( In any case, without a nice structured design to base things on,<BR>>quibbling over specific buttons will be futile in the long run, so this <BR>>is<BR>>something that needs to be adressed.<BR></DIV>
<DIV>Yes, it would be good to have a general buttons layout philosophy. I propose a slightly different philosophy though:</DIV>
<DIV> </DIV>
<DIV>1, All buttons that are related should be placed next to each other.</DIV>
<DIV> </DIV>
<DIV>2, The buttons should be put into groups wherever possible so that the user would be able see what a specific function relates to. (for example evrything that has to to with how an object is displayed could be put in a Display box, like in this image: <A href="http://www.shadeless.dk/editbuttons2.jpg">http://www.shadeless.dk/editbuttons2.jpg</A>)</DIV>
<DIV> </DIV>
<DIV>3, Then there is all the buisness of making a collapse system where you can minimise some settings, and the vertical layout idea, but I think we all agree that those are good ideas.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Regards, William (Monkeyboi)</DIV><p>------------<br>
<a href=http://dk.mail.yahoo.com>Yahoo! Mail</a> - Gratis: 6 MB lagerplads, spamfilter og virusscan
--0-222847739-1066218003=:14122--