Sketching in Code

Flexible dreams for a responsive world

Last week’s Artifact Conference focused on the challenges of designing for multiple devices simultaneously. One frequent suggestions on stage and off was rough sketching, on screen or on paper, but it’s tricky to get there. The problem is easiest to see for designers on the Web, but it applies to a wide range of digital projects.

The challenge isn’t just devices – designing for a particular device with its given constraints isn’t (usually) that hard. HTML, CSS, and JavaScript have long had tools for abstracting just far enough away from the device that sites can work even in unexpected places. The challenges come from the multiplicity. I used to spend a lot of time helping designers and clients move from “it looks like this in print” to “it probably looks like this on the Web”. That was largely about surrendering control, which was difficult enough, but this is frequently about controlling just enough to create multiple variations with a single code base.

What does a sketch of a page look like when that page morphs itself to fit differently in different containers? What does a sketch of a site look like when that site may present different content (and different types of content) to different users based on their past encounters with the site? What does a sketch of a program look like when it handles many different kinds of input in many different kinds of circumstances?

One answer – the classic answer for those of us walking around with notebooks full of dot grid paper – is multiple sketches. Breakpoints become critical as “it looks like this when…” becomes a mantra.

At the same time, though, I rarely feel comfortable creating site (or code) details on paper when I know the result will be electronic. I spent way too much time explaining how paper and screens are different to saddened designers to want to inflict that pain on my own projects. My notebooks are largely filled with words, with occasional pictures.

Read more…

Comment |