Re: [Usability] ui-review of new modules

[Havoc Pennington <hp redhat com>]

On Thu, Jul 03, 2003 at 04:27:41PM +0100, Calum Benson wrote:
> On Thu, 2003-07-03 at 15:04, David Adam Bordoley wrote:
> 
> > [1] I'm really starting to question the usefulness of ui-reviews. They tend 
> > to only address skin deep layout problems and do nothing to address 
> > interaction problems which are the biggest usability bugs in gnome right now 
> > anyway. 
> 
> This is one of the points I was trying to make during my usability talk
> at GUADEC, but no, I didn't have any brilliant ideas as to how to
> improve either of those situations :)  (I don't think any other large
> open source project does either, though, so we still have plenty
> opportunity to innovate...)
> 

My .02 is that we need to have concrete output that contributors can
generate.

That is, if you are contributing to usability, what are the tasks that
you work on, and what are the written documents or bugs or other
artifacts that result from those tasks. What constitutes a design
document plus rationale.

Once you have that, you have the tools to get lots of people involved,
because you can give them things to do. And you also have the tools to
establish a meritocracy that distinguishes people who just speculate
about UI on mailing lists from people who do useful stuff, because
contributors can do more work or better work than other contributors.

So I have some sense that books such as "designing from both sides of
the screen" and "about face 2.0" that go through a kind of detailed
methodology are good for this. Say you want to design the UI for 
ripping CD tracks, you can go through a set of steps:

  - research some sample users
  - develop your personas (possibly already done desktop-wide) 
  - develop lists of tasks and prioritize/categorize 
  - develop a user model
  - mock up a UI, and evaluate/iterate in light of your personas and
    tasks
  - iterate design with user testing
 
Or whatever the steps you want to have are, I'm sure there's more than
one way to do it.

Right now what happens is that people tend to just jump to the "mock
up the UI" part, it seems like. The only replicable/scalable way we
have to evaluate UI quality is the HIG, so that's what people use.
Other than that, all evaluation bottlenecks through a few designers ->
which doesn't work, it's not scalable.

So to change that, maybe we need to introduce other dimensions of
evaluation, such as the "visibility" and "number of clicks" metrics in
the "designing from both sides of the screen" book, or the user model
simplification diagram for the desktop.  These things have to be
documented, because that lets other people learn about them and lets
us distinguish a UI proposal with rationale from a UI proposal
invented out of thin air.

In short, we need to find ways to improve the UI that involve
replicating processes and knowledge, rather than ways that involve
replicating particular individuals. ;-) 

Yes some work will always require experts, and just as some GTK work
bottlenecks on Owen, some design work will bottleneck on our usability
maintainers. But the more we can avoid that, the better.

Most programmers that start hacking on GNOME are clueless and often,
frankly, quite bad. I was when I started. But they learn. So can
interaction designers. What we have to do is give them the tools to do
so if they're motivated and talented.

Havoc