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

[Martin Albisetti <argentina gmail com>]

On Tue, Dec 15, 2009 at 7:15 AM, James Moschou <james moschou gmail com> wrote:
> 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.

In Launchpad[1], a 25 developer team distributed across 9 timezones,
we implemented UI reviews a bit over a year ago and it was very
successful. A rough idea of what it looks like is available in a wiki
page[2]. I've even submitted a paper about it to the agile XP2010
conference[3].
The UI review process had a bigger impact than expected for us, not
only in the end result, but in how it evolved. The fact that
developers had people they could talk to before kicking off a feature
or a change proved incredibly valuable as well, as it removed some of
the mental burden on them.
Initially, picking a few of people that not only understand and care
about UI, but can give very quick turnarounds is crucial in my
experience. Sometimes giving a quick answer that unblocks the
developer and providing a great UI contradict each other, but
especially in open source, I feel the right balance there is key to
making sure the process is helpful for everyone.
The second, and most interesting stage to me, is when you've had the
process in place for a while, and most develoeprs have gond through it
a few times, and you start adding more and more *developers* as UI
reviewers, helping and mentoring with their first steps. Our
experience was that once developers sat on the other side, reviewing
changes from a pure UI perspective, their own perception of their work
changed.
I think that last step is what really makes a dent on the general flow
of the project.


> 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.

Having a guideline that everyone can refer to and change as new
use-cases come up is invaluable to scale the process. How the
information is presented is important though, too much or too little
detail can make people shy away from even looking. Providing good
layering of the information, high-level information first, and digging
deeper in lower layers as needed, is one way to have the best of both
worlds.


> 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.

I think that rather than redundant, it may be possible because of the
increased awareness.


I'd be more than happy to help out in whatever I can with this process.



[1] https://launchpad.net
[2] https://dev.launchpad.net/UI/Reviews
[3] http://beuno.com.ar/talks/xp2010.pdf  (submitted at:
http://xp2010.agilealliance.org/node/5256)

-- 
Martin