Tag: design

What the hubbub is

There’s some move­ment over at the web­site for my new ven­ture. I men­tioned Hub­bub before: it is a design stu­dio I am set­ting up for phys­i­cal, social games that are played in pub­lic places. We hope to address social issues and the like using these games.

Recent­ly…

Today's harvest

Also, we’ll be doing some­thing play­ful and run­ning a work­shop at the upcom­ing Game in the City con­fer­ence in Amersfoort. 

To stay post­ed on Hub­bub devel­op­ments, fol­low us on Twit­ter or sign up for our newslet­ter. There’s good old RSS as well, of course.

Work now so you can play later

There’s a lot going on at the Leapfrog stu­dio, which explains at least in part why things have gone qui­et around here. How­ev­er, I want­ed to take the time to alert you to some upcom­ing events that might be of interest.

An urban game in the Rotterdam city center

On Sun­day Sep­tem­ber 27 around 50 young peo­ple will play an urban game I designed for Your World — Rot­ter­dam Euro­pean Youth Cap­i­tal 2009.1 It is part of a two-day event called Change Your World, which enables groups of youth to set up a new ‘move­ment’ with finan­cial sup­port and advice from pro­fes­sion­als. You might want to hang around the Rot­ter­dam city cen­ter dur­ing the day, to wit­ness what is sure to be an inter­est­ing spec­ta­cle. More info should show up soon enough at the Your World web­site.

A pervasive game in the Hoograven neighborhood of Utrecht

Around the same time, from Sep­tem­ber 18 to Octo­ber 11, you’ll be able to play Kop­pelkiek in the Hoograven area of Utrecht. This is a game I’ve cre­at­ed for the Dutch Design Dou­ble pro­gram.2 To play, you take pho­tos of your­self with oth­ers in a range of sit­u­a­tions and upload them to the game’s web­site. It’s designed to sub­tly per­me­ate your dai­ly life. With the help of our play­ers we’re hop­ing to cre­ate a col­lec­tion of pho­tos that pro­vide a unique look into life in the neigh­bor­hood. Do join in if you’re in the area. Also, we’ll have a playtest on Sep­tem­ber 16. If you’re inter­est­ed in play­ing a round or two, drop me a line.3

Data visualizations of silence

I’m wrap­ping up some data visu­al­iza­tion work I’ve done for the artist Sarah van Sons­beeck.4 Sarah’s work revolves (amongst oth­er things) around the con­cept of silence. Alper and I took a dataset she gen­er­at­ed dur­ing a few of her ‘silence walks’ using a GPS track­er and a sound lev­el meter and cre­at­ed a num­ber of sta­t­ic visu­al­iza­tions in Pro­cess­ing. Some of the out­put can be seen at the exhi­bi­tion Een Dijk van een Kust. More will prob­a­bly be on dis­play at anoth­er occa­sion. Also, I’ve learnt some new tricks that I intend to share here soon.

What else, what else…

  • I’m still mean­ing to write some­thing up about the work that went into Mega Mon­ster Bat­tle Are­na™ but it will have to wait. I attend­ed two of the three shows and enjoyed both through­ly. There’s some pho­tos up at the opera’s web­site.
  • We’re in the process of fin­ish­ing up the This hap­pened – Utrecht #3 videos. Once they’re all done we’ll add them to the event’s page on the .org site along with the slides. Plan­ning for our fourth event has already start­ed. Mark your cal­en­dar for Octo­ber 26 and sub­scribe to our newslet­ter so you won’t miss the reg­is­tra­tion’s opening.
  • And final­ly, I’m slow­ly but sure­ly giv­ing shape to a new ven­ture which will focus on the use of play in pub­lic space to effect social change. Its name is Hub­bub. The crazy design­ers at BUROPONY are devel­op­ing a sweet brand iden­ti­ty and a first place­hold­er site is up. Stay tuned for more news on that.

That’s about it for now, thanks for your atten­tion. I promise to pro­vide con­tent with more meat and less self-pro­mo­tion in upcom­ing posts. 

  1. Karel Mil­lenaar, game design­er extra­or­di­naire at Fource­Labs and a fel­low res­i­dent of the Dutch Game Gar­den, has helped me out on this one. [↩]
  2. I’ve asked Tij­men Schep of Pinep­ple­Jazz, NetNiet.org and the new Utrecht medi­al­ab to be my part­ner on this one. [↩]
  3. Around the same time a lot of oth­er inter­est­ing stuff relat­ed to design and soci­ety will be going on, such as the third edi­tion of Utrecht Man­i­fest, the bien­ni­al for social design. [↩]
  4. I was turned on to this gig by the ubiq­ui­tous Alper Çuğun. [↩]

Buildings and Brains at the Nijmegen Design Platform (NOP)

It’s been a few weeks since I pre­sent­ed at the Nijmegen Design Plat­form (NOP), but I thought it would still be use­ful to post a sum­ma­ry of what I talked about here. 

Update: it took me a while, but the slides that accom­pa­nied this talk are now up at SlideShare. 

A lit­tle con­text: The NOP run fre­quent events for design­ers in the region. These design­ers most­ly work in more tra­di­tion­al domains such as graph­ic, fash­ion and indus­tri­al design. NOP asked Jeroen van Mas­trigt — a friend and occa­sion­al col­league of mine — to talk about games at one of their events. Jeroen in turn asked me to play Robin to his Bat­man, I would fol­low up his epic romp through game design the­o­ry with a brief look at per­va­sive games. This of course was an offer I could not refuse. The event was held at a love­ly loca­tion (the huge art-house cin­e­ma LUX) and was attend­ed by a healthy-sized crowd. Kudos to the NOP for orga­niz­ing it and many thanks to them (and Jeroen) for invit­ing me.

So, what I tried to do in the talk was to first give a sense of what per­va­sive games are, what char­ac­ter­izes them. I drew from the Hide & Seek web­site for the list of char­ac­ter­is­tics and used The Soho Project as a run­ning exam­ple through­out this part. I also tied the char­ac­ter­is­tics to some the­o­ry I found interesting:

  • Mix­ing dig­i­tal tech­nol­o­gy with real world play — I empha­sized that ulti­mate­ly, tech­nol­o­gy is but a means to an end. At Inter­ac­tion ‘09 Robert Fab­ri­cant said the medi­um of inter­ac­tion design is human behav­ior. I think the same holds true for the design of per­va­sive games.
  • Social inter­ac­tion — Raph Koster once said sin­gle play­er games are a his­tor­i­cal aber­ra­tion. It is clear much of the fun in per­va­sive games is social. In a way I think they bridge the gap between the “old” board games and con­tem­po­rary video games.
  • Using the city as a play­ground — Here I could not resist bring­ing in Jane Jacob’s notions of the city as an enti­ty that is organ­ised from the bot­tom up and Kevin Lynch’s work on the men­tal maps we cre­ate of cities as we move through them. Cities play a vital role in facil­i­tat­ing the play of per­va­sive games. At best they are the main pro­tag­o­nist of them.
  • Trans­form­ing pub­lic spaces into the­atri­cal stage­sets — This is relat­ed to the pre­vi­ous one, but here I made a side­step into the embod­ied nature of play­er inter­ac­tions in per­va­sive games and how embod­i­ment facil­i­tates read­ing at a dis­tance of such actions. In a sense, the social fun of embod­ied play is due to its per­for­ma­tive quality.

After this, I tried to show why design­ers out­side the domain of games should care about per­va­sive games. This I did by talk­ing about ways they can be used for pur­pos­es oth­er than ‘mere’ enter­tain­ment. These were:

  • Enlarg­ing per­ceived real­i­ty; you can cre­ate games that play with the way we cus­tom­ar­i­ly per­ceive real­i­ty. This was inspired by the talk Kevin Slavin of Area/Code deliv­ered at MIND08. Exam­ples I used were Cross­roads and The Com­fort of Strangers.
  • Chang­ing human behav­ior for the bet­ter; think of the Toy­ota Prius dash­board­’s effect on people’s dri­ving behav­ior. Exam­ples of games that use feed­back loops to steer us towards desir­able goals are Cryp­to­Zoo and FourSquare.
  • Crowd­sourc­ing solu­tions; games can sim­u­late pos­si­ble futures and chal­lenge play­ers to respond to their prob­lems. Here I used Jane McGo­ni­gal’s ideas around col­lec­tive intel­li­gence gam­ing. The exam­ple game I talked about was World With­out Oil.
  • Con­vey­ing argu­ments pro­ce­du­ral­ly; Ian Bogost’s con­cept of pro­ce­dur­al rhetoric isn’t spe­cif­ic to per­va­sive games, but I think the way they get mixed up with every­day life make them par­tic­u­lar­ly effec­tive chan­nels for com­mu­ni­cat­ing ideas. I used The Go Game, Cru­el 2B Kind and Join the Line1 as examples. 

By talk­ing about these things I hoped to pro­vide a link to the audience’s own design prac­tice. They may not deal with games, but they sure­ly deal with com­mu­ni­cat­ing ideas and chang­ing people’s behav­ior. Come to think of it though, I was doing a very old media style pre­sen­ta­tion in attempt to achieve the same… Oh well.

  1. Join the Line is a game stu­dents con­cep­tu­al­ized dur­ing a work­shop I ran. [↩]

A Playful Stance — my Game Design London 2008 talk

A while ago I was inter­viewed by Sam War­naars. He’s research­ing people’s con­fer­ence expe­ri­ences; he asked me what my most favourite and least favourite con­fer­ence of the past year was. I wish he’d asked me after my trip to Play­ful ’08, because it has been by far the best con­fer­ence expe­ri­ence to date. Why? Because it was like Toby, Richard and the rest of the event’s pro­duc­ers had tak­en a peek inside my brain and came up with a pro­gram encom­pass­ing (almost) all my fas­ci­na­tions — games, inter­ac­tion design, play, social­i­ty, the web, prod­ucts, phys­i­cal inter­faces, etc. Almost every speak­er brought some­thing inter­est­ing to the table. The audi­ence was com­posed of peo­ple from many dif­fer­ent back­grounds, and all seemed to, well, like each oth­er. The venue was love­ly and atmos­pher­ic (albeit a bit chilly). They had good tea. Drinks after­wards were tasty and fun, the tapas lat­er on even more so. And the whiskey after that, well let’s just say I was glad to have a late flight the next day. Many thanks to my friends at Pix­el-Lab for invit­ing me, and to Mr. Davies for the referral. 

Below is a tran­script plus slides of my con­tri­bu­tion to the day. The slides are also on SlideShare. I have been told all talks have been record­ed and will be pub­lished to the event’s Vimeo group.

Per­haps 1874 words is a bit too much for you? In that case, let me give you an exec­u­tive sum­ma­ry of sorts: 

  1. The role of design in rich forms of play, such as skate­board­ing, is facil­i­ta­to­ry. Design­ers pro­vide tools for peo­ple to play with.
  2. It is hard to pre­dict what peo­ple will do exact­ly with your tools. This is OK. In fact it is best to leave room for unex­pect­ed uses. 
  3. Under­spec­i­fied, play­ful tools can be used for learn­ing. Peo­ple can use them to explore com­plex con­cepts on their own terms.

As always, I am inter­est­ed in receiv­ing con­struc­tive crit­i­cism, as well as good exam­ples of the things I’ve discussed. 

Con­tin­ue read­ing A Play­ful Stance — my Game Design Lon­don 2008 talk

Chris Crawford on design suggestions

I have a con­sid­er­able amount of books with dog-eared pages lying around the office. One such book is The Game Design Read­er, which con­tains a large and var­ied col­lec­tion of essays on (yes) game design. This book prob­a­bly has the largest num­ber of dog-ears. Part­ly because it is quite thick, but also because it is filled to the brim with good stuff.

One essay is writ­ten by Chris Craw­ford. He is with­out a doubt one of the best known game design­ers out there, a real vet­er­an of the indus­try. He is also a con­tro­ver­sial char­ac­ter, often voic­ing unpop­u­lar opin­ions. I guess you could call him an iconoclast.

This icon­o­clasm shines through in his essay for TGDR. Craw­ford shares the sto­ry behind the design of East­ern Front (1941) his “first big hit”. Towards the end, he devotes some atten­tion to game tun­ing, and has this to say about how you as a design­er should approach sug­ges­tions from oth­ers:1

“Your job is to build a great design, not grat­i­fy your co-workers.”

Accord­ing to him, a good design­er has thought the sys­tem through so thor­ough­ly, that the vast major­i­ty of sug­ges­tions have already passed through his mind. There­fore, these can all be reject­ed with­out much thought. If you are swamped with sug­ges­tions you have not thought of before, this is an indi­ca­tion you have not prop­er­ly done your job.

I can only agree, but I think the real chal­lenge is in reject­ing these ideas in a per­sua­sive man­ner. It is hard to make appar­ent the fact that you have thought all these things through.

One strat­e­gy I am pur­su­ing is to be rad­i­cal­ly trans­par­ent in my process. I try to doc­u­ment every sin­gle con­sid­er­a­tion using quick and dirty sketch­es, and share all of these. This way, I hope to make appar­ent the think­ing that has gone into the design.

What Chris Craw­ford makes clear is that design isn’t a pop­u­lar­i­ty con­test:2

“This isn’t noble; it’s stu­pid. Seri­ous­ly con­sid­er­ing every idea that drifts by isn’t a sign of open mind­ed­ness; it’s an indi­ca­tor of inde­ci­sive­ness. […] Be cour­te­ous, but con­cen­trate on doing your job.” 

Some time ago, Craw­ford more or less turned his back on the games indus­try and focussed his atten­tion on the thorny prob­lem of inter­ac­tive sto­ry­telling. The out­comes of this are final­ly see­ing the light of day in the shape of Sto­ry­tron; a com­pa­ny that offers a free author­ing tool as well as ready-to-play ‘sto­ry­worlds’.

I wasn’t too impressed with the inter­ac­tion design of the author­ing tool, but the con­cept remains intrigu­ing. We’ll see where it goes.

If this has piqued your curios­i­ty; Chris Craw­ford will be speak­ing at IDEA 2008 in Chica­go, 7–8 Octo­ber. Rea­son enough to attend, in my hum­ble opinion.

  1. Page 723 [↩]
  2. Ibid. [↩]

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.1 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.2 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: 

Today's start - timeline

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, 

Neatly centred now

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?,

Bugfix – made a mistake in the tick mark labels

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.3 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:

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. [↩]

Sketching the experience of toys

A frame from the Sketch-A-Move video

“Play is the high­est form of research.”

—Albert Ein­stein1

That’s what I always say when I’m play­ing games, too. 

I real­ly liked Bill Bux­ton’s book Sketch­ing User Expe­ri­ences. I like it because Bux­ton defends design as a legit­i­mate pro­fes­sion sep­a­rate from oth­er disciplines—such as engineering—while at the same time show­ing that design­ers (no mat­ter how bril­liant) can only suc­ceed in the right ecosys­tem. I also like the fact that he iden­ti­fies sketch­ing (in its many forms) as a defin­ing activ­i­ty of the design pro­fes­sion. The many exam­ples he shows are very inspiring.

One in par­tic­u­lar stood out for me, which is the project Sketch-A-Move by Anab Jain and Louise Klink­er done in 2004 at the RCA in Lon­don. The image above is tak­en from the video they cre­at­ed to illus­trate their con­cept. It’s about cars auto-mag­i­cal­ly dri­ving along tra­jec­to­ries that you draw on their roof. You can watch the video over at the book’s com­pan­ion web­site. It’s a very good exam­ple of visu­al­iz­ing an inter­ac­tive prod­uct in a very com­pelling way with­out actu­al­ly build­ing it. This was all faked, if you want to find out how, buy the book.2

The great thing about the video is not only does it illus­trate how the con­cept works, it also gives you a sense of what the expe­ri­ence of using it would be like. As Bux­ton writes:3

“You see, toys are not about toys. Toys are about play and the expe­ri­ence of fun that they help fos­ter. And that is what this video real­ly shows. That, and the pow­er of video to go beyond sim­ply doc­u­ment­ing a con­cept to com­mu­ni­cat­ing some­thing about expe­ri­ence in a very vis­cer­al way.”

Not only does it com­mu­ni­cate the fun you would have play­ing with it, I think this way of sketch­ing actu­al­ly helped the design­ers get a sense them­selves of wether what they had come up with was fun. You can tell they are actu­al­ly play­ing, being sur­prised by unex­pect­ed out­comes, etc.

The role of play in design is dis­cussed by Bux­ton as well, although he admits he need­ed to be prompt­ed by a friend of his: Alex Manu, a teacher at OCAD in Toron­to writes in an email to Bux­ton:4

“With­out play imag­i­na­tion dies.”

“Chal­lenges to imag­i­na­tion are the keys to cre­ativ­i­ty. The skill of retriev­ing imag­i­na­tion resides in the mas­tery of play. The ecol­o­gy of play is the ecol­o­gy of the pos­si­ble. Pos­si­bil­i­ty incu­bates creativity.”

Which Bux­ton rephras­es in one of his own per­son­al mantras:5

“These things are far too impor­tant to take seriously.”

All of which has made me real­ize that if I’m not hav­ing some sort of fun while design­ing, I’m doing some­thing wrong. It might be worth con­sid­er­ing switch­ing from one sketch­ing tech­nique to anoth­er. It might help me get a dif­fer­ent per­spec­tive on the prob­lem, and yield new pos­si­ble solu­tions. Bux­ton’s book is a trea­sure trove of sketch­ing tech­niques. There is no excuse for being bored while design­ing anymore.

  1. Sketch­ing User Expe­ri­ences p.349 [↩]
  2. No, I’m not get­ting a com­mis­sion to say that. [↩]
  3. Ibid. 1, at 325 [↩]
  4. Ibid., at 263 [↩]
  5. Ibid. [↩]

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 comments!

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 valuable.

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 easily.

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. [↩]

Learning about emergence from games

A game of Go

I’m still try­ing to get a grip on why I think games are such a good ref­er­ence point for IAs and IxDs. I’ll try to take anoth­er stab at it in this post. Pre­vi­ous­ly I wrote about how games might be a good way to ‘sell’ algo­rith­mic archi­tec­tures to your client. Even if you’re not active­ly push­ing your clients to adopt ideas such as on-the-fly cre­ation of site nav­i­ga­tion, soon­er or lat­er I’m con­vinced you’ll find your­self con­front­ed with a project where you’re not asked to devel­op a defin­i­tive infor­ma­tion archi­tec­ture. Instead you’ll be charged with the task to come up with mech­a­nisms to gen­er­ate these pro­ce­du­ral­ly. When this is this case, you’re tru­ly fac­ing a sec­ond-order design prob­lem. How can games help here? 

One of the defin­ing char­ac­ter­is­tics of games are their com­plex­i­ty. A few years ago Ben Cer­ve­ny gave a bril­liant talk on play (MP3) at Reboot 7.0 and men­tioned this specif­i­cal­ly — that much of the plea­sure derived from game-play is the result of the play­er com­ing to terms with com­plex pat­terns. This com­plex­i­ty is some­thing dif­fer­ent from pure ran­dom­ness and most cer­tain­ly dif­fer­ent from a ‘mere’ state machine. In oth­er words, games show emergence.

There are many exam­ples of emer­gent sys­tems. The Game of Life springs to mind. This sys­tem isn’t real­ly a game but shows a remark­able rich­ness in pat­terns, despite (or maybe because of) the fact that it is based on a set of decep­tive­ly sim­ple rules (which appar­ent­ly took its cre­ator, John Con­way, over 2 years to per­fect!) The thing is though, The Game of Life is not interactive. 

A won­der­ful exam­ple of a com­plex emer­gent sys­tem that is inter­ac­tive is the real game Go. It has a set of very sim­ple rules, but play­ing it well takes a huge amount of prac­tice. The joy of play­ing Go for me (an absolute begin­ner) is large­ly due to dis­cov­er­ing the many dif­fer­ent per­mu­ta­tions play can go through. 

So get­ting back to my ear­li­er remark: If you’re con­vinced you’ll need to get a bet­ter han­dle on solv­ing the sec­ond-order design prob­lems pre­sent­ed by the design of com­plex emer­gent sys­tems, games are an excel­lent place to start learn­ing. They are emer­gent first and inter­ac­tive sec­ond, the per­fect twin to the web envi­ron­ments we’ll be shap­ing in the future.

UX designers should get into everyware

I’ve been read­ing Adam Greenfield’s Every­ware on and off and one of the things that it has me won­der­ing the most late­ly is: are UX pro­fes­sion­als mak­ing the move to design for ubiq­ui­tous computing?

There’re sev­er­al places in the book where he explic­it­ly men­tions UX in rela­tion to every­ware. Let’s have a look at the ones I man­aged to retrieve using the book’s trusty index…

On page 14 Green­field writes that with the emer­gence of ubi­comp at the dawn of the new mil­len­ni­um, the user expe­ri­ence com­mu­ni­ty took up the chal­lenge with “vary­ing degrees of enthu­si­asm, scep­ti­cism and crit­i­cal dis­tance”, try­ing to find a “lan­guage of inter­ac­tion suit­ed to a world where infor­ma­tion pro­cess­ing would be every­where in the human environment.” 

So of course the UX com­mu­ni­ty has already start­ed con­sid­er­ing what it means to design for ubi­comp. This stuff is quite dif­fer­ent to inter­net appli­ances and web sites though, as Green­field points out in the­sis 09 (pp.37–39):

“Con­sis­tent­ly elic­it­ing good user expe­ri­ences means account­ing for the phys­i­cal design of the human inter­face, the flow of inter­ac­tion between user and device, and the larg­er con­text in which that inter­ac­tion is embed­ded. In not a sin­gle one of these dimen­sions is the expe­ri­ence of every­ware any­thing like that of per­son­al com­put­ing.” (p.37)

That’s a clear state­ment, on which he elab­o­rates fur­ther on, men­tion­ing that tra­di­tion­al inter­ac­tions are usu­al­ly of a “call-and-response rhythm: user actions fol­lowed by sys­tem events.” Where­as every­ware inter­ac­tions “can’t mean­ing­ful­ly be con­struct­ed as ‘task-dri­ven.’ Nor does any­thing in the inter­play between user and sys­tem […] cor­re­spond with […] infor­ma­tion seek­ing.” (p.38)

So, UX design­ers mov­ing into every­ware have their work cut out for them. This is vir­gin territory:

“[…] it is […] a rad­i­cal­ly new sit­u­a­tion that will require the devel­op­ment over time of a doc­trine and a body of stan­dards and con­ven­tions […]” (p.39)

Now, UX in tra­di­tion­al projects has been prone to what Green­field calls ‘val­ue engi­neer­ing’. Com­mer­cial projects can only be two of these three things: fast, good and cheap. UX would sup­port the sec­ond, but sad­ly it is often sac­ri­ficed for the sake of the oth­er two. Not always though, but this is usu­al­ly depen­dent on who is involved with the project:

“[…] it often takes an unusu­al­ly ded­i­cat­ed, per­sis­tent, and pow­er­ful advo­cate […] to see a high-qual­i­ty design project through to com­ple­tion with every­thing that makes it excel­lent intact. […] the painstak­ing­ly detailed work of ensur­ing a good user expe­ri­ence is fre­quent­ly hard to jus­ti­fy on a short-term ROI basis, and this is why it is often one of the first things to get val­ue-engi­neered out of an extend­ed devel­op­ment process. […] we’ve seen that get­ting every­ware right will be orders of mag­ni­tude more com­pli­cat­ed than achiev­ing accept­able qual­i­ty in a Web site, […] This is not the place for val­ue engi­neers,” (p.166)

So if tra­di­tion­al projects need UX advo­cates on board with con­sid­er­able influ­ence, com­pa­ra­ble to Steve Jobs’s role at Apple, to ensure a descent user expe­ri­ence will it even be pos­si­ble to cre­ate ubiq­ui­tous expe­ri­ences that are enjoy­able to use? If these projects are so com­plex, can they be even got­ten ‘right’ in a com­mer­cial con­text? I’m sor­ry to say I think not…

Design­ers (used broad­ly) will be at the fore­front of decid­ing what every­ware looks like. If you don’t think they will, at least I’m sure they should. They’re not the only ones to deter­mine its shape though, Green­field points out that both reg­u­la­tors and mar­kets have impor­tant parts to play too (pp.172–173):

“[…] the inter­lock­ing influ­ences of design­er, reg­u­la­tor, and mar­ket will be most like­ly to result in ben­e­fi­cial out­comes if these par­ties all treat every­ware as a present real­i­ty, and if the deci­sion mak­ers con­cerned act accord­ing­ly.” (p.173)

Now there’s an inter­est­ing notion. Hav­ing just come back from a pre­mier venue for the UX com­mu­ni­ty to talk about this top­ic, the IA Sum­mit, I’m afraid to say that I didn’t get the impres­sion IAs are tak­ing every­ware seri­ous­ly (yet.) There were no talks real­ly con­cerned with tan­gi­ble, per­va­sive, ubiq­ui­tous or ambi­ent tech­nolo­gies. Some basic fare on mobile web stuff, that’s all. Wor­ry­ing, because as Green­field points out:

“[UX design­ers] will best be able to inter­vene effec­tive­ly if they devel­op appro­pri­ate insights, tools, and method­olo­gies ahead of the actu­al deploy­ment of ubiq­ui­tous sys­tems.” (pp.173–174)

This stuff is real, and it is here. Green­field points to the exis­tence of sys­tems such as Octo­pus in Hong Kong and E‑ZPass in the US. Hon­est­ly, if you think beyond the tools and meth­ods we’ve been using to com­mu­ni­cate our designs, IxDs and IAs are well-equipped to han­dle every­ware. No, you won’t be required to draw wire­frames or sitemaps; but you’ll damn well need to put in a lot of the think­ing design­ers do. And you’ll still need to be able to com­mu­ni­cate those designs. It’s time to get our hands dirty:

“What ful­ly oper­a­tional sys­tems such as Octo­pus and E‑ZPass tell us is that pri­va­cy con­cerns, social impli­ca­tions, eth­i­cal ques­tions, and prac­ti­cal details of the user expe­ri­ence are no longer mat­ters for con­jec­ture or sup­po­si­tion. With ubiq­ui­tous sys­tems avail­able for empir­i­cal enquiry, these things we need to focus on today.” (p.217)

So, to reit­er­ate the ques­tion I start­ed with: are there any UX design­ers out there that have made the switch from web-work to ubi­comp? Any­one con­sid­er­ing it? I’d love to hear about your experiences.