Tuesday, 11 December 2012

The instructions for playing Pong

Pong - the first massively successful video game - has just turned 40 years old. The original Pong machines were placed in bars and pubs, like pinball machines or fruit machines, but they attracted whole new groups of users who were not already players of slot machine games. Which raises the question: given that the technology and the type of game were wholly new to most of those who played it and loved it, how did they learn to play Pong?

From the kind of guidance we produce for students learning to use our online learning systems, you might think that there would have had to be some pretty long and detailed instructions. A lot of things would have been unfamiliar and would have needed to be explained: the rules of the game, how to use the control knobs to move your bat up and down the screen, what happens when the ball hits your bat, what happens when the ball goes out of play, how score is kept, and so on.

You might think that, but you'd be wrong.  The instructions for playing Pong, printed on the machine cabinets, read as follows:
Avoid missing ball for high score.
That's it; there was nothing else. Or rather there was a whole lot else: the physical features of the machine and the experience of experimenting with the game. The coin slot was a familiar affordance for the insertion of a coin, which started the game. The knobs were obvious controls, and nudging them visibly moved the paddles on the screen. The contact between the ball and a paddle was marked as a significant event by the distinctive "pong" sound, and one or the other of the numbers at the top of the screen could be seen to increase whenever the ball went off a left or right edge, which was also accompanied by a negative sound. The one thing which the games designers judged needed explaining was the object of the game: to get a high score by avoiding missing (not, interestingly, "hitting") the ball. The single instruction also, as a bonus, identified the dot on the screen as a representation of a ball, which together with the game's name printed on the machine casing ("pong" does not carry its unfortunate British meaning in the USA, and to its first American users would have suggested only "ping pong"), provided further clues to interpretation from the real-world.

I'm not suggesting that instructions for students using online learning systems should be as brief as the original instructions for Pong, but I do challenge our tendency to strive for thoroughness and explicitness. Consider the advantages of brevity: first, students are more likely to read it; and second, by actually requiring students to fill in the gaps for themselves, they have to think about what they're reading and activate their previous knowledge in order to interpret it - in other words, the learning is deeper and more likely to be retained. Of course, not every single student will be able to manage with brief instructions - there may be some key piece of background knowledge which they lack, or  some distraction may lead them to a wrong interpretation; but most will, and will benefit from the brevity, and for those who need it we can also provide longer, more detailed guidance which holds their hand while walking them through stage by stage. (And those who need to refer to the detailed guidance will probably not need all of it.)

I adopted this approach a couple of years ago, when revising the guidance for new users of the Elluminate Live! audiographic conferencing system. The full Walkthrough ran for 15 pages, and included screenshots to show what should be happening at every stage of installation and setup, but I also produced a 2 page Short Guide, without screenshots, for those users who were used to installing new software and adjusting settings, and needed only a few essential details. Earlier this year, I was pleased to see the new edition of the Open University Computing Guide adopting the same strategy: prefacing its information on each feature of the Virtual Learning Environment with a Quickstart  page for those who neither want nor need the full detail.

Not always, but most of the time, less is more.


Katie Salen and Eric Zimmerman, Rules of Play: Game Design Fundamentals (MIT Press, 2004), p. xiii

No comments:

Post a Comment