Archives for Design

Making Prototypes Work (TEI paper submission)

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

Design vs. Art

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).

Kevin Mullet and Darrell Sano, Designing Visual Interfaces

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.

Java Applet for Abstract Composition

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?

Design and order custom US stamps ($17 for a sheet of 20); and a related Wired article. Update: not anymore.

Automata :: for automatically generating multiple variations from an Adobe Illustrator document


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?

Alan Cooper, The Inmates are Running the Asylum

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.

Human Computers

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.