Prototyping is a team sport

Late­ly I have been bing­ing on books, pre­sen­ta­tions and arti­cles relat­ed to ‘Lean UX’. I don’t like the term, but then I don’t like the tech industry’s love for invent­ing a new label for every damn thing. I do like the things empha­sis­es: shared under­stand­ing, deep col­lab­o­ra­tion, con­tin­u­ous user feed­back. These are prin­ci­ples that have always implic­it­ly guid­ed the choic­es I made when lead­ing teams at Hub­bub and now also as a mem­ber of sev­er­al teams in the role of prod­uct design­er.

In all these lean UX read­ings a thing that keeps com­ing up again and again is pro­to­typ­ing. Pro­to­types are the go-to way of doing ‘exper­i­ments’, in lean-speak. Oth­er things can be done as well—surveys, inter­views, whatever—but more often than not, assump­tions are test­ed with pro­to­types.

Which is great! And also unsur­pris­ing as pro­to­typ­ing has real­ly been embraced by the tech world. And tools for rapid pro­to­typ­ing are get­ting a lot of atten­tion and inter­est as a result. How­ev­er, this comes with a cou­ple of risks. For one, some­times it is fine to stick to paper. But the lure of shiny pro­to­typ­ing tools is strong. You’d rather not show a crap­py draw­ing to a user. What if they hate it? How­ev­er, high fideli­ty pro­to­typ­ing is always more cost­ly than paper. So although well-inten­tioned, pro­to­typ­ing tools can encour­age waste­ful­ness, the bane of lean.

There is a big­ger dan­ger which runs against the lean ethos, though. Some tools afford deep col­lab­o­ra­tion more than oth­ers. Let’s be real: none afford deep­er col­lab­o­ra­tion than paper and white­boards. There is one per­son behind the con­trols when pro­to­typ­ing with a tool. So in my view, one should only ever progress to that step once a team effort has been made to hash out the rough out­lines of what is to be pro­to­typed. Basi­cal­ly: always paper pro­to­type the dig­i­tal pro­to­type. Togeth­er.

I have had a lot of fun late­ly play­ing with brows­er pro­to­types and with pro­to­typ­ing in Framer. But as I was get­ting back into all of this I did notice this risk: All of a sud­den there is a per­son on the team who does the pro­to­types. Unless this solo pro­to­typ­ing is pre­ced­ed by shared pro­to­typ­ing, this is a prob­lem. Because the rest of the team is left out of the think­ing-through-mak­ing which makes the pro­to­typ­ing process so valu­able in addi­tion to the testable arte­facts it out­puts.

It is I think a key over­sight of the ‘should design­ers code’ debaters and to an extent one made by all pro­to­typ­ing tool man­u­fac­tur­ers: Indi­vid­u­als don’t pro­to­type, teams do. Pro­to­typ­ing is a team sport. And so the suc­cess of a tool depends not only on how well it sup­ports indi­vid­ual pro­to­typ­ing activ­i­ties but also how well it embeds itself in col­lab­o­ra­tive work­flows.

In addi­tion to the tools them­selves get­ting bet­ter at sup­port­ing col­lab­o­ra­tive work­flows, I would also love to see more tuto­ri­als, both offi­cial and from the com­mu­ni­ty, about how to use a pro­to­typ­ing tool with­in the larg­er con­text of a team doing some form of agile. Most tuto­ri­als now focus on “how do I make this thing with this tool”. Use­ful, up to a point. But a large part of pro­to­typ­ing is to arrive at “the thing” togeth­er.

One of the lean UX things I devoured was this pre­sen­ta­tion by Bill Scott in which he talks about align­ing a pro­to­typ­ing and a devel­op­ment tech stack, so that the gap between design and engi­neer­ing is bridged not just with process­es but also with tool­ing. His exam­ple applies to web devel­op­ment and app devel­op­ment using web tech­nolo­gies. I won­der what a sim­i­lar approach looks like for native mobile app devel­op­ment. But this is the sort of thing I am talk­ing about: Smart think­ing about how to actu­al­ly do this lean thing in the real world. I believe organ­is­ing our­selves so that we can pro­to­type as a team is absolute­ly key. I will pick my tools and process­es accord­ing­ly in future.

All of the above is as usu­al most­ly a reminder to self: As a design­er your role is not to go off and work solo on bril­liant pro­to­types. Your role is to facil­i­tate such efforts by the whole team. Sure, there will be solo deep design­er­ly craft­ing hap­pen­ing. But it will not add up to any­thing if it is not embed­ded in a col­lab­o­ra­tive design and devel­op­ment frame­work.

Prototyping in the browser

When you are design­ing a web site or web app I think you should pro­to­type in the brows­er. Why? You might as well ask why pro­to­type at all. Answer: To enable con­tin­u­ous test­ing and refine­ment of your design. Since you are design­ing for the web it makes sense to do this test­ing and refine­ment with an arte­fact com­posed of the web’s mate­r­i­al.

There are many ways to do pro­to­typ­ing. A com­mon way is to make wire­frames and then make them ‘click­able’. But when I am design­ing a web site or a web app and I get to the point where it is time to do wire­frames I often pre­fer to go straight to the brows­er.

Before this step I have sketched out all the screens on paper of course. I have done mul­ti­ple sketch­es of each page. I’ve had them cri­tiqued by team mem­bers and I have reworked them.

Drawing pictures of web pages

But then I open my draw­ing pro­gram—Sketch, in my case—and my heart sinks. Not because Sketch sucks. Sketch is great. But it some­how feels wrong to draw pic­tures of web pages on my screen. I find it cum­ber­some. My draw­ing pro­gram does not behave like a brows­er. That is to say in stead of defin­ing a bunch of rules for ele­ments and hav­ing the brows­er fig­ure out how to ren­der them on a page togeth­er I need to fol­low those rules myself in my head as I put each ele­ment in its place.

And don’t get me start­ed on how wire­frames are sup­posed to be with­out visu­al design. That is non­sense. If you are using con­trast, rep­e­ti­tion, align­ment and prox­im­i­ty, you are doing lay­out. That is visu­al design. I can’t stand wire­frames with a bad visu­al hier­ar­chy.

If I per­se­vere, and I have a set of wire­frames in my draw­ing pro­gram, they are sta­t­ic. I can’t use them. I then need to export them to some oth­er often clunky pro­gram to make the pic­tures click­able. Which always results in a poor resem­blance of the actu­al expe­ri­ence. (I use Mar­vel. It’s okay but it is hard­ly a joy to use. For mobile apps I still use it, for web sites I pre­fer not to.)

Prototyping in the browser

When I pro­to­type in the brows­er I don’t have to deal with these issues. I am doing lay­out in a way that is native to the medi­um. And once I have some pages set up they are imme­di­ate­ly usable. So I can hand it to some­one, a team mem­ber or a test par­tic­i­pant, and let them play with it.

That is why, for web sites and web apps, I skip wire­frames alto­geth­er and pro­to­type in the brows­er. I do not know how com­mon this is in the indus­try nowa­days. So I thought I would share my approach here. It may be of use to some.

It used to be the case that it was quite a bit of has­sle to get up and run­ning with a brows­er pro­to­type so nat­u­ral­ly open­ing a draw­ing pack­age seemed more attrac­tive. Not so any­more. Tools have come a long way. Case in point: My set­up nowa­days involves zero screw­ing around on the com­mand line.

CodeKit

The core of it is a paid-for Mac app called CodeK­it, a so-called task man­ag­er. It allows you to install a front-end devel­op­ment frame­work I like called Zurb Foun­da­tion with a cou­ple of clicks and has a built in web serv­er so you can play with your pro­to­type on any device on your local net­work. As you make changes to the code of your pro­to­type it gets auto­mat­i­cal­ly updat­ed on all your devices. No more man­u­al refresh­ing. Saves a huge amount of time.

I know you can do most of what CodeK­it does for you with stuff like Grunt but that involves tedious con­fig­u­ra­tion and work­ing the com­mand line. This is fine when you’re a devel­op­er, but not fine when you are a design­er. I want to be up and run­ning as fast as pos­si­ble. CodeK­it allows me to do that and has some oth­er fea­tures built in that are ide­al for pro­to­typ­ing which I will talk about more below. Long sto­ry short: CodeK­it has saved me a huge amount of time and is well worth the mon­ey.

Okay so on with the show. Yes, this whole pro­to­typ­ing in the brows­er thing involves ‘cod­ing’. But hon­est­ly, if you can’t write some HTML and CSS you real­ly shouldn’t be doing design for the web in the first place. I don’t care if you con­sid­er your­self a UX design­er and some­how above all this low­ly tech­ni­cal stuff. You are not. Nobody is say­ing you should become a fron­tend devel­op­er but you need to have an acquain­tance with the mate­ri­als your prod­uct is made of. Fol­low a few cours­es on Codecadamy or some­thing. There real­ly isn’t an excuse any­more these days for not know­ing this stuff. If you want to lev­el up, learn SASS.

Zurb Foundation

I like Zurb Foun­da­tion because it offers a coher­ent and com­pre­hen­sive library of ele­ments which cov­ers almost all the com­mon pat­terns found in web sites and apps. It offers a grid and some default typog­ra­phy styles as well. All of it doesn’t look flashy at all which is how I like it when I am pro­to­typ­ing. A pro­to­type at this stage does not require per­son­al­i­ty yet. Just a clear visu­al hier­ar­chy. Work­ing with Foun­da­tion is almost like play­ing with LEGO. You just click togeth­er the stuff you need. It’s pain­less and looks and works great.

I hard­ly do any styling but the few changes I do want to make I can eas­i­ly add to Foundation’s app.scss using SASS. I usu­al­ly have a few styles in there for tweak­ing some mar­gins on par­tic­u­lar ele­ments, for exam­ple a foot­er. But I try to focus on the struc­ture and behav­iour of my pages and for that I am most­ly doing HTML.

GitHub

Test­ing local­ly I already men­tioned. For that, CodeK­it has you cov­ered. Of course, you want to be able to share your pro­to­type with oth­ers. For this I like to use GitHub and their Pages fea­ture. Once again, using their desk­top client, this involves zero com­mand line work. You just add the fold­er with your CodeK­it project as a new repos­i­to­ry and sync it with GitHub. Then you need to add a branch named ‘gh-pages’ and do ‘update from mas­ter’. Presto, your pro­to­type is now on the web for any­one with the URL to see and use. Per­fect if you’re work­ing in a dis­trib­uted team.

Don’t be intim­i­dat­ed by using GitHub. Their on-board­ing is pret­ty impres­sive nowa­days. You’ll be up and run­ning in no time. Using ver­sion con­trol, even if it is just you work­ing on the pro­to­type, adds some much need­ed struc­ture and con­trol over changes. And when you are col­lab­o­rat­ing on your pro­to­type with team mem­bers it is indis­pens­able.

But in most cas­es I am the only one build­ing the pro­to­type so I just work on the mas­ter branch and once every while I update the gh-pages branch from mas­ter and sync it and I am done. If you use Slack you can add a GitHub bot to a chan­nel and have your team mem­bers receive an auto­mat­ic update every time you change the pro­to­type.

The Kit Language

If your project is of any size beyond the very small you will like­ly have repeat­ing ele­ments in your design. Head­ers, foot­ers, recur­ring wid­gets and so on. CodeK­it has recent­ly added sup­port for some­thing called the Kit Lan­guage. This adds sup­port for imports and vari­ables to reg­u­lar HTML. It is absolute­ly great for pro­to­typ­ing. For each repeat­ing ele­ment you cre­ate a ‘par­tial’ and import it wher­ev­er you need it. Vari­ables are great for chang­ing the con­tents of such repeat­ing ele­ments. CodeK­it com­piles it all into plain sta­t­ic HTML for you so your pro­to­type runs any­where.

The Kit Lan­guage real­ly was the miss­ing piece of the puz­zle for me. With it in place I am very com­fort­able rec­om­mend­ing this way of work­ing to any­one.

So that’s my set­up: CodeK­it, Zurb Foun­da­tion and GitHub. Togeth­er they make for a very pleas­ant and pro­duc­tive way to do pro­to­typ­ing in the brows­er. I don’t imag­ine myself going back to draw­ing pic­tures of web pages any­time soon.

Writing for conversational user interfaces

Last year at Hub­bub we worked on two projects fea­tur­ing a con­ver­sa­tion­al user inter­face. I thought I would share a few notes on how we did the writ­ing for them. Because for con­ver­sa­tion­al user inter­faces a large part of the design is in the writ­ing.

At the moment, there aren’t real­ly that many tools well suit­ed for doing this. Twine comes to mind but it is real­ly more focused on pub­lish­ing as opposed to author­ing. So while we were work­ing on these projects we just grabbed what­ev­er we were famil­iar with and felt would get the job done.

I actu­al­ly think there is an oppor­tu­ni­ty here. If this con­ver­sa­tion­al ui thing takes off design­ers would ben­e­fit a lot from bet­ter tools to sketch and pro­to­type them. After all this is the only way to fig­ure out if a con­ver­sa­tion­al user inter­face is suit­able for a par­tic­u­lar project. In the words of Bill Bux­ton:

Every­thing is best for some­thing and worst for some­thing else.”

Okay so below are my notes. The two projects are KOKORO (a code­name) and Free Birds. We have yet to pub­lish exten­sive­ly on both, so a quick descrip­tion is in order.

KOKORO is a dig­i­tal coach for teenagers to help them man­age and improve their men­tal health. It is cur­rent­ly a pro­to­type mobile web app not pub­licly avail­able. (The engine we built to dri­ve it is avail­able on GitHub, though.)

Free Birds (Vri­je Vogels in Dutch) is a game about civ­il lib­er­ties for fam­i­lies vis­it­ing a war and resis­tance muse­um in the Nether­lands. It is a loca­tion-based iOS app cur­rent­ly avail­able on the Dutch app store and playable in Air­borne Muse­um Harten­stein in Oost­er­beek.


For KOKORO we used Gingko to write the con­ver­sa­tion branch­es. This is good enough for a pro­to­type but it becomes unwieldy at scale. And any­way you don’t want to be lim­it­ed to a tree struc­ture. You want to at least be able to loop back to a par­ent branch, some­thing that isn’t sup­port­ed by Gingko. And maybe you don’t want to use the branch­ing pat­tern at all.

Free Birds’s sto­ry has a very lin­ear struc­ture. So in this case we just wrote our con­ver­sa­tions in Quip with some basic rules for for­mat­ting, not unlike a screen­play.

In Free Birds play­er choic­es ‘colour’ the events that come imme­di­ate­ly after, but the path stays the same.

This approach was inspired by the Walk­ing Dead games. Those are super clever at giv­ing play­ers a sense of agency with­out the need for sprawl­ing sto­ry trees. I remem­ber see­ing the cre­ators present this strat­e­gy at PRACTICE and some­thing clicked for me. The impor­tant point is, choic­es don’t have to branch out to dif­fer­ent direc­tions to feel mean­ing­ful.

KOKORO’s choic­es did have to lead to dif­fer­ent paths so we had to build a tree struc­ture. But we also kept track of things a user says. This allows the app to “learn” about the user. Sub­se­quent seg­ments of the con­ver­sa­tion are adapt­ed based on this learn­ing. This allows for more flex­i­bil­i­ty and it scales bet­ter. A sec­tion of a con­ver­sa­tion has var­i­ous states between which we switch depend­ing on what a user has said in the past.

We did some­thing sim­i­lar in Free Birds but used it to a far more lim­it­ed degree, real­ly just to once again colour cer­tain pieces of dia­logue. This is already enough to give a play­er a sense of agency.


As you can see, it’s all far from rock­et surgery but you can get sur­pris­ing­ly good results just by stick­ing to these sim­ple pat­terns. If I were to inves­ti­gate more advanced strate­gies I would look into NLP for input and pro­ce­dur­al gen­er­a­tion for out­put. Who knows, maybe I will get to work on a project involv­ing those things some time in the future.

Hardware interfaces for tuning the feel of microinteractions

In Dig­i­tal Ground Mal­colm McCul­lough talks about how tun­ing is a cen­tral part of inter­ac­tion design prac­tice. How part of the chal­lenge of any project is to get to a point where you can start tweak­ing the vari­ables that deter­mine the behav­iour of your inter­face for the best feel.

Feel” is a word I bor­row from game design. There is a book on it by Steve Swink. It is a fun­ny term. We are try­ing to sim­u­late sen­sa­tions that are derived from the phys­i­cal realm. We are try­ing to make things that are pure­ly visu­al behave in such a way that they evoke these sen­sa­tions. There are many games that heav­i­ly depend on get­ting feel right. Basi­cal­ly all games that are built on a physics sim­u­la­tion of some kind require good feel for a good play­er expe­ri­ence to emerge.

Physics sim­u­la­tions have been find­ing their way into non-game soft­ware prod­ucts for some time now and they are becom­ing an increas­ing part of what makes a prod­uct, er, feel great. They are often at the foun­da­tion of sig­na­ture moments that set a prod­uct apart from the pack. These sig­na­ture moments are also known as microin­t­er­ac­tions. To get them just right, being able to tune well is very impor­tant.

The behav­iour of microin­t­er­ac­tions based on physics sim­u­la­tions is deter­mined by vari­ables. For exam­ple, the feel of a spring is deter­mined by the mass of the weight attached to the spring, the spring’s stiff­ness and the fric­tion that resists the motion of the weight. These vari­ables inter­act in ways that are hard to mod­el in your head so you need to make repeat­ed changes to each vari­able and try the sim­u­la­tion to get it just right. This is time-con­sum­ing, cum­ber­some and resists the easy explo­ration of alter­na­tives essen­tial to a good design process.

In The Set­up game design­er Ben­nett Fod­dy talks about a way to improve on this work­flow. Many of his games (if not all of them) are playable physics sim­u­la­tions with pun­ish­ing­ly hard con­trols. He sug­gests using a hard­ware inter­face (a MIDI con­troller) to tune the vari­ables that deter­mine the feel of his game while it runs. In this way the loop between chang­ing a vari­able and see­ing its effect in game is dra­mat­i­cal­ly short­ened and many dif­fer­ent com­bi­na­tions of val­ues can be explored eas­i­ly. Once a sat­is­fac­to­ry set of val­ues for the vari­ables has been found they can be writ­ten back to the soft­ware for future use.

I do believe such a set­up is still non-triv­ial to make work with todays tools. A quick check ver­i­fies that Framer does not have OSC sup­port, for exam­ple. There is an oppor­tu­ni­ty here for pro­to­typ­ing envi­ron­ments such as Framer and oth­ers to sup­port it. The approach is not lim­it­ed to motion-based microin­t­er­ac­tions but can be extend­ed to the tun­ing of vari­ables that con­trol oth­er aspects of an app’s behav­iour.

For exam­ple, when we were mak­ing Stand­ing, we would have ben­e­fit­ed huge­ly from hard­ware con­trols to tweak the sen­si­tiv­i­ty of its motion-sens­ing func­tions as we were using the app. We were forced to do it by repeat­ed­ly chang­ing num­bers in the code and build­ing the app again and again. It was quite a pain to get right. To this day I have the feel­ing we could have made it bet­ter if only we would have had the tools to do it.

Judg­ing from sna­fus such as the poor feel of the lat­est Twit­ter desk­top client, there is a real need for bet­ter tools for tun­ing microin­t­er­ac­tions. Just like pen tablets have become indis­pens­able for those design­ing the form of user inter­faces on screens. I think we might soon find a small set of hard­ware knobs on the desks of those design­ers work­ing on the behav­iour of user inter­faces.

Design without touching the surface

I am prepar­ing two class­es at the moment. One is an intro­duc­tion to user expe­ri­ence design, the oth­er to user inter­face design. I did not come up with this divi­sion, it was part of the assign­ment. I thought it was odd at first. I wasn’t sure where one dis­ci­pline ends and the oth­er begins. I still am not sure. But I made a prag­mat­ic deci­sion to have the UX class focus on the high lev­el process of design­ing (soft­ware) prod­ucts, and the UI class focus on the visu­al aspects of a product’s inter­face. The UI class deals with a product’s sur­face, form, and to some extent also its behav­iour, but on a micro lev­el. Where­as the UX class focus­es on behav­iour on the macro lev­el. Sim­ply speaking—the UX class is about behav­iour across screens, the UI class is about behav­iour with­in screens.

The solu­tion is work­able. But I am still not entire­ly com­fort­able with it. I am not com­fort­able with the idea of being able to prac­tice UX with­out ‘touch­ing the sur­face’, so to speak. And it seems my two class­es are advo­cat­ing this. Also, I am pret­ty sure this is every­day real­i­ty for many UX prac­ti­tion­ers. Notice I say “prac­ti­tion­er”, because I am not sure ‘design­er’ is the right term in these cas­es. To be hon­est I do not think you can prac­tice design with­out doing sketch­ing and pro­to­typ­ing of some sort. (See Bill Buxton’s ‘Sketch­ing User Expe­ri­ences’ for an expand­ed argu­ment on why this is.) And when it comes to design­ing soft­ware prod­ucts this means touch­ing the sur­face, the form.

Again, the real­i­ty is, ‘UX design­er’ and ‘UI design­er’ are com­mon terms now. Cer­tain­ly here in Sin­ga­pore peo­ple know they need both to make good prod­ucts. Some prac­ti­tion­ers say they do both, oth­ers one or the oth­er. The lat­ter appears to be the most com­mon and expect­ed case. (By the way, in Sin­ga­pore no-one I’ve met talks about inter­ac­tion design.)

My con­cern is that by encour­ag­ing the prac­tice of doing UX design with­out touch­ing the sur­face of a prod­uct, we get shit­ty designs. In a process where UX and UI are seen as sep­a­rate things the risk is one comes before the oth­er. The UX design­er draws the wire­frames, the UI design­er gets to turn them into pret­ty pic­tures, with no back-and-forth between the two. An iter­a­tive process can mit­i­gate some of the dam­age such an arti­fi­cial divi­sion of labour pro­duces, but I think we still start out on the wrong foot. I think a bet­ter prac­tice might entail includ­ing visu­al con­sid­er­a­tions from the very begin­ning of the design process (as we are sketch­ing).

Two things I came across as I was prepar­ing these class­es are some­how in sup­port of this idea. Both result­ed from a call I did for resources on user inter­face design. I asked for books about visu­al aspects, but I got a lot more.

  1. In ‘Mag­ic Ink’ Bret Vic­tor writes about how the design of infor­ma­tion soft­ware is huge­ly indebt­ed to graph­ic design and more specif­i­cal­ly infor­ma­tion design in the tra­di­tion of Tufte. (He also men­tions indus­tri­al design as an equal­ly big prog­en­i­tor of inter­ac­tion design, but for soft­ware that is main­ly about manip­u­la­tion, not infor­ma­tion.) The arti­cle is big, but the start of it is actu­al­ly a pret­ty good if unortho­dox gen­er­al intro­duc­tion to inter­ac­tion design. For soft­ware that is about learn­ing through look­ing at infor­ma­tion Vic­tor says inter­ac­tion should be a last resort. So that leaves us with a task that is 80% if not more visu­al design. Touch­ing the sur­face. Which makes me think you might as well get to it as quick­ly as pos­si­ble and start sketch­ing and pro­to­typ­ing aimed not just at struc­ture and behav­iour but also form. (Hat tip to Pieter Diepen­maat for this one.)

  2. In ‘Jump­ing to the End’ Matt Jones ram­bles enter­tain­ing­ly about design fic­tion. He argues for pay­ing atten­tion to details and that a lot of the design he prac­tices is about ‘sig­na­ture moments’ aka micro-inter­ac­tions. So yeah, again, I can’t imag­ine design­ing these effec­tive­ly with­out doing sketch­ing and pro­to­typ­ing of the sort that includes the visu­al. And in fact Matt men­tions this more or less at one point, when he talks about the fact that his team’s deliv­er­ables at Google are almost all visu­al. They are high fideli­ty mock­ups, ani­ma­tions, videos, and so on. These then become the start­ing points for fur­ther devel­op­ment. (Hat tip to Alexan­der Zeh for this one.)

In sum­ma­ry, I think dis­tin­guish­ing UX design from UI design is non­sense. Because you can­not prac­tice design with­out sketch­ing and pro­to­typ­ing. And you can­not sketch and pro­to­type a soft­ware prod­uct with­out touch­ing its sur­face. In stead of tak­ing visu­al design for grant­ed, or talk­ing about it like it is some innate tal­ent, some kind of mag­i­cal skill some peo­ple are born with and oth­ers aren’t, user expe­ri­ence prac­ti­tion­ers should con­sid­er being less enam­oured with acquir­ing more skills from busi­ness, mar­ket­ing and engi­neer­ing and in stead prac­tice at the skills that define the fields user expe­ri­ence design is indebt­ed to the most: graph­ic design and indus­tri­al design. In oth­er words, you can’t do user expe­ri­ence design with­out touch­ing the sur­face.

This pervasive games workshop I ran at this conference

A few things I got peo­ple to do at this year’s NLGD Fes­ti­val of Games:

Paper sword fight

Fight each oth­er with paper swords…

Hunting for a frisbee with lunch-boxes on their heads

…and run around with lunch-box­es on their heads.1

This was all part of a work­shop I ran, titled ‘Play­ful Tin­ker­ing’. The mys­te­ri­ous Mink ette — who amongst many things is a design­er at Six to Start — and I got peo­ple to rapid­ly pro­to­type per­va­sive games that were be played at the con­fer­ence venue the day after. The best game won a mag­nif­i­cent tro­phy shaped like a spring rid­er.

Some exer­cis­es we did dur­ing the work­shop:

  • Play a name game Mink ette had made up short­ly before the work­shop in no time at all. This is good for sev­er­al things: phys­i­cal warm-up, break­ing the ice, demon­strate the kinds of games the ses­sion is about.
  • Walk around the room and write down imag­i­nary game titles as well as names of games you used to play as a child. Good for emp­ty­ing heads and warm­ing up men­tal­ly.
  • Walk around again, pick a post-it that intrigues you. Then guess what the game is about, and have oth­ers to fill in the blanks where need. Then play the game. This is most­ly just for fun. (Noth­ing wrong with that.)
  • Analyse the games, break them up into their basic parts. Change one of those parts and play the game again. See what effect the change has. This is to get a sense of what games design is about, and how chang­ing a rule impacts the play­er expe­ri­ence.

Participants brainstorming game ideas

Par­tic­i­pants brain­storm­ing game ideas

Peo­ple then formed groups and worked on an orig­i­nal game. We pushed them to rapid­ly gen­er­ate a first rule­set that could be playtest­ed with the oth­er groups. After this they did anoth­er design sprint, and playtest­ed again out­side the room, “in the wild”. All of this in less than four hours. Whew!

The games that were made:

  • A game that involved hunt­ing for peo­ple that matched the descrip­tions on post-its that were hid­den around the venue. You first need­ed to find a post-it, then find the per­son that matched the descrip­tion on it and final­ly take a pho­to of them for points. This game was so quick to play it already ran at the par­ty, hours after the work­shop fin­ished.
  • Crowd Con­trol’ — com­pete with oth­er play­ers to get the largest per­cent­age of a group of peo­ple to do what you are doing (like nod­ding your head). This game won the tro­phy, in part because of the fero­cious play­er recruit­ment style the run­ners employed dur­ing the playtest.
  • A sail­ing game, where you tried to maneu­ver an imag­i­nary boat from one end of a space to the oth­er. Your move­ment was con­strained by the “wind”, which was a func­tion of the amount of peo­ple on either side of your boat. It fea­tured an ingen­u­ous mea­sur­ing mechan­ic which used an impro­vised rope made from a torn up con­fer­ence tote bag.
  • The lunch­box thing was impro­vised dur­ing the lunch before the playtest. A stu­dent also brought in a game he was work­ing on for his grad­u­a­tion to playtest.

We set up the playtest itself as fol­lows:

The room was open to any­one pass­ing by. Each game got their own sta­tion where they could recruit play­ers, explain the rules, keep score, etc. Mink ette and I hand­ed each play­er a red, blue and yel­low tid­dly­wink. They could use this to vote on their favorite game in three sep­a­rate cat­e­gories, by hand­ing the run­ners a tid­dly­wink. Peo­ple could play more than once, and vote as often as they liked. We also kept track of how much play­ers each game got. We hand­ed out prizes to win­ners in the dif­fer­ent cat­e­gories (a lucky dip box loaded with piña­ta fillers). The most played game got the grand prize — the spring rid­er tro­phy I cre­at­ed with help from my sis­ter and fab­ri­cat­ed at the local fablab.2

The spring rider trophy and tiddlywinks all set for the playtest

Spring rid­er tro­phy and tid­dly­winks ready for some playtest­ing action

It was a plea­sure to have the elu­sive Mink ette over for the ride. I loved the way she explained what per­va­sive games were all about — being able to play any­time, any­where with any­thing. I was also impressed with the way she man­aged to get peo­ple to do strange things with­out think­ing twice.

We had a very ded­i­cat­ed group of par­tic­i­pants, most of whom stuck around for the whole ses­sion and returned again for the playtest the next day. I’m very grate­ful for their enthu­si­asm. The whole expe­ri­ence was very reward­ing, I’m keen on doing this more often at events and apply­ing what I learnt to the work­shops I run as part of my own games design prac­tice.

Happy, happy winners!

Hap­py win­ners of the spring rid­er tro­phy flanked by Mink ette and yours tru­ly

  1. May­hem ini­ti­at­ed by Evert and Marin­ka. []
  2. I still need to write up the process of the trophy’s cre­ation. []

The making of a travel-time map of the Netherlands

Sub­scribers to my Flickr stream have prob­a­bly noticed a num­ber of images of some kind of map flow­ing past late­ly. They were the result of me track­ing my progress on a pet project. I have more or less fin­ished work on it this week, so I thought I’d detail what I did over here.

Background

Fol­low­ing my Twit­ter dataviz sketch­es, I thought I’d take anoth­er stab at pro­to­typ­ing with Pro­cess­ing. On the one hand I want­ed to increase my famil­iar­i­ty with the envi­ron­ment. On the oth­er, I con­tin­ued to be fas­ci­nat­ed with data-visu­al­iza­tion, so I want­ed to do anoth­er design exer­cise in this domain. I was par­tic­u­lar­ly inter­est­ed in cre­at­ing dis­plays that assist in deci­sion mak­ing and present data in a way that allows peo­ple to ‘play’ with it — explore it and learn from it.

The seed for this thing was plant­ed when I saw Sta­men’s work on the mySo­ci­ety trav­el-time maps. I thought the idea of visu­al­ly over­lay­ing two datasets and allow­ing the inter­sec­tion to be manip­u­lat­ed by peo­ple was sim­ple but pow­er­ful. But, at that time, I saw no way to ‘eas­i­ly’ try my hand at some­thing sim­i­lar. I had no ready access to any poten­tial­ly inter­est­ing data, and my scrap­ing skills are lim­it­ed at best.

Luck­i­ly, I was not the only one whose curios­i­ty was piqued. After see­ing Ben Cer­ve­ny demo­ing the same maps at The Web and Beyond 2008, Alper won­dered how hard it would be to cre­ate some­thing sim­i­lar for the Nether­lands. He pre­sent­ed a way to do it with freely avail­able tools and data (to an extent) in a work­shop at a local uncon­fer­ence.1

I did not attend the event, but after see­ing his blog post, I sent him an email and asked if he was will­ing to part with the data he had col­lect­ed from the Dutch pub­lic trans­port trav­el plan­ning site 9292. Alper being the nice guy he is, he soon emailed me a JSON con­tain­ing of the data.

So that’s the back­ground. I had an exam­ple, I had some data, and I had a lit­tle expe­ri­ence with mak­ing things in Pro­cess­ing.

JSON

The first step was to read the data in the JSON file from Pro­cess­ing. I fol­lowed the instruc­tions on how to get the JSON library into Pro­cess­ing from Ben Fry’s book (pages 315–316). On the Pro­cess­ing boards, a cur­so­ry search unearthed some code exam­ples. After a lit­tle fid­dling, I got it to work and could print the data to Processing’s con­sole.

Plotting

Next up was to start visu­al­iz­ing it. I used the exam­ples of scat­ter­plot maps in Visu­al­iz­ing Data as a start­ing point, and plugged in the JSON data. Pret­ty soon, I had a nice plot of the postal codes that actu­al­ly resem­bled the Nether­lands.

Playing with some data Alper gave me

Coloring

From there, it was rather easy to show each postal code’s trav­el time.2 I sim­ply mapped trav­el times to a hue in the HSB spec­trum. The result nice­ly shows col­ored bands of trav­el-time regions and also allows you to pick out some inter­est­ing out­liers (such as Gronin­gen in the north).

Second pass

Selecting

At this point, I want­ed to be able to select trav­el-time ranges and hide postal codes out­side of that range. Ini­tial­ly, I used the key­board for input. This was OK for this stage of the project, but of course it would need to be replaced with some­thing more intu­itive lat­er on. In any case, I could high­light select­ed points and dim oth­ers, which increased the display’s explorabil­i­ty con­sid­er­ably.

Pass 3

Coloring, again

The HSB spec­trum is quick and easy way of get­ting access to a full a range of col­ors. It served me well in my Twit­ter visu­al­iza­tions. How­ev­er in this case it left some­thing to be desired, aes­thet­i­cal­ly speak­ing. Via Tom Car­den I found the won­der­ful cpt-city, which cat­a­logues gra­di­ents for car­tog­ra­phy and the like. Ini­tial­ly I strug­gled with ways to get these col­ors into Pro­cess­ing, but then it turned out you could eas­i­ly read out the col­ors of pix­els from images. This allowed me to cycle through many palettes just by adding the files to my Pro­cess­ing sketch. I dis­cov­ered that a palette with a clear divi­sion in the mid­dle was best, because that pro­vides you with an extra ref­er­ence point besides the begin­ning and end.

Playing with palettes (pass 4)

Selecting, again

I next turned to the inter­ac­tion bits. I knew I want­ed a so-called dual slid­er that would allow peo­ple to select the upper and low­er lim­it of trav­el time. In the Pro­cess­ing book, there is code for plen­ty of inter­face wid­gets, but sad­ly no dual slid­er. I looked around on the Pro­cess­ing board and could find none either, to my sur­prise. Even in the UI libraries (such as controlP5 and Inter­fas­cia) I could not locate one.

So I decid­ed to low­er the bar and first include two hor­i­zon­tal slid­ers, one for the upper and one for the low­er lim­it. These I made using the code on pages 448–452 of the Pro­cess­ing book. Not per­fect, but an improve­ment over the key­board con­trols.

Pass 5 – some basic interactivity

Selecting, yet again

Next, I decid­ed I’d see if I could mod­i­fy the code of the hor­i­zon­tal scroll­bar so that I would end up with a dual slid­er. After some mess­ing about (which did increase my under­stand­ing of the orig­i­nal code con­sid­er­ably) I man­aged to get it to work. This was an unex­pect­ed suc­cess. I now had a decent dual slid­er.

A proper dual slider

Exploring

So far there was no way of telling which point cor­re­spond­ed to which postal code. So, I added a rollover that dis­played the postal code’s name and trav­el time. At this point it became clear the data wasn’t per­fect — some postal codes were erro­neous­ly geocod­ed by GeoN­ames. For instance, code 9843 (which is Gri­jpskerk, 199 min­utes to the Dam) was placed on the map as Ams­ter­dam Noord-Oost!

Rollovers

Adding more data

Around this point I vis­it­ed Alper in Delft and we dis­cussed adding a sec­ond dataset. Although hous­ing prices à la mySo­ci­ety would have been inter­est­ing, we decid­ed to take a dif­fer­ent route and add a sec­ond trav­el-time set for cars.3 My first step in inte­grat­ing this was to sim­ply gen­er­ate a map each for the pub­lic trans­port and car trav­el data and man­u­al­ly jux­ta­pose them. What I liked about this was that even though you know intu­itive­ly that trav­el­ing by car is faster, the two maps next to each oth­er pro­vide a dra­mat­ic visu­al con­fir­ma­tion of this piece of knowl­edge.

Compare: travel by public transport or car

Representing

Mov­ing ahead with the extra data, I start­ed to strug­gle with how to rep­re­sent both trav­el times. My first effort was to draw two sets of dots on top of each oth­er (one for car trav­el times and one for pub­lic trans­port) and col­or each accord­ing­ly. For each set I intro­duced a sep­a­rate slid­er. I wasn’t very sat­is­fied with the result of this. It did not help in under­stand­ing what was going on that much.

The gap

Showing differences

After dis­cus­sions with Alper and sev­er­al oth­er peo­ple, I decid­ed it would make more sense to show the dif­fer­ence between trav­el times. So I cal­cu­lat­ed the per­cent­age dif­fer­ence between pub­lic trans­port and car trav­el time for each postal code. This val­ue I mapped to a col­or. Here, a sim­ple gra­di­ent worked bet­ter than the palettes used ear­li­er for trav­el times.

I also dis­card­ed the idea of hav­ing two dual slid­ers and sim­ply went with one trav­el time selec­tor. Although more user-friend­ly, it cre­at­ed a new prob­lem: for some points both trav­el times would fall with­in the select­ed range, and for oth­ers one or the oth­er. So I need­ed an extra visu­al dimen­sion to show this. This turned out to be the great­est chal­lenge.

After try­ing many approach­es, I even­tu­al­ly set­tled on using the shape of the point to show which trav­el times fell with­in the range. A small dot meant that only the pub­lic trans­port trav­el time is with­in the range, a donut means only the car trav­el time is select­ed, and a big dot rep­re­sents selec­tion of both times.

Return of the map

Final tweaks

Around this point I felt that it was time to wrap up. I had learnt about all I could from the exer­cise and any extra time spent on the project would result in mar­gin­al improve­ments at best. I added a leg­end for both the shapes and col­or, improved the leg­i­bil­i­ty of the rollover and increased the visu­al affor­dance of the slid­er, and that was it.

It's hard to stop tweaking

Thoughts

It is becom­ing appar­ent to me that the act of build­ing dis­plays like this is play­ful in its own way. Through sketch­ing in code, you can have some­thing like a con­ver­sa­tion with the data and get a sense of what’s there. Per­haps the end result is mere­ly a byprod­uct of this process?

I’m amazed at how far a novice pro­gram­mer like myself, with a dra­mat­ic lack of affin­i­ty for any­thing relat­ed to math­e­mat­ics or physics, can get by sim­ply mod­i­fy­ing, aug­ment­ing and com­bin­ing code that is already out there. I have no ambi­tion what­so­ev­er of becom­ing a pro­fes­sion­al devel­op­er of pro­duc­tion-qual­i­ty code. But build­ing a col­lec­tion bits and pieces of code that can do use­ful and inter­est­ing things seems like a good strat­e­gy for any design­er. I am learn­ing to trust my innate reluc­tance to code stuff from scratch.

Also, isn’t it cool that it is becom­ing increas­ing­ly fea­si­ble for reg­u­lar cit­i­zens to start ana­lyz­ing data that is — or at least should be — pub­licly avail­able? Gov­ern­ment still has a long way to go. Why do we need to go through the painstak­ing process of scrap­ing this data from sources such as 9292 which for all intents and pur­pos­es is a pub­lic ser­vice?4

I will prob­a­bly make the final pro­to­type avail­able online at some point in the future. For now, if you have any ques­tions or com­ments I would love to hear them here, or via email.

Update: Alper has released a JSON file con­tain­ing all the data I used to make this. Go on and grab it, and make some dis­plays of your own!

And anoth­er update: I’ve decid­ed to make this appli­ca­tion avail­able for down­load, includ­ing source files.

  1. Those of you who under­stand Dutch might enjoy his walk­through on Vimeo. []
  2. Inci­den­tal­ly, all trav­el times in this project were from the Dam in Ams­ter­dam to all the postal codes in NL. []
  3. This we retrieved from the ANWB site. The time of day was set to 12:00 noon. []
  4. Tools like Mech­a­nize make this eas­i­er, but still. []

Pollinator — a casual game prototype made with Mobile Processing

I wrote a game about a bee and flowers today

Last sun­day I sat down and cod­ed a pro­to­type of a casu­al game in Mobile Pro­cess­ing. I got the idea for it the evening before: You’re a bee who needs to col­lect as much hon­ey as pos­si­ble in his hive while at the same time keep­ing a flower-bed bloom­ing by pol­li­nat­ing… Play it and let me know what your high score is in the com­ments!

Thinking and making

I’ve been look­ing for an excuse to get some expe­ri­ence with Pro­cess­ing (par­tic­u­lar­ly the vari­ant suit­able for devel­op­ing mobile stuff) for a while. I also felt I need­ed to get back into the mak­ing part of the field I’ve been think­ing about so much late­ly: Game Design. I agree with Saf­fer, Webb and oth­ers — mak­ing is an impor­tant part of the design prac­tice, it can­not be replaced by lots of think­ing. The things learnt from engag­ing with the actu­al stuff things are made of (which in the case of dig­i­tal games is code) aren’t gained in any oth­er way and very valu­able.

Get the game

I’ve uploaded the first ver­sion of the game here. You can play it in the emu­la­tor in your brows­er or if your phone runs Java midlets, down­load the file and play it like you’re sup­posed to: While out and about. The source code is pro­vid­ed as well, if you feel like look­ing at it.1

Pollinator 0.1

How to play

You’re the yel­low oval. The orange tri­an­gle in the top left cor­ner is your hive. Green squares are grass, brown squares are seeds, red squares are flow­ers and pink squares are pol­li­nat­ed flow­ers. The field is updat­ed in columns from left to right (indi­cat­ed by the yel­low mark­er in the bot­tom). A seed will turn into a flower (in rare cas­es a pol­li­nat­ed flower). A flower will die, a pol­li­nat­ed flower will die and spread seeds to grass around it. Move your bee with the direc­tion­al keys, use the cen­tre key to grab nec­tar from a flower. You can cary a max­i­mum of 100 nec­tar. Drop your nec­tar off at the hive (again using the cen­tre key) to up your score. When you first grab nec­tar from a pol­li­nat­ed flower and sub­se­quent­ly from a nor­mal flower, the lat­ter is pol­li­nat­ed. Try to keep the flower-bed in bloom while at the same time rack­ing up a high-score!

You’ll get 10 nec­tar from a flower (in bloom or not). Pol­li­nat­ing a flower costs 5 nec­tar. If you try to take nec­tar more than once from the same flower, you’ll loose 10 nec­tar.2

Improvements

Stuff not in here that I might put into a next ver­sion (when­ev­er I get around to it):

  • Ani­ma­tion — I need to get my feet wet with some script­ed ani­ma­tion. Thing is I’ve always sucked at this. For now it’s all tile-based stuff.
  • Bet­ter feed­back — For instance show the points you earn near the bee and the hive. I think that’ll make the game a lot eas­i­er to under­stand and there­fore more fun.
  • Menus, pause, game over — It’s a pro­to­type, so you get dumped into the action right away. (The game starts on the first key you press.) And there’s no actu­al game over mes­sage, the field just turns green and you’re left to won­der what to do.
  • Bal­ance — I’m not sure if the game like it stands is bal­anced right, I will need to play it a lot to fig­ure that out. Also there’s prob­a­bly a dom­i­nant strat­e­gy that’ll let you rack up points eas­i­ly.

The aim was to cre­ate a rel­a­tive­ly casu­al game expe­ri­ence that will almost allow you to zone out while play­ing. I think it is far too twitchy now, so per­haps I real­ly should sit down and do a sec­ond ver­sion some­time soon.

Mobile Processing

I enjoy work­ing with Mobile Pro­cess­ing. I like the way it allows you to pro­gram in a very naive way but if you like struc­ture things in a more sophis­ti­cat­ed fash­ion. It real­ly does allow you to sketch in code, which is exact­ly what I need. The empha­sis on just code also pre­vents me from fid­dling around with ani­ma­tions, graph­ics and so on (like I would in Flash for instance.) Per­haps the only thing that would be nice is an edi­tor that is a bit more full-fea­tured.3 Per­haps I should grab an exter­nal edi­tor next time?

Feedback

If you played the game and liked it (or thought it was too hard, bor­ing or what­ev­er) I’d love to get your feed­back in the com­ments. Any­one else out there pro­to­typ­ing games in Pro­cess­ing? Or using it to teach game design? I’d be very inter­est­ed to hear about it.

  1. Not that it’s par­tic­u­lar­ly good, I’m an ama­teur coder at best. []
  2. I’m not sure this is the right kind of neg­a­tive rein­force­ment. []
  3. The auto­mat­ic code for­mat­ting refused to work for me, requir­ing me to spend a bit too much effort on for­mat­ting by hand. []