[Bf-taskforce25] Widget Colouring Suggestion

Shaul Kedem shaul.kedem at gmail.com
Tue Apr 7 15:21:47 CEST 2009


A functional note: if we have this little emblems on the top we can
use them as levers for sliders, and so, if someone press and drag them
right they increment in small amount and if dragged to the left they
decrement in small amount. we can even increment in larger numbers if
the emblem is dragged further to the right or decrement more if
dragged more to the left.

On Tue, Apr 7, 2009 at 2:29 AM, Brian Staub <brian.staub at yahoo.com> wrote:
>
>
> ________________________________
> for the color blind...
>
> http://invertednormal.wordpress.com/files/2009/04/widgetcolors03.png
>
> From: Rob Cozzens <robcozzens at gmail.com>
> To: The Blender 2.5 TaskForce <bf-taskforce25 at blender.org>
> Sent: Monday, April 6, 2009 11:54:47 PM
> Subject: Re: [Bf-taskforce25] Widget Colouring Suggestion
>
> One point about color coding this keying info... it makes it less useful for
> people with certain types of color-blindness. I think version #5 has the
> most promise, because it could be a theme option to have a different symbol
> in those badges in addition to/instead of color.
> I guess as long as the colors are changeable, any of those versions could
> be usable for the color-blind with some tweaking.
> -Rob
>
> On Mon, Apr 6, 2009 at 9:32 PM, Brian Staub <brian.staub at yahoo.com> wrote:
>>
>> mmm k... grrrr....  sorry again.  let's try this one more time.  this link
>> should work  =/
>>
>> http://invertednormal.wordpress.com/files/2009/04/widgetcolors013.png
>>
>>
>> > Ton Roosendaal wrote:
>> >
>> > Hi,
>> >
>> >
>> >
>> > These special state-widgets, just like text outside buttons, work
>> > nicely in layouts that are strictly displayed as a list
>> >
>> >
>> > Such features can be part of "Style" definitions, so it can be added
>> > where appropriate.
>> >
>> > Further there's plenty of subtle ways to explore; here's a quicky I
>> > did, the button outline code is a quad strip, so can be any width;
>> > http://download.blender.org/institute/rt.jpg
>> > Or just color items in button:
>> > http://download.blender.org/institute/rt2.jpg
>> >
>> > Still; a problem with color coding remains that you have drop (part of)
>> > the freedom to assign colors to visualize widget types. Color encoding
>> > is very limited and with more than just a few colors it starts looking
>> > messy and loses meaning.
>> >
>> > -Ton-
>> >
>> > ------------------------------------------------------------------------
>> > Ton Roosendaal  Blender Foundation  ton at blender.org    www.blender.org
>> > Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>> >
>> > On 5 Apr, 2009, at 21:03, William Reynish wrote:
>> >
>> >
>> >
>> > On 5 Apr, 2009, at 12:49 PM, Ton Roosendaal wrote:
>> >
>> >
>> >
>> > Hi,
>> >
>> > This is of course a temporary situation. We're experimenting with it.
>> > :)
>> >
>> > The basic idea remains that widget coloring will be derived from a set
>> > of theme colors you've defined yourself, visualizing widget
>> > functionality or widget types, and matching the overal looks you want.
>> >
>> > We will also check smaller and more subtle ways to show animated
>> > variables. We could make the layout engine add space for a small
>> > icon/button, allowing standard input methods to edit it, and visualize
>> > whether the variable has a function curve, is being driven, or
>> > controlled by expression, and allowing a way to make a function curve
>> > editor to show the curve/driver.
>> >
>> > One thing is quite cool of the current flashy coloring though; it's
>> > totally clear and obvious for debugging purposes. Might be worth
>> > putting a theme option in Blender that does it, so you can optionally
>> > switch to it on a simple command, and back. :)
>> >
>> >
>> > We have to find a balance where this information is as clear as
>> > possible, yet not totally distracting. Current solution isn't too bad
>> > I don't think - like you say it's obvious, yet non-intrusive whenever
>> > that information is not needed or not focused on - buttons that are
>> > not animated keep looking normal. However, I appreciate that
>> > there definitely are other solutions and it'd be nice if anyone with
>> > other ideas could scribble them down and preferably do some visual
>> > mockups of buttons in animated/expression/keyframe/driven states.
>> >
>> > The problems with having a separate icon for animation states
>> > are twofold: first, you have to create a visual connection between it
>> > and the 'parent' widget, and second, you have much more clutter and
>> > information in the users face. These special state-widgets, just like
>> > text outside buttons, work nicely in layouts that are strictly
>> > displayed as a list - a la Apple Motion, XSI, etc, but probably not so
>> > much in Blender where buttons layouts so far are a lot more varied.
>> >
>> > -William
>> >
>> > _______________________________________________
>> > Bf-taskforce25 mailing list
>> > Bf-taskforce25 at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-taskforce25
>> >
>> >
>> > _______________________________________________
>> > Bf-taskforce25 mailing list
>> > Bf-taskforce25 at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-taskforce25
>> >
>> >
>> >
>> > _______________________________________________
>> > Bf-taskforce25 mailing list
>> > Bf-taskforce25 at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-taskforce25
>> >
>> >
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>>
>> _______________________________________________
>> Bf-taskforce25 mailing list
>> Bf-taskforce25 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>>
>
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>
>


More information about the Bf-taskforce25 mailing list