By Juan-Pablo Hourcade
Summary
The KidPad project had the goal of creating a learning environment for children through software with the peculiarities of having a zooming interface, and being designed by an interdisciplinary and intergenerational team.
While development of children's software often takes children into account after a good part of the software has been designed, the KidPad project included children as part of the design team from the very beginning. The thinking behind this choice was that while children are not engineers, they are experts at what they want and why they want it. The collaboration with children combined participant observation techniques with participatory design experiences.
Forty-eight children (ages 8-10) of very diverse backgrounds and abilities took part in a design process that lasted six months. They started by using an existing version of Pad++. From observation, video taping, and researcher notes on this experience, the first version of KidPad was created. After a few months, the children were asked to describe their "dream" KidPad. The children's suggestions were then used to produce a new version of KidPad.
The three goals in the development of KidPad were that it: support visual and verbal literacy, support children constructing their own paths to knowledge, and use the intergenerational approach to building software effectively.
The design team was interdisciplinary because it included professors and students from the fields of computer science and education. A positive finding during the process was that researchers from each discipline were sensitive to different issues. Another interesting finding was that each research discipline took the lead depending on the type of activity carried out.
Working with children was a challenge. It became clear that children need time, experience, self-awareness and confidence before becoming effective partners in design. As the children's expertise grew they were able to provide more suggestions and ideas to the rest of the team.
When the children started working with the existing version of Pad++, they loved the zooming and thought it was "cool". They also enjoyed using Pad++ lenses. The most important contribution of zooming to the software was its support for the creation of non-linear stories. The children also had problems when they used Pad++. They got lost in desert fog, they didn't like the existing drawing tools or floating menus, and sometimes they needed help getting started on their stories.
After observing these problems, the first version of KidPad was created. Local tools were added to solve the problem with the drawing tools and floating menus. Local tools are large, simple tools that sit on the screen. One of the local tools was a picture scrapbook, which was added to help children get started with their stories. Another tool, the magic wand, was used to help with the problem of desert fog by allowing the children to make links between KidPad objects. A toolbox allowed the children to put all the tools back in their original locations.
After using KidPad for sometime and becoming proficient with it, the rest of the team asked the children to suggest changes to the software. The main problem the children identified was that they had a hard time using the mouse. They also asked for sound, more pictures, animation, a typing tool, more drawing functionality, and expanded zooming capabilities.
In order to solve the mouse problems, zoom and pan tools were added to KidPad. These seemed to be so successful that even younger children were able to use the software. A drop bucket was also added to drop local tools (instead of double-clicking), but the children didn't like it.
As far as directions for the future, the authors mention a "DrawMe" tool. It would be used to replicate and modify existing KidPad objects more easily. The other main direction they mention is making KidPad single display groupware, by allowing multiple mouse input. This was successfully implemented after the paper was written, with good results.
Analysis
The distinctive characteristics of KidPad are its design team and its zooming interface. It is unclear whether the interdisciplinary and intergenerational approach had been used before. The paper makes it sound like it's a new idea.
Certainly, interdisciplinary teams are nothing new. I wonder if some of the interdisciplinary experiences related in the paper have been documented in previous research.
The most interesting aspect of the development team though, seems to be the inclusion of children from the start. Again, the paper makes it sound as if it is a new approach. I wonder if it has been used before, not necessarily for software development, but for the development of some product for children.
While it makes sense to include the children from early in the software building process, the paper doesn't make a good case for them being effective designers. The changes to the software in the development process were made because the children were having difficulty using the software, not because they suggested the design changes. Therefore, the paper makes a good case for making the children part of the software development process as test users observed by experts, and as users who can suggest new features. Maybe if the experience with the children had continued, they could have reached a level of sophistication that would have allowed them to be good designers and some of their design ideas could have been implemented and tested. Part of the issue is the definition of being a designer. Does the fact that someone asks for a feature to be added to some software make him/her software designers?
Another issue with the participation of children was that even though they started contributing early in the development stages of the software, there still was a piece of software for them to use when they started. It would be interesting to know how children could help in the design of software from the very beginning when specifications are made.
I thought it was interesting that children needed time, experience, self-awareness, and confidence before they could become effective design partners. Maybe this is because they are not so used to the "constructionist" approach, and instead they are used to there being right answers and wrong answers. Since there's definitely a lot of gray area in software design, maybe the difficulty children have is with coming up with ideas that may not be particularly right or wrong. The danger though with the children becoming experienced is that they may give the rest of the team a false sense of security that some features are easy to use when they actually may be difficult to understand for novice users.
The other peculiarity about KidPad is its use of zooming. The best case for the use of zooming is its strong support for the creation of non-linear stories. The paper doesn't mention whether any other tools out there, not necessarily software, also support the creation of non-linear stories. It would be interesting to compare them with KidPad for effectiveness. Another plus for zooming was its "coolness" (something you can never underestimate with children).
Also related to zooming, I thought the paper didn't do a good job of describing Pad++ as the children used it at the start of development.
Questions
Had an intergenerational approach like the one described for KidPad ever been used before in the development of any kind of children's product?
Do you think the time it took for children to become effective design partners may have something to do with the fact that they are not used to the "constructionist" approach in the classroom (i.e. there's no clear right or wrong in design suggestions)?
Did the children program the lenses?
What other kinds of tools (not necessarily software) have been used for non-linear story-telling?
Where there other problems the children had with the original Pad++ software that were not mentioned and for which solutions were not found?
How long did the children use the first version of KidPad before being asked to brainstorm?
Was the "DrawMe" tool ever implemented?