Sketching is the defining activity of design writes Buxton and I tend to agree. The genius of his book is that he shows sketching can take on many forms. It is not limited to working with pencils and paper. You can sketch in 3D using wood or clay. You can sketch in time using video, etc. Buxton does not include many examples of sketching in code, though.1 Programming in any language tends to be a hard earned skill, he writes, and once you have achieved sufficient mastery in it, you tend to try and solve all problems with this one tool. Good designers can draw on a broad range of sketching techniques and pick the right one for a given situation. This might include programming, but then it would need to conform to Buxton’s defining characteristics of sketching: quick, inexpensive, disposable, plentiful, offer minimal detail, and suggest and explore rather than confirm.
I have been spending some time broadening my sketching repertoire as a designer. Before I started interaction design I was mostly into visual arts (drawing, painting, comics) so I am quite comfortable sketching in 2D, using storyboards, etc.2 Sketching in code though, has always been a spot. I have started to remedy this by looking into Processing.
As an exercise I took some data from Twitter — one data set was the 20 most recent tweets and the other my friends list — and decided to see how quick I could create a few different visualizations of that data. The end results were:
one: a timeline that spatially plots the latest tweets from my friends — showing density at certain points in time; or how ‘noisy’ it is on my Twitter stream,
two: an ordering of friends based on the percentage of their tweets that take up my timeline — who’s the loudest of my friends?,
three: a graph of my friends list, with number of friends and followers on the axes and their total number of tweets mapped to the size of each point.
The aim was not to come up with groundbreaking solutions, or finished applications.3 The goal was to exercise this idea of sketching in code and use it to get a feel for a ‘complex’ data set, iterating on many different ways to show the data before committing to one solution. In a real-world project I could see myself as a designer do this and then collaborate with a ‘proper’ programmer to develop the final solution (which would most likely be interactive). I would choose different sketching techniques to design the interactive aspects of a data-visualization. For now I am content with Processing sketches that simply output a static image.
Tools & resources used were:
- Processing — a free and open source programming environment for visual folks
- The Twitter4J library for working with the Twitter API
- The wonderful Processing book by Ben Fry and Casey Reas
- Visualizing Data by Ben Fry, including some of the accompanying code
- The community that lives on the board of the Processing site
If as a designer you are confronted with a project that involves making a large amount of data understandable, sketching in code can help. You can use it to ‘talk’ to the data, and get a sense of its ‘shape’.
- There is one involving Phidgets and Max/MSP, a visual programming solution for physical computing. [↩]
- Some examples include a multi-touch project I did for InUse and a recent presentation at TWAB 2008. [↩]
- I don’t think any of these visualizations are very profound, they’re interesting at best. [↩]
10 thoughts on “Sketching in code — Twitter, Processing, dataviz”
As said before: I still hope you make this into a app I can use to plot my own friends (including a mouse-over functionality to browse the friends).
I think it will be popular in the twitter community too!
Perhaps I’ll try to make it so you can use it yourself Iskander, but there are some snags (particularly in the preprocessing department — Twitter does not like me hitting the API repeatedly for each friend).
I agree some interface additions to figure out which dot is which friend would be nice too. I have some ideas, so perhaps I’ll include that when I have time.
Good post kars. A few months ago I was at HKU discussing the redefinition of their ID curriculum and I was flabbergasted about the way ‘design’, ‘programming’ and ‘vormgeving’ were discussed, and placed in abstract squares. I was thinking of our sessions at ICAT, building the search engine, and tried to explain what I was about, but there was no response..
Thanks Joost. I too still have fond memories of our work in Costa Rica. Perhaps I’ve missed my calling as web hacker? ;-) In any case, I am convinced that ‘proper’ interaction design can only be practiced by those with at least some programming skills. The problem used to be with tools, but that is no longer the case — Processing, Arduino and related projects make it all very accessible, even for ‘visual thinkers’ such as myself. I wish I had access to ’em when I was in school.
Comments are closed.