Re: A Violent Realisation [Was: Preferences]

[Seth Nickell <snickell stanford edu>]

Here's a riddle for you... Microsoft hires some of the brightest
programmers, they spend more money on usability research and applied
testing than any other software company, and apply an enormous amount of
money to software development. Why does Microsoft software tend to suck
(unless you count features, it very often has the most features)? Why is
it generally hard to use, esp. odd since they do so much usability
testing? Have you ever wondered this?

I think its because Microsoft product development is dominated by
engineering. At best people "develop stuff" at the same time as
usability is done. At worst they change a couple things in response to
after-the-fact usability testing. Of course, this is the pattern at most
software companies, and its the pattern GNOME development generally
follows. The deepest structures of the system, the deepest interactions
which fundamentally affect user's conception of the system, are set in
code/granite before usability is applied. The best usability can hope to
do is file off some of the rough edges.

On Mon, 2002-04-29 at 18:04, Havoc Pennington wrote:
> 
> Seth Nickell <snickell stanford edu> writes:
> > 
> > I believe we can. Its not really that hard. The trick is that we have to
> > be designing for a narrower audience. Part of the reason WinXP, MacOS/X,
> > KDE and GNOME suck so much is that they try to be universal. I think
> > there's a huge market for an "operating system" that solves a specific
> > type of user's problems really damn well. But the problem is we'd never
> > be able to agree on what this target audience is, because everyone has
> > their own interests and goals for GNOME.
> > 
> 
> jrb mentioned your argument on this to me. I think if we had a
> dedicated small group with a pragmatic attitude focused on some
> specific audience, they could do a good job of adapting gnome toward
> that audience, even without a huge advance consensus.

I don't think adaption nearly gets at the level of design that would be
necessary to do this *well* (as in the "two to three times better"
figure cited, whatever the hell the metric we are using there is ;-). To
get a really good interface, you design from a clean sheet. The odds
that GNOME will be close enough to the final design to make adaption
reasonable is low. Some GNOME libraries could be very useful though,
obviously, where they don't force certain interface choices (for
example, gnome-xml, glib, maybe gtk, etc).

For example, for some user audiences we could choose, I would be
strongly in favour of removing the "structured information tree"
metaphor (i.e. the filesystem) from the interface. Its a computer-y idea
that's just not helpful to everyone. We love computers of course, and
powerful abstractions like the filesystem kick ass for many many people,
but for some people having a list of their documents is actually better.
OK, that's an extreme example, and I doubt we're in a very good position
to target this audience. But the audience you choose can (at least,
should) have very profound effects on your interface. Much deeper than
"adaption".

Usability is still an afterthought for the deepest structures of GNOME.
We are still haphazardly copying these from other systems (often not
even intentionally, its just we as users of those other systems have
formed mental models which we implicitly implement in our own software).
I say haphazardly because the lack of intentionality means, I think, we
often miss important "details" of these models. Clearly many of these
models are very good and we should use them, "standing on the shoulders
of giants" and all that good stuff (not to mention keeping new users
migrating from those systems oriented). But if we don't know *why* we
are using them, I think we will fail to use them well.

For example... How much serious usability attention have we paid to the
basic structure of the desktop. The panel/filemanager dichotomy for
example. What can I put on a panel? What can I put in a "folder"? What
about the concept of running vs. not running? (there are systems that do
not have this distinction, or make it more weakly such as PalmPilot). Or
to cite an example many people have heard about, the "document centric"
interface vs. "application centric". etc. etc. etc. etc.

I'm not saying what's right or wrong on these issues, because the truth
is that *I* haven't been thinking much about these things, so maybe we'd
decide that what we have is right on a lot of these things. What's sad
is that these are the most important thing to get right, and they're
nearly impossible to change without scrapping huge piles of code,
something we're never emotionally prepared to do. So we rationalise and
justify the status quo, try to make the bad structures a little more
palatable, or ignore the issue altogether.

We need to design GNOME from the ground up to achive significantly
better usability[3]. This is called interaction design. What we're doing
now is, roughly speaking, interface design...we're pushing pixels on the
screen. Usability has to be more than spit and polish if we want to be
any better than mediocre[1]. Sadly, I really doubt we, as a project are
either nimble enough, or agree well enough who GNOME should be for, or
have the guts to do this. Throwing away code is too painful[2].

-Seth

[1] I consider Windows to be mediocre. I'm not saying GNOME will be a
totally unusable pile of shit if we don't do interaction design, I'm
saying we ain't gonna be particularly good. I think its sad because just
"resource wise" in terms of man hours and development skill that goes
into GNOME, we *could* be really awesome. If we want to grab market
share based on being a better product, which in an ideal world I'd like,
we're going to have to be a *significantly* better product.

[2] And hey, I'm as guilty of this as the next man. Its inevitable. Code
& (interface/interaction) design shouldn't be mixed. I'm sure much of
the advice I give, particularly with projects I'm more intimately
involved with the development of, is compromised by my hacking on the
project too.

[3] When I say design, I do not mean the "architecture", though much of
the code architecture would likely have to change to accomodate the
design.