[Usability] Re: ui-review of new modules

["David Adam Bordoley" <bordoley msu edu>]

Havoc Pennington writes:
> 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 


The problem here is lack of coherent vision and desktop wide model. Without 
it, everyone does it a little different.[1] FWIW, the best ui for ripping 
cd's is probably to put an icon on the desktop representing the cd, open the 
cd, dnd the "files" from the disk to any folder, popup a simple dialog 
asking the user in what format they would like the songs to be stored in. 
[2] 

dave 

[1] Epiphany is very document oriented, evolution is very application 
like..etc.
[2] the dialog step is even debatable.