Tag: Dan Saffer

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

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

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

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 information.”

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

I did not give Don­ald Nor­man all the cred­it he was due in my ear­li­er post. He does­n’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 exploration.”

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 interaction.”

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 Saf­fer­’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 per­son­’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. [↩]