Form follows function. First make it work, make it
efficient and reliable, and then make it pretty. If you make
prettiness the priority, then the whole work becomes irreparably
flawed. This is a universal principle that is true for all human
creations: houses, vehicles, industrial machines, clothing, books,
paintings, music, food-- everything. A bad foundation does not lead
to a sound structure, no matter how you pretty it up.
Before building anything you have to have a design, a plan,
because if you don't know where you're going you won't get there.
What drives the plan? The needs of the user. Oh I know, this is
anathema to the
"scratch your own itch" philosophy. But that particular
philosphy has been misrepresented and distorted into something
self-centered, a "If you don't like it then don't use it" attitude,
when in fact it isn't:
"7. Release early. Release often. And listen to your
customers."
But What Do Users Want?
Building anything is a creative act, and creators put a lot of
themselves into their works. It's natural to take criticism
personally. But when you make something for other people to use you
have to listen to them. If you don't develop a sense for what will
appeal to your users then you won't have users.
Sometimes knowing what users want is easy, because they tell you
very specifically. Sometimes it is hard because they don't have
enough experience or knowledge to know for themselves. When I was
geeklancing I spent a lot of time watching how my customers used
their computers, and learning what they were trying to do with
them. Once I figured out their workflow and the tasks they needed
to do it was easy to come up with a coherent plan that made sense.
It took both sets of knowledge to come up with a competent
computing infrastructure.
Digikam Rocks
To me Digikam is one great example of the right way to steer the
development of a complex application. The Digikam team are very
good at understanding what a good digital photo management workflow
is, and every release of Digikam advances both functionality and
efficiency. They listen to users, and while it is impossible to
please everyone, I think they're doing a great job. The best FOSS
projects have this blend of clueful leadership that has a sound,
clear vision, and also knows how to listen to users.
KDE4 and Gnome Wobble
I've been holding back on reviewing KDE4 because I was appalled at
the initial outpouring of venom and hostility, and did not want to
chance fueling the lynch mob in any way. I am still appalled. There
is no excuse for being so vicious.
Desktop environments are considerably more complicated than
single applications, which makes it even more imperative to start
with a clear design vision and a sound framework.
I'm a KDE fan from version 1. Version 1 was pretty rough, but it
was usable and very customizable. It didn't take me long to learn
my way around it and become efficient. Before that I liked Gnome
1.4; it was very customizable and useful. Gnome 2.0 was so crippled
and inflexible I had to find something else, it was little more
than a bloated application launcher. For some years I had all kinds
of window managers and desktop environments installed, and switched
around every couple of days. I still try different ones regularly,
but for me KDE 3.5 is where I am the most efficient and
productive.
KDE 4.2 on Kubuntu is my current KDE 4 testbed. In a nutshell,
it looks like prettiness comes first instead of functionality. I
won't give a complete review here; the short story is it's
unstable, inflexible, and inefficient.
In the
newly-revived Gnome Journal I'm hearing something that is
making me nervous:
"Another way that GNOME 3.0 should change is to
completely rewrite what it means to be a desktop environment. Maybe
the entire desktop need not be a desktop metaphor at all. The
community has a lot of bright and creative people. I believe its
time for the open source desktop community to bring the best minds
together to create something completely new."
Erp. This sort of talk scares me because the existing KDE 4.x
and Gnome 2.x implementations still have a lot of rough spots and
things that don't work right. There are plenty of users who would
be happy with existing problems being fixed, rather than the dev
teams haring off on new adventures. Anyone can do a half-baked job
and walk away; is that the FOSS model? Leave messes for someone
else to clean up? If I never got beyond a first or second draft
nobody would buy my books, and I could not take any pride in
them.
A lot of attention is being paid to glitz and bling. It is true
that style and appearance matter, and it is usually appearance that
first attracts attention. But if that is all there is, and users
are not happy with how the software actually works, glitz and bling
won't be enough to keep them.
One more food for thought from ESR:
"Another
strength of the Unix tradition, one that Linux pushes to a
happy extreme, is that a lot of users are hackers too. Because
source code is available, they can be effective hackers. This can
be tremendously useful for shortening debugging time. Given a bit
of encouragement, your users will diagnose problems, suggest fixes,
and help improve the code far more quickly than you could
unaided."
There are never enough developers or helpers (documentation
writers, helping new users, artists, etc.). I hope that users will
keep this in mind the next time they catch themselves thinking
"Someone else should fix this."
