[Bf-committers] Actuall usability of some tools and new features

Brecht Van Lommel brecht at blender.org
Thu Nov 19 18:31:28 CET 2009

Hi Jon,

I don't really like this approach, as to me it feels like giving up
trying to reduce the number of clicks. Having to open a panel each
time you want click a button in it just seems quite slow to me, and
also makes it harder to find things at a glance.

I can understand how it would be helpful in for example the particle
or material buttons, but in my opinion this works around the more
fundamental problem that these are not organized / modularized better.
The fact that you have to jump around between many panels to me
indicates that presets and nodes could better organize these. The
system should be designed such that only the panels/buttons are shown
that are likely relevant to what I want, rather than trying to make a
better UI to navigate through irrelevant options.

Of course there will always be a need to have some levels of
navigation, but I think we should keep the hierarchy as flat as
possible. Right now we have one level for tabs, and a second level for
panels that you only sometimes need to navigate because usually it
will show what you want. I think that is preferable over two levels of
navigation that you always have to take into account. I really think
this is a critical design choice...


2009/11/19 Jon Sandström <sjon at student.chalmers.se>:
> I wrote a proposal that adress your second statement (and more) some
> time ago to the taskforce-25 list. It didn't get too much attention
> then, but i'll include it in this mail as nothing has been done, and i
> did not get very much feedback.
> here is the original mail:
> ----------
> The buttons window (properties) has seen some major improvements in 2.5, however, even more can be done to improve readability and navigation of the interface. The biggest problem is that blender has to show a lot of data, but there is an easy way to solve this which is already practiced in the interface to some extent. The trick is to only show data which is of interest to the user. currently blender gives the user the ability to hide unneccesary data by for example collapsing tabs.
> A more efficient way to work is to give the user the ability to show the requested data and then hide it automatically when it is no longer of interest to the user (Imagine having to close the windows start-menu manually every time after opening it). An easy way to extend this behaviour in blender is to automatically collapse all tabs when a new tab is opened. This way the interface will stay clean, and a minimum amount of scrolling is needed. (see mockup:
> http://img156.imageshack.us/img156/5245/mockupr.jpg)
> sometimes however, it is desireable to show multiple tabs. this can be done in two ways:
> 1) shift+click - this opens the selected tab without closing the ones currently open.
> 2) pinnig - all tabs that are pinned will remain open untill unpinned. This is basically a more flexible version of current behaviour.
> this workflow will require an improved design of the "hotspot" area in the tab headers. currently the triangle is used to open and close the tabs, while the rest of the area is used to move the tabs. since the "open/close" hotspot is the one most frequently used, this should have the largest area, and a new third area could be used to pin the tab open (again, see mockup:
> http://img156.imageshack.us/img156/5245/mockupr.jpg )
> when the user opens a tab we can assume that he/she wants to see all its content, and therefore blender should if necessary scroll to a position were the entire content of the most recently opened tab can be viewed
> conclusion:
> if tabs are automatically closed, it will be easier and faster to find desired data. this behaviour can co-exsist with current behaviour (pinning) so i cannot find any arguments not to implement it
> if anyone with the knowledge, time, and motivation required, could try this in action i would be very thankful. i'd also like to hear your thoughts on this, and maybe someone can find some arguments against this approach. If you like/dislike it, please let me know  :)

More information about the Bf-committers mailing list