[Bf-taskforce25] Panels, colours and such...

[William Reynish]

Hi Andrzej/jendrzych,

Thanks for your great icon work - it's an awesome contribution to the  
project.


On 8 Apr, 2009, at 11:03 PM, Andrzej Ambroż wrote:

> -I-
> AUTOMAGICAL PANELS
>
> Right now, when the Buttons Window is small (as well as in case of N- 
> key
> toolboxes, Outlier, and so on) panels doesn't fit the space so user  
> have to
> scroll/pan to reach hidden content. Besides it's impossible to  
> figure out
> how much of the content is outside the window (OK, it's easier when  
> You
> knows the specific incarnation of the interface by heart).
> Picture:
> http://img511.imageshack.us/img511/7907/panelautofit.png
> fig. 1. - current situation
> fig. 2. - how it could look like when the window's space is smaller  
> than
> its content - the lowest panels could fold until everything go in the
> window (just one panel in my mockup).
> fig. 3. - after unfolding minimized panel, panels just above could  
> fold
> until everything fits the window again.

I don't really understand this - you pin certain panels to make them  
always display? How's this different from just opening them? It could  
be me, but I don't understand how this is readily useful. Remember KISS!

The video you sent also shows panels opening and closing in  
unpredictable ways - maybe I'm stupid, but it seems a little over  
complicated to me.

> Moreover:
> a) the proposed system could be used all around the interface - in  
> Outliner,
> N-key toolboxes etc.
> b) pins on headers allow keeping panels maximized all the time. One  
> can pin
> all of panels to get current way of displaying the content.
> Those icons help an user to orientate himself in the layout as well.  
> We get
> stronger visual emphasize of each of content's group.
> c) Headers could get highlighted when mouse hovers over specific  
> panel.
> Again - help for sense of orientation. There're of course more  
> alternatives
> for my proposal - highlighting whole panel or just its outline.
>
>
> -II-
> WIDGET COLOURING
>
> Regarding to William's proposal - have to say that symbols used in  
> the very
> mockup could be confusing since chain is commonly used to communicate
> linked edition of specific content. That's why I would suggest using
> "chain" for linking values editing in Transformations, render x and  
> y size
> and such (will have to make mockup as well).

Oh, yeah, I just put this mockup together using your icons (hope you  
don't mind), for demonstration. If we do use some sort of icon for  
visualizing widget states, I'd hope you'll design some new ones, for  
the purpose!

Some of these, like drivers, are a little abstract though. Suppose it  
would indicate a relationship between two items, or a dependancy, and  
a chain seems like an obvious candidate. But if you can think of  
something better, I'm all for it.


> Besides currently we have two Transformation panels (Object [F7] and  
> 3D
> Window's N-key toolbox). I believe that:
> a) this functionality will be moved to (F7) panel

Correct, that's the plan. Buttons within editors are meant for in- 
editor settings that are relevant only to that view. Transformations  
are global and don't really belong here.

The n-key buttons are temporary, and will use the same layout system  
as the Properties Editor.

> b) we'll have two exactly the same panels in different spaces.
> In both cases we'll have one more icon (pad lock) next to the
> transformations value boxes.
> It's getting crushy here...
> So maybe outline alternative ain't so bad? We could use colours and  
> outline
> types - continuous, dotted, etc. so it's somehow colour independent.
> At last Brian's idea of placing icons slightly over the specific  
> element of
> GUI is interesting as well, because relation between symbol and  
> content is
> obvious.

Right, that's the main issue with icons. It's more obvious, but you  
also get more clutter, and less space available. The original idea of  
using some kind of a shading variance (colors, outlines etc.) is still  
an option.

I'm not crazy about the think outlines though, because this is usually  
used to indicates an active widget, like an OK button in a dialog box,  
and it looks a bit clumsy ;)

But it's clear there are quite a few different ways one could vary the  
draw style to indicate widget states, like so:

http://www.reynish.com/files/blender25/widget_state_styles.png


Cheers,

William