by Corrina Perrone, Alexander Repenning, and David Clark
The World Wide Web (WWW) is widely considered a successful new media for communication of ideas, a hotbed for commerce, and, more quietly, a new research media that can bring hundreds of gigabytes of useful information to classrooms around the world. However, without a structuring mechanism that allows focus on specific learning domains, the usefulness of the WWW to students is questionable.
The huge information “cyberspace” is, to our children, more like having 500 channels of TV. Surfing the WWW is largely a passive consumer activity, multimedia and java applets notwithstanding. We have found that the effectiveness of the WWW as a learning tool can be significantly increased by combining it with constructive tools. This paper presents WebQuest, a system combining the WWW with the notion of an interactive quest game. Using WebQuest, students not only read information on the WWW, but learn to think critically about it as they use it to construct educational simulation games about the themes of their research. They set up complex worlds containing interesting objects obtained by navigating tricky obstacles and landscapes. These objects are needed to solve a quest, or go on to a new level. This approach offers several learning opportunities to students using the World Wide Web. Students can be players or authors of quest games. As players, students learn by finding Web sites and forming answers to questions to acquire important objects needed to progress through and finish the game. Authors learn by creating the worlds, formulating challenging yet solvable questions, and providing (or not) helpful hints and clues to lead players to sites on the Web that will answer the questions. Both players and authors use the quest game — either by constructing or by playing — to focus their research on the Web.
Used by multiple groups in the same classroom, a dialog is started between authors and players, which facilitates reflective learning. Players help authors to understand what works and what doesn’t in a learning game; how much information should be given in a clue, which questions are good or bad, and perhaps provide new topic-related Web sites. In this paper, WebQuest is described, the roles of teachers and students in the classroom are outlined, and we present our initial classroom tests with middle school, high school, and undergraduate students. We conclude with a description of WebQuest”s future development.
What teachers think of the World Wide Web
The value of the design process and educational games
WebQuest: Interactive simulation game + WWW
WebQuest in the classroom — Authoring & playing quest games
Playing learning quests
Reflecting and giving feedback on learning quests
Future WebQuest work
The efforts of Vice President Gore’s Information Infrastructure Initiative are linking the nation’s schools to the Internet. The World Wide Web (WWW) is rapidly gaining acceptance as an educational resource. Among teachers of all levels, however, concerns are rising about how to use the Web in the classroom, how to find sites that are truly useful, and how to keep students from wasting time with sites that are clearly not useful or those that contain objectional material. Teachers are the first to admit that they are often not as fluent in the technology as they would like to be, or in many cases, as their students already are, but they have neither the time, nor the training resources to access and incorporate the use of online curriculums into their own.
At the Center for LifeLong Learning and Design, our use of technology in education has focused on blending constructionist systems, in the form of interactive simulations, with the support of network media, such as the World Wide Web [1, 11]. Constructionism, based on the constructivist ideas of Piaget that stress that knowledge is constructed from a child’s experiences in the world, proposes that people best construct new knowledge when they are engaged in personally meaningful tasks . In contrast, a more traditional, instructionist approach in the classroom treats a student as an empty vessel to be filled with facts. Ideally, these approaches should be combined, for on their own, they each lack a crucial element of the learning process. Instructionist methods often neglect the hands-on practical experience that constructionist methods stress and may ignore altogether the intrinsic motivation of self-direction, and constructionist methods stress de-contextualized doing with little or no intervention or presentation of fundamental material.
|Figure 1: Students getting hypertracked.|
Turning students loose on World Wide Web browsers in a classroom or computer lab setting combines the worst of both of these approaches. Students are exposed to the huge information space of instructionist material and quickly lose their focus — they become hypertracked following link after link which usually takes them farther away from the information they may be seeking (see Figure 1). In this context, the technology becomes a step back, rather than a step forward. Internet browsers were designed for the cross-platform distribution of multimedia information, and this useful feature, along with firewalls and necessary computer security restrictions, are often an impediment to comprehensive, interactive, participatory applications for education. The majority of sites on the Web have been developed for commercial or entertainment reasons, and allowing students to Websurf in class may entertain them, but learning is questionable. The challenge for technology in the classroom is to provide a high level of engagement and to support the learning process as well .
Educational games are usually more successful in an entertainment context than a learning context. A few, such as SimCity®, Carmen San Diego®, and various multi-user dungeons/dimensions (MUDs/MOOs) have been used effectively for education [2, 3, 18]. We have combined an Internet Scavenger hunt, or quest, with an interactive simulation game to create a software package called WebQuest. WebQuest is an educational game for K-12 classrooms, designed to help students gain Internet research skills while researching answers to questions relevant to current classroom curricula.
Participation in a design process provides rich opportunities for learning [4, 20]. Learning happens by active participation in the formulation and construction of personally meaningful artifacts [ 9 ]. Learning through design proposes a new pedagogy in which children are placed in the position of producers of knowledge . Furthermore, learning relationships to subject matter emerge over time . By creating as many motivations as possible to engage the learner with their task of constructing an Internet quest game we tried with WebQuest to foster this process. There are many aspects to spark interest and deeper exploration: research on the Web, formulating a quest, designing the look and behavior of the game. In our student trials, we find that the game construction component is just as exciting to students as working on the World Wide Web.
Designing a quest gives authors ownership and control of a questworld, and allows them to integrate knowledge about a quest’s theme with knowledge acquired from the WWW and knowledge about game construction. The presence of an audience has an effect on the learning process. The artifact is framed, executed, reflected upon, and perhaps revised with the audience in mind. By combining an interactive simulation game and the WWW, we enable learning by acquisition, but also by design, construction, and reflection. Learning by players and authors in WebQuest is summarized in Table 1, which is an expanded version of the table that appeared elsewhere .
|Table 1: Learning from an Interactive Simulation Game + WWW.|
WebQuest combines the WWW with an environment to build interactive simulation games. Webquest is implemented in Agentsheets [13–16], a programming substrate developed here at the University of Colorado that facilitates the creation of visual environments. In the past four years, Agentsheets has been used to create more than 60 educational and industrial applications such as construction kits, interactive simulation environments, visual programming languages, design environments and games. Similar to spreadsheets and cellular automata , Agentsheets uses a visual formalism  based on a grid structure. Agents are autonomous computational units arranged in the grid structure, which is called an agentsheet. The look and behavior of individual agents can be defined by users, which is why Agentsheets was selected for WebQuest.
Each agent has sensors and effectors that allow it to communicate with the user or other agents. Sensors include mouse, keyboard and microphone input. Effectors can be used to animate agents, send messages to other agents, get messages from neighboring agents, to play sounds or even to speak via voice synthesizers. WebQuest features a number of predefined agents including knights, musketeers, paths, and trees (Figure 2). For WebQuest, Agentsheets was extended to use AppleEvents to control the Netscape Navigator WWW browser. When this capability is added to the behavior of various game objects, such as scrolls, the connection between the game environment in Agentsheets and the WWW environment of Netscape Navigator becomes as seamless as possible to the students and teachers using the game, yet does not diminish functionality from either of the systems. For more information about Agentsheets, see http://www.cs.colorado.edu/~l3d/systems/agentsheets.
WebQuest was created to be a constructionist learning environment. There are two kind of users. Authors create worlds such as in Figure 2. A world represents a quest containing little puzzles that need to be solved by the players of the game.
The game environment (Agentsheets), and the WWW browser (Netscape Navigator) are active on the screen at the same time. Players first choose their game identity from a palette of Renaissance characters (Figure 3), and place it onto the gameboard. The gameboard is the visual representation of the questworld, and contains a maze of roads winding through trees and over and around rivers and lakes. It is filled with dragons, greedy ferryboat men, and other potentially interesting objects, such as rocks, trees, doors, jewels, ships, purses of money, and keys. Gameboard components have associated behaviors and attributes that the player discovers as the game proceeds. For example, keys open doors, castles can be entered, and money can be used to pay the ferryboat man, who will then rent you his boat and take you to an island. Some game objects can be connected to questpages, which are WWW pages that contain questions that must be answered to obtain an object for later use.
In Figure 2, the student’s character is the knight navigating the path around the lake. As in a MUD or other adventure game, minimal information is provided at the outset, and clues about how to play are obtained by trial. The player wanders around the gameboard by using the cursor keys, exploring objects and actions that give hints about what is required to progress to the next level. A player soon learns that keys open the doors that separate a dragon from the playing field, and that keys are obtained by answering the questions posed by scrolls. Players can accumulate wealth, sail ships to other worlds, find jewels and other objects-each earned by research contributing to the knowledge about the theme of the quest.
|Figure 2: The Web World and a portion of a WebQuest Gameboard.|
In this section, we present a scenario for the classroom use of WebQuest. The game environment of WebQuest, which consists of the Renaissance characters and objects mentioned above, is used to build an instructional quest game about the theme of Africa.
David, the teacher of a middle school social studies class, is about to teach a module on Africa. Traditionally, he would simply hand out information such as maps, assign reading, and a research project. After giving his lectures and discussing the reading in the social studies book, he would give his students a test on the material before proceeding to the next module — Asia and the Far East. David hopes to supplement the reading in the class with research time on the WWW. He decides to incorporate WebQuest to teach the Africa module. This way, the students can use the WWW to find these various sites and share them with the class. David splits up the class into teams of four. Each team choses a more specific subtopic related to Africa for which they will have to create a learning quest. One team choses to work on African history.
|Figure 3: The WebQuest palette of game characters and objects.|
1. Researching the theme
Building a quest begins with the theme “African history”. Members of the authoring team search the Web to find relevant sites, determine the goals of the quest, and develop appropriate questions to challenge the quest players. These questions will be used to create questpages, which are Web pages that pose questions and provide hints, and a questworld, which consists of the gameboard that the players navigate, and game objects, which the players interact with.
Using Internet search engines, such as Yahoo and others, the authors quickly find three URLs of interest (Figure 4). Browsing these sites and the information they contain, they formulate a list of topic-related questions that other members of the class will need to answer to solve ‘AfricaQuest’. Students type this information into the Agentsheets environment, and an HTML file (questpage) and a scroll are automatically created for them by the system and placed into their game folder.
|Figure 4: Finding relevant URLs.|
2. Designing and laying out the gameboard
Once the students have riddles that players will need to solve, they are ready to lay out their gameboard. A questworld has several components. First, there is the gameboard, which an author creates by using objects from the palette and laying them out onto a blank gameboard. Next, there is the palette itself. The palette consists of game objects and their behaviors. Working together, the authoring team designs their gameboard using the existing palette objects. First, they can lay out a background of forest, then weave a winding path through the forest (Figure 5). One of the students wishes to add a river, and another wishes to add a lake or an ocean, so that ships may be sailed on the quest. The authors decide where the quest will end, and talk about placing the barriers they have chosen. By selecting game objects from the palette and drawing them on the gameboard, they conceptualize the various routes a player may take through the quest.
|Figure 5: Laying out a gameboard.|
3. Connecting the questworld with questpages
The students place a dragon at the end of the quest. The dragon’s question must be answered before the player can go past. One author points out that if the dragon is too accessible, the game will be over very quickly, and the group decides that more barriers must be placed along the path so that a player will find the desired Web sites to learn about African history before getting to the dragon. Soon, the dragon is surrounded by locked doors. Doors are objects in the palette that must be opened by keys. Keys are hidden under scroll objects, which point to questpages. By answering the question on the scroll’s questpage, the player earns a key which can open a door to give access to the dragon. The authors place several keys, covered by scrolls, on the gameboard, and, by using the game’s authoring interface, hook the scrolls to the questpages they have prepared (Figure 6). The answers to the questions they have placed on the questpages are programmed into the keys through the author’s interface, so that when a player tries to grab a key, they must type in the correct answer to the scroll’s question to successfully obtain it. This is an important step in the learning process for the students as they are taking the information they found on the WWW and rerepresenting it for educational use in their game.
After much discussion, the group decides to make the dragon’s question something that must be discovered by navigating several links into the “Story of King Solomon and the Queen of Sheba” Web site. Going back and forth between the gameboard they are developing and that Web site, they formulate what they believe is a suitably hard question and finally, the dragon is programmed with this question, and its answer. When the teacher announces that the class time is over, they save their work. The next week they will trade quests with another team, who is working on a quest about African wildlife.
|Figure 6: Re-representing WWW information for the quest game.|
4. Changing & extending the questworld
In a middle school trial lasting one week, teams usually have time only to build a quest using the existing WebQuest tools, as they are learning about surfing the Web for research, and also about the WebQuest system. However, the game also allows students to add game objects, or change the look of existing objects in the palette. Additionally, an author has access to the behavior of the game objects, and in adding a new game object, can “borrow” behavior from existing objects or create completely new behavior. The author’s interface to the interactive simulation game offers various ways to build new ideas into a quest. These range from the relatively simple task of drawing a new playing character to the more difficult task of creating a new game object with its own special behavior. Current work on a Visual Programming language for Agentsheets, called Visual AgenTalk seeks to make these programming tasks as simple as “drag and drop”, and to include mechanisms for better comprehension and sharing .
5. Sharing quests
Customized quests can be shared with other players, locally and around the world through the Agentsheets Remote Explorium  & the new Behavior Exchange . In this way, the author’s games are not merely disposable artifacts of a class project, but personalized contributions to the WebQuest Collection. We find there are strong motivations by students as authors to “outdo” other authors — by providing a new character that no one has thought of, by making the path to be navigated full of creative obstacles, or by making scrolls that lead to Web sites that no one else has found.
|Figure 7: Playing the AfricaQuest game.|
As players, students learn by exploring worlds, solving quests and finding interesting information on the WWW related to the quest theme and bringing it directly back to the game. This reduces the “hypertracked” phenomenon when students browse the Web. Quest themes can be linked directly to curriculum, which means that students are not simply set in front of a Web browser to passively absorb presented information. Through the game questions, thematic information is made valuable to them in an immediate way. Additionally, when they play WebQuest, they serve as a critical audience, providing encouragement or feedback to a quest’s author, reflecting upon what sorts of questions or hints were effective or ineffective, providing new sites that might be given as clues, or suggesting other questions related to the quest theme.
When the class time is over, the students from the Ethiopia group meet with the students from the African wildlife group to talk about their quest experiences. They provide feedback to each other about the quest games and their experiences playing them, including which questions were too hard or too easy, problems they had accessing hint URLs, etc. Armed with new information about what players actually did in their quests, what players prefer to do, and problems or bugs in their quest game, the authors are motivated to modify them.
When all the quest exchanges have been made, David spends a class period trying to determine what his students have learned during this experiment. The children talk about the new Web sites they have found and what interested them about the Web sites as well as the information they remembered about each of the subtopics. When they discuss both the quest-making and reflection processes , he realizes that the students have learned not only about Africa, but about representing knowledge they gain from their research and how to try to explain it or present it so that others can understand it. He agrees to give them time to improve their quests based on the feedback they have received from the other groups and suggests that when they are finished they submit the quests to the WebQuest Explorium to be shared with students at other schools.
|Figure 8: Students as authors.|
The program was initially created with middle school students in mind. The game is appropriate for this level because children have reached a developmental stage that allows for non-linear thinking, yet are still young enough to be motivated by a game environment. The initial testing of the program occurred in August of 1995, during the Science Discovery Program at the University of Colorado. Twelve students ages eight to fifteen who were taking part in a two week long class on the Internet agreed to try the software and supply feedback (Figure 8 is a worksheet created by a student of the Science Discovery Program).
The students were delighted with the design features, and even more thrilled to learn they could create their own quests. A few quickly discarded the worksheet provided and began creating their own playing environments. These students progressed from creating scenarios connecting roads and rivers in ways that were similar to the initial worksheet, to radically new ideas, such as groups of islands that had to be navigated with ships.
The ability to control their environment by building gameboards and navigating their own way to quest answers on the WWW was a large factor in the students’ positive learning experiences with the program. While some explored the design elements, two students teamed up to look for ways to cheat and gleefully announced their discoveries when they came up with ways to circumvent the answer checking mechanism and obtain game objects without researching the answers. (This bug in the system has since been fixed.)
Others delved into the Web and moved fluidly from Web page to Web page in search of the answers. These students were proud of the fact that they were able to reach the dragon and answer its question honestly to pass onto the next level.
Although the students in the third category modeled the results we were hoping for, we were constantly surprised at the discoveries and creations by the students who fell into the former categories. In all cases, we had to pull the students away after the hour and a half session was over. There was no shortage of creative suggestions for ways to make the game do what they wished. “We need a chainsaw”, “It would be cool if you could fall into traps”, and “I want to make a dungeon, I need some steps” were just a few of the comments we received. All students stayed focused on the game and their research and the “hypertracked” phenomenon was greatly reduced.
Additional middle school classroom testing took place in the spring of 1996 to further design and test WebQuest’s authoring interface. A team of undergraduate students took WebQuest into Platt Middle School and critically evaluated the existing user interface. They identified areas where students had problems creating quests. During the semester, the authoring interface was simplified, additional bugs were found and fixed, and a Web-based tutorial was developed, as well as additional teacher and student support material, in the form of a “WebQuest Worksheet” to help students organize their research and formalize the questbuilding process a bit more, and help teachers evaluate the research being performed by the students. At the end of the semester, these materials were brought back into the classroom and the improvement was measured. We found that it was easier for students to keep track of their questions with the Worksheet, and that it was necessary to more fully integrate online help to provide a useful resource for the students.
In November of 1995, WebQuest was presented to 10 high school students from a computer-oriented group at New Vista High School in Boulder, Colo. At this level, the students were familiar with the WWW, and therefore were far more interested in extending the game rather than simply playing it. Out of the 10 students, all students created a new quest environment using the existing gallery agents, and four chose to update the gallery — two of them collaborated with their art teacher to draw a wooden-legged pirate.
We noticed that a possible gender split occurred at this level, as well. All 10 reacted favorably to the game, except the two girls in the group, who thought it was “ok”. Further testing needs to be done to determine why this happened, and what might be changed in the game to encourage girls to participate. Two of these students continued as authors of a quest game for middle school students to play.
In the summer of 1996, WebQuest was presented to over 60 students of the High School Honors Institute, which gathered here at the University for hands-on technology workshops. We found that students of this age group expect a much higher level of sophistication from computer games, and this affected their motivation for building quests. Once the students were presented with mechanisms to change the look and behavior of the game, they became a bit more engaged, and additionally, the WWW research aspect was still appealing. However, it is clear to us that this age group will need to be presented with a version of WebQuest to which they can better relate, and work is currently being done on such a version. We found no evidence of a gender split in this larger population, and stipulate that the disinterest seen in the previous test on a smaller population was due to the experimental situation. In that test, girls were paired with boys and did not get to control the computer, thus reducing their participation in the game. In this larger test, several teams of girls built interesting quests on Italian Renaissance Art, Dog Breeds, and other topics, and were just as interested as the boys.
In the spring of 1996, a group of undergraduates in a design lab in the College of Architecture and Planning developed the “Mr. Roger’s Sustainable Neighborhood” . This team used WebQuest components in Mr. Roger’s to create a neighborhood modeling game, where the quest component is made up of decision points to change various aspects of the neighborhood based on information about sustainability found on the WWW and provided by the game’s authors. This project is continuing currently with the cooperation of the Boulder Counties Healthy Communities Initiative, a group of 400 residents and professionals of Boulder County, whose goals are to educate the community about sustainability issues, and to encourage community discourse and participation in decision and policy-making for sustainability.
Previous work has demonstrated the advantages of combining network technologies, such as the World Wide Web, with the Agentsheets design environment to broadcast and share multimedia artifacts , thereby attempting to augment the passive, instructionist learning experience facilitated by Web browsers with the interactive, constructionist, and collaborative experience of learning by designing and doing.
Further work in WebQuest will progress along the lines of building more complex simulation in quest games, and sharing quest game components. To more easily build quests, we will create a Visual AgenTalk version of WebQuest. This will allow students to create and program new game objects merely by drawing the object, and then composing the desired behavior by dragging and dropping visual behavior components onto these objects. What this will accomplish is the ability for students to let their quest game theme correspond to the look and the feel of the game. The African wildlife group mentioned above, for instance, can create animal icons and a simple watering hole ecology simulation. There is a limit to the complexity of simulations that can be created by middle schools students, however, constructing such a simulation is a learning experience that has rich opportunities for incorporating research information found on the WWW. Additionally, we are hoping that this version will appeal more to high school age students as well.
For sharing, we will implement the WebQuest Explorium, a repository of completed quests, new game objects and their behaviors, author profiles, results from student tests, as well as other help and hints for both playing and authoring quests.
The combination of a design environment and networking mechanisms, such as the World Wide Web, show a great deal of promise for bringing distributed, constructionist learning activities to the classroom. By preserving the engaging, evocative qualities of a quest game and adding the programmable capabilities of a design environment, students are not only presented with a new way of finding and learning information, but a rich context in which to create something personally meaningful with that information. Taking on roles as players allows them to gain Internet research skills that can be used for any subject, and while solving quests, players learn about the quest’s theme. When players are authors, they learn by design, recasting and applying knowledge gained while researching a theme into a quest that can be played and solved by others.
More information can be found about WebQuest at http://www.cs.colorado.edu/~corrina/mud
About the authors
Corrina Perrone and Alexander Repenning
Center for LifeLong Learning and Design
Department of Computer Science and Institute of Cognitive Science
Campus Box 430
University of Colorado, Boulder Colo. 80309
E-mail: corrina [at] cs [dot] colorado [dot] edu; ralex [at] cs [dot] colorado [dot] edu
Boulder Valley Schools
6500 Arapahoe Rd
Boulder, Colo. 80301
E-mail:dclark [at] stripe [dot] colorado [dot] edu
The authors wish to acknowledge: the members of the Center for LifeLong Learning and Design, especially Jim Ambach for assisting in classroom experiments, Boulder Valley School District, students of the Science Discovery Program, High School Honors Institute, and Professor Ernesto Arias. This research was supported by the National Science Foundation under grants No. RED 925-3425, and Supplement to RED 925-3425.
1. J. Ambach, C. Perrone, and A. Repenning, 1995. “Remote exploratoriums: Combining networking and design environments,” Computers & Education, volume 24, number 3, pp. 163–176.
2. A. Bruckman and M. Resnick, 1995. “The MediaMOO project: Constructionism and professional community,” Convergence, volume 1, number 1, pp. 94–109.
3. D. Clark, 1995. Student’s guide to the Internet. Indianapolis, Ind.: Alpha Books.
4. G. Fischer, 1994. “Turning breakdowns into opportunities for creativity,” Knowledge-Based Systems, volume 7, number 4, pp. 221–232.
5. G. Fischer, 1995. “Distributed cognition, learning Webs, and domain-oriented design environments,” CSCL ’95: The First International Conference on Computer Support for Collaborative Learning, pp. 125–129.
6. Y. Kafai, 1995. Minds in play: Computer game design as a context for children's learning. Hillsdale, N.J.: L. Erlbaum Associates.
7. Y. Kafai and M. Resnick (editors), 1996. Constructionism in practice: Designing, thinking, and learning in a digital world. Mahwah, N.J.: L. Erlbaum Associates.
8. B. Nardi, 1993. A small matter of programming: perspectives on end user computing. Cambridge, Mass.: MIT Press.
9. D. Norman, 1993. Things that make us smart: Defending human attributes in the age of the machine. Reading, Mass.: Addison-Wesley.
10. S. Papert, 1991. “Situating constructionism,” In: I. Harel and S. Papert (editors). Constructionism: research reports and essays, 1985–1990. Norwood, N.J.: Ablex, pp. 1–11.
11. R. Pea, 1994. “Seeing what we build together: Distributed multimedia learning environments for transformative communications,” Journal of the Learning Sciences, volume 3, number 3, pp. 285–299.
12. C. Perrone, D. Clark, and A. Repenning, 1996. “WebQuest: Substantiating education in edutainment through interactive learning games,” >Computer Networks and ISDN Systems, volume 28, numbers 7–11, pp. 1,307–1,319.
13. A. Repenning, 1993. “Agentsheets: A tool for building domain-oriented visual programming environments,” CHI ’93: Proceedings of the INTERACT ’93 and CHI ’93 Conference on Human Factors in Computing Systems, pp. 142–143.
14. A. Repenning, 1994. “Programming substrates to create interactive learning environments,” Interactive Learning Environments, volume 4, number 1, pp. 45–74.
15. A. Repenning, 1995. “Designing domain-oriented visual end user programming environments,” to appear in Interactive Learning Environments, special issue on end-user environments.
16. A. Repenning and T. Sumner, 1995. “Agentsheets: A medium for creating domain-oriented visual languages,” Computer, volume 28, number 3, pp. 17–25.
17. A. Repenning and J. Ambach, 1996. “Tactile programming: A unified manipulation paradigm supporting program comprehension, composition and sharing,” VL ’96: Proceedings of the 1996 IEEE Symposium on Visual Languages, pp. 102–109.
18. M. Resnick and N. Rusk, 1996. “The computer clubhouse: Preparing for life in a digital world,” IBM Systems Journal, volume 35, numbers 3–4, pp. 431–439.
19. D. Schön, 1987. Educating the reflective practitioner: Toward a new design for teaching and learning in the professions. San Francisco: Jossey-Bass.
20. E. Soloway, M. Guzdial, and K. Hay, 1994. “Learner-centered design: The challenge for HCI in the 21st century,” Interactions, volume 1, number 2, pp. 36–48.
21. T. Toffoli and N. Margolus, 1987. Cellular automata machines: A new environment for modeling. Cambridge, Mass.: MIT Press.
22. We are currently discussing the use of this name with the legal copyright owners and Public Broadcasting Service.
Copyright © 1996, Corrina Perrone, Alexander Repenning and David Clark. All Rights Reserved.
WebQuest: Using WWW and interactive simulation games in the classroom
by Corrina Perrone, Alexander Repenning and David Clark.
First Monday, Volume 1, Number 5 - 4 November 1996