Sketching in code — Twitter, Processing, dataviz

Sketch­ing is the defin­ing activ­i­ty of design writes Bux­ton and I tend to agree. The genius of his book is that he shows sketch­ing can take on many forms. It is not lim­it­ed to work­ing with pen­cils and paper. You can sketch in 3D using wood or clay. You can sketch in time using video, etc. Bux­ton does not include many exam­ples of sketch­ing in code, though.¹ Pro­gram­ming in any lan­guage tends to be a hard earned skill, he writes, and once you have achieved suf­fi­cient mas­tery in it, you tend to try and solve all prob­lems with this one tool. Good design­ers can draw on a broad range of sketch­ing tech­niques and pick the right one for a giv­en sit­u­a­tion. This might include pro­gram­ming, but then it would need to con­form to Bux­ton’s defin­ing char­ac­ter­is­tics of sketch­ing: quick, inex­pen­sive, dis­pos­able, plen­ti­ful, offer min­i­mal detail, and sug­gest and explore rather than confirm.

I have been spend­ing some time broad­en­ing my sketch­ing reper­toire as a design­er. Before I start­ed inter­ac­tion design I was most­ly into visu­al arts (draw­ing, paint­ing, comics) so I am quite com­fort­able sketch­ing in 2D, using sto­ry­boards, etc.² Sketch­ing in code though, has always been a weak spot. I have start­ed to rem­e­dy this by look­ing into Pro­cess­ing.

As an exer­cise I took some data from Twit­ter — one data set was the 20 most recent tweets and the oth­er my friends list — and decid­ed to see how quick I could cre­ate a few dif­fer­ent visu­al­iza­tions of that data. The end results were: 

one: a time­line that spa­tial­ly plots the lat­est tweets from my friends — show­ing den­si­ty at cer­tain points in time; or how ‘noisy’ it is on my Twit­ter stream, 

two: an order­ing of friends based on the per­cent­age of their tweets that take up my time­line — who’s the loud­est of my friends?,

three: a graph of my friends list, with num­ber of friends and fol­low­ers on the axes and their total num­ber of tweets mapped to the size of each point.

The aim was not to come up with ground­break­ing solu­tions, or fin­ished appli­ca­tions.³ The goal was to exer­cise this idea of sketch­ing in code and use it to get a feel for a ‘com­plex’ data set, iter­at­ing on many dif­fer­ent ways to show the data before com­mit­ting to one solu­tion. In a real-world project I could see myself as a design­er do this and then col­lab­o­rate with a ‘prop­er’ pro­gram­mer to devel­op the final solu­tion (which would most like­ly be inter­ac­tive). I would choose dif­fer­ent sketch­ing tech­niques to design the inter­ac­tive aspects of a data-visu­al­iza­tion. For now I am con­tent with Pro­cess­ing sketch­es that sim­ply out­put a sta­t­ic image.

Tools & resources used were:

• Pro­cess­ing — a free and open source pro­gram­ming envi­ron­ment for visu­al folks
• The Twitter4J library for work­ing with the Twit­ter API
• The won­der­ful Pro­cess­ing book by Ben Fry and Casey Reas
• Visu­al­iz­ing Data by Ben Fry, includ­ing some of the accom­pa­ny­ing code
• The com­mu­ni­ty that lives on the board of the Pro­cess­ing site

If as a design­er you are con­front­ed with a project that involves mak­ing a large amount of data under­stand­able, sketch­ing in code can help. You can use it to ‘talk’ to the data, and get a sense of its ‘shape’.

1. There is one involv­ing Phid­gets and Max/MSP, a visu­al pro­gram­ming solu­tion for phys­i­cal com­put­ing. [↩]
2. Some exam­ples include a mul­ti-touch project I did for InUse and a recent pre­sen­ta­tion at TWAB 2008. [↩]
3. I don’t think any of these visu­al­iza­tions are very pro­found, they’re inter­est­ing at best. [↩]