[Bf-taskforce25] Bf-taskforce25 Digest, Vol 10, Issue 47

[John E. Herreño V.]

>
> On Thu, 2009-06-25 at 21:30 -0500, John E. Herre?o V. wrote:
> > So what's the proposal:
> >         Identify the minimal set of parameters that let the user get
> >         enough general control of the feature (in my case it's just
> >         shading, but I think it's possible to find some other cases
> >         with the same behavior).
> >         Organize the default UI putting those parameters first on the
> >         list on the corresponding panel. That way, the overall
> >         behavior can be controlled quite fastly and only the
> >         power-user will dare to "deepen" into the panel, using the
> >         more advanced/fine-grained parameters.
>
> I think this is generally a good guideline to follow, ordering things by
> importance. Other things to keep into account are also to keep related
> buttons together, and showing the hierarchy in the settings. In addition
> there's aesthetics, avoiding gaps, symmetry, etc.  There's a difficult
> trade-off here.


Yeah, definitely there is a tradeoff, e.g. when the parameters for the
feature tend to have a logical (from the code perspective) grouping that
causes power-users to think by using that grouping, which helps them to see
not just *many buttons*, but a *few groups* of them.

In fact I think this is already taken into account often, even if
> subconsciously, but there's definitely room for improvement.


I haven't made a thorough revision of the current UI, but I think that's the
case too.

> To avoid getting this message even longer than what it already is I
> > will just show a snapshot of the SSS panel reorganized applying the
> > ideas I just wrote about:
> > http://nucleo-digital.com/tmp/Parameter_Ordering.png . Working with
> > only the first two rows it's quite easy to get nice results without
> > having to worry about so many parameters.
>
> This illustrates a bit how it's a matter of interpretation too. I think
> the SSS panel in 2.4x is better than this mockup and the one in 2.5.


> It keeps the scale and radius settings together, because they are
> closely related, scale is just a multiplier for the radius. Preset is at
> the top, IOR is a bit lower because it is a bit of a difficult
> parameter. Error is at the bottom. Col/tex front/back are at the right
> because are there to tweak the influence in a non-physical way.
>

That's the right illustration for the grouping I just wrote about: the
actual code uses the radius parameters and there is the scale that makes it
easier to drive the actual, real parameters; so the grouping (from the coder
perspective) is absolutely evident. But then I think: if I get the more
general parameters first, would I be happy with it when I understand the
logic of the actual code/technique?, or would I think the parameters are
just plain-disorganized?... I think I would prefer the straightforward
workflow.

> I've added a fake "SSS presets" widget, because I think the presets
> > are a key part to accomplish my goal: easying the workflow. BTW, I'm
> > proposing/asking for the SSS presets to be put there in 2.5x :)
>
> Yes, SSS presets will be added back.


Great, happy to know it :)

> If the idea gains some adepts I will ellaborate more on other aspects
> > and take the time to analyze more features and try to apply the
> > criteria.
>
> OK, guidelines could be good to have for reference, though the best way
> to have influence is to get actively involved doing panel layouts for
> 2.5 :).


I'm gonna take a more in-depth look at my ideas, comparing against some
others I can think of. Give me a couple days for having a more structured
proposal (with examples, of course :) ).

JEHV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090627/caa6a495/attachment.htm