JavaCAP evolved from case libraries developed at Georgia Tech for aiding experts (Domeshek & Kolodner, 1992), aiding architecture students, and for supporting engineering and industrial design education. A case library for experts holds "cases" dedicated to a specific content area. Before getting involved in educational endeavors, our AI group at Georgia Tech worked with architects and engineers to develop case libraries of prisons, courthouses, skyscrapers, public libraries, and handicapped access to support architects; for hydraulics engineers working on aircraft hydraulic system design; and so on. An expert using a case library might browse it to get ideas or ask to see cases that address a particular issue (e.g., lighting in a judge's chambers, effect of high pressure on a hydraulic system). Cases can suggest ways to address a problem, suggest solutions, suggest results that might accrue, and so on.

We've also successfully made these case libraries available to students in our architecture and industrial design classes. But, as stated above, we had problems when we introduced expert-written cases to middle school students (Hmelo et al., 1997). The cases, as we wrote them, were not aimed correctly for them. But more than that (we could have written them better), they simply weren't interested in reading what experts had to say. By asking students to author cases for others to use and then asking students to use other students' authored cases, we thought we could add both an element of engagement that was missing in our adult-written case libraries, an authentic reason for students to summarize and extract what they learned, and an activity for students that would promote deeper learning. We've focused first on case authoring.

A big issue we had to deal with was how to help the students look back on what might have been a two-week or longer project and extract what they had learned. We've dealt with that issue two ways. Students keep design diaries (Puntambekar, et al., 1997) throughout their activities. Design diaries differentiate between different phases of their design activities: understanding the problem, generating and choosing between several possible alternatives, building, trying out, and analyzing the solution, and so on. Our first way of dealing with this issue is that we've organized JavaCAP in the same way and asked students to have their design diaries in front of them as they are writing their summaries. When entering their experiences understanding the problem, they know which design diary pages to refer back to. Our second solution is as yet unimplemented: we intend to integrate electronic versions of design diaries (which support reflection while working on a problem or project) with JavaCAP (used after completion of the project).

JavaCAP asks students to think of their previous design activity as a play with scenes. They compose a case by describing their experiences as if they are writing a narrative (not quite a play, as they are describing and summarizing what happened rather than writing dialog). Students can upload multimedia elements for a scene and annotate them. When finished, they can publish their case by choosing indexes for it, anticipating the kind of description each of their scenes needs to have for others to recognize its usefulness to their endeavors.

JavaCAP is implemented using Java and runs over the World Wide Web (hence its name). JavaCAP’s main and authoring menus are displayed in Figure 1. The main menu at the left bar allows students to browse, search or author cases. Also, customizing is available for authorized users. When authoring is chosen, the student logs in with his/her user name and tells the system which design problem s/he is commenting on. From the authoring menu students may access the four scenes or publish their case.

The first scene in JavaCAP is the "Problem Presentation" scene, where the problem specifications and expectations are presented (see an example in Figure 2). Then comes the "Alternatives Selection" scene where students complete an alternatives table, entering the criteria used to compare the alternatives considered (see an example in Figure 3). In the "Solution" scene they describe the solution they chose, what happened as a result of trying it out, and what they learned from it. Finally, they conclude the entire experience in the "It’s a Wrap" scene, where they can also describe anything else that was especially important to their effort (e.g., collaboration experiences, what they learned about doing design).

Figure 1: The authoring menu of JavaCAP after logging in through "Authoring" at the left bar main menu.

With the exception of the alternatives scene, all scenes are designed with the same ‘two-column notebook’ screen. The left column of the notebook provides an unstructured area for kids to freely write about their experience, while referring to an image. Students use digital cameras to capture their design artifacts. Annotating images anchors the reflection process to concrete and attractive elements. On the right column of the notebook there are labeled slots for text entry as well as pull-down menus for indexing. This format creates a structured and sequenced procedure for the reflection process. Some of the slots are accompanied by scaffolding features such as suggestions for criteria (general and problem-specific) to compare alternatives or lessons learned in previous cases (Guzdial, 1994).

The two-page notebook interface supports collaboration by providing distinctly different space for two approaches to expressing the problem and the collaborative design solution. For instance, in the "Problem Presentation" scene, the right-hand page includes requests for a title for the case, the problem presentation and some learning expectations. On the left-hand page, the students are simply prompted to talk about what was important to them when they began the design problem. They are encouraged to use a digital image to illustrate some aspect of the this initial phase of the design process. This duality requires distinctly different responses, providing collaboration based on an image and again on more structured text responses. While one student may contribute by drawing a scale diagram of the proposed solution, another may be best able to synthesize the group’s statement of the problem. The paired presentations elicit and support multiple levels of student participation in the group solution.

Figure 2: The ‘Problem Presentation’ scene in JavaCAP.

Figure 3: The ‘Alternatives Selection’ scene in JavaCAP where a student filling a 9x3 table.

Figure 3 shows an "Alternatives Selection" scene. This is the most challenging scene. Kids summarize the set of criteria they used (the vertical dimension of the table) to make their design decisions and what alternatives they considered (the horizontal dimension). During design, they might or might not have pulled together all of their considerations in this way. We ask them, in their summaries, to do that. Many groups have "design fixation", finding it difficult to go beyond their initial idea. To encourage consideration of multiple design alternatives, the students are asked to evaluate at least two solutions against the same set of criteria. The interface in the "Alternatives" scene illustrates this alignment of different solutions, side-by-side in vertical columns against the same set of criteria. Students have difficulties understanding the concept of criteria used to select the best alternative. We ask them to give it another try after solving a problem even if they had trouble doing it while they were engaged in design. JavaCAP provides prompts for criteria appropriate to each problem and also describes criteria in a generic manner. Our intention is to integrate the scaffolding for summarizing (in JavaCAP) with scaffolding for making the design decision using electronic design diaries.

In the two summative scenes, i.e., the "Solution" scene and the "It’s a Wrap" scene, there are several pull-down menus that aid students in indexing their case based on the knowledge accrued in the case library. For example, students need to select from a list of problems found in previous solutions, the one that is most similar to the main problem they have encountered in their solution. The list is compiled and customized by experts and teachers, based on the growing database of cases (see a further section on customizing).

The "It’s a Wrap" scene is where the group can describe important aspects of the design solution or process. The free-form page of the notebook provides an area for the group to summarize their experience or tell their story and illustrate it with an image. The other page guides the group through describing a key scene from their work. This significant event may be the location of an important resource or some aspect of the collaborative experience. There is a pull down menu to select an activity or tool that was used in this "key" scene for the design process. The group goes on to describe what happened in that crucial event and then what they have learned in general from working on this problem. This scene provides the "creative" outlet for the group. "It’s a Wrap" is the place where they get to "rap". It is like a prologue, where the group has an opportunity to reflect on what is significant at the end of the design process. They can contrast this to their initial expectations in the "Presentation" scene. When peers use the case, these personal reflections may provide valuable insights to the process as well as the content of the design solution. The last scene is very open-ended, providing a forum for reflection on the entire spectrum of the processes and content experienced in the design problem.

We envision the use of JavaCAP as a collaborative tool, where authoring a case is done by a team of students. One team approach is to assign each member to be responsible for the first draft of one scene, all members review each scene, then collaborate on the final version of every scene. JavaCAP facilitates this collaborative work of a team in an asynchronous mode. Once a team member has entered a scene page to edit, no one else in his/her team can enter that page. The warning message includes a link to the e-mail of the member who is currently editing the page, as well as other contact information. When a team member exits the scene page, then it is unlocked for others to edit. Team members can review their peers work at any time, entering any of its scenes through the browsing section. Of course, there are many collaboration issues that need to be addressed before we can say that JavaCAP provides mature collaboration support.

In order to be able to include prompting appropriate to particular design problems students are reporting on, JavaCAP has a facility for customization that is simple enough for teachers to use. Teachers can refine existing prompts and scaffolding features, or even add new materials that might better fit their students’ needs. The general preferences include modifications to problems and its types, activities/methods/tools, solution statuses, and suggestions for criteria by problem types. For a specific problem the preferences include: suggestions for criteria, classifications of the solution, and major problems encountered in the solution.

The authoring module of JavaCAP was tested twice in a Georgia middle school to evaluate the usefulness of the authoring tool and to acquire student authored cases.

An early version of JavaCAP was used by seven eighth grade earth science students and one seventh grade life sciences student, selected by the classroom teachers from a pool of over forty-five volunteers. The students used their individual design diaries to assist in authoring cases representing the experiences of their group and its chosen solution.

The volunteers joined the EduTech staff members in a science classroom after school for two sessions (a total of three hours) in November, 1996. The authoring tool was accessed via an intranet of nine PowerBooks, with one as the server.

The students were able to complete their cases and rated the tool's usability as very good. They liked the permanence of the case in the computer database and publishing their solution.

A new and improved version of JavaCAP was used later by thirteen seventh grade life sciences students in June, 1997. They had just spent three weeks in class developing a group design for robotics locomotion derived from the way one or more arthropods get around. The students worked in groups of three to five keeping individual diaries of their design work as well as a group portfolio of their experiences and design products. These students felt comfortable with the JavaCAP interface since they had used another EduTech software tool with a web-browser interface. The teacher selected thirteen students from two classes, representing a cross-section of abilities and interest levels. In each class there was one pair of students who had worked within the same team, each of these pairs authored a single solution collaboratively, the other students authored individually.

The selected students joined EduTech staff members in the middle school media center during their science class on two successive days. JavaCAP was accessed via Internet connections available in the school; it was served from a Macintosh server at Georgia Tech. None of the students had previous experience with JavaCAP.

Students were provided with their individual diaries from the problem and their design artifacts from the portfolio. They took turns capturing images of their design products with a digital camera. Images were captured during the first session. Overnight, EduTech personnel loaded them onto the web into the scenes students had designated so that students could write in the context of the images on day two.

Students were excited to author their recently-completed problem solutions and were able to use the software with minimal instruction. This was the first test where the uploading of images was a working option. Students found the digital camera easy to use and were able to efficiently acquire images to accompany the case they were authoring. The four-scene framework for recording their solutions was readily understood. Students grasped the different spaces within the authoring tool and were able to move between the scenes as intended. Most completed the scenes in the order presented on the introductory screen, but a few skipped a scene in their authoring. Of the eleven cases authored, only three had alternative tables providing information for several solutions and a systematic evaluation mechanism. The "Solution Scenes" contained general functional science knowledge, many described some detail of the collaborative process they used to solve the problem. The final scene, "It's a Wrap," was most often used to show the importance of research to their solution and the collaborative process in determining the solution. These initial student cases contained only high level functional descriptions of science (we would have liked more technical detail), but the play metaphor elicited some very specific explanations of the collaborative design process students used.

D.1 Lessons Learned

The net-browser interface for text and images is an easy interface for students to use. The middle school students readily fill in the blanks on the display form, but the content of the cases contained very little evidence of science learning in the problem domain. The pull down menus within the text areas were almost always used, but hyperlinks to scaffolding were not. Most of these links were at the bottom of the display, and may not have been seen in time to be used. The time allocated to student authoring will need to accommodate the accessibility of the cases on the network and the complexity of collaboration. Accessing the tool via the world-wide web yielded variable response times. The class test did not allow enough time for all students to complete their cases or to review and edit them. Image capturing and uploading adds a considerable amount of time to the case authoring. However, the use of images, diagrams and models to represent a design idea is very valuable in the authoring process, the additional time is well-spent.

Even though nine of the eleven test cases were authored individually, the students often portrayed the collaborative nature of their solutions. Several scene titles included the group name and many alternative solutions were identified by student names. The more specific entries in the scenes usually portrayed collaborative processes, with either favorable results or stating how it might work differently in the next design problem. For instance, an entry in the "It's a Wrap scene" by one seventh grader:

During the individual authoring, the students naturally gravitated to the computers in pairs working together on how to use the case tool. The synchronous collaboration is very evident in the students’ case authoring, while the asynchronous mode is not so familiar to them.

Initial development and trial of JavaCAP perhaps raises more questions that it answers. Some have to do with its use. Will JavaCAP perform well when the team members access the case asynchronously to author and revise the scenes? How will teachers use the tool in the curriculum and how will they manage the computer access required to author cases? What is a reasonable time frame for the middle school student to be able to author? Will the depth of science knowledge in the scenes increase if more time is allocated to authoring? Will more iterations of authoring increase reflection and thus lead to better construction of scientific knowledge?

Others have to do with the potential contributions of case libraries and case-authoring tools to learning. When will browsing the middle school student authored case library be useful and in what ways will it strengthen the student's ability to grapple with an ill-structured problem? Should there be criteria for including student authored cases? Can the student learn about the design process by browsing a case authored by a design team, even if the domain knowledge is distinct from that of the current problem? Can the case reflect the process as well as the content used to derive a solution?

Some have to do with its integration into the classroom and LBD environment. When is it better to start using JavaCAP along the design process? Would it be appropriate to author the problem presentation and alternatives selection scenes when the design solution was chosen, then finish the solution and it’s a wrap scenes after the design is completed?

But the most important questions, we think, have to do with the role the software should play in learning and the embellishments it needs to help students summarize and articulate better. What they entered into JavaCAP, as mentioned above, was lacking the technical kinds of details and specificity we would have liked. The problem may not be with JavaCAP; it may be with what students were pushed to do during their classroom experiences. We've found that, in general, students are not pushed to get to details in middle school but that when we sit with them and talk and prompt, they are able to consider far more than is asked of them. We will have to find out what levels of detail we can expect and how to promote it.

More broadly, we would like to be creating tools that, in some sense, free the teacher from responsibility for facilitating perfectly. If a teacher is weak at helping students identify constraints and criteria or doesn't know what kinds of questions to ask students to get them down to specifics, for example, a piece of software that scaffolds appropriately might fill in. Other times, teachers and software will have equal expertise, with the software and teacher supporting each other. Other times, the teacher will be able to help more. We see a symbiotic relationship here. When the software is more capable than the teacher, it might serve as scaffolding both for the students and the teacher. The teacher may learn from the software how to get the students to more specificity, for example. When the program is weak compared to the teacher, we will know that we need to examine what teachers are doing and decide whether this is something that we want or can feasibly put into our software.

A tool that would help students be more specific scientifically might also help teachers create more interdisciplinary curriculum. Students were concerned with spelling and punctuation, the need to edit their draft case, and the desire to be understood by many. A tool that helped students with the science would make it easier for a language arts teacher to help students write a narrative describing a science experience.

We have described JavaCAP, a case authoring program we developed aimed at middle-school students studying the EduTech LBD curriculum. Middle-schoolers can author cases in teams and use the tool in a collaborative way to share their experiences while learning science through solving design problems. Their teachers can customize scaffolding and indexing features in JavaCAP to better fit their students’ needs. Students can upload multimedia elements they have captured during their studies and eventually they can publish their cases on the Web.

We have tried JavaCAP with 20 students and made significant changes in its structure and interface along the formative evaluation process. According to our observations, the program is usable and the current interface is well understood by students and teachers, though some concepts remain difficult for students, such as distinguishing between criteria and alternatives. Teachers collaborating in the development of the LBD science curriculum are authoring exemplary cases and customizing JavaCAP for new problems they develop for their students. Further research will be completed in order to learn how to better scaffold the authoring process and to enhance the collaboration features.

Future research efforts will focus on use of JavaCAP to support teaching in collaborative settings at the middle school level. The tool provides the opportunity for teachers to form student groups based on interests, rather than the by classroom period. JavaCAP would provide the collaboration across class periods or even between schools, where the curriculum implementation called for wider-based collaboration. JavaCAP might provide the forum for the sharing of ideas, another tool from our research group may be employed to facilitate the cross-classroom discussion.

Another focus will be to determine how JavaCAP can better facilitate reflection and iteration. The authoring portion of JavaCAP is designed to be completed at the conclusion of the design process, to prompt the students to take another look at what they have learned and accomplished within their group. But we see JavaCAP playing an important reflective role throughout the students' design and problem-solving processes. The task of writing a case would be easier on the students if it was a piecemeal, iterative process, rather than a colossal task at the end of a project. Further, the solution and "It's a Wrap" scenes could be more reflective. It is important for students to remember and record their design process, including wrong-turns and other realistic elements that might not appear in a statement of a final, clean solution. We need to find a way to encourage that.

One path to a greater role for the JavaCAP software is to continue our process of integration between JavaCAP and other collaborative tools being developed by the EduTech Institute (Mark Guzdial et al, 1997). For example, JavaCAP has many elements that would dovetail nicely with the design diaries that we have been developing, and use of JavaCAP could be easily scaffolded through use of the Planning tool in SMILE.

In summary, JavaCAP is playing an important role in encouraging student reflection through collaborative case authoring. The task of case authoring is challenging for students, as are many learning activities. Our hope is to improve integration and guidance (through scaffolding) to ease the complexity and improve the learning benefits of the task.

Amnon Shabo, Kris Nagel, Mark Guzdial, Janet Kolodner: EduTech Institute, Georgia Institute of Technology, GCATT Building, 250 14th Street, N.W. Suite #138, Atlanta, GA 30318-0490. amnonh@cc.gatech.edu, kris@cc.gatech.edu, guzdial@cc.gatech.edu, jlk@cc.gatech.edu.