Web site logical path: [www.psy.gla.ac.uk] [~steve] [fun] [this page]
Fun cannot be part of the requirements for all software, despite occasional libertarian claims to the contrary, at least if design is to follow users' needs and wants. If software use were always fun, it could never be a transparent means to an end: it would always be obtruding on the user's attention. This is not always what is wanted. Personal digital assistants, pocket calculators, flight deck safety systems, and so on, like the processor in your microwave oven, should surely be designed to fade into the background. Fun requires conscious attention, and we often do not want to give that when we are trying to achieve something else, any more than we want a difficult user interface to intrude on and distract from a work task.
However there are three different major cases where fun is, or could usefully be, important in user software: where enjoyment is taken to be the main function of the software, where learning is the main function, and where learnability is considered as an important secondary requirement of software with some other main function. This paper offers a conceptual analysis of fun in terms of other concepts such as intrinsic and extrinsic motivation, "flow", and others; and relates the analysis to these three major cases where fun may sensibly be taken as a requirement in designing software.
We will assume here that computer games are played for amusement or fun (ignoring the possibility that they might be played professionally, and that that might require a different design) — in other words, for intrinsic motivation. We may distinguish extrinsic from intrinsic motivation, where the former refers to external reasons for action (e.g. working for pay, doing chores for a relative), while the latter refers to a person's inherent enjoyment in the activity for its own sake (e.g. eating, going to a movie). It is important to realise that these are not mutually exclusive alternatives, and some actions may be motivated in both ways. When people say they did something for fun, they are drawing attention to the existence of intrinsic motivation for the action, but that doesn't itself mean there cannot have been extrinsic motivation too. Conversely, when they say they had to go to Hawaii for work, it doesn't prove they didn't enjoy it. This distinction is similar to that of work (extrinsic) vs. leisure (intrinsic) (Rieber et al., 1998) except that leisure tends to get defined as whatever no-one else pays you for which includes things like going to the dentist, while on the other hand many people enjoy at least parts of their job, so leisure vs. work does not reliably correspond to enjoyment vs. unpleasant activity. Intrinsic and extrinsic motivation, while contrasted, are separate attributes that can be present or absent together. We assume that computer games are designed to satisfy intrinsic motivation, and that this is the primary requirement.
Many different kinds of intrinsic motivation are possible (Malone, 1980; Malone & Lepper, 1987; Neal, 1990) including for example "idle" curiosity (who will win the match on TV? what graphics will appear on the next level of this computer game?) and arbitrary learning goals (will I get a higher score than last time? can I learn to score the maximum?). As those authors and others note, a number of different intrinsic motivations can be addressed, often in combination, in computer game design.
Inherent in the notion of fun seems to be that it doesn't matter what the product, the direct result, of the actions is: something is fun to do not done as a means to an end, i.e. it is an activity done for its own sake, the sake of the process. This is what play is, fun being play for pleasure. To see that playing essentially involves a process not an end state, remember that however much you want to win, you have played even when you lose; while if you are declared a winner by default, you have won but cannot be said to have played.
Fun is play for pleasure, but not all the ways a computer game may attempt to give enjoyment (i.e. satisfy various kinds of intrinsic motivation) are by play, and hence fun as it will be defined here: fun is only a subtype of intrinsic motivation. The use of sensory (indeed sensuous) features e.g. colour, video, sound, music all may be attractive and rewarding to game users without being play, and indeed information as in trivia quiz answers and fact based dramas may be of this type too. Fun seems to involve play, and play to involve performing a process for its own sake, while the wider notion of enjoyment or intrinsic motivation may equally only require a product or end state. Computer games, like any entertainment, can aim at providing both kinds of satisfaction: fun is not necessarily the whole story.
An important point to note, however, is that motivation and so fun is not in fact a property of an activity, but a relationship between that activity and the individual's goals at that moment. Most things that you find fun in the middle of a day on holiday you do not find fun when woken in the middle of a night during a work week. Furthermore, the demand level of a game if it is to be fun must be matched to the player's arousal level, which in part varies independently of the game, for instance with the time of day. One should expect to design different games for different arousal levels: for falling asleep over at night versus for being the main activity of a day. High-challenge, high arousal arcade games address one kind of user demand, but TV schedules suggest there is also a great demand for low-challenge material. As noted, it is a mistake to think this is about different user types: it is at least as much about how one individual varies from hour to hour in arousal and in how challenged they wish to be.
Similarly while one use for games is to absorb the players' attention, concentration, and abilities to the maximum extent, another use is to occupy the hands with an unconscious more or less automatic activity, leaving the mind free either to rest if tired or to brood on an unrelated problem: like going for a walk while continuing to think about the day's problems. Obviously the design of a game to require maximum mental consciousness and effort is different from the design of a game of the latter kind, to be soothing and undemanding.
"C-flow" is introduced to refer to a smooth flow of actions that, in contrast to u-flow, is managed by and fills the consciousness of the actor. Examples might be driving a car sufficiently fast and dangerously to require the driver's total attention; debugging a computer program by reacting to error messages and test output; playing an absorbing computer game; being completely absorbed by watching a movie or reading a novel. (Thus c-flow may not involve physical actions at all, but always involves complete mental attention.) At each step, the next action suggests itself unproblematically: the person is not at a loss to think of anything to do, nor worried about how to select between more than one possible next move, nor worried about whether they have forgotten to do something important. C-flow also corresponds to an optimum balance between boredom (when neither this nor any other available action seems important) and anxiety (when too many goals and actions seem important, urgent, and uncertain to be satisfied).
The term "flow" originates from Csikszentmihalyi's work (1988, 1990) in another area, where he in turn attributes it to one of his interviewees, and is adopted because it felicitously alludes to the connected and effortless properties of these modes of action, but the initial letters "U" and "C" are added to distinguish two different modes of this kind. His work is directed towards a theory of "optimal experience" or happiness. This work mainly relies on questionnaire and interview instruments, and has tackled subject groups such as painters and sculptors. It attempts to describe and investigate periods of positively valued total involvement they achieve or experience, referred to as "flow" or "autotelic experience". Referring to this work, Jones (1998) listed these as components of the experience:
Clearly this analysis could be of interest to games designers, as it seems to offer an account of how players may become absorbed by successful computer games. However, though missing from Jones' list, it is clear that an account of optimal (most greatly valued) experience for Csikszentmihalyi's subjects requires not just c-flow, but "engagement" — connection to the person's deepest values and goals.
One problem with Csikszentmihalyi's approach is that it fails to distinguish between separate properties of experience: u-flow, c-flow, and engagement. Another is that an alert person may flick in and out of c-flow from moment to moment e.g. think for a moment of other concerns without it breaking the mood. Questionnaires and retrospective interviews are hopelessly blunt instruments for investigating moment to moment consciousness (Hedden, 1998a, 1998b). A full account of these phenomena may still be some way off. Nevertheless concepts of flow seem likely to be important for understanding fun and computer games by introducing an account of the quality of the cognitive processing as well as of the end results and motivation, just as Hutchins et al. (1986) did in their account of Direct Manipulation.
As noted above, play is about performing a process, and in particular to discover what the outcome will be (e.g. will I win? can I build this chair? and if so, how?). Play thus necessarily leads to learning of the "learning by exploration" kind, where the means are determined in advance and the effect is learned. (This is in contrast to problem-based learning, where the result, e.g. baking bread, is specified in advance, and the means are to be discovered.)
Since play is about discovering the outcome of the process (the consequences of some rules), learning will always result. All learning except the most alienated rote memorisation of isolated and meaningless facts is in an important sense the learning of rules. This is true not only (obviously) of learning procedures, but also of learning concepts: a general concept can be seen as a rule relating members of a class to each other and to an abstract description defining the class. To learn what "force" is in physics it is not enough, in fact is of hardly any use at all, to learn the words "a force is a push or a pull": you have to relate this phrase to the force between your hands and a supermarket trolley (stops as soon as contact is lost), the invisible reaction force that a table applies to support a mug resting on it, and so on. We may, then, sensibly regard learning as centrally concerned with discovering and exercising the relationships between rules (including generalisations) and their consequences. Langer (1997) argues that even learning normally conceived of as about rote learning of basic skills must be seen like this, at least if learning is it be effective.
All play thus causes and supports learning (although it may not be done for
that reason). But it is not true that all learning is play. Exercises
(whether gymnastic exercises, maths problems, or French translations) are
process goals from a pedagogical viewpoint (i.e. the teacher believes the
benefit is in doing the process, not in producing an answer useful for
something else). But so often they are not play because they are not done by
the learner to explore the outcome. Instead they are typically set and
understood by the learner as product goals ("get the right answer") even if any
surviving learning benefit comes from the process i.e. is the same as if it
were done as a play activity.
However there are many educational arguments — although not consensus
— that all learning should be play. Such arguments are closely related to
Langer's (1997), to constructivism (Watzlawick, 1984) and its central tenet
that learning depends upon learners building links from their own experience,
activity, and discoveries to what is learned, and to the work on deep and
shallow learning (Marton et al., 1984). It is coming to be recognised that
this applies to programming as well. In old official stories of software
engineering, you start with requirements, and programming means creating
software that exactly matches them. In reality, in Human Computer Interaction,
and in newer accounts of software engineering, it is only by creating software
(often called "prototypes") that the real requirements are discovered. In this
case the process is about discovering what the product is, and so is a form of
play in which software engineers learn what the requirements are through
exploration (i.e. play).
Nevertheless, despite those arguments for organising learning as play, there are also other important educational ideas that centre on organising learning around product goals and so seem to imply that neither fun nor play have much place in learning. Problem-based learning (Boud & Feletti, 1991) is increasingly being adopted in medical schools and elsewhere. The feature of this approach is the organisation of learning around real world tasks: the opposite of taking a set of rules (or concepts) and playing with them to explore their range, implications, and uses. The "situativity" ideas about learning developed by Jean Lave and others are even more oriented to specific outcomes and real world settings. The essential model here is that of apprenticeship, and scaffolding learners as they acquire skills that contribute to a product outcome. These ideas also are associated with strong motivational benefits for the learners, but in a way diametrically opposed to fun: learners find them motivating exactly because they see a strong and direct connection between their learning and the real world situation they are being empowered to contribute to. This is the opposite of both friviolous enjoyment and learning for its own sake.
Another indication comes from examining the obvious idea that has been pursued by some educational software designs of adding enjoyment as a rewarding extra ingredient e.g. by attractive sounds and pictures, and by game structures superposed on top of the pedagogical aims. However Langer (1997, especially ch.3) argues that to make learning enjoyable it is best NOT to add "fun" because that sends the message that it is work that needs such extrinsic rewards added to it. In other words, adding a sugar coating sends the message that this learning is inherently unpleasant, when without that they might well be brought to experience it as intrinsically enjoyable. It seems probable that learning activities are, or perfectly well could be for most learners, intrinsically enjoyable and satisfying. But that is not their main motive; nor is it useful to make pleasure the main, overt goal for adult learners (preschool children are different matter). Focussing on the pleasure does not maximise or aid the learning. Rather we may hope for the main goal to be learning; for the means to be sometimes a set of play activities, sometimes a set of task-oriented problem-solving activities; and for enjoyment to be a frequent side-effect. In fact enjoyment in learning may be like pain for bodily injuries: a useful signal worth paying attention to, but not the main point or something that cannot be ignored once duly considered.
This suggests that if play has a role, it can at most be one component or approach; and if learning can be enjoyable, fun is not the only, and perhaps not the best, way in which that can be so. If you ask adult learners whether their educational learning is fun, they often hesitate, and hesitate more than if you ask whether they are enjoying it. This is because it involves more effort than most things described as "fun", but also can be more deeply satisfying because it can engage much deeper goals. It is this deeper engagement we should be aiming for where possible. We may perhaps conclude that fun raises issues that are important to designing software that supports learning, but that while related, it is not at the root of the matter. (But for a somewhat different view see Rieber, 1996.)
In principle we might expect fun to make a contribution, applying the issues about learning discussed above to the case of learning a user interface. However this seems to be a most difficult area. Humour wears thin instantly, and "rewards" such as little animations are very often resented if they take any time or attention during a work goal. So often such "features" seem to be much more amusing and motivating to the programmer who created them than they do to the end user. The key almost certainly is the user's goals at the time: fun is not a property of software, but a relationship between the software and the user's goals at that moment. If the user is trying to get work done, then any feature which obstructs that will be as unwelcome as a phone call in the middle of the night to invite you to a party. We might therefore expect that when learning is the main goal, fun may be appropriate: this will be case in tutorials and training course material, where the user has devoted time specifically to learning the software. On the other hand in on-line help and "wizards", where the user is probably trying to get work done, then fun will probably not be appropriate but would be perceived as obstructive by the user. Thus the distinction between the user goals of learning and doing (wanting to learn versus wanting only to get a job done), that is problematic for the design of documentation (Draper, 1998; Draper & Oatley, 1992), is likely also to correspond to the cases where fun may and may not play a role in supporting learning with computers.
The issues raised by and involved in understanding fun are important in many ways to designing computer software, and should be taken seriously. However the relationship is not simple: for instance it is not true to say that all software should involve fun. The main connections seem to involve two things. Firstly, learning has an important connection with play, and so with fun, and almost all computer use involves human learning. Secondly, providing enjoyment is now a defining requirement of an important class of software, and this has not been sufficiently recognised in our analyses and design methods. Furthermore there seem to be several ways in which this can be important: as an end in itself, or as a property of the mental processing accompanying interactions aimed at something else. These "flow" experiences relate to the deepest absorbtion seen in software users, and are clearly a design aim for both computer games and educational software, even when users would not choose the word "fun".
It also owes a debt to discussions on ITFORUM, and particularly to interactions with Joe Beckmann, Lloyd Rieber, and Clark Quinn.
Csikszentmihalyi,M. & Csikszentmihalyi,I.S. (eds.) (1988) Optimal experience: Psychological studies of flow in consciousness (Cambridge, UK.: Cambridge University Press).
Csikszentmihalyi,M. (1990) Flow: the psychology of optimal experience (New York: Harper & Row)
Dowell,J. & Long,J. (1989) "Towards a conception for an engineering discipline of human factors" Ergonomics vol.32 no.11 pp.1513-1535
Dowell,J. & Long,J. (1998) "A conception of the Cognitive Engineering design problem" Ergonomics vol.41 no.2 pp.126-139
Draper, S.W. (1998) "Practical problems and proposed solutions in designing action-centered documentation" Minimalism beyond the Nurnberg funnel (ed.) J.M.Carroll ch.13 pp.349-374 (MIT Press: Cambridge, Mass.)
Draper S.W. & Oatley K. (1992) "Action Centered Manuals or Minimalist Instruction? Alternative theories for Carroll's minimal manuals" in P.O.Holt & N.Williams (eds.) Computers and Writing: state of the art ch.15 pp.222-243 (Intellect Books: Oxford; and Kluwer Academic Publishers: Norwell, MA).
Hedden,C. (1998a) A guided exploration model of problem-solving discovery learning (Ph.D. Dissertation; University of Washington). Also [WWW document] URL http://learningtech.com/diss.html (abstract visited 2 May 1999).
Hedden,C. (1998b) "Re: ITFORUM paper #30 (Jones)" (Email message to ITForum 6 Dec 1998). Also [WWW document] URL http://itech1.coe.uga.edu/itforum/paper30/30-5.html
Hutchins, E.L., Hollan, J.D., & Norman D.A. (1986) "Direct manipulation interfaces" in D.A.Norman & S.W.Draper (eds.) ch.5 pp.87-124 User Centered System Design (Erlbaum: London).
Jones,M.G. (1998) "Creating engagement in computer-based learning environments" ITForum (email list: invited paper posted 7 Dec. 1998) and [WWW document] URL: http://itech1.coe.uga.edu/itforum/paper30/paper30.html
Langer,E.J. (1997) The power of Mindful learning (Addison-Wesley: New York)
Malone,T.W. (1980) "What makes things fun to learn? A study of intrinsically motviating computer games" Technical Report CIS-7 Xerox PARC: Palo Alto, CA.
Malone,T.W. & Lepper,M.R. (1987) "Making learning fun: a taxonomy of intrinsic motivations for learning" in Snow,R.E. & Farr,J.J. (eds.) Aptitude learning and instruction: III Conative and affective process analysis pp.223-253 (Erlbaum: London).
Marton,F., D.Hounsell & N.Entwistle (1984) (eds.) The experience of learning (Edinburgh: Scottish academic press)
Neal,L. (1990) "Implications of computer games for system design" in Human Computer Interaction: INTERACT '90 (eds.) D. Diaper, D. Gilmore, G. Cockton, B. Shackel (North-Holland: Oxford) pp.93-99
Rieber,L.P. (1996) "Seriously considering play: designing interactive learning environments based on the blending of microworlds, simulations, and games" Educational technology research and development vol.44 no.2 pp.43-58
Rieber, L. P., Smith, L., & Noah, D. (1998) "The value of serious play" Educational Technology vol.38 no.6 pp.29-37 [URL: http://itech1.coe.uga.edu/faculty/lprieber/valueofplay.html (visited 13 March 1998)]
Watzlawick, P. (1984) The invented reality: How do we know what we believe we know? Contributions to constructivism (ed.) (W.W.Norton: New York)
Web site logical path:
[www.psy.gla.ac.uk]
[~steve]
[fun]
[this page]
[Top of this page]