Archives for Design
11 November 2009
My submission to the TEI conference was rejected, but I wanted to share the paper anyway. Here's an excerpt:
Working prototypes have many disadvantages and difficulties. Foremost among these is the time they take to build. In the course, most of the student groups spent fully two weeks (half of the time) constructing their final prototype. Compared to the hours or days taken on most of their earlier prototypes, this was a large commitment. It can also be difficult to estimate the time required to complete an electronic prototype, particularly because they tend to be non-functional until they are almost finished. Almost none of the students in the class slept the night before the final presentations as they struggled to get the prototypes into a demonstrable state.
Electronic prototypes can be particularly inflexible, difficult to adjust or craft as one's conception of the design changes. Component choices and circuit designs constrain the flexibility of the prototype, even as its functioning begins to reveal new possibilities. Tweaking prototypes is particularly difficult for non-technical students who may only know the specific component or piece of code they're working with. The components they’ve already used or purchased often shape the behavior or interface of a prototype.
Another obstacle to adjusting the design of a prototype is that any change risks breaking it completely. This points to one of the other weaknesses of electronic prototypes: their fragility. They are difficult to transport, hard to maintain, and often poorly documented. This greatly limits their lifespan and scope. Although four of the prototype built for the class were later exhibited at a conference, they required significant effort and rebuilding for the occasion. In particular, the more custom electronic circuitry involved (as opposed to standard modules or computer peripherals), the greater the difficulties.
One surprising drawback of electronic prototypes is their tendency to engross and distract students. It's easy to become so intent on getting something to work that you forget its purpose, or fail to consider other ways of achieving the same end. Often the prototype detracts from the design by moving focus from the interface and interactions to the implementation. Although many of the students do not intend to to use electronics later in their careers, in this class, they showed a strong desire to prove that they could make their prototypes work.
Finally, working prototypes (at least in an exhibition) tend to discourage contemplation of the role that the object would play in one's life. Visitors tend to be absorbed by the behavior and functionality of the prototype - playing with it rather than thinking about it. A combination of a model and video can better suggest the relationship one might have with an object outside of the exhibition (see [2] for an in-depth discussion).
Download: Making Prototypes Work - Mellis.pdf
A designer makes things. Sometimes he makes the final product; more often, he makes a representation – a plan, program or image – of an artifact to be constructed by others. He works in particular situations, uses particular materials, and employs a distinctive medium and language. Typically, his making process is complex. There are more variables – kinds of possible moves, norms, and interrelationships of these – than can be represented in a finite model. Because of this complexity, the designer's moves tend, happily or unhappily, to produce consequences other than those intended. When this happens, the designer may take account of the unintended changes he was made in the situation by forming new appreciations and understandings and by making new moves. He shapes the situation, in accordance with his initial appreciation of it, the situation "talks back," and he responds to the situation's back-talk. — Donald Schön, The Reflective Practitioner
12 June 2008
In an
interview with Charlie Rose, Paola Antonelli suggests an interesting criteria for distinguishing between design and art: design is done for someone else (she says around minute 30) and art is done for oneself (my addition).
21 June 2005
A good overview of the application visual principles to the design of user interfaces. This includes topics like hierarchy, balance, harmony, etc. An especially interesting section discusses various visual attributes (hue, value, size, orientation, shape, position, and texture) and their perceptual properties (e.g. we can instantly pick out objects of a particular color, but not shape, from a mixed collection). The diagrams feel old-fashioned, but give an appreciation for the clarity and consistency of the original Mac interface. The color plates are mostly wasted on examples of bad design or diagrams found elsewhere in the book. For better illustrations and an excellent discussion of these same principles applied to data presentation as opposed to UI design, see Edward Tufte's books, especially Envisioning Information.
For more information on Designing Visual Interfaces, see these excerpts and diagrams.
12 October 2004
This applet comes from an assignment in my design and programming skills class. We had to express a mood by arranging four equally-sized black squares on a white square. The moods were balance, tension, progression, motion, play, and rhythm.
I had trouble with the paper squares, so I wrote a Java applet to arrange the squares. It could use a few more features, such as different shapes and colors, but it worked well for my assignment.
Try it out and let me know what you think.
11 October 2004
As you may have noticed, I redid my website. It's not up to the standards
of the the sites of my classmates, but perhaps it's no longer an embarrasment.
I certainly prefer it to the old look. What do you think?
24 April 2004
I want a way to annotate web pages and other documents on my computer.
Ideally, these could be shared, to allow, for example, everyone at my job to
attach disclaimers and warnings to .NET's horrendous documentation. Does
anyone know of a plugin for Mozilla (or anything else) that allows for this sort
of thing?
21 March 2004
It is ironic that a book so concerned with the quality of a person's
experience should be so callous with that of its reader's. This is
one of the ugliest books I've read. A team of thirteen (including
an “interior designer” and two “layout
technicians”) couldn't keep endorsements from covering
both sides of the fly-leaf and the illustrations from looking like
clip-art. Cooper claims his illustrator “did a remarkable
job”, but his art directors would have done well to omit
those images entirely.
No book in recent memory has inspired so many growls and
groans. Cooper presents some useful information, but that doesn't
redeem his work any more than a hodgepodge of features can
save the computer programs Cooper excoriates. Why must using
a computer make us feel stupid?, Cooper demands. Well, why
should reading a book make us so angry?
Aesthetics aside, The Inmates are Running the Asylum
was an insightful read. Cooper believes that software development
has been run by programmers, on behalf of computers, for too
long. It is time for designers to take over, on behalf of humanity.
He's right, of course. As a programmer, I know how easy it is to
start writing code before considering what the program has to do,
much less what the user hopes to accomplish.
To save you the annoyance of reading this book, here are the main
points of the book (Cooper repeats himself often, so there aren't
many of them). First, computers should let people get some work
done in a pleasant way. Second, programs need to be designed
before they're written, by someone who does nothing else. Third,
those designers should create personas representing typical users,
their backgrounds, and their goals. Fourth, this process should
suggest the crucial features of a program, which should be focused
on to the exclusion of boundary cases. Fifth, there are numbers
between one and infinity: that is, an interface to select from 30
options can simply list them, instead of imposing the hiererarchical
format that might be necessary for hundreds or thousands of
options.
Altogether, a few useful steps that could dramatically improve the
usability and pleasantness of most software. Cooper's descriptions
of products his firm designed excellenty illustrate his points. It's a
shame there aren't more of them. Maybe if he'd been more attentive
to his reader's personal goals, a few of the worthless images of
bland-looking people would have been replaced with screenshots
from well-designed programs. And maybe then I could recommend
this book to others.
22 February 2004
In The Inmates are Running the Asylum, Alan Cooper talks about the
need to make computers more like people. This is, in general, a difficult and
complex problem. I believe, however, that if a computer could gauge your
openness to interruption, it could make specific changes to its behavior in ways
that would mirror the response of a person.
For example, notification of available upgrades should be postponed until the
user is open to distraction, as should requests for configuration, and even the
assigning of file names. Programs are getting better about not interrupting us,
but sometimes this means that important tasks are postponed indefinitely. If
the computer were more human, it might ask us to deal with administrative
details at scheduled times, or when we seem to have a few minutes free, the
same way a co-worker or secretary might.
Probably the biggest interruption on the computer is instant messaging. A lot
of people have talked about the need for a central console for all
computer-based communication, so I'll just add a quick point. IM programs
should show you who's messaging and (approximately) what they want
without popping up a dialog box or flashing anything. This would allow you to
finish your current thought in the same way as when a person walks up and
waits for you to give him your attention.
The tought part is figuring out your current tolerance for interruption. Failing
a good algorithm, a postonement ability should be added to more interactions.
Right now, we're forced to deal with interruptions on the computer because we
can't put them off. A person can always come back later, but we don't have
the option to wait to name files, or to be reminded later about an email we
need to answer. How about a word processor that always saves our documents
and lets us name them when we want (or when we create them)? Or an
email program that lets us ask it to resend us an email in an hour, or at the
end of the day? Natural language understanding may be a long way off, but
there are little things than could make computers more human now.