Re: Enter the build sheriff: Jacob.

[Havoc Pennington <hp redhat com>]

Alan Cox <alan redhat com> writes: 
> I've worked with *good* UI people in the gaming world. Seth seems to be
> mostly a reciter of other peoples work without doing research and good
> UI lab testing and study.

You're on crack. He's the only person on the list that _has_ done UI
testing on GNOME 2, AFAIK.
 
> You are also too close to the project to see the problems. You must feed
> Gnome 2.0 final (ish) to people who are going straight from 1.4. You'll
> see deep annoyance at the dialogs without any understanding of why it
> irritates them. Take 30 people into a lab and try it some day.

Have you done this?

If you read gnome-list you'll see that Seth _has_ done it, unless I'm
totally misremembering. Not 30 people (which would be a multi-week
multi-person expensive-as-hell project), but as best we can
realistically do.

When we can't afford the testing, we have to go with prior art and
research and general principles based on those, and that is 100% the
right approach.
 
> We won't have a consistent UI. Remember you are going to support 1.4 and 2.0
> at the same time. Oh dear now my dialog boxes are in random order.

As I said, I agree with you on this issue. But based on GUI apps you
have written, I don't think in general you know what you are talking
about more than the UI team does. They aren't going to tell you about
kernel code and we should be less aggressive in telling them about
their area.

I would also say that you (like most of us) will tend to overvalue the
importance of complaints from the traditional Linux vocal userbase on
mailing lists. I've made dozens of changes in GNOME 2 that I _know_
they won't like, because we have good evidence that those changes are
better for the silent majority and potential new GNOME/Linux converts.
(The dialog button case is not an example of that however.)

We do need to value these complaints and fix them, but they can't
_drive_ our development or we will end up with the same usability
mistakes that GNOME 1.4 and KDE 2.2/3 have made. GNOME 2 finally
overcomes a lot of those, and we need to keep those enhancements.

The problem is that the fastest way to accomodate traditional users is
usually to add a configuration option. That's the trap we have to
avoid at all costs, in favor of fixing the defaults to address the
root issues.

Havoc