KidPad: A Design Collaboration Between Children, Technologists, and Educators


The following stages can be seen in the iterative design of KidPad:

The Pad++ Interface Used with Children

Children and researchers began by using the Pad++ software to tell stories. As the children became immersed in this zooming environment, we saw that they LOVED to zoom. When left to their own devices, the children spent hours zooming the Pad++ surface. Their favorite activity was to draw a face, then zoom closer to draw another face inside the eye; then to do the same again and again. Once they had enough, they would zoom from face to face [see Figure 1]. The smooth zooming and extremely large surface offered children an experience they called "a ride". Many times while zooming, the children would make what they called "zooming noises" (e.g., brrrrrrrrrrr, ziiiiiiiiiing, zooooom). In addition, they would tell stories while zooming: "Once there was a boy who had lots of friends. When you zoomed into his eye you could see his friend Fernando. When you zoomed into Fernando you could see his friend Jean. And when you..."

Another activity the children continually wanted to do was create "X-Ray" stories. What they were referring to was the lens technology in Pad++. To the children, lenses helped them see what information was inside of a picture or text. Children simply placed what looked like an empty box over a picture. When the box was placed over that picture some "hidden information" was seen [see Figures 2 and 3]. For example in the case of a cow picture, when a lens was dragged near or over it, the word "moo" appeared.

Thanks to these very basic activities, we saw a number of possibilities for the development of a zooming environment that supported children's learning activities. First and foremost, we saw that children wanted to tell stories. And what came as a surprise to us, was that the activity of zooming strongly supported the creation of non-linear stories. It seemed to be a very natural way for children to tell their stories. They enjoyed the freedom of piecing together their thoughts and connecting them any which way they wanted to by zooming. This zooming approach to story-telling also strongly supported collaboration between children. Many times one child would begin the story by typing or drawing, and another child would add the next part of the story in another part of the Pad surface. In this way, children would work together endlessly writing, drawing, zooming, and telling their stories.

For the children, these activities developed and exercised their visual and verbal literacy skills, and enabled some proficiency with their use of new technologies. For us as researchers, these experiences made clear that the children needed zooming story-telling tools that suited their needs. To begin with, they wanted a better way to "program their zooms" between story elements. It was far too easy for the children to become lost on the Pad++ surface when zooming in the wrong direction. The children also seemed to need different drawing tools for their story-telling. When using the existing palette of drawing tools in Pad++, they easily became confused with all the extraneous tools not necessary for their drawing or writing. They also had a difficult time when they would zoom on the Pad++ surface and weren't sure why the drawing tools "lived in a different box from the rest of the things in the zooming world". They didn't like moving the floating menus around the Pad++ surface. "They're always in the way of our zooming," said one child. In addition, there were times that the children also seemed to need our help in getting started on their stories. They often would ask, "Start me a picture, please?" With this in mind, we also tried to consider new ways of offering story resources.

The Local Tools and KidPad

After a short intense period of development, researchers came back to the classroom with the first version of what we called "KidPad". It included a new interface paradigm we called "Local Tools" [3]. Instead of traditional floating palettes of tools, there were large, simple tools that sat directly on the Pad++ surface [see Figure 4]. They reminded a number of children of the "fat pencils they could write with if they were good". With local tools, children could select a tool (by single-clicking on it), and the cursor would turn into that tool in both size and shape. If the child wanted to drop that tool and use another, the child would double-click in the place they wanted to drop it and the tool would remain in that place on the Pad++ surface.

These tools included what the children called a "crayon" to draw with, an "eraser" to delete objects, and an "arrow" to select objects [see Figures 4, 5 and 6]. The arrow was used in combination with the picture scrapbook. This scrapbook consisted of a slider to move through pictures which ranged from green dinosaurs to red hats. Once the child saw what they wanted, they chose a picture with the arrow, and dragged the picture onto the Pad surface. Automatically a copy of the picture would be placed on the Pad surface.




Another local tool was the "magic wand". In response to the children's love for zooming, and their frustration with getting lost "on a long zoom" the magic wand was created. When children selected the wand, then selected anywhere else on the Pad++ surface, a link was started. The next place children selected was the place that would be "linked to". These two places could be seen easily because a bright yellow line connected the two selections. When children de-selected the magic wand, they could zoom between links by touching a "hot zooming spot" with another tool. Children seemed to love this tool. While similar functionality was available in the Pad++ substrate, the interface was not intuitive to children, and therefore was used very little. Once this became a magic wand with "yellow magic lines" showing where there would be zoom paths, the children used this tool repeatedly to tell stories.

In addition to these local tools, there was a "tool box". This box was placed in the bottom right corner of the screen. When children clicked on it, all the local tools would zoom back to where they started, lined up along the bottom of the screen. This turned out to be extremely useful when children would zoom around the Pad++ surface and forget where they left their tools.

Children's KidPad Design Ideas

The children seemed to enjoy this new zooming environment. Their stories became more complex and richer in content and structure, thanks in part, we believe, to the local tools they used. Once the children had spent some time with this new environment, we asked the children to brainstorm with us on how to make a better technology for them [see Figures 7, 8 and 9]. What we heard from them in conversations, drawings, and writing were the following suggestions (these suggestions are only listed if a majority of the children we worked with raised the issue):




Up until this brainstorming experience, we had generally chosen to focus our development efforts on "the biggest problem of the week". At our classroom sessions with children (usually an hour, three times a week) they would show us where they had difficulties, or suggest new possibilities. These were generally not large development projects, but small areas that could quickly be implemented and tested with the children. However, once examining the results of our children's brainstorming work, the team went back to the lab to decide what features seemed to suggest important new directions for the future. What follows is a discussion of where the children's ideas have taken us.

KidPad for Preschool Children

Thanks to the abundance of ideas from our child design partners, we found ourselves (due to limited programming resources) having to focus on a few areas of development. One important area that the children pointed out was zooming. We heard and observed that the 3-button mouse was confusing and difficult to use for many of our children. By making the left button the select button, the middle button the zoom-in button, and the right button the zoom-out button, we found that children usually had to depend on trial-and-error to remember which button did what. The mice that the children drew had whiskers and noses for zooming, which we suspected might be much easier to remember than right button or middle button. Many of them just wanted to get rid of the mice all together and point at the screen. Listening to their concerns, we began to focus on alternative zooming and panning tools that lived on the screen. We created a "zoom in" and a "zoom out" local tool [see Figure 10]. By picking up a zoom tool, the cursor became that tool. Moving and pressing it would zoom at that spot. We also developed a "panning frame" which enabled children to merely move the mouse over the frame in the direction they wanted to go and the pad surface would pan in that direction [see Figure 11]. Each of these tools had the additional feature of animating when the cursor was over it. We came to the conclusion that local tools should not have a text label, thus accommodating younger children. We decided that these tools should only be icons, and that animating the icons would replace the need for text [1]. The zoom and pan tools proved to be excellent in their self-explanatory nature.

In addition to these tools, we tried developing a "drop bucket", one which would replace the need for double-clicking to drop a tool. However, we quickly saw and heard from children that this drop bucket was not the right solution. The "dropping" was an unnecessary step to the children. Instead, they wanted to "swap tools" . They wanted to merely click on another tool and have that tool become the cursor and have the previous tool be put on the Pad++ surface. We took this to heart and quickly implemented this interface suggestion. Interestingly enough, our preliminary results with this version of KidPad show that these new features, (except for the drop bucket) seemed to be much more intuitive for children. In fact, it appears from our pilot tests with a small number of children ages three and four, that much younger children were able to use these KidPad tools.

KidPad for the Future

What does the future hold for KidPad? There is still a great deal of work ahead, even to fulfill the initial design suggestions we received from the children. In a perfect world, we would love a 1,000 more hours with hundreds of more children, in a relaxed setting outside of the structure of a typical classroom. But without more resources for personnel and facilities, we have continued on with our small group of researchers, finding access to classrooms and children where possible. Currently, our energies are focused on more short-range areas of development that support the needs and desires of our child design partners. We are in the process of expanding the drawing tools, developing sound capability, simplifying the "X-Ray" interface, and adding animation functionality.

We also would like to see two more long-range additions to KidPad. The first addition would be in automating the drawing process. We call it the "DrawMe" tool. It is envisioned that a child could use this to replicate and modify existing objects more easily. A child could select the DrawMe tool and place it over a given drawing. When the child clicks on the drawing, all the local tools that were used to create this drawing would gather right below the picture selected. For example, a child might select a picture of a pumpkin. And what s/he might get with the DrawMe tool would be an orange crayon, black ruler, and the eraser gathered below the pumpkin. This would help the child remember what tools s/he used to create that picture. In addition, it would also show the child how other children created their drawings, thus spurring on new ideas to pursue. Once any of the tools gathered directly below a picture were used, they would function as in the past to create a new picture.

The second set of functionality we see as important, is to support new forms of collaboration between children. In much of our work we saw children sharing one computer. Many times they were frustrated when they could not agree who would get to use the mouse to zoom or to draw. We observed that more assertive children would tend to monopolize the use of the computer, frustrating more passive children. Therefore, we hope to implement software and hardware support for two mice on one computer. In this way, a computer might better support the work of two children sharing the same Pad surface. This is interesting to us, not only from the standpoint of children's story-telling endeavors, but in terms of new collaboration functionality for the Pad++ substrate.







User Profile






Design Process




Goals for Development


Design Evolution



Web Accessibility