[Usability] UI review as well as code review (r+/r-)

[James Moschou <james moschou gmail com>]

The main point I want to get across in this email is that while code
changes get an r+ to ensure integrity etc, the design of UI does not.
Now I'm just an outsider so I may be wrong in this, but even if I am I
still don't think design reviews conducted separately within each
project is enough.

My idea is that before committing any changes to UI, GNOME developers
need some sort of central infrastructure (mailing list, bugzilla?)
where they submit their design for approval and a GNOME-wide committee
would r+ it before it gets committed. I'm not talking about "design by
committee" btw which doesn't work, just a bunch of people, probably
from this mailing list, who are trained in the HIG etc. and are able
to make such decisions and offer improvements, much like how code
review works. My point is that this team will be reviewing UI, not
actually doing it themselves, that's still the developer's job.

I think this is needed because the HIG, while helpful, is quite brief
(I believe there was another thread on this list suggesting splitting
it into two books and bulking it up.) To me it's either very vague
"direct manipulation is preferred" or very specific "use 6/12 px
spacing", but if you're looking for guidance on what would work best
for, say, a video editor the HIG falls short. I think some sort pool
of "goto guys" would be appropriate for this kind of thing. I'm sure
there are people on this list that would certainly volunteer.

The advantages I can see are:
* The team has direct influence in each project, as opposed to
publishing guidelines and hoping people listen.
* The team has an overview over all of GNOME and would be in the best
position to ensure consistency across projects
* Developers can shift the burden of design to someone else (assuming
that they are better coders than designers). Of course they don't have
to and well thought out UIs will get r+ immediately, and good
developers will eventually be trusted to make good decisions.
* The HIG will improve over time with experiences from real world applications.

The disadvantages I can see are:
* A review process can lead to delays in development
* The team would need to be all on the same page for it to be
effective. (I don't think this list would work - it's too large)
* The team could become overwhelmed, although I don't think this is an
issue as UI changes happen less frequently than code changes.

Other considerations:
* The team would have to be quite small, just enough to cope with the
workload. They're not so much working together than sharing the burden
around. A developer could choose from any number of senior developers
to get an r+ but ultimately only one person needs to look at the
patch.
* They would need to be able to respond quickly and hence would need
to be well versed in the GNOME philosophy etc.


This all may seem a bit redundant with the increasing awareness about
the importance of usability, and developers do try to do the right
thing. But I think this approach is worthwhile due to the "central
brain" effect and goes towards that top-down approach that design
really needs but often lacks in bottom-up open source development.


What are your thoughts!