Spectra of learnability

They gave us Donald Norman’s The Design of Everyday Things1 to read in interaction design school. I remember reading it and—being young an cocky—finding it all very common sense and “Why do they ask us to read this stuff?” And so on.2

I am rereading it now, in the hopes of sharpening my argument for playful user experiences.

(There are a lot of things I want to blog about actually, such as how Hill and Webb‘s adaptive design reminds me of Salen & Zimmerman‘s transformative play, why Cook rejects MDA while Saffer embraces it and more.)

Anyway, my new copy of DOET has a nice introduction by Norman in which he summarizes a few core concepts form the book. On page xi—writing on conceptual models—he writes:

“[G]ood design is … an act of communication between the designer and the user, … all the communication has to come about by the appearance of the device itself.”

In other words, if you can’t figure “it” out by just looking at it, it’s not well designed. Where “figure it out” basically means understand how to operate “it” successfully. Of course this is an important concept, but I think something’s missing.

In games, it’s not enough just to be able to figure out how to make Mario jump—for instance—you want to learn how to jump well.

It’s about skill and mastery in other words. A “Norman Door” (a door that is difficult to open) can be fixed so that people can open the door easily. But a door has a narrow spectrum of learnability. Or as Koster would probably say: The pattern to “grok” is really simple.

Figure 1: A door’s spectrum of learnability

And anyway, why would you want to become a master at opening doors, right?

But a lot of the things I’m working on (for instance creative tools, but also toy-like environments) have more complex patterns and therefore (wether I like it or not) have a wider spectrum of learnability. And that’s where usability alone is not enough. That’s where in testing, I’d need to make sure people don’t just understand how to do stuff by looking at it. (That’s the start, for sure.) But I also want to be able to tell if people can get better at doing stuff. Because if they get better at it, that’s when they’ll be having fun.

Figure 2: A toy’s spectrum of learnability
  1. Or The Psychology of Everyday Things as it was then titled. []
  2. I still consider myself young, only slightly less cocky. []

Slides for my Oslo UXnet meetup talk

Last night I presented at the January UXnet meetup in Oslo. When Are invited me to come over I thought I’d be talking to maybe 60 user experience people. 200 showed up—talk about kicking off the year with a bang. I think the crew at Netlife Research may just have written UXnet history. I’m not sure. (Don’t believe me? Check out the RSVPs on the event’s page at Meetup.com)

The talk went OK. I had 20 minutes, which is pretty short. I finished on time, but I had to leave out a lot of examples. The original talk on which this was based is a 2 hour lecture I deliver at UX companies. (I did this last year for instance at InUse.)

The lack of examples was the biggest point of criticism I got afterwards. I’ll try to make up for that a bit in a later post, listing some examples of web sites and apps that I would call in some way playful. Stay tuned.

For now, here are the slides (no notes I’m afraid, so it’ll be hard to make any sense of them if you weren’t there). Thanks to Are Halland for inviting me. And greetings to all my friends in Oslo. You’ve got a beautiful UX thing going on there.

Playyoo goes beta

Today Playyoo went beta. Playyoo is a mobile games community I have been involved with as a freelance interaction designer since july of this year. I don’t have time for an elaborate post-mortem, but here are some preliminary notes on what Playyoo is and what part I’ve played in its conception.

Playyoo's here

Playyoo brings some cool innovations to the mobile games space. It allows you to snack on free casual mobile games while on the go, using a personalized mobile web page. It stores your high scores and allows you to interact with your friends (and foes) on an accompanying regular web site. Playyoo is a platform for indie mobile game developers. Anyone can publish their Flash Lite game on it. Best of all — even if you’re not a mobile games developer, you can create a game of your own.

It’s that last bit I’ve worked on the most. I took care of the interaction design for an application imaginatively called the Game Creator. It allows you to take well known games (such as Lunar Lander) and give them your own personal twist. Obviously this includes the game’s graphics, but we’ve gone one step further. You can change the way the game works as well.

Screenshot of my lolcats pairs game on Playyoo

So in the example of Lunar Lander you can make the spaceship look like whatever you want. But you can also change the gravity, controlling the speed with which your ship drops to the surface. Best of all, you can create your own planet surface, as easy as drawing a line on paper. This is why Lunar Lander in the Playyoo Game Creator is called Line Lander. (See? Another imaginative title!)

At the moment there are six games in the Game Creator: Tic-Tac-Toe, Pairs, Revenge, Snake, Ping-Pong, and the aforementioned Line Lander. There’s long list of other games I’d like to put in there. I’m sure there will be more to come.

Since today’s launch, people have already started creating crazy stuff with it. There’s a maze-like snake game, for instance. And a game where you need to land a spider crab on the head of some person called Rebecca… I decided to chip in with a pairs game full of lolcats (an idea I’ve had since doing the very first wireframe.) Anyway, the mind boggles to think of what people might come up with next! That’s the cool part about creating a tool for creative expression.

Screenshot of a Line Lander game in progress in the Playyoo Game Creator

So although making a game is very different from playing one, I hope I managed to make it fun nonetheless. My ambition was to create a toy-like application that makes ‘creating’ a game a fun and engaging way to kill a few minutes — much like Mii creation on the Nintendo Wii, or playing with Spore‘s editors (although we still haven’t had the chance to actually play with latter, yet.) And who knows, perhaps it’ll inspire a few people to start developing games of their own. That would probably be the ultimate compliment.

In any case, I’d love to hear your comments, both positive and negative. And if you have a Flash Lite compatible phone, be sure to sign up with Playyoo. There is no other place offering you an endless stream of snack sized casual games on your phone. Once you’ve had a taste of that, I’m sure you’ll wonder how you ever got by without it.

Game player needs and designing architectures of participation

How do you create a corporate environment in which people share knowledge out of free will?1 This is a question my good friends of Wemind2 are working to answer for their clients on a daily basis.3 We’ve recently decided to collaboratively develop methods useful for the design of a participatory context in the workplace. Our idea is that since knowledge sharing is essentially about people interacting in a context, we’ll apply interaction design methods to the problem. Of course, some methods will be more suited to the problem than others, and all will need to be made specific for them to really work. That’s the challenge.

Naturally I will be looking for inspiration in game design theory. This gives me a good reason to blog about the PENS model. I read about this in an excellent Gamasutra article titled Rethinking Carrots: A New Method For Measuring What Players Find Most Rewarding and Motivating About Your Game. The creators of this model4 wanted to better understand what fundamentally motivates game players as well as come up with a practical play testing model. What they’ve come up with is intriguing: They’ve demonstrated that to offer a fun experience, a game has to satisfy certain basic human psychological needs: competence, autonomy and relatedness.5

I urge anyone interested in what makes games work their magic to read this article. It’s really enlightening. The cool thing about this model is that it provides a deeper vocabulary for talking about games.6 In the article’s conclusion the authors note the same, and point out that by using this vocabulary we can move beyond creating games that are ‘mere’ entertainment. They mention serious games as an obvious area of application, I can think of many more (3C products for instance). But I plan on applying this understanding of game player needs to the design of architectures of participation. Wish me luck.

  1. Traditionally, sharing knowledge in large organisations is explicitly rewarded in some way. Arguably true knowledge can only be shared voluntarily. []
  2. Who have been so kind to offer me some free office space, Wi-Fi and coffee since my arrival in Copenhagen. []
  3. They are particularly focused on the value of social software in this equation. []
  4. Scott Rigby and Richard Ryan of Immersyve []
  5. To nuance this, the amount to which a player expects each need to be satisfied varies from game genre to genre. []
  6. Similar to the work of Koster and of Salen & Zimmerman. []

I was interviewed for the Playyoo blog

I was interviewed by Playyoo the other day

Most of you will probably know I’m involved1 with this new mobile game community called Playyoo. I haven’t blogged about it here explicitly because most of my contributions so far are still being developed and will hopefully hit the internet around December. I have an excuse to talk about it now though, because recently I was interviewed by the people of Playyoo for their blog. Read about my thoughts on the role of sociality in (mobile) gaming and how that will work in Playyoo’s meta-game, as well as what I think about casual games and the unique game design opportunities for mobile.

A quote from the interview:

What does the term ‘casual game’ mean to you?

‘Casual,’ to me, says something about the level of attention and engagement that a player has (or is required to have) with the game. For me as a designer, casual games provide interesting challenges. It might seem simple to create these casual games, but they’re actually quite tricky to pull off, or pull off well, that is. From a game design perspective, I think it’s more challenging to pull off a high quality causal game than yet another first-person shooter game.

Read the rest of the interview over at the Playyoo blog.2

  1. They’ve hired me to do game and interaction design. I have been working on mobile games, a game creation tool, and a web-based meta-game. []
  2. Thanks to Alper Çuǧun for the photo that’s in the post. []

Pollinator — a casual game prototype made with Mobile Processing

I wrote a game about a bee and flowers today

Last sunday I sat down and coded a prototype of a casual game in Mobile Processing. I got the idea for it the evening before: You’re a bee who needs to collect as much honey as possible in his hive while at the same time keeping a flower-bed blooming by pollinating… Play it and let me know what your high score is in the comments!

Thinking and making

I’ve been looking for an excuse to get some experience with Processing (particularly the variant suitable for developing mobile stuff) for a while. I also felt I needed to get back into the making part of the field I’ve been thinking about so much lately: Game Design. I agree with Saffer, Webb and others – making is an important part of the design practice, it cannot be replaced by lots of thinking. The things learnt from engaging with the actual stuff things are made of (which in the case of digital games is code) aren’t gained in any other way and very valuable.

Get the game

I’ve uploaded the first version of the game here. You can play it in the emulator in your browser or if your phone runs Java midlets, download the file and play it like you’re supposed to: While out and about. The source code is provided as well, if you feel like looking at it.1

Pollinator 0.1

How to play

You’re the yellow oval. The orange triangle in the top left corner is your hive. Green squares are grass, brown squares are seeds, red squares are flowers and pink squares are pollinated flowers. The field is updated in columns from left to right (indicated by the yellow marker in the bottom). A seed will turn into a flower (in rare cases a pollinated flower). A flower will die, a pollinated flower will die and spread seeds to grass around it. Move your bee with the directional keys, use the centre key to grab nectar from a flower. You can cary a maximum of 100 nectar. Drop your nectar off at the hive (again using the centre key) to up your score. When you first grab nectar from a pollinated flower and subsequently from a normal flower, the latter is pollinated. Try to keep the flower-bed in bloom while at the same time racking up a high-score!

You’ll get 10 nectar from a flower (in bloom or not). Pollinating a flower costs 5 nectar. If you try to take nectar more than once from the same flower, you’ll loose 10 nectar.2

Improvements

Stuff not in here that I might put into a next version (whenever I get around to it):

  • Animation — I need to get my feet wet with some scripted animation. Thing is I’ve always sucked at this. For now it’s all tile-based stuff.
  • Better feedback — For instance show the points you earn near the bee and the hive. I think that’ll make the game a lot easier to understand and therefore more fun.
  • Menus, pause, game over — It’s a prototype, so you get dumped into the action right away. (The game starts on the first key you press.) And there’s no actual game over message, the field just turns green and you’re left to wonder what to do.
  • Balance — I’m not sure if the game like it stands is balanced right, I will need to play it a lot to figure that out. Also there’s probably a dominant strategy that’ll let you rack up points easily.

The aim was to create a relatively casual game experience that will almost allow you to zone out while playing. I think it is far too twitchy now, so perhaps I really should sit down and do a second version sometime soon.

Mobile Processing

I enjoy working with Mobile Processing. I like the way it allows you to program in a very naive way but if you like structure things in a more sophisticated fashion. It really does allow you to sketch in code, which is exactly what I need. The emphasis on just code also prevents me from fiddling around with animations, graphics and so on (like I would in Flash for instance.) Perhaps the only thing that would be nice is an editor that is a bit more full-featured.3 Perhaps I should grab an external editor next time?

Feedback

If you played the game and liked it (or thought it was too hard, boring or whatever) I’d love to get your feedback in the comments. Anyone else out there prototyping games in Processing? Or using it to teach game design? I’d be very interested to hear about it.

  1. Not that it’s particularly good, I’m an amateur coder at best. []
  2. I’m not sure this is the right kind of negative reinforcement. []
  3. The automatic code formatting refused to work for me, requiring me to spend a bit too much effort on formatting by hand. []

Helping users retell experiences

A frame from a Second Life machinima

I talked about the difference between emergent and embedded narrative in games a while ago. I also introduced my Interaction 08 talk in a previous post. I’d like to now follow up with some thoughts on the storytelling that happens outside of a user’s direct interaction with a product or service – the storytelling she engages in when recounting the experience of use to other people.

Obviously, supporting the retelling of experiences is important. After all if you’re offering a cool product or service, you want others to know about it. A passionate user is probably your best advocate. It only makes sense for you to create easy ways for her to share her experiences with others. It can also deepen a user’s own experience – making the product or service part of a story wherein she is kicking ass can create a positive feedback loop.

Games have picked up on this, of course. They’ve employed numerous ways for users to retell their play-sessions. In Rules of Play, Salen and Zimmerman list a number of them:

  1. The replay – found in racing games for instance – literally replays the actions of the player after she completes a track, stage or level. Sometimes this is done in ways that wouldn’t be practical in the game itself1 in all cases it is done in a way that fits the feel of the game, the experience the game aims for.
  2. Other games take this one step further and allow players to control the view of the replay themselves. They’ll also allow users to redistribute the recording of their actions. Doom did this, it was called the recam.
  3. A logical progression is found in the machinima phenomenon, where the play of a game takes a back-seat to the retelling of play, effectively making the game a tool for personal creative expression. A famous example are the many soap opera episodes produced by players of The Sims.
  4. Finally, with the advent of more embodied interactions in gaming there’s an upsurge of online videos of game-play. Having an embodied interface makes it much easier for bystanders to ‘read’ what’s going on, effectively opening the way for play to become like performance2.

How does this translate to the design of user experiences in digital and physical products? I think there are a few things that are important in the retelling of experiences:

  • The protagonist is the user, not your product. Your product or service is the enabler for the user to look cool in a story.
  • The way in which you enable retelling should be well-integrated with the experience you’re aiming for. The recam made sense for Doom because it allowed players to boast about their achievements.
  • You don’t have to create all the storytelling tools yourself. You should try to play nice with the stuff that’s already out there, such as pod-casting services, video-blogging tools, sketch-casting, photo-sharing etc.

Have good examples of products and services that help their users tell stories about their experiences? Let me know in the comments!

  1. For instance using different camera angles, lenses or filters for a more dramatic look. []
  2. My favorite example being this video of a couple of guys playing Guitar Hero. []

Work with me in Copenhagen (or where-ever)

Panorama of Copenhagen harbour

Now that I’m over three months into my stay in Copenhagen I thought it would be good to post a short update. Here are the facts, bullet-wise (with apologies to Mr. Tufte):

  • I have been in Copenhagen, Denmark since July 1st 2007
  • Until now I have mostly been working on Playyoo, doing interaction and game design
  • I also presented on Playful IAs at the Euro IA Summit in Barcelona
  • No later than July 1st 2008, I will return to Utrecht, the Netherlands
  • Yes, I intend to continue freelancing when I get back (I officially left Info.nl on October 1st 2007)
  • I am available for freelance interaction design gigs that involve social media, mobile technology and/or gaming
  • You can also invite me to speak at your event or company, particularly on the topic of applying game design principles to the user experience of products and services

Oh and of course, if you happen to be in Copenhagen, don’t hesitate to drop me a line when you feel like going out for some drinks!

Snacking on casual games

Snacks

Following up on an earlier post about short-session games here are some comments on a recent Gamasutra article by Ian Bogost (it’ll be in the link post for tomorrow). It’s titled ‘Casual As In Sex, Not Casual As In Friday‘ and in it Bogost argues there is quite a bit of unexplored space in the casual games domain.

In the article, Bogost points out that casual games are usually seen as easy to learn but hard to master, like Go. They are commonly cheap (or at least cheaper than typical console and PC titles) and easy to get. Finally, control of the game is often simple and limited to few inputs. (Bogost recommends only using the mouse on the PC, I wonder what he’d recommend on a mobile…one button?)

Bogost points out that a typical casual game-play session might be short, but that the overall model of casual gaming (both the distribution and the game mechanics) actually encourage repeated play over a long period of time whereby a player achieves an increasingly higher level of mastery of the game (which arguably is the antithesis of casualness.)

What we rarely see are games that are explicitly created to be played once and never revisited. Bogost mentions September 12th and Zidane Head-Butt as prototypes for these types of casual games.

This is all very interesting to me because in a current project I have been discussing this notion of snack-sized games quite a lot. I am convinced there is a market for games that are consumed once and are then discarded, but there are some challenges to overcome. Bogost mentions these as well: They need to be ridiculously simple to access, as cheap as possible (ideally free) and instantly learnable.

One point Bogost doesn’t raise is: Who will feel compelled to create these games? Because game creation always involves some effort, typical game developers might not see much profit in releasing their games into the wild for free. What’s in it for them? I think the key there is the democratization of game creation. Giving ordinary users fun tools to create these short-session, snack-sized, casual-as-in-sex games as a form of personal expression.

Play, story and recombination

A bunch of Lego bricks

“Dominant models in IA: space + story” was one of the notes I took while at this year’s Euro IA Summit. I’ll get into space some other time. Concerning story: Basically it strikes me that for a discipline involved with an interactive medium, so often designing is likened to storytelling. I’m not sure this is always the most productive way to approach design, I actually think it is very limiting. If you approach design not as embedding your story in the environment, but as creating an environment wherein users can create their own stories, then I’d say you’re on the right track. An example I tend to use is a game of poker: The design of the game poker was certainly not an act of storytelling, but a play session of poker is experienced as (and can be retold as) a story. Furthermore, the components of the game can be recombined to create different variations of the basic game, each creating different potentials for stories to arise. I’d like to see more designers approach interactive media (digital, physical or whatever) like this: Don’t tell a story to your user, enable them to create their own.1 Realize users will want to recombine your stuff with other stuff you might not know about (the notion of seamful design comes into play here). When you’ve done a proper job, you’ll find them retelling those stories to others, which I would say is the biggest compliment you can get.

1. Or to put this in Marc LeBlanc‘s terms: Don’t embed narrative, let it emerge through play.