[Bf-funboard] UI talk + session at bconf

[Brecht Van Lommel]

On Thu, Sep 26, 2013 at 5:26 AM, david j <davidj at gmail.com> wrote:
> Can you explain why you think this, as I see them as easily separable.
>
> A UI proposal is going to need feedback from people who deeply understand
> blender code (to figure out what is practically possible), but it should
> contain nothing more than the description of what would change (with
> screenshots), how it would change, what other UI similar mechanisms exist,
> and why this is a good solution. If we can't agree on this, there is no
> point in looking at code.
>
> Just as a trivial example to make the point, the "UI design review" for
> this tiny trivial UI change I made (which was accepted!) does not require
> looking at the patch code. You can see everything you need to decide
> whether this is a good usability change merely from the descriptions and
> screenshots... Whether or not the patch correctly *implements* this change
> in an acceptable way is an entirely different issue -- and should be
> handled during code review.
>
>   http://lists.blender.org/pipermail/bf-committers/2013-July/041329.html

This is of course fine, moving some buttons is not very difficult,
that kind of change can usually be approved without any developer
involved.

But for more complex changes there's often issues that only come up
once the implementation is being done. I just find it a very rare
thing for even experienced users to think about the implications and
trade-offs of the features they request until you point them out. I
don't know if that's just because they aren't expected to think about
those things or because they don't have the insight into things that
you have as a developer looking at the code.

I would be happy to be proven wrong here.

> I'm sure both cases occur. My experience so far is the opposite.
>
> I spent time deeply understanding the spline handle-set code, and the "just
> bugfix" version of my patch is sitting in part because the committers I've
> tried to get to look at it don't know that code. I was told on IRC this is
> 15 year old blender code, the implication being there is waryness of
> touching it.  For a committer to understand this patch as well as I did
> when I wrote it, they'll probably have to spend the same amount of time I
> spent learning, changing, and testing the code when I wrote the patch.
>
> I don't mean that to come across as some kind of self-aggrandizing, as I've
> only contributed a *stupidly* *small* amount of code to blender, and this
> patch is also trivially small. I'm merely trying to make the point that for
> a committer to understand that patch as well as I did when I wrote it is
> basically going to cause them to duplicate the research effort which went
> into me making the patch in the first place. Very inefficient.

Well, the whole point of the review is that it's not possible to trust
a developer not experienced in some area to get it right.

Regarding that spline handle change, it seems like a big change that
would have an impact on animation workflow, and the one reply you got
from an experienced animator is that they don't consider it a bug. The
reason I would be hesitant to commit that change is not because the
code would be difficult to review, but because neither of us is an
animator and I don't think either of us understands the implications
of this change for animators in practice. Especially since I have
never heard any user complain about this before, this is the kind of
thing that needs feedback from an animator to be approved.

Brecht.