Notes on play, exploration, challenge and learning

(My read­ing notes are pil­ing up so here’s an attempt to clear out at least a few of them.)

Part of the play expe­ri­ence of many dig­i­tal games is fig­ur­ing out how the damn thing works in the first place. In Rules of Play on page 210:

[…] as the play­er plays with FLUID, inter­ac­tion and obser­va­tion reveals the under­ly­ing prin­ci­ples of the sys­tem. In this case the hid­den infor­ma­tion grad­u­al­ly revealed through play is the rules of the sim­u­la­tion itself. Part of the play of FLUID is the dis­cov­ery of the game rules as infor­ma­tion.”

(Sad­ly, I could not find a link to the game men­tioned.)

I did not give Don­ald Nor­man all the cred­it he was due in my ear­li­er post. He doesn’t have a blind spot for games. Quite the con­trary. For instance, he explains how to make sys­tems eas­i­er to learn and points to games in the process. On page 183 of The Design of Every­day Things:

One impor­tant method of mak­ing sys­tems eas­i­er to learn and to use is to make them explorable, to encour­age the user to exper­i­ment and learn the pos­si­bil­i­ties through active explo­ration.”

The way to do this is through direct manip­u­la­tion, writes Nor­man. He also reminds us that it’s not nec­es­sary to make any sys­tem explorable.1 But (on page 184):

[…] if the job is crit­i­cal, nov­el, or ill-spec­i­fied, or if you do not yet know exact­ly what is to be done, then you need direct, first-per­son inter­ac­tion.”

So much writ­ten after DOET seems to have added lit­tle to the con­ver­sa­tion. I’m sur­prised how use­ful this clas­sic still is.

I’m remind­ed of a sec­tion of Matt Jones’s Inter­ac­tion 08 talk—which I watched yes­ter­day. He went through a num­ber of infor­ma­tion visu­al­i­sa­tions and said he’d like to add more stuff like that into Dopplr, to allow peo­ple to play with their data. He even com­pared this act of play to Will Wright’s con­cept of pos­si­bil­i­ty space.2 He also briefly men­tioned that eas­i­ly acces­si­ble tools for cre­at­ing infor­ma­tion visu­al­i­sa­tions might become a valu­able tool for design­ers work­ing with com­plex sets of data.

Nor­man actu­al­ly points to games for inspi­ra­tion, by the way. On page 184 just before the pre­vi­ous quote:

Some com­put­er sys­tems offer direct manip­u­la­tion, first-per­son inter­ac­tions, good exam­ples being the dri­ving, fly­ing, and sports games that are com­mon­place in arcades and on home machines. In these games, the feel­ing of direct con­trol over the actions is an essen­tial part of the task.”

And so on.

One of the most use­ful parts of Dan Saffer’s book on inter­ac­tion design is where he explains the dif­fer­ences between cus­tomi­sa­tion, per­son­al­i­sa­tion, adap­ta­tion and hack­ing. He notes that an adap­tive sys­tem can be designed to induce flow—balancing chal­lenge with the skill of the user. In games, there is some­thing called dynam­ic dif­fi­cul­ty adjust­ment (DDA) which has very sim­i­lar aims.

Salen and Zim­mer­man have their doubts about DDA though. In Rules of Play on page 223 they write:

Play­ing a game becomes less like learn­ing an expres­sive lan­guage and more like being the sole audi­ence mem­ber for a par­tic­i­pa­to­ry, impro­vi­sa­tion­al per­for­mance, where the per­form­ers adjust their actions to how you inter­act with them. Are you then play­ing the game, or is it play­ing you?”

Per­haps, but it all depends on what DDA actu­al­ly adjusts. The tech­nique might be objec­tion­able in a game (where a large part of the point is over­com­ing chal­lenge) but in oth­er sys­tems many of these objec­tions do not apply.

With a suc­cess­ful adap­tive design, the prod­uct fits the user’s life and envi­ron­ment as though it were cus­tom made.”

(Design­ing for Inter­ac­tion, page 162.)

Adap­tive sys­tems explic­it­ly antic­i­pate trans­for­ma­tive play. They allow them­selves to be changed through a person’s inter­ac­tions with it.3

A char­ac­ter­is­tic of good inter­ac­tion design is play­ful­ness, writes Mr. Saf­fer in his book on page 67:

Through seri­ous play, we seek out new prod­ucts, ser­vices and fea­tures and then try them to see how they work. How many times have you pushed a but­ton just to see what it did?”

The fun­ny thing is, the con­di­tions for play accord­ing to Saf­fer are very sim­i­lar to some of the basic guide­lines Nor­man offers: Make users feel com­fort­able, reduce the chance for errors and if errors do occur, make sure the con­se­quences are small—by allow­ing users to undo, for instance.

Mr. Nor­man writes that in games “design­ers delib­er­ate­ly flout the laws of under­stand­abil­i­ty and usabil­i­ty” (p.205). Although even in games: “[the] rules [of usabil­i­ty] must be applied intel­li­gent­ly, for ease of use or dif­fi­cul­ty of use” (p.208).

By now, it should be clear mak­ing inter­ac­tions play­ful is very dif­fer­ent from mak­ing them game-like.

  1. Appar­ent­ly, “explorable” isn’t a prop­er Eng­lish word, but if it’s good enough for Mr. Nor­man it’s good enough for me. []
  2. I blogged about pos­si­bil­i­ty space before here. []
  3. Yes, I know I blogged about adap­tive design before. Also about flow and adap­ta­tion, it seems. []

Summary of my Playful IAs argument

I thought I’d post a short sum­ma­ry of the argu­ment I made in my Euro IA Sum­mit 2007 talk, for those who weren’t there and/or are too lazy to actu­al­ly go through the notes in the slides. The pre­sen­ta­tion is basi­cal­ly bro­ken up into three parts:

  1. Future web envi­ron­ments are becom­ing so com­plex, they start to show emer­gent prop­er­ties. In this con­text a lot of tra­di­tion­al IA prac­tice doesn’t make sense any­more. Instead of direct­ly design­ing an infor­ma­tion space, you’re bet­ter off design­ing the rules that under­ly the gen­er­a­tive con­struc­tion of such spaces. In oth­er words, IA is becom­ing a sec­ond order design prob­lem.
  2. IAs tend to argue for the val­ue of their designs based sole­ly on how well they sup­port users in achiev­ing their end goals. I pro­pose sup­port­ing expe­ri­ence goals is just as impor­tant. From there I try to make the case that any pow­er­ful expe­ri­ence is a play­ful one, where the user’s fun fol­lows from the feel­ing that he or she is learn­ing new stuff, is kick­ing ass, is in flow.
  3. Game design is not black mag­ic (any­more). In recent years a lot has become under­stood about how games work. They are built up out of game mechan­ics that each fol­low a pat­tern of action, sim­u­la­tion, feed­back and mod­el­ling. Design­ing play­ful IAs means tak­ing care that you encour­age dis­cov­ery, sup­port explo­ration and pro­vide feed­back on mas­tery.

Get the the slides, and a list of sources for the talk in this ear­li­er post.

Playful IAs — slides for my Euro IA Summit 2007 talk

After a con­sid­er­able amount of fid­dling with SlideShare I’ve final­ly man­aged to upload a ver­sion of the slides that go with my Play­ful IAs pre­sen­ta­tion. This more or less as I pre­sent­ed it at the Euro IA Sum­mit 2007 and includes an approx­i­mate tran­script of my talk. I hope to get an audio/video record­ing of most of it in the near future as well. When I do I’ll update this page.

Update: I’ve post­ed a short sum­ma­ry of the cen­tral argu­ment of my talk.

Down­load a ver­sion includ­ing an approx­i­mate tran­script (14,5 MB).

I had some great reac­tions to this talk and I want to thank all the peo­ple who engaged with me in dis­cus­sions after­wards. It’s giv­en me a good pic­ture of what areas I should devel­op fur­ther in future sub­se­quent talks. I’m also pleas­ant­ly sur­prised to see that con­trary to what some peo­ple think, the IA com­mu­ni­ty (the Euro­pean one at least) is very much open to new ideas. That’s real­ly nice to expe­ri­ence first­hand.

A lot of peo­ple asked for a list of books and oth­er good sources on the top­ics I cov­ered. Here’s an incom­plete list of stuff I’ve used at some stage to inform my think­ing:

If that doesn’t keep you busy for a while, you could always have a dig through my del.icio.us links. There’s plen­ty of good stuff there. Of course of if you ever find any­thing you think would be of inter­est to me, do let me know. Just tag it for:kaeru.

Design challenges for short-session gaming

Screenshot of a particularly funny Elite Beat Agents sequence

I’ve just fin­ished read­ing an excel­lent series of post by two video game jour­nal­ists on the appar­ent revival of short-ses­sion games. (What’s not to love about an arti­cle that fin­ishes by assert­ing that Desk­top Tow­er Defense beats BioShock at its own mechan­ic?) It’ll be in tomorrow’s link post but here’s the link any­way. Being involved with a casu­al gam­ing project myself late­ly, I’ve spent a some time think­ing about what the design chal­lenges for this sub-genre are. In oth­er words: what make short-ses­sion games hard to pull off? I think it breaks down to these things:

  1. You need to get the play­er in flow as soon as pos­si­ble. This means you can’t both­er him with lengthy intros (or even menus). It also means the game’s mechan­ics should be as self-explana­to­ry as pos­si­ble. I’m remind­ed of the first time I start­ed up Elite Beat Agents the oth­er day and was giv­en a super-short tuto­r­i­al on how to play the game, then was dumped into the action right away (this is good).
  2. No sto­ries please. Short-ses­sion gam­ing forces you to design for play, not for nar­ra­tive (as it should be, in my opin­ion). It’s about giv­ing the play­er an engag­ing activ­i­ty and inter­est­ing choic­es, noth­ing more.
  3. Tra­di­tion­al dis­tri­b­u­tion mod­els make no sense for small games. Luck­i­ly, we now have net­work con­nec­tiv­i­ty on vir­tu­al­ly all gam­ing devices (not to men­tion PCs and mobile phones). The wait is for an open plat­form for game devel­op­ers to exper­i­ment on while at the same time being able to make a buck. But even now, net­worked mar­ket­places on con­soles have encour­aged exper­i­men­ta­tion.
  4. The visu­al lay­er does not have to be retro. Although most short-ses­sion game expe­ri­ences remind us of the good old games from the begin­ning days of elec­tron­ic gam­ing, there’s no rea­son why these games should look retro.
  5. Throw some of that pro­cess­ing at the rules, not the visu­als. Short-ses­sion, small and sim­ple don’t nec­es­sar­i­ly mean crude. Don’t go all-out on my 4th point’s visu­als with­out for­get­ting about all the cool com­plex behav­iours you can cre­ate with today’s proces­sors.

There’s much more to think and talk about, but I think these are the high­lights. Par­tic­u­lar­ly get­ting peo­ple into flow ASAP and cou­pling this with inter­est­ing dis­tri­b­u­tion mech­a­nisms is I think worth some more dis­cus­sion.

Reboot 9.0 day 2

(Wait­ing for my train home to arrive, I final­ly have the oppor­tu­ni­ty to post this.)

So with Reboot 9.0 and the after-par­ty done, I think I’ll briefly write up my impres­sions of the sec­ond day.

Stowe Boyd — Good talk as always, offer­ing a new def­i­n­i­tion of ‘flow’. I guess his attempt to have peo­ple open them­selves up to the ben­e­fi­cial sides of being inter­mit­tent­ly con­nect­ed was a suc­cess.

Marko Ahti­saari — Inter­est­ing char­ac­ter with a good sto­ry to tell. His free mobile oper­a­tor for teenagers scheme made a lot of peo­ple curi­ous. (Free stuff always does that, it seems.)

Lee Bryant — Very fit­ting to the theme of human?, a touch­ing sto­ry of how for­mer inhab­i­tants of a Bosn­ian town used social soft­ware to recon­nect and rebuild the town.

Julian Bleeck­er — Cool stuff on new ways to inter­act with com­put­ing tech­nol­o­gy beyond the util­i­tar­i­an and effi­cient, into the realm of play.

Dave Win­er — An inter­est­ing char­ac­ter hav­ing a nice con­ver­sa­tion with Thomas. I enjoyed his off­beat remarks and dry wit.

Guy Dick­in­son — Anoth­er round of micro­p­re­sen­ta­tions, this time with me par­tic­i­pat­ing. I stum­bled sev­er­al times. Next time I’ll pre­pare a cus­tom talk for this. The oth­er pre­sen­ters were awe­some.

Ras­mus Fleis­ch­er and Mag­nus Eriks­son — Two cool young anar­chists with inter­est­ing ideas about file shar­ing and the future of music. Too bad large parts of their pre­sen­ta­tion were read from a sheet.

Leisa Reichelt — A care­ful­ly put togeth­er overview of ambi­ent inti­ma­cy, what it is and what it’s for. Next step: com­ing up with design guide­lines for these types of ‘tools’.

Matt Webb — Deliv­ered on the expec­ta­tions raised by his per­for­mances pre­vi­ous years. Inter­est­ing to see him move into expe­ri­ence design ter­ri­to­ry and hear his take on it. Very much applic­a­ble to my dai­ly work in design­ing web ser­vices.

Din­ner and the after-par­ty were great (although it seemed that the reser­va­tions scheme had gone awry, they had no place for us at our cho­sen restau­rant). I guess drink­ing and talk­ing into the night at Vega with a lot of con­fused locals around was a fit­ting way to end anoth­er great Reboot.

Harmonious interfaces, martial arts and flow states

Screenshot of the game flOw

There’s been a few posts from the UX com­mu­ni­ty in the recent past on flow states (most notably at 37signals’s Sig­nal vs. Noise). This got me think­ing about my own expe­ri­ences of flow and what this tells me about how flow states could be induced with inter­faces.

A com­mon exam­ple of flow states is when play­ing a game (the play­er for­gets she is push­ing but­tons on a game pad and is only mind­ful of the action at hand). I’ve expe­ri­enced flow while paint­ing but also when doing work on a PC (even when cre­at­ing wire­frames in Visio!) How­ev­er, the most inter­est­ing flow expe­ri­ences were while prac­tis­ing mar­tial arts.

The inter­est­ing bit is that the flow hap­pens when per­form­ing tech­niques in part­ner exer­cis­es or even fight­ing match­es. These are all sit­u­a­tions where the ‘sys­tem’ con­sists of two peo­ple, not one per­son and a medi­um medi­at­ed by an inter­face (if you’re will­ing to call a paint brush an inter­face that is).

To reach a state of flow in mar­tial arts you need to stop think­ing about per­form­ing the tech­nique while per­form­ing it, but in stead be mind­ful of the effect on your part­ner and try to visu­al­ize your own move­ments accord­ing­ly. When flow hap­pens, I’m actu­al­ly able to ‘see’ a tech­nique as one sin­gle image before start­ing it and while per­form­ing it I’m only aware of the whole sys­tem, not just myself.

Now here’s the beef. When you try to trans­late this to inter­face design, it’s clear that there’s no easy way to induce flow. The obvi­ous approach, to cre­ate a ‘dis­ap­pear­ing’ inter­face that is unob­tru­sive, min­i­mal, etc. is not enough (it could even be harm­ful). In stead I’d like to sug­gest you need to make your game, soft­ware or site behave more like a mar­tial arts fight­er. It needs to push or give way accord­ing to the actions of it’s part­ner. You real­ly need to approach the whole thing as an inter­con­nect­ed sys­tem where forces flow back and forth. Flow will hap­pen in the user when he or she can work in a har­mo­nious way. Usu­al­ly this requires a huge amount of men­tal mod­el adap­ta­tion on the user’s part… When will we cre­ate appli­ances that can infer the inten­tions of the user and change their stance accord­ing­ly? I’m not talk­ing about AI here, but what I would like to see is stuff more along the lines of flOw.