Archives for November 2009

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

Updated XBee library for Processing

09 November 2009

For a project in my group, we needed to talk to multiple XBee radios from a computer. I adapted the XBee API library for Processing by Rob Faludi and Daniel Shiffman, adding methods for sending and receiving serial data (Series 1 radios only).

To send data to a specific radio (identified by its 16-bit address), you use the xbee.sendDataString16(int addr, int[] bytes) function. There's a new constant, xbee.SERIES1_RX16PACKET, that's returned by XBeeDataFrame.getApiID() for incoming data from a radio. XBeeDataFrame's with this API ID support the getAddress16() and getBytes() methods.