Interactive Storytelling Spaces for Children
1 Junior members of the design team, ages 7-12 years old.
Houman Alborzi, Allison
Druin, Jaime Montemayor, Lisa Sherman, Gustav Taxén*,
Jack Best1, Joe Hammer1, Alex Kruskal1, Abby Lal1, Thomas Plaisant Schwenn1,
Lauren Sumida1, Rebecca Wagner1, Jim Hendler
Human-Computer Interaction Lab, Institute for Advanced
University of Maryland, College Park, MD 20742 USA
for User Oriented IT Design
Royal Institute of Technology
Lindstedvägen 5, SE-100 44,
Limited access to space, costly props, and complicated authoring technologies are among the many reasons why children can rarely enjoy the experience of authoring room-sized interactive stories. Typically in these kinds of environments, children are restricted to being story participants, rather than story authors. Therefore, we have begun the development of “StoryRooms,” room-sized immersive storytelling experiences for children. With the use of low-tech and high-tech storytelling elements, children can author physical storytelling experiences to share with other children. In the paper that follows, we will describe our design philosophy, design process with children, the current technology implementation and example StoryRooms.
Augmented Environments, Storytelling, Children, Educational Applications, Participatory Design, Cooperative Inquiry
A child sits in a playroom. She tells a story to her dolls about her family. Another child sits at the dinner table with his mom and dad. He retells them the stories he read in school that day. Another child runs to catch her friend. Together they imagine they are flying an airplane to a far away place (Researcher notes, September 1999).
Storytelling can be a powerful tool for communication, collaboration, and creativity [2, 10, 11, 15]. The tools of storytelling can also be a critical part of a child’s world. From storybooks, to television and movies, to theme parks and museums, to toys and computer games, all can offer storytelling opportunities that support the development of language, social and cognitive skills .
Recently, there has been an explosion of commercial software for children’s storytelling: from “interactive books” (e.g., LivingBooks), to more open-ended computer games (e.g., SimCity), to flexible authoring tools (e.g., StoryMaker). Today there is a wide range of interaction options, depending on whether children want to listen to stories, interact with them, or tell a story of their own. While these software experiences can offer creative learning possibilities, we believe they lack an important element in a child’s world—the physical environment. A critical part of a child’s early cognitive development is in negotiating the physical world .
We believe there is no longer a need to restrict our children to desktops with plastic boxes. The importance of familiar objects such as stuffed animals or blocks cannot be minimized. A number of researchers over the past few decades have combined the power of computation with the familiarity of a child’s world. One such group can be found at MIT, led for years by Professor Seymour Papert. Since the 1970s, this group of researchers has been exploring concrete ways for children to use what they intuitively understand about the physical world. They have combined the children’s programming language of Logo with mechanical turtles, LEGO gears, motors, and programmable bricks. In more recent years, their work has been commercialized in the popular Mindstorms Robotic Invention System . Other researchers have concentrated on robotic stuffed animals that enable children to listen to stories or tell their own. Such research initiatives include the MIT Media Lab’s SAGE  and the University of Maryland’s PETS . Commercial products have also become commonplace from Microsoft’s Actimates Barney  to Tiger Electronics’ Furby .
While we believe computer augmented objects are an important step toward embedding the power of technology in the physical world, we believe they can be limiting. Imagine asking children to tell their many stories with only one toy. Instead, we should be enabling children to tell their stories with any plaything they want, in any part of their playroom they choose. To this end, we are pursuing research in “StoryRooms,” room-sized interactive storytelling spaces for children.
Physical interactive spaces have a long rich history. Since the 1960s and the establishment of such science and technology museums as the Exploratorium in San Francisco, CA, children have been able to explore complex concepts with physically interactive experiences . Today there are hundreds of these kinds of museums all over the world. Children can explore anything from the history and restoration of 18th Century army barracks, to the family immigration experiences of Ellis Island, New York . Children can interact with information that is reactive to their touch, movement, or voice. They can play the role of an explorer, scientist, or artist as they manipulate images, sound, physical objects and more. In addition to museums, theme parks have also displayed a sophisticated use of physical interactive spaces. The Walt Disney Company, a pioneer in these efforts, now competes in recent years with such companies as Warner Brothers, Universal Studios, Six Flags and more.
University researchers have also pursued activities in this area. While physical interactive spaces have generally been developed for adult audiences, it has become more common to find research in this area for children as users (e.g., NYU’s Immersive Environments , MIT’s Kid’s Room ). We have found that these environments can offer children:
(1) a truly active multi-sensory learning experience;
(2) a social opportunity for learning among many co-located children;
(3) an intrinsically motivating experience (otherwise known as fun).
However, the drawbacks of such environments can also include:
(1) limited access to designated presentation space (e.g., not generally found in schools but in museums or public spaces);
(2) costly props to develop—out of the financial range of typical schools;
(3) complicated technology to program or author the experience;
(4) not easily modifiable technologies for entirely different content;
(5) difficulties for children to be story authors, rather than story participants.
Therefore, our research in developing StoryRooms sets out to address these complex issues. We have begun to focus on the development of “Story Kits” which consist of low-tech and high-tech storytelling elements, offering a low-cost yet easily accessible physical storytelling experience for children. Our emphasis has been on supporting children as authors of StoryRooms, rather than participants. We have found that most storytelling environments of this type are the result of adults’ imaginations, not children’s. Children are generally only able to choose between a few pre-created choices in a room-sized experience. It is as if we are only allowing children to read books, but never to write their own. Therefore, the StoryRooms environment supports children as storytellers from the very start of their experience.
In the paper that follows, we will further describe the design of StoryRooms, and the current technology implementation. Before we do so, let us first take you to an example StoryRoom built in at the University of Maryland.
You are entering the Island of Sneetches, a place from a Dr. Seuss story. Upon entering the room, you are given a small box to wear around your belly. With this box, you are now an inhabitant of the island, a Sneetch. You are either a Sneetch with a star on your belly, or a Sneetch without one. As it happens, you notice that a bright green star appears on your belly, however, others are not so lucky. You come to find out that the star-bellied Sneetches only like to play with other star-bellied Sneetches.
You now walk towards a mysterious cardboard toybox in the middle of the room. It reacts to you with blinking lights and noises. However, you notice the toybox only works for those Sneetches with stars on their bellies. The starless Sneetches are sad. You now hear that a person named Mr. McBean had come to the island with a special machine. It helps Sneetches without stars become star-bellied Sneetches. A spotlight goes on over the cardboard machine. It has a tunnel with flashing lights and sound. Starless Sneetches crawl through the machine, and to their surprise, they have stars on their bellies. Now everyone can play with the toybox.
But that does not seem fair to those Sneetches who originally had stars. But you are told that Mr. McBean has another machine that removes stars from star-bellied sneetches. By crawling through this other machine, the stars can disappear. So you crawl through that cardboard machine. Now, you are able to add or remove stars from you belly by using these two machines. Each time you use one of them, you hear the noise of a cash register. You notice that projected on the wall, Mr. McBean is making money, while the Sneetches’ are losing money, paying for each trip through a star machine. After a while, all of your money is gone, and you can’t go through the star machines anymore. Some of the Sneetches are left with star on their bellies, and some of them are left with stars off. What you come to find out is that all of Sneetches can play with the toybox if you decide to be friends.
What you have just been a part of is our first StoryRoom, built at the University of Maryland in the summer of 1999. This StoryRoom was designed and built by an “intergenerational design team” of adults and children (ages 7-11 years old). By using cardboard boxes, computers, overhead projectors, and speakers, we created a room-sized interactive version of Dr. Seuss’s story The Sneetches . From this experience, we learned that we needed easier, more flexible authoring tools to design our StoryRooms. In the sections that follow, we will discuss our design challenges, philosophy, and process.
Designing StoryRooms has challenged our team in two areas. The first has been in the very nature of the technology itself. Designing “beyond the desktop” is much more difficult than designing a computer screen or a single object. Sketching on paper or with low-tech models does not completely capture the notion of “location” and “time.” We have found in brainstorming these kinds of environments, that an understanding of where the user is in time and space is critical. To come to a common understanding, we have used a combination of methodologies: scenario walk-thrus, low-tech prototyping, and a lot of sticky notes.
The second challenge in designing StoryRooms has been in our partnership with children. As we will soon discuss in detail, we have chosen to include children (ages 7-11 years of age) as our design partners. We work together twice a week, after school, during the school year, and two weeks over the summer. While we have had many rewarding opportunities to work together as a team on other storytelling projects (e.g., storytelling robots , zooming software environments ), this has been our most difficult project to date. We believe this has been primarily due to the abstract nature of the technology we are designing. Most of our team participants (both child and adult) have had little experience in developing room-sized environments. We found that the children on the team looked to the adults for answers and direction. However, the adults on the team felt they knew as little as the children about what they wanted to build. Designing beyond the desktop challenged our team and team processes as they had never been challenged before. In the sections that follow we will discuss how our team design methods have been adapted to support the development of StoryRooms.
At the University of Maryland, we believe children can contribute in significant ways to the design of new technologies for children [3, 4]. For the past two and a half years we have been developing new technologies for children with children in an “intergenerational design team.” This team consists of six elementary school children and at least six adults with expertise in education, computer science, art, and robotics. Together we have adapted and changed the design process to support the inclusion of children as full design team partners. We have come to call this process “Cooperative Inquiry” . Over the years, we have developed a design philosophy that includes six assumptions:
(1) No team member knows “more” than the next, no matter what the age. Each has experiences and skills that are unique and important.
(2) A new power-structure between children and adults must be found. This starts with the rule of “no hand-raising,” something that needs to be unlearned from school.
(3) “Idea elaboration” is the ultimate goal of the design process. Ideas from both children and adults should be built upon by other team members.
(4) A casual work environment and clothing can support the free-flow of ideas. This includes sitting on the floor, wearing jeans and sneakers.
(5) All design team members should be rewarded. Adults are paid and children are given yearly gifts (due to child labor laws in the United States it is very complex to “pay” children).
(6) It takes time and patience to build an effective intergenerational design team. We have found that 6 months is needed before a team of children and adults can become truly effective.
To support these assumptions, we have changed the way we set expectations, brainstorm and reflect as a team. In the sections that follow, more description of those areas will be presented.
We have found that agreed upon expectations can lead to a coherent design vision, a more communicative team and less opportunity for miscommunication and frustration among team members. We are careful to set team expectations at the start of any project, but also at the start of any design session. The way we do this with children and adults on the same design team is with something as simple as “snack time.” While this was meant originally to replenish the energies of young children and graduate students with food, we have come to see this time as a critical part of our design methodology.
Each of our sessions starts with 15 minutes of snack time, where adults and children informally discuss anything that comes to mind. One day it could be a discussion about too much homework in school, the next day it could be sharing the most embarrassing situation we’ve all ever encountered. We have found that when our team spends time this way, adults and children come to know each other as people with lives outside of the lab. This helps all partners to be more eager in later sharing brainstorming ideas. The intercultural communications literature discusses this type of informal socializing in “contact theory.” This theory suggests that to get beyond prejudice and develop better working relationships there must be some social contact .
Following this informal discussion, we typically talk about the work for the day. We look to find agreement among design team members when it comes to goals and activities to be accomplished. Typically, we will make adjustments to our day’s focus based upon team member input.
We have written a great deal in regards to the brainstorming process with children [3, 4, 5, 6]. However, what we have come to realize is the unpublished importance of “idea elaboration.” We have found that our best ideas are ones where it is difficult to tell who originated the idea. Was it a child’s, an adult’s, two adults and a child, or two children and two adults’? Whatever the case, our ultimate goal as a team is one of “idea-building,” where one person builds on another person’s idea.
This may seem to be an obvious goal, but when people work with children, this goal can get lost. What is more typical is for design teams of adults to brainstorm and develop initial ideas. Once this occurs, only later will adults bounce an idea off of a child either in the form of a sketch, prototype, or general discussion. In that case, there is little elaboration of ideas and more reactionary feedback.
With our team, we look to include children’s ideas from the moment we start the design process. Such techniques as the low-tech prototyping of participatory design and the use of sticky notes on a white board can give all design partners a voice in the brainstorming process. However, at any time, if one technique does not lead to idea elaboration, the team will quickly change course and try another brainstorming method. We have seen all too often, that when working with children, researchers try to carefully follow their session plan, similar to a curriculum plan for a schoolteacher. But with this kind of brainstorming, researchers need to be flexible and look for the best methods of communication. To do this, it is critical to have a supply of design materials freely accessible (e.g., sticky notes, paper, crayons, LEGO blocks, clay, etc.) It surprises many adults that children are not upset by this more improvisational design methodology. We have found children can soon learn that the goal of the day is important, and that any method to get to that goal (within reason) is fine.
The specific brainstorming techniques we used to develop the StoryRooms concepts and interactions will be further described in later sections.
We have found that team design with children can be especially “messy.” Unfortunately, it can be easy to lose track of ideas or data generated by the team. This may be due to a quick change necessary in the brainstorming process that day. This may be due to a young child’s inability to remember where he or she left the team notes. This may also be due to an adult forgetting to hit the “play” button on the video camera, because he was interrupted in the middle of a thought by a child team member. Therefore, we use a combination of journal writing, video camera observation, team discussion, and adult debriefing. With many ways to capture data, we are less likely to lose what we are looking for.
In terms of journal writing, children and adults are asked to keep a “lab notebook” that can include anything from what they found important one day, to making a list of things they still need to do for a project. We use these journals to keep track of our project ideas, and to examine the design process—what’s working, what’s not. In addition to the journals, in each design session we use video to record our activities. For the most part, the children on the team will use the video camera. In this way, our young team members feel less self-conscious about a camera since one of their own peers is using it. In addition, the adults on the team also feel less uncomfortable being taped since it is likely a child is videotaping the oddest of things (e.g., a knee, a nose, room fly-thrus, etc.).
Team reflection also occurs with a great deal of discussion. Many times we will split up into smaller groups to accomplish a series of tasks needed for a day. When this happens, we are sure to end the day with a full team discussion about what each sub-group accomplished, thought about, or found. Following each design session, we also have an “adult debriefing.” This is a time when the adults on the team reflect on the design process. How are we doing? What new or better ways are there to help the children understand a difficult concept? This is a time where adults can stand back and look at the big picture of things—sometimes more difficult to do when children are present.
Overall, the reflection process is critical in capturing design history, refocusing efforts if necessary, and looking to the future. Reflecting as a team can help us to set expectations and change our team brainstorming practices.
In this section we will focus on how we applied our methodology of “cooperative inquiry” to designing StoryRooms. We began our research by trying to develop as shared concept of StoryRooms. We then attempted to build our own StoryRoom environment. And finally we began to develop authoring methods and tools for StoryRooms.
We began our work by trying to decide what a StoryRoom actually was. The adults on our team started with the notion that a StoryRoom was a collection of sensors and actuators that people interact with in a room, such that the interaction conveys a story. This concept was not something that the children on our team even began to understand. Therefore, we started our research with a series of “scenario walk thrus” of the nursery rhyme Hickory Dickory Dock. By this we mean, the team members emulated the possible sensors, actuators, and the computer program by using their bodies, spotlights, colored paper and more.
In our prototype, the story started with narrating the first parts of the rhyme and asking the StoryRoom participant to continue the rhyme with a choice of different objects. For example, the second line of the rhyme was “The mouse ran up the ?” and the participant in the StoryRoom had to chose either a clock, a table, or a phone, which were augmented with tags and sensors. Then, the rhyme continued depending on the chosen object.
From this experience, the team began to envision an entire room that could tell an interactive story. However, for many of our child team members, there was still a bit of confusion. They saw this scenario walk thru as a “play” we were going to perform for parents and friends. They did not see how this could turn into a “computer” as they knew it. Therefore, we decided it was time to do some local research at a science and technology museum in Baltimore. We jumped into a rented van and drove to Port Discovery. There we explored their “StoryRooms.” The children could solve a crime or explore an Egyptian mystery. After this day of fieldwork, we went back to the lab and wrote down on sticky notes, three things we liked about the experiences, and three things we did not. The most frequently discussed aspect was summed up by one child; “I didn’t like that there was too many broken things. Some things seemed dangerous or I slipped sometimes” (Lauren, age 8, August 1999). The team also agreed that the “long lines were not fun” (Thomas, age 9, August 1999). What they did seem to universally like, was “solving mysteries.” So while the team found the storytelling aspects of the rooms compelling, the physical implementation was less than appealing. From this contextual inquiry experience, we all (adults and children) came to a shared understanding of StoryRooms.
Our next step was to try
building a prototype StoryRoom of our own, taking into consideration what we
already liked and disliked about our previous experiences. To do this, we split up into three smaller
groups of two adults and two children to work on different aspects of the
problem. The hardware team looked at different sensors and actuators to be
used; the software team attempted to design a software authoring tool for the
room; and the story group worked on writing a story for the room.
Unfortunately, this arrangement did not get us very far. What we came to find out is that we were
missing agreed-upon story content.
Without a story, our work was just too abstract for both adults and
children. For example the hardware
group had a very difficult time imagining all the sensors and actuators needed
without a story example. The story group tried to develop an example, but it
was almost impossible to use
since it was so complex. Unfortunately, it was a story understood only by the story group.
Therefore, we took a few steps back as a team and found a simple agreed upon story. We did this by thinking about all the stories we liked. We took a vote and the Dr. Seuss story, The Sneetches won. Once we had a story, things started to take shape quickly. We went from “what if’s” to “this is how’s.” The story group developed an adaptation of the story for an interactive room. Specifically, they drew a storyboard of the events happening in the room. The hardware group built props for the stage. The props were made of cardboard boxes, and were decorated by the children. We augmented the props with embedded computers (Handy Boards), electric switches, and lightbulbs. We connected the props to Macintosh computers to control the room interactions. We also used loudspeakers and video projectors to playback voice and display graphics in the room.
In addition to this, the software group developed the necessary software for computers, which included coding and creating graphics and voices for the story. Most of the graphics were simple, and the voices were recordings of parts of the original story.
We then scheduled a demonstration of the StoryRoom for members of the lab, parents of children, and our friends. During the demonstration we found out that many aspects of a good interactive storytelling were missing from our prototype. We had designed the room with implicit knowledge of the story, but the StoryRoom participants missed some connecting elements that were critical to understanding the story. For example, participants didn’t know what the StoryRoom expected them to do, and many times during their experience the participants were idle, trying to find out an interaction possibility. Nevertheless, we observed that the six children on our team who built the environment greatly enjoyed interacting with the StoryRoom.
Again, we took some time to reflect on our experiences. We came to the following conclusions using our sticky notes method:
(1) We didn’t just want to build StoryRooms using other people’s stories. The Sneetches was a nice start, but we wanted to do more. We wanted an easier way to build our own stories.
(2) We liked the low-tech props we created. It gave us a chance to build our room quickly using materials we were familiar with. At first, we saw these props as something temporary until we built more “permanent props.” Instead, we’ve come to see these props as being fine the way they are.
(3) We thought that the act of building the room was as fun (if not more) than actually participating in the story itself. Somehow, our StoryRooms should let all kids have this same experience.
We set the new goals of our research team to include the following: (1) to build an authoring tool for children to create their own stories; (2) to provide tools to make augmenting physical objects easier; (3) to develop a software architecture to easily integrate the augmented objects and the authoring tool together.
In the fall of 1999, we began to focus on the storytelling experience. Specifically, we asked ourselves what processes and technologies were necessary to tell a story in a StoryRoom? We understood how to adapt an existing story, but we were uncertain in how to come up with a new story from scratch. To explore the possibilities, we began by telling stories verbally. One brainstorming experience that worked quite well for us was a traditional collaborative storytelling methodology. We passed a “magic” plate to each other. We began with, “Once upon a time there was a magic plate…” Each time a person on the team received the plate they would add something to the story. In this way, we improvised a multi-authored story that was somewhat coherent. As we reflected on our experience, we realized that this storytelling exercise, symbolized to us what we ultimately wanted our StoryRooms to be. We wanted StoryRooms that could be as easy to tell a story as passing a plate around. We wanted them to be collaborative storytelling experiences. We also realized, perhaps most importantly, how critical props could be. The magic plate became an agreed upon thread throughout our stories. This same prop never stopped us from making new stories over and over, and yet, it was a way to build a coherent shared story.
With the magic plate in mind, we split up into two groups to try to develop our general ideas into a specific approach to StoryRooms. Over the course of three months, we continued to brainstorm in our competing groups (three children and three adults in each group). We found that the within team competition (e.g., which group would come up with the better StoryRoom) was an easy way to spur on continued excitement for the research. This competition propelled the team members to come up more refined ideas about StoryRooms.
Interestingly, the thing we struggled with most as a team was how to move from being storytellers, to StoryRoom builders. As one of our team members would say from time to time, “I’m telling the story again. That’s not what I’m supposed to do. We’re supposed to make the room” (Abby, age 8, September 1999).
It soon became clear, that the whole team became adept at telling stories. Most of these stories were about magic, witchcraft and sorcerers. We also had stories about aliens, outer space, and a few stories about animals. We developed a “story-starter method” quite by accident one day. We were sitting at a table trying to come up with stories when we began throwing “story props” into the magic plate. We asked ourselves, what if that plate could contain any props we wanted to start stories? We threw our keys in, a thumbtack, a chewed pencil, and a mangled Styrofoam coffee cup. When we did this, we started connecting all the props in a story. “Once upon a time, there was a mystery, who left the coffee cup? Why did they leave in such a hurry that they left their keys? …” (Researcher notes, September 1999).
From this story starting experience we discussed that certain props were better at prompting stories than others. There was also the discovery that props could lead to different story structures: (1) the same props can produce different stories; (2) the same props can produce one story with many different orders to it; (3) different props can produce the same story; (4) and different props can inspire different stories.
From this experience, we began to realize that our StoryRooms should be built with a kit, one that had the possibility of any prop people wanted. We “simulated “ this with sticky notes. Each team member wrote a few prop ideas on sticky notes, to be shared by the team. We then would pick three of these ideas out of a pile. A story was then developed using the three props. We later changed the sticky notes with written words on them, to cards with pictures and a written idea which we now call “idea cards.” We realized that our kit to build StoryRooms could not contain every prop in the world already made. But it could contain ideas, to get children thinking about what they could make.
Eventually we settled into a storytelling routine. Before we would begin brainstorming about StoryRooms, we would tell a few stories with idea cards. The next stage in our design process was to transform our team from storytellers to builders of a StoryRoom. We accomplished this transformation by asking team members to think about the steps they needed to take to make a StoryRoom based on the stories they told with idea cards. We talked about how we could use sound effects, graphic, sensors, and computers to build StoryRooms. For example, we talked about how we could use a projected image in the room to tell different aspects of the stories, or how a robot could be used as part of story. As one of our child team members explained in his journal, “Today we worked on our StoryRooms. My big idea was to project doors on the walls. I also thought up the thing that you were the main character in the story. Now we’re getting more done because we know what we’re doing. It’s getting more fun all the time” (Thomas, age 11, October 1999).
And Thomas was right. By October, we began to make progress in understanding StoryRooms. We understood that StoryRooms would start out with a kit. We understood that it would contain “story starters” that would prompt children to make story props. We envisioned these props coming alive thanks to sensors and actuators, but we still had one more area to define. This was the StoryRoom authoring software that would be used to define the room’s magic. Gradually, the team members grasped the idea of an authoring software, and we came to three different ways to author a story for a StoryRoom. One of the team members came up with the idea to use comic strips as the Story visualization. Other ideas shortly followed, to use timelines, and to use arrow-notes. What we were looking at was in fact a visual programming language for a StoryRoom. This language needed to have constructs to build all kinds of interaction between objects in the StoryRoom as well as the participants. It needed to support events happening in the room that may have spatial and temporal features.
To further define this visual programming language, we chose one of our previously developed team stories and tried to visualize it in different ways. We divided the team into three groups, each had the task of drawing the story in one of the representation formats described previously. We again evaluated these different ideas. At the end, we decided to combine these ideas together, and use comic strips as the main representation of the story, and using arrow notes to connect the comic strips together.
In reflecting on our design process, we have come to realize that our design steps truly mirrored the roles we understood. We began as StoryRoom participants. During that phase, we explored other people’s StoryRooms and our own. We then moved on to storytellers. During that phase in the design process, we excelled in imagining what new stories could be told in our StoryRooms. We have now finally moved on to being StoryRoom builders. We have focused our energies in developing the technologies that can become StoryRooms. Would we still need to pass through these design phases and roles again, had someone just told us what to expect? We believe the answer is yes. Since none of us had spent much time with StoryRooms, we needed to immerse ourselves in what they were, before we could build tools for others to create them. Perhaps our brainstorming process might have gone more quickly than the six months, but we have had the luxury of being university researchers able to enjoy the exploration.
Currently our vision of building StoryRooms consists of three parts: hardware, software, and “funware.” Software and hardware are well known concepts in computer world, however funware we believe will become critical in the years to come. Funware in our StoryRoom authoring environment is the part of system that supports users with ideas. It is how we can help people start stories. Compared to programming language packages, funware is the package of example code, or it is the example LEGO constructions in a LEGO kit. During our work with our child design partners, we observed that the younger of our children liked to play with ideas given to them. In fact, one of our team members specifically asked to be surrounded with objects so he could come up with stories more easily.
The materials to build StoryRooms will consist of a wide spectrum of technologies: high-tech material (e.g., sensors, wireless enabled embedded computers, electronic tags) and low-tech materials (e.g., cardboard, paper, and plastic cups to build the props). It is our belief that any room should be able to become a StoryRoom. Children in schools or at home should be able to develop their own story, by building props for the story using low-tech materials or any other object they may find in their surroundings. They can then augment the props with the embedded technologies that essentially work as wireless sensors or actuators. They then can use a more powerful computer to develop their stories on, and program the props the way they wish.
Developing a StoryRoom in this sense is in fact like building a robot, a robot whose parts are spread all throughout the room. However, the user interface issues are completely different. From a lower level view, the problem is different in the sense that the communications with a robot is easier as it is a more compact artifact. Therefore, while the final product can be compared with robotic kits for children (e.g. LEGO Mindstorms), the complexity of developing StoryRoom technologies of this type can be overwhelming for children. In addition, the possibility of large numbers of augmented objects in a story, and the infeasibility of wiring or connecting all these objects to each other is no small task. Along with this, the need for low-power, small, inexpensive, and lightweight embedded technologies that communicate through a wireless medium is another challenge we are currently addressing.
However, we consider the main challenge of our work to be the design of a visual programming tool for the StoryRoom. While we have prototypes running in the lab today, we are still refining and working towards software that is easy to use for children, yet inherently suitable for developing a story throughout a room. This software system must provide support for many augmented objects in a room. Another challenge is in developing the underlying software architecture that can support all kinds of events that could happen in StoryRoom. These events consist of both spatial and temporal information. Spatial processing of events is a concept that lacks previous attention. For example, LEGO Mindstorms does not have a way to program the robot concerning its location in space. However, it is easy to see example interactive stories that need to know the location of objects in the room.
We have developed idea cards, example stories, and example story themes as ways to encourage children to develop their own StoryRooms. The idea cards, are cards printed with the image of on object and words describing the object. The system stores information about each idea card that will be used later for authoring the story. The software also allows children to generate new idea cards using a printer. Example stories and story themes are simple adventures with instructions of how to make a StoryRoom based on them.
We have sensors (touch, proximity, heat and light sensors), wireless radio transceiver modules, actuators (motors, lights, speakers), in the “Story Kit”. Children, with the help of older friends can put together these to form an embedded computer. They can then augment physical objects in the room with these computers. For example, a child could make a talking stuffed animal by embedding it with a speaker, a touch sensor, and a wireless module. She could also build her own props using low-tech materials found in her home. Once she creates and/or selects her props, she could then attach the idea card to the prop, so that she knows what kind of object she has to build. She then could use a handheld computer to relate the prop with the corresponding idea card. From this point on, the system is aware of the prop and the types of activities it can perform. In our example, the system knows that the stuffed animal is capable of playing back sound, and being touched by the children. This information will later be used in the software to connect all elements of the story.
We foresee children will have more high-tech toys in near future. Toys that are already augmented with computing power, and can communicate to other devices. We envision children being able to incorporate their favorite toys in StoryRooms of their own. They will be also able to participate in stories with their friends and parents, share the stories with other children, and have the freedom to realize their make-believe worlds. We hope to focus on future enhancements that will enable users to share and participate in stories that occur in separate rooms.
Currently, a child can author a StoryRoom based on the props she has made. She can always change or add new props while authoring the story. This is accomplished by composing a series of comic strips. Each frame of the comic strip shows props in the room at their current location. The next frame in comic strip indicates all changes that happened in the story objects. For example, if a light is turned on in the next comic strip frame, the transition will make the light turn on in the room. The comic frames may have many transitions to other comic frames. The status of sensors in comic strips indicates the transition. For example in a typical opening frame of a story, a touch sensor is used to welcome the participant to the StoryRoom. So, the very first frame (#1) shows the touch sensor not activated and the next frame (#2) shows it activated. Now, suppose the story has two talking props that start talking to the participant when he gets close to them. For these props to begin talking, there are two frames (#3 and #4) representing props talking with transitions from frame #2. Each shows the participant close to one of the props. The system will then decide which of these frames to activate based on the position of the participant to any of these props. Both frames #3 and #4 contain a measure of closeness to the participant. It is also possible that none of the frames gets activated. A special clock object will enable users to activate certain frames based on the passage of time. In our example, let’s consider that a hint about the story should be given to the user if he does not get close to any of the props in 5 minutes. Adding the clock object to frame #2, and a hint frame (#5) allows the user to specify the time. The only requirement will be that the time on frame #5’s clock is 5 minutes after frame #2’s clock.
Navigating in the software through different parts of the story is supported by Jazz, a Java-based architecture, developed at the University of Maryland (http://www.cs.umd.edu/hcil/projects/jazz). To support more complex stories, the user can encapsulate different parts of the story and then zoom through encapsulations to see the details underlying them. This same zooming interface allows for setting up or controlling props. To navigate through different props in the room, the user simply uses the zooming interface to select them for inclusion in a frame. At the same time, by zooming on a prop of a frame, the user can change its various status or activities.
As we look to the future, we see two important areas for further work. The first is to continue to refine the StoryRoom technologies and user experiences. We know there is still a great deal more to understand in supporting children as authors of these environments. What additional tools do children need? What environments can they make? What impact can these environments have on children’s learning experiences? All are questions that we hope to answer with future empirical studies.
The second area we intend to focus on is our design process. We intend to continue our efforts in further refining and understanding the Cooperative Inquiry design process with children. With each research project we undertake, we continue to rethink what we do, how we do it, and ultimately this changes what we make for the future.
This work has been funded through the generous support of the European Union’s i3 Experimental School Environments initiative, DARPA, the Lilly-Center for Teaching Excellence Fellowship, and the Institute for Advanced Computer Studies. We would also like to thank our colleagues in the Human-Computer Interaction lab who continue to inspire and support us in numerous ways.
1. Bobick, A., Intille, S., Davis, J., Baird, F., Pinhanez, C., Campbell, L., Ivanov, Y., Schutte, A., & Wilson, A. The KidsRoom: A perceptually-based interactive and immersive story environment. Presence: Teleoperators and Virtual Environments, 8, 4, 367-391.
2. Bruchac, J. Survival this way: Interviews with American Indian poets. University of Arizona Press. Tucson AR, 1987.
3. Druin, A. Cooperative Inquiry: Developing New Technologies for Children with Children, in Proceedings of CHI’99 (Pittsburgh PA, May 1999), ACM Press, 592-599.
4. Druin, A. The role of children in the design of new technology. Submitted to ACM Transactions on Human-Computer Interaction.
5. Druin, A., Bederson, B., Boltman, A., Miura, A., Knotts-Callahan, D., & Platt, M. Children as our technology design partners. A. Druin (Ed.), The design of children's technology. Morgan Kaufmann, San Francisco CA, 1999.
6. Druin, A., Montemayor J., Hendler J., McAlister B., Boltman A., Fiterman E., Plaisant A., Kruskal A., Olsen H., Revett I., Schwenn T., Sumida S., Wagner R. Designing PETS: A Personal Electronic Teller of Stories, in Proceedings of CHI’99 (Pittsburgh PA, May 1999), ACM Press, 326-329.
7. Druin, A., and Perlin, K. Immersive environments: A physical approach to the computer interface. in Companion of CHI ‘94 (Boston, MA, April 1994), ACM Press, 325-326.
8. Edwin Schlossberg Inc. http://www.esidesign.com.
9. Geisel, T. The Sneetches, and Other Stories. Random House, New York, 1961.
10. Gish, R. F. Beyond bounds: Cross-Cultural essays on Anglo, American Indian, and Chicano literature. University of New Mexico Press, Albuquerque NM, 1996.
11. Goldman, L. R. Child's play: Myth, mimesis, and make-believe. New York, Berg Press, 1998.
12. Jackson, J. W. Contact theory of intergroup hostility: A review and evaluation of the theoretical and empirical literature. International Journal of Group Tensions, 23, 1, 43-65.
13. Maddocks, R.. Bolts from the blue: How large dreams can become real products. A. Druin, & J. Hendler (eds.), Robots for kids: New technologies for learning. Morgan Kaufmann, San Francisco CA, in press.
14. Martin, F., Mikhak, B., Resnick, M., Silverman, B., & Berg, R. To Mindstorms and beyond: Evolution of a construction kit for magical machines. A. Druin, & J. Hendler (eds.), Robots for kids: New technologies for learning. Morgan Kaufmann, San Francisco CA, in press.
15. Ortiz, S. Speaking for generations: Native writers on writing. University of Arizona Press, Tucson AR, 1998.
16. Semper, R. J. Science museums as environments for learning. Physics Today, 43, 11, 50-56. (1990)
17. Strommen, E. When the interface is a talking dinosaur: Learning across media with Actimates Barney. in Proceedings of CHI ’98 (Los Angeles CA. April 1998), ACM Press, 288-295.
18. Umaschi, M. Soft toys with computer hearts: Building personal storytelling environments. in Extended Abstracts of CHI’ 97 (Atlanta GA, March 1997), ACM Press, 20-21.
19. Vygotsky, L. Thought and language. MIT Press, Cambridge MA, 1986.