Summary
Ken Arnold, the original lead architect of JavaSpaces, talks
with Bill Venners about the role of taste in design and the
importance of designing with the user in mind.

Ken Arnold has done a lot of design in his day. While at Sun Microsystems, Arnold
was one of the original architects of Jini technology and was the original lead architect of
JavaSpaces. Prior to joining Sun, Arnold participated in the original Hewlett-Packard
architectural team that designed CORBA.
While at UC Berkeley, he created the Curses library for terminal-independent screen-oriented programs.
In Part I of this
interview, which is being published in six weekly installments, Arnold explains why
there's no such thing as a perfect design, suggests questions you should ask yourself when
you design, and proposes the radical notion that programmers are people. In this second
installment, Arnold discusses the role of taste and arrogance in design, the value of other
people's problems, and the virtue of simplicity.

Bill Venners:In an interview with chief Jini architect Jim Waldo, Frank
Sommers asked Waldo how he assembled such a talented team of people in the Jini
group, Waldo responded, "Much of [building a good team] is just finding people who
have the right sense of aesthetic -- a lot has to do with taste, and a desire to keep things
simple and elegant." What does taste have to do with design?

Ken Arnold: When you are faced with a design problem, it is
important to ask the question, "What does the user want?" The answer to that question
has a lot to do with taste.

It's funny. To some extent you can answer that question empirically. You can ask
users what they want. But sometimes people say they want something when they really
want something else.

You cannot apply your understanding of human beings in a purely rational way,
because human beings aren't purely rational. In the end, you have to use some sense of
judgment. You may say, "People think they want to do this, but frankly they're wrong."
Or, "People don't realize this is a good way to approach it, but if I present it to them they
would get it." And those are intrinsically arrogant statements. You are essentially telling
users that in this area, you know more than they know about what they should want. But
that kind of arrogance is a form of aesthetic.

Say you have a guy who paints your house. He'll paint it any color you want, but he
doesn't want to paint something that looks ugly. If you suggest one color, he may push
you the other way. Eventually, since you're the boss, he'll do it if you insist. But his sense
of aesthetics leads him to tell you, "You think you know what you're doing, but I actually
have more experience in this area. I know better how to implement what you say you
want."

That is the sense of aesthetics required to design things. Your sense of aesthetics
could be right or wrong in a given case, but you must have confidence in it. You must
trust your interpretation of how irrational human beings will actually do something and
what they will actually need.

Teaching Taste

Bill Venners:If you have taste, can you teach it? If you don't
have taste, can you learn it?

Ken Arnold: Whether or not someone can learn taste depends on
what kind of person they are. Some people have a really bad sense of taste. Other people
have no sense of taste whatsoever.

People who have no taste don't consider aesthetics at all. They say, "Oh, I'll just add a
method that does this. I'll just add a class that does that." If you talk to them about
aesthetics they go, "Huh?" It doesn't make any sense to them. These people might be
wearing polka dot pants and striped shirts at the same time, and there's nothing you can
do about it. I don't think these people are trainable, though you can potentially improve
their sense of taste. I've known a couple people who one day woke up realizing that taste
mattered. But it is hard to teach taste to people for whom taste is not an important factor
in life. It's a tough sell.

People with bad taste, on the other hand, are much easier to train. Such people have a
sense of aesthetics, but they have a different set of values that they apply to those
aesthetics. You can try to convince these people that their values are not optimal, that
they can look at things another way.

It is a lot easier to convince someone with bad taste to look at something differently
than to get someone with no taste to notice something they don't see in the first place. If
you are color blind, you can't do anything about it except work around that problem. But
if you aren't color blind, yet you like to mix really bad colors together, you can learn what
a good color combination is.

Learning Taste

Bill Venners:How do you learn what is good and tasteful in
design?

Ken Arnold: Some people have a natural sense. Other people have
to learn. But to a large extent, what people have to learn is to value other people's
problems.

Taste is a very personal thing. There is no textbook. When people ask me about
books on object design, the books I hand them have nothing to do with object design per
se. I commonly recommend The Design of Everyday Things, by Donald
Norman. This book promotes focusing on usability in the design of doors, teapots, and
faucets -- everyday things. If you do that for objects, you'll have the idea.

Again the questions are, "What is the user coming at the problem with? What are they trying to
accomplish?" Most people who have what I call bad taste are talking about themselves.
When I express things in bad taste, which of course I am not immune from, I am usually
talking about myself. I am not integrating my understanding with other people's
understanding. If you can merge those together then you can acquire good taste. So
teaching people taste is mostly teaching them how to listen and how to put themselves in
someone else's place.

Instead of thinking from the implementation out, people need to think from the user
in. As a designer, you may have two data structures that the user could merge to get a
result, but do you understand that users don't care about your data structures? They just
want to get the result. That is a revelation for many designers. Someone may have very
good aesthetics if the problem is how to merge two data structures to get a result. But you
can show them that that is not the question. The first step on the road, which many people
miss, is asking, "What is the other person trying to do?"

Simplicity as its Own Virtue

Also, to me simplicity is its own virtue. Many people don't really understand that. If
you make something big and complex, it will be hard to use and understand. If it has a
large surface area, many methods and classes, the interactions of those things will
continuously lure people even if you think they shouldn't. People will wonder, "If I make
this method call, how will that affect this other thing?" Those two things may seem
obviously unrelated to the designer, but users come up with all sorts of weird models
about how things work together. That is partly because people tend to make those weird
models, but they may also have an experience of calling some method that seemed
completely unrelated to something else and having a result they didn't expect.

Users don't care about what the designer does. They care about what they do. If every
time you drove a car, you had to learn the meaning of 100 knobs, the whole system
wouldn't work. Simplicity comes from tuning down the tasks required to drive the car
into a certain set of understood paradigms and tools. Yes, there are many people who
would love to pull up the hood and start tinkering with things. You can let them, as long
as that is all under the hood.

There is nothing wrong with having all those knobs. I mentioned the complexity of Swing before, that
JButton has more than 200 methods even though most of the time people
care about maybe five of them. My solution would be to design the system so that it had a
getKnobs() method. JButton would have 10 methods,
including getKnobs(). It would return a ButtonKnobs
object, which lets you play with all the little ditties if needed. Then
JButton's surface area to a newcomer would be nine methods plus a way
to get under the hood.

Simplicity has real value on its own that makes the system more usable. It's the
difference between reading a 100-page manual and reading a 500-page manual. It is more
than five times the size.

Bill Venners:I think of simplicity as a virtue because the
client for whom I am designing is a human being, and simplicity helps human beings. I
see simplicity as a virtue in the context of the client. What exactly do you mean when you
say simplicity is its own virtue?

Ken Arnold: Some people view simplicity -- and again, I mean the
external simplicity, the user's view -- as something that happens if their system is
internally simple. I am saying you should strive for external simplicity on its own.

Just like you should strive for efficiency or clarity, you should strive for simplicity.
And returning to taste, striving for simplicity requires that you make choices. You have to
say to the user, "You know, frankly, you think you want to do this, but you really don't.
And if you really do need to do it, come back and beat me up. Show me why, and we'll
do it later." To achieve simplicity, you sometimes have to say, "You think you want this,
but you're not quite right." That is arrogance, the arrogance of taste.

Discuss

Have something tasteful to say yourself? Discuss this article in the Cool Stuff Forum topic, Taste and Aesthetics