Hardware interfaces for tuning the feel of microinteractions

In Digital Ground Malcolm McCullough talks about how tuning is a central part of interaction design practice. How part of the challenge of any project is to get to a point where you can start tweaking the variables that determine the behaviour of your interface for the best feel.

“Feel” is a word I borrow from game design. There is a book on it by Steve Swink. It is a funny term. We are trying to simulate sensations that are derived from the physical realm. We are trying to make things that are purely visual behave in such a way that they evoke these sensations. There are many games that heavily depend on getting feel right. Basically all games that are built on a physics simulation of some kind require good feel for a good player experience to emerge.

Physics simulations have been finding their way into non-game software products for some time now and they are becoming an increasing part of what makes a product, er, feel great. They are often at the foundation of signature moments that set a product apart from the pack. These signature moments are also known as microinteractions. To get them just right, being able to tune well is very important.

The behaviour of microinteractions based on physics simulations is determined by variables. For example, the feel of a spring is determined by the mass of the weight attached to the spring, the spring’s stiffness and the friction that resists the motion of the weight. These variables interact in ways that are hard to model in your head so you need to make repeated changes to each variable and try the simulation to get it just right. This is time-consuming, cumbersome and resists the easy exploration of alternatives essential to a good design process.

In The Setup game designer Bennett Foddy talks about a way to improve on this workflow. Many of his games (if not all of them) are playable physics simulations with punishingly hard controls. He suggests using a hardware interface (a MIDI controller) to tune the variables that determine the feel of his game while it runs. In this way the loop between changing a variable and seeing its effect in game is dramatically shortened and many different combinations of values can be explored easily. Once a satisfactory set of values for the variables has been found they can be written back to the software for future use.

I do believe such a setup is still non-trivial to make work with todays tools. A quick check verifies that Framer does not have OSC support, for example. There is an opportunity here for prototyping environments such as Framer and others to support it. The approach is not limited to motion-based microinteractions but can be extended to the tuning of variables that control other aspects of an app’s behaviour.

For example, when we were making Standing, we would have benefited hugely from hardware controls to tweak the sensitivity of its motion-sensing functions as we were using the app. We were forced to do it by repeatedly changing numbers in the code and building the app again and again. It was quite a pain to get right. To this day I have the feeling we could have made it better if only we would have had the tools to do it.

Judging from snafus such as the poor feel of the latest Twitter desktop client, there is a real need for better tools for tuning microinteractions. Just like pen tablets have become indispensable for those designing the form of user interfaces on screens. I think we might soon find a small set of hardware knobs on the desks of those designers working on the behaviour of user interfaces.

Notes on play, exploration, challenge and learning

(My reading notes are piling up so here’s an attempt to clear out at least a few of them.)

Part of the play experience of many digital games is figuring out how the damn thing works in the first place. In Rules of Play on page 210:

“[…] as the player plays with FLUID, interaction and observation reveals the underlying principles of the system. In this case the hidden information gradually revealed through play is the rules of the simulation itself. Part of the play of FLUID is the discovery of the game rules as information.”

(Sadly, I could not find a link to the game mentioned.)

I did not give Donald Norman all the credit he was due in my earlier post. He doesn’t have a blind spot for games. Quite the contrary. For instance, he explains how to make systems easier to learn and points to games in the process. On page 183 of The Design of Everyday Things:

“One important method of making systems easier to learn and to use is to make them explorable, to encourage the user to experiment and learn the possibilities through active exploration.”

The way to do this is through direct manipulation, writes Norman. He also reminds us that it’s not necessary to make any system explorable.1 But (on page 184):

“[…] if the job is critical, novel, or ill-specified, or if you do not yet know exactly what is to be done, then you need direct, first-person interaction.”

So much written after DOET seems to have added little to the conversation. I’m surprised how useful this classic still is.

I’m reminded of a section of Matt Jones’s Interaction 08 talk—which I watched yesterday. He went through a number of information visualisations and said he’d like to add more stuff like that into Dopplr, to allow people to play with their data. He even compared this act of play to Will Wright’s concept of possibility space.2 He also briefly mentioned that easily accessible tools for creating information visualisations might become a valuable tool for designers working with complex sets of data.

Norman actually points to games for inspiration, by the way. On page 184 just before the previous quote:

“Some computer systems offer direct manipulation, first-person interactions, good examples being the driving, flying, and sports games that are commonplace in arcades and on home machines. In these games, the feeling of direct control over the actions is an essential part of the task.”

And so on.

One of the most useful parts of Dan Saffer’s book on interaction design is where he explains the differences between customisation, personalisation, adaptation and hacking. He notes that an adaptive system can be designed to induce flow—balancing challenge with the skill of the user. In games, there is something called dynamic difficulty adjustment (DDA) which has very similar aims.

Salen and Zimmerman have their doubts about DDA though. In Rules of Play on page 223 they write:

“Playing a game becomes less like learning an expressive language and more like being the sole audience member for a participatory, improvisational performance, where the performers adjust their actions to how you interact with them. Are you then playing the game, or is it playing you?”

Perhaps, but it all depends on what DDA actually adjusts. The technique might be objectionable in a game (where a large part of the point is overcoming challenge) but in other systems many of these objections do not apply.

“With a successful adaptive design, the product fits the user’s life and environment as though it were custom made.”

(Designing for Interaction, page 162.)

Adaptive systems explicitly anticipate transformative play. They allow themselves to be changed through a person’s interactions with it.3

A characteristic of good interaction design is playfulness, writes Mr. Saffer in his book on page 67:

“Through serious play, we seek out new products, services and features and then try them to see how they work. How many times have you pushed a button just to see what it did?”

The funny thing is, the conditions for play according to Saffer are very similar to some of the basic guidelines Norman offers: Make users feel comfortable, reduce the chance for errors and if errors do occur, make sure the consequences are small—by allowing users to undo, for instance.

Mr. Norman writes that in games “designers deliberately flout the laws of understandability and usability” (p.205). Although even in games: “[the] rules [of usability] must be applied intelligently, for ease of use or difficulty of use” (p.208).

By now, it should be clear making interactions playful is very different from making them game-like.

  1. Apparently, “explorable” isn’t a proper English word, but if it’s good enough for Mr. Norman it’s good enough for me. []
  2. I blogged about possibility space before here. []
  3. Yes, I know I blogged about adaptive design before. Also about flow and adaptation, it seems. []