To appear in SIGCSE Bulletin Vol. 29, no. 3, 1997, Conference Proceedings of ITiCSE 97.
Copyright 1997 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissionsfrom Publications Dept, ACM Inc., fax +1 (212) 869-0481, orpermissions@acm.org.
Ursula Wolz, Daniel Domen, Michael
McAuliffe
Department of Computer Science,
The College of New Jersey (formally Trenton State
College)
Hillwood Lakes, Box 4700, Trenton, New Jersey, USA,
08650
{wolz,domen,mcauliff} @tcnj.edu
Abstract
An interactive children's story is presented as a unifying class project for CS 2. Curricular topics include: data and algorithm abstraction, project dynamics (team work, software engineering and ethics), multi-media techniques, and hypermedia story telling. We encompass alternative learning styles by fostering collaborative team work, and promoting the big picture over esoteric detail. Students receive a detailed design document, extensive code libraries, and graphic, sound and video files. A story board gives them ample room for individual creativity and whimsy. The project is implemented in C++. This paper describes curricular goals, articulates management concerns and summarizes our past experiences.
1 Introduction
The standard CS 2 curriculum has as an overarching goal to present a single cohesive theme: modular abstractions help control complex, many faceted problems. Students often loose sight of the big picture as they struggle to master the details. First, they don't work on a large enough project to appreciate the modular approach. Second, our students tell us such projects are "boring" without extensive graphics and interactivity. Until recently it was relatively easy to incorporate graphics and interactivity into introductory courses. However, in the most current environments that rely on Graphical User Multi-Media Interfaces (which we affectionately refer to as GUMMIs) programming even the simplest graphics or interactivity is hard without a deep understanding of GUMMI protocols and concepts.[3,4,6]. We report here on a single large project with a strong multi-media component that is developed throughout the semester. It is an interactive story, potentially of students' own making, which promotes creativity and whimsy.
The project provides students with practice in the standard curriculum of CS 2. It reinforces an introduction to key multi-media techniques without degenerating into a course on multi-media "minutia." It exposes students to a single large project in a carefully guided manner, providing a vehicle for discussion and experience in team dynamics as well as ethics. The project is designed to reach students with diverse learning styles, including women[1,2] because it allows the instructor to present course content within a larger context, one with social relevance. It diminishes the need to view problems in small isolated settings. All this occurs within the context of telling a story in hypertext. Computer Science students should gain an appreciation for the elegance and complexity of such networks early in their careers.
The project is implemented in C++, however students are given a detailed design document, story board and extensive libraries, as well as graphics, video and sound files. It must be stressed that the emphasis is on the interplay of curricular goals within the project. Depending on the specific story implemented, that interplay will change in subtle ways. This paper provides an example story and describes our curricular goals in detail. If students choose to create their own stories they must meet those goals. Student assessment is also based on the relative weight of these goals.
The next section presents the curricular goals of the project and illustrates the interplay between them. Section 3 provides an overview of an example story and shows how the curricular goals are met. Section 4 addresses management issues, and addresses the problem of supporting team work while evaluating individual performance. Section 5 provides a summary of our experiences with GUMMIs and large projects.
2 Curricular Goals
In designing this project we deliberately addressed the problems of integrating the following topics, listed in order of curricular significance. Each will be discussed in turn:
A concern in designing our curriculum was to address how the material is taught. This topic has relevance to gender issues in technology and science courses. Typically in the sciences, topics are covered as isolated skills, concepts or facts. Although the instructor may have a clear idea of the overall relevance of the topics, students focus on the details, loosing sight of the larger context. This is especially true in lab-based courses in which isolated labs may not have an obvious relevance to a big picture. Studies indicate [1,2] that in general women learn better when material is presented in context, in which the big picture is obvious, and especially when it includes social relevance. Furthermore, women tend to thrive in a collaborative environment.
Students with particular learning styles, especially women, are often turned off to computer science because of a lack of perceived relevance in assigned course work. They leave the field saying that they do not derive satisfaction from solving small isolated problems, that they are more interested in interacting with people than computers. They are often overwhelmed when they attempt to compete with male "hackers" who have been playing with computers for years. Their experience in courses in which competition for grades is stressed gives them the wrong perception of what it means to do computer science. We have found this attitude to be especially true in introductory courses in which a large and complex set of techniques, problems solving skills, and simple facts must be mastered in a relatively short period of time. Sadly, by the time students begin to do interesting and challenging collaborative projects in advanced courses, many creative individuals have moved on to other fields where they believe they will find greater social relevance.
The curricular goals described in the following subsections are implemented in order to promote collaboration and to keep the big picture at the forefront. Communication between team members, idea sharing, and close interaction with the instructor are stressed. Our goals can be acheived because the project is highly interactive and exploits GUMMI technology.
2.1 Data and Algorithm Abstraction
The primary emphasis of the course is on data and algorithm abstraction including graphs, stacks, queues, tables, lists; recursion versus iteration; search and sorting algorithms (linear and binary); and external data sources. Although implementation of abstraction is presented in the course, students are given libraries, both standard and of our design, through which to implement abstraction for the project. For example a lecture might contrast pointer and array implementations of queues and include a discussion of which is best under what circumstances. The emphasis is on finding the right implementation for a particular task. A lecture might analyze the trade-offs between using recursion or iteration to manage program control. In the project, students are encouraged to implement a history of user actions via a stack. They are required to choose which of a number of practical implementations, pointer versus array, for example, is most appropriate for their task.
Data abstraction is critical to multi-media programming[6]. A clear grasp of the principles of object-based design provides a solid grounding for managing GUMMIs. Understanding the need for communications protocols (message passing) between objects is necessary to create robust code. For example, a window is an object. Both a text and graphics window are refinements of that object and should be created, updated, modified and removed using standard protocols. In C++ it is easy to recast an object into another data structure, violating established protocols between objects. However doing so often leads to nasty system crashes; a very valuable lesson.
All of the classic abstract data structures can appear within this project. For example the story itself is a graph that is traversed, a history of the user's path is stored in a stack, a part of the story might involve lining the characters up in a queue and having them enter an activity in order. Lists and tables can be used to organize graphic, video and sound components of the project.
Classic algorithms for searching and sorting can be implemented. For example searching can be done of the pixels in a picture to change object attributes. Characters or objects displayed in order of one attribute can be sorted by another and redisplayed. We make an effort to integrate the concepts cleanly so that their inclusion does not appear to be contrived.
Trade-offs between precompiled and dynamic solutions come into play. For example, animation fragments can be implemented by displaying precompiled tables of pixels, or by "morphing" in real time. Although real time morphing is compelling, caching tables of pixel and displaying the tables creates smoother animation in most windows-based operating systems.
Issues related to external storage tie in nicely here. The algorithms for searching and sorting might be implemented as utilities that are used to create picture or sound files. Students might choose to implement a morphing utility to generate pixel tables that are then used in the interactive story. Similarly, searching pixel color in real time is impractical. If the end user has a restricted selection set, it is probably more efficient to precompile all of the potential solutions and simply load the selection. This does not preclude studying search because the requisite utilities can be built by students.
2.2 Project Dynamics and Ethics
Team dynamics, software engineering and ethics come into play throughout the project. These are explicitly discussed in lecture. They are reinforced through journal writing and team discussions with the instructor. Student understanding is assessed through written and oral reports and to a lesser degree through formal written exams.
2.2.1 Team Dynamics
Students are grouped in teams of 3 to 6 and keep journals of team interaction including how tasks are assigned and completed. Teams are initially proposed by the students, however, the instructor will insure that no group is too weak to complete the project. Teams may dissolve and regroup as the semester progresses with permission of the instructor.
During lab sessions with an average class size of 24, the instructor meets regularly with all groups. These meetings are not graded to encourage free flowing question answer periods. Students do not feel compelled to show how "smart" they are. Students get advice not only on the progress of their project, but on how they should be communicating among themselves and distributing the work. Lecture sessions explicitly address the trade-offs between collaboration and competition.
2.2.2 Software Engineering
Software engineering principles are formally and informally introduced. Lectures emphasize how protocols and conventions allow independently developed code to be easily merged. The development cycle is modeled in the lab. Students are guided through design, implementation, debugging, testing and documentation. Students are taught how to effectively use outside resources such as libraries and data (GUMMI) files. Code resuse is addressed and support utility coding is encouraged.
Student journals, while not graded are informally reviewed on a regular basis. Journals are expected to include notes on algorithm development and final decisions, plans for test cases, and results of testing. Good software development practice is pervasive in the lab. Every interaction with the instructor brings home the lesson in some way. This type of modeling is far more effective than formally teaching these concepts.
2.2.2 Ethics
Discussion of ethics appears in three ways. First we consider the issue of collaboration versus plagiarism. Team work and cross team collaboration is strongly encouraged, for example a team might find or develop a utility and share it with other teams. In lecture we explicitly ask questions such as what does it mean to "own" an idea, an algorithm, or a code fragment. We discuss the boundaries of sharing these things and ask when does it become plagiarism. We also address how individual achievement is measured in a group context.
We also consider copyright issues, particularly of code, graphics, sound and video, and story line. The sound, graphics and video files we provide are all of our own making, however students enjoy finding alternatives on the World Wide Web. We ask them to think about the circumstances in which they may use these in their programs.
Finally we discuss content of the interactive story, and ask them to consider balancing free speech with moral responsibility. Since the project is targeted toward very young children, we discuss what content is appropriate. If versions of the program are posted on the Web, we consider the responsibilities of the creators to ensure that it won't offend particular groups. Because these issues relate in a very practical way to their project, in our experience, students discuss them with more passion than in purely theoretical contexts. They are also more willing to consider viewpoints other than their own.
2.3 Multi-Media Techniques
The following multi-media techniques are incorporated into the project. Rather than presenting these in isolation, each is introduced within the context of how it is used, thus avoiding over-emphasis on the nuance of a technique in a particular programming environment. Libraries, both from commercial sources and of our design[8] are provided. Techniques include:
Many of these techniques are highly dependent upon the operating system (Microsoft Windows/NT, MacOS, Unix). Consequently we emphasize principles and general concepts and do not belabor how the techniques are applied in particular environments. For example, we provide libraries for invoking a simple dialog box, but do not cover the extensive range of functionality of a MacOS version.
A critical component of the multi-media curriculum is discussion of the event model. The model creates a "loop" within a program which triggers object invocation depending upon what external event (for example from the user, external storage devices or networks) has just occurred. It is exited when an "exit" event occurs. In concept it is very different from the classic interactive "main" loop found in most introductory CS texts because of how responsibilities are distributed. In practice, in simplified form it looks remarkably like the old model. The flaw in many introductory texts is that very simple (and brittle) versions are first shown, with subsequent chapters adding complexity.
A bad introduction to the event model fosters bad programming discipline. Students either ignore critical problems or over design their solutions. For example students might ignore data incompatibility. If their program is using a simplified event loop it may not catch the error, creating a brittle situation that can be nearly impossible to debug. Or students might write elaborate code to handle a file not found error. Their code will probably override a standard, more robust event handler resident in the operating system. Worse, if their handler interacts with the user, it may not conform to standards, compromising the look and feel of the entire interactive environment. We directly address these issues in lecture. In lab, we do not require our students to write the event loop from scratch. Instead we provide a robust event loop as a black box and gradually reveal key components in lecture.
The GUMMI techniques we present are admittedly complex. We do, however, have room for them in the curriculum because we are able to throw away significant amounts of obsolete detail found in a text-based curriculum. For example, we use libraries to implement strings, and avoid all discussion of text formatting. Standard user directed input, output is superseded by our new GUMMI topics. Furthermore, since we provide our own event protocols and handlers to the students for basic user input output, we do not have to introduce all of the horrible detail involved in supporting GUMMIs. This approach is in the same spirit as that at Northeastern[4]. Relevant tools are provided to students to support specific interactive and graphic tasks.
2.4 Story Telling Constituents
The story itself is less critical than the components of a good story. We focus on children's stories because they can be compelling in their simplicity, and they raise interesting design and ethical issues.
The components must include the following. A cast of characters is needed, including a protagonist and an antagonist, with a supporting cast for such things as comic relief. Details of their personality may provide interesting graphics or sound programming. The story must contain conflict, a turning point, and a resolution. Graphics and video can provide details on setting and context. A children's story may, but need not necessarily, include a plot or a moral.
The story should have at least 10 "pages" of main story line. The pages themselves may introduce or reveal characters or setting or advance the plot. An interactive computer-based story allows alternative paths that develop the story from differing perspectives. Pages within an interactive story can also be used to provide elaboration on characters or events. Finally, young children are explorers who delight in finding extraneous detail on a page, for example, inanimate objects that dance when you touch them, flowers that sing, wall hangings that come alive. These do not necessarily contribute to advancing the story, but should contribute to the overall feel of the story line.
The story components are introduced within the context of discussing hypermedia and interactivity. A children's story provides an excellent level of detail for considering how a document can be transformed into a "hyper-document." Since the story is aimed at early readers decisions on how to control interactive components are critical. Although students are expected to understand basic story components, the emphasis is on how the interactivity and hypermedia support the story.
3 An Example Story
Our example story is targeted to a 4 to 7 year old audience and explores the concept of mood and personality. The story is based on a short story by Wolz[9], written for her son. The story is about five year old Henry and the seven little monsters who live in his closet. The monsters include Grumpy Bumpy, The Whiney One, The No! Monster, and The Small Sweet One. The others may be found at our web site [8]. There are four main scenes in our story. In the introductory scene Henry wakes up as one of the monsters (selected by the reader) emerges from the closet, complaining of a rough night because the other monsters misbehaved. Henry is sympathetic and suggests that breakfast will help. In the second scene, a perspective is randomly chosen from a set of seven, one for each monster. At breakfast one of the monsters unintentionally causes trouble. For example the No! Monster won't eat even though it is his favorite cereal. In the third scene the monsters and Henry mess up the play room. A set of five scenes can be explored in any order. The end result is that toys are strewn all over the place. By now Henry is pretty annoyed with all the monsters. In the last scene the user helps Henry and the monsters put the toys away, sorting toys based on some attribute. As they settle down for lunch Henry realizes that all of the personalities are OK, because without them life would be pretty dull.
In developing this story four kinds of flow control were captured that create programming challenges for second semester students. They also provide interesting problems from the standpoint of interactivity. They are:
Figure 1 shows the overall story flow. The scenes are delineated by marked boxes. The scene order presented here works for our story, however the scene types could be rearranged to facilitate other story lines, or some types could appear as secondary plot ellaborations with one of the others. Clearly there are other possible ways to control flow and create interesting interactive problems for students. These lent themselves to our original linear story and covered our curricular goals as well.
User control is typically initiated via "hot spots". These are regions on the screen, that when selected, initiate an event. Hot spots can be used to start small snippets of animation, sound or video that provide story detail or simply add whimsy. Hot spots can lead to "digression loops." A box marked "D" in scene 3 show one such loop. These can provide both interesting story elaboration and programming projects.
Two hot spots occur on each page. At any point in the story the user can exit to the start/exit page. A "go back" hot spot allows the user to reverse direction and return to previously explored pages. The latter activity supports implementation of a stack. Since the path through the story is dynamic, based on user input and a random event, a small stack provides the only reasonable way to keep track of the current invocation of the story.
An interesting design problem that can be left to the students is whether to constrain forward motion after backtracking: if the user reaches a choice point, may a new path be taken or should forward motion be restricted to the previously traversed path? This question brings up some interesting questions about graph traversal.
3.1 User Selects From Choices
The first scene includes the "front page" to the application, allowing the user to enter and exit. Each subsequent page must have a hot spot to return to this page. A second page allows the user to "wake" a monster in the closet who comes out to talk to Henry in scene 1. Students are encouraged to design their own interactive control. They must decide whether the users selects the monster via a hot spot, a pull down menu or some other input device. Finally, the third page in this scene is loaded based on the user selection. Any of these pages may include digression elements.
3.2 A Random Choice Is Made
In the second scene the program randomly selects one of seven pages. Each presents the breakfast scene from the perspective of one of the monsters. At first this flow control seems overly simplistic. However a truly random choice is not necessarily desirable, since in practice a page may appear repeatedly and then not appear for a long time. A priority queue in persistent storage provides a nice solution to creating the appearance of randomness while guaranteeing that all versions appear with a fairly even distribution. The probability lessons that emerge here are also invaluable.
This scene also highlights the special problems of program verification in non-deterministic settings: How can you simultaneously guarantee that the selection algorithm and all possible resulting pages work properly. The approach usually taken by students in CS 2 is to mindlessly rerun their program until all cases happen to come up. The idea of substituting a deterministic algorithm to verify that pages run, and then inserting the randomizing algorithm rarely dawns on them. This problem provides a good example for discussing debugging and verification strategies in lecture. A fascinating discussion question is to ask how you can verify that the selection code does indeed meet the algorithm description.
3.3 A Complete Graph Can Be Explored
The third scene provides an example of non-deterministic flow control. In the third scene, a complete graph of pages can be explored by the user. Only when the user has explored some subset of the pages does a "go on" hot spot become available. Although students may attempt to implement this as a stack, a simple table will suffice to keep track of visited pages.
This scene also presents interesting problems for the "history" feature, namely what does it mean to go back. It also provides fodder for convincing students to fully articulate design before implementation begins. Students may make decisions about what constitutes "history" without considering this part of the problem. Their implementation may not be able to support the flow control in this scene. They may decide to view "going back" as something very different in this scene, creating a special case. The problem lends itself to good discussion on design and implementation trade-offs.
From a story design standpoint this scene is problematical. Any subset of pages must advance the story adequately to go on. This presents an interesting graph covering problem for students to explore intuitively. Our version is very simple. Five pages may be explored, and any three cover two story elements. The first, or entry page covers the first story element in which Henry and the No! Monster start to take toys off the shelf. Each of the other four pages describes how two other monsters interact, increasing the mess in the playroom. An exit page alludes to the activities that occurred on all the pages, thus guaranteeing that regardless of the path taken through the graph, the story will flow into the next scene.
3.4 A Page Is Modified Dynamically
The final scene illustrates how animation techniques can be used to modify the interactivity in a scene. In our attempt to include a sorting algorithm in the project, the final scene is the most contrived from a story telling perspective. This scene involves two pages, with simple flow control. The complexity comes in managing the interactivity and animation. The user chooses a toy attribute (color, size, type) by which to sort the toys that have been scattered around the room. The page dynamically changes using animation functions we provide. The students implement the sorting algorithm. Integrating this page into the project requires inserting animation hooks into their code. An interesting lesson learned here is that the sorting algorithm should be fully debugged before adding the animation hooks. The additional complexity of the animation code slows debugging. It is far easier to study the sorting code in pure form using a debugging tool.
3.5 Divisions of Labor
This project has great potential for stressing division of labor. Students must rely heavily on libraries of objects and functions that we provide. This is an invaluable experience for novice programmers and reinforces the modularity concept. The four scenes can be developed and debugged independently of the others, provided the team members adhere to agreed upon protocols. Digression loops within pages provide another division, as does creating hot spot events that generate animation, sound or video. The history stack can also be implemented independently. Finally, program development utilities, for example, to create frames for animation, can be assigned to individual team members.
4 Project Management Issues
This project provides an exciting vehicle for students to learn to appreciate the complexity of constructing a computer program. The project is well within the ability of a CS 2 student provided its development is carefully monitored by the instructor. This is not an activity that can be assigned and then evaluated weeks later. The activity requires frequent and meaningful contact between an instructor (or skilled assistant) and the students. Furthermore, extensive coding resources including code libraries, graphics, sound and video are also required. This section will address the managerial aspects of this project. A full syllabus as well as libraries for Macintosh and Intel platforms will be maintained at our web site[8].
4.1 Syllabus and Resources
The project is introduced at the beginning of the semester, however students do not begin coding until midterm. We use a flexible lab system where lab and lecture can be interleaved in three 80 minute periods per week on an as needed basis. During the first half of the semester the lecture, lab ratio is approximately 2 to 1. Lectures consist of formal presentations on the requisite data structures, algorithms, software engineering and GUMMI techniques. Minimal time is spent on the story telling components. These are introduced within the context of discussing hypermedia and interactivity.
We also introduce C++. In CS 1 we use a language that is more supportive of the novice programmer[5,7]. We have had experience with both Scheme and Mathematica. We are currently considering Java. Because of our language choice in CS 1 we can focus on abstraction without concern for implementation detail. We introduce abstract data types, recursion and the classic algorithms as tools to be used. These are accessed via libraries in CS 1 and consideration for their implementation is deferred until CS 2. Similarly we can superficially introduce GUMMI techniques instead of standard input output. Because of this emphasis in CS 1, we have the time in CS 2 to introduce a new language and simultaneously consider implementation of abstractions. We deliberately chose C++ because it allows us to get into memory management detail (pointers versus arrays, for example). The programmer is protected from these concerns in more novice friendly languages.
In the first half of CS 2 students practice the skills introduced in lecture through small contained lab projects. They also study a design document for the large project and begin to address implementation issues. Admittedly, the first half of the semester is intense, however students are not expected to gain complete mastery over all of the lecture topics by midterm.
During the second half of the semester the lab, lecture ratio is reversed, with approximately one lecture for every two labs. Lectures are used to review or expand on topics introduced in the first half, to provide detail on programming techniques for the project, and to handle topics and especially problems that emerge during the lab sessions. For example, a lecture might review implementation of the stack data structure, discuss how to practically use it to maintain a history, discuss student solutions to the history problem in the project, and present a novel and elegant solution that a team found. Lectures are also used to create a forum for discussion of ethics, software engineering and team dynamics.
The project requires extensive coding resources. Students cannot hope to complete this project without access to libraries and coding templates. For example, each page in the story is a data structure that includes a link to a background graphics file, as well as the location of hot spots and their resulting action. A page driver function is provided as a library that reads the data structure, establishes the position of hot spots, and manages the event loop that reacts to user activity. The students must write the code that is triggered by the hot spot events, for example allowing the user to select a monster to wake up in the first scene. Although students do not need to program the page manager, they must understand how it works to integrate their code properly.
In the past, the CS 2 project has been implemented in a Macintosh or UNIX environment. During the past two years we have been to creating cross platform tools to support GUMMI on three platforms: Macintosh, Microsoft/Intel, and UNIX[6]. Libraries for Macintosh and Microsoft/Intel are currently available on our web site[8]. Our goal is to make the project platform independent while continuing to require C++ coding. Ideally teams should be able to work on the platform of their choice.
4.2 Creativity and Assessment
The project allows the instructor to balance student creativity and assessment. Student work is evaluated proactively by regular feedback from both the instructor and other students. Regular status reports occur through informal meetings, as more formal team presentations, and as written documents. Students are encouraged to keep journals of group dynamics and code development.
Team members are expected to critique each others' code in order to learn about implementations they did not code. This essential skill is sometimes ignored in the computer science curriculum. We do not expect all of the students in a class to code everything. We do, however, expect them to have reading and comprehension knowledge of all basic components of the completed project. We warn them that the basic programming techniques of the project are fair game for the final exam. Consequently it is in their interest to study algorithm implementations and discuss their merits and shortcomings.
Although a standard story is provided along with all the requisite graphic and sound files, details on particular pages must be developed by the students. For example, students must find good solutions for presenting interactive elements such as dialog boxes. They may add a personal touch through detail elements such as graphic, sound and video clips that respond to hot spots. Teams may also create graphics and sound files. They are free to develop their own stories if they meet the required curricular agenda. The instructor ensures that they do not become overly diverted by these activities.
These diversions motivate very experienced programmers to participate in the project. In years past we have found that such students who have not placed out of the course are not challenged by the small, often highly constrained projects assigned in CS 2. Although they may have sufficient programming skill to complete the project, they do not appreciate the abstraction and software engineering topics central to the course. Only assignment of an alternative project has kept them interested and motivated in the past. Alternative assignments can be incorporated directly into the interactive story, or specific details may be sufficiently interesting to keep experienced programmers motivated.
Grades are not based on the quality of the story, or the sophistication of the graphics and sound files, but reflect the emphasis on data abstractions and algorithm design. Grading for the course is based on formal exams (40%), successful completion of the first half lab assignments (10%), and graded components of the large project (50%). Exams test mastery of algorithm and data structure concepts as well as team dynamics and software engineering. GUMMI techniques are tested within the context of hypermedia and interactivity, and constitute no more than 10% of the exams. Reflective comments on ethical questions are addressed in the individual final report described below. First half lab assignments are submitted by individuals, and are marked as complete or incomplete. The sum of completed labs constitutes the grade.
The lab project grade (50% of the final grade) is divided into the following: Project grade (60%), Group Presentation (10%), Project Documentation (20%), Individual Summary Report (10%). The team receives a single grade for all but the individual summary report, therefore 65% of a student's final grade is based on individual work (40% exams, 10% first half labs, 5% individual summary.) Our experience shows that this model creates a fair balance between strong and weak students on the team project. Since a goal of the course is to teach team dynamics, all students learn that load sharing does not necessarily mean equal achievement. A strong programmer may need to rely on a project leader with good communication skills to keep the project on track and to present it in a favorable light.
The design document for the project clearly states grading criteria. For example to receive a B on the project, all four scenes as well as the user history must be implemented. An A requires including specific GUMMI elements. Extra credit projects are also suggested, such as implementing a utility that can be adopted by other teams. Oral and written presentation skills provide a safety net for projects that suffer from bad team dynamics. For example, a weak member may not deliver on a component, or a strong programmer may ignore protocols and deliver a flashy, but unusable product. Since the grade for documentation and presentation are independent of the program itself, teams can "rescue" the grade of a program that remains buggy at the eleventh hour.
The focus of the course is on collaboration and mutual support. Individual grades are antithetical to that perspective. Although grading policy is clearly stated, it is down-played. Students are expected to keep journals which make final documentation, presentation and individual reporting easier. Pro-active feedback during labs that is not graded provides students with far more useful assessment of their work, and fosters communication skills. Students have ample time to talk about the project among their peers and with the instructor in a non-judgmental manner.
The project outlined here provides a vehicle for preventing blatant plagiarism. An instructor might use a different story each semester, or assign unique stories to each team in a class. Minor modifications to a story's sequence can create significant changes in coding that ensure that students cannot "borrow" code from each other or from students in past semesters. We anticipate supporting multiple story lines on our web site in the future.
5 Summary of Our Experience
This project has been developed over four years as we switched from using Pascal to C++ in CS 2. Software engineering issues have always been a topic in this course. User interface concerns have changed as we moved from text-based to Graphical User Interface environments. We have gradually included discussion of the major GUMMI techniques. Collaborative final projects and discussion of team dynamics have been included within the last three years as well.
A children's interactive story was first implemented by students in a senior level seminar on graphical user interfaces in Spring 1995. In that course, students wrote their own simple stories based on a set of story and programming criteria, including the flow control types presented in section 3. This experience convinced us to provide the story, since it was hard to separate story quality from programming quality. Furthermore students became engrossed in creating elaborate stories and lost sight of the curricular issues. Finally, experience in this course convinced us that we needed to supply students with extensive GUMMI libraries for C++. Programming these "in the raw" requires far too much concern for esoteric, ugly detail. Cross-platform support utilities have since been built for a CS 2 level course[6].
A version of the project based on an elaboration of the game of life was assigned in Academic Year 1995-1996 to approximately 40 students in two sections of CS 2, taught by different instructors. One section used the Macintosh while the other used Sun Workstations, with Solaris and Xterm. The major difference between that project and the one presented here is that the GUMMI requirements were less broad: students used simple dialog boxes for input and displayed graphics results using generic draw utilities. Some teams created full windows environments with pulldown menus and elaborate display bars. However the project did not capture the full range of interactivity and hypermedia of in the project presented here.
Three problems occurred with the game of life project. First, the theme was too open-ended. We gave teams the opportunity to build complex life rules. Some teams became so engrossed in the results that they did not find time to meet basic design requirements. Second, only a few GUMMI techniques were required which barely touched on the important concepts. Most teams completely avoided the event model and produced running programs that were extremely brittle. The children's story poses a variety of GUMMI problems with alternative solutions, and requires the use of the event model. Finally, we were not sufficiently explicit in reinforcing issues of software engineering. Some teams ignored our informal feedback given in lab which impacted on their ability to complete the entire project. Consequently we plan to stress team dynamics and software engineering more directly in lecture.
There were also positive results. Student final exams showed that the essential data structures and algorithms were mastered by almost all of those students who actively participated in the project. Student reports reflected the enthusiasm most had for the project. The energy expended on the project, and the coding and debugging frenzy that occurred as the semester neared its end were fascinating to watch. Even weak teams were fanatically determined to get the project running. The large project was far more compelling than smaller, shorter duration exercises we have assigned in the past. Students became inspired when they could contribute personal creative elements.
Although we did not explicitly test for mastery of software engineering principles, anecdotal evidence suggests that students got the message. A number of groups boxed themselves into corners because they initially ignored advice about good programming practice. Teams were rescued from failure by instructor intervention. For example, the instructor helped a number of groups restructure code that wasn't modular. Modeling analysis and debugging in an informal setting was seen as very valuable by the students because the lesson was immediately relevant to their task. Proactive feedback from the instructor also helped groups cut their losses from bad decisions both at the design and coding level. Rather than give up and submit an incomplete project hoping for a "D", students sincerely tried to produce a respectable result.
The attempt to provide experience in team dynamics was certainly a success. Most teams stayed intact, but a few reorganized themselves for a variety of reasons. In at least one case a single-minded hacker was unable to integrate with the group. The group learned they could produce a solid result without him. He learned that although his project had incredible bells and whistles it did not meet the specifications. He needed the team to keep him on track. Everyone learned that computer science can not be done as well in isolation.
A powerful lesson for students with ability, but lacking discipline, was learning how to pull their weight. It is one thing to make up excuses to oneself or the instructor, quite another to one's peers. Less than 10% of the students who initially enrolled dropped the course formally or disappeared late in the semester. Even students who demonstrated little technical comprehension on the formal final exam actively participated in the project and were able to demonstrate meaningful insight on issues of software engineering and team dynamics.
Individual final reports also provided insight into lessons learned. A surprising outcome for the students was that the strongest programmer was not necessarily the team leader. We did not explicitly require groups to assign this position, however a leader or pair of leaders emerged in each group. To our surprise all three women in one class emerged as the leaders of their respective teams. When asked in the individual reports to reflect on the qualities of group leadership, both the men and women articulated attributes including the ability to promote compromise, create consensus and positively motivate all team members to do their part.
Based on instructor notes, student journals and final reports the unifying project excited our students. It taught them the importance of a modular approach and introduced them to the complexity of multi-media programming. It gave them practical lessons in software engineering and provided invaluable experience in a collaborative effort. The interactive children's story has the potential to enhance our focus on collaborative learning and allow us to fully integrate GUMMI concepts into the CS 2 curriculum.
This work was initially supported by NSF grant DUE-9254109 and more recently by the FIRSL program at The College of New Jersey. We are grateful to Angela Sgroi for her advice on story telling and to Gail Berry for her extensive contributions to the success of the game of life project curriculum. Finally, without Christopher Dunne, the story of Henry and the Closet Monsters would never have been imagined.
1 Felder, R., Felder, G., Mauney, M., Hamrin, C., and Dietz, J. , A Longitudinal Study of Engineering Student Performance and Retention: Gender Differences in Student Performance and Attitudes, Journal of Engineering Education , April, 1995. pp151-163.
2 Martin, C., Murchie-Beyma, E., In Search of Gender Free Paradigms for Computer Science, International Society for Technology in Education, Eugene OR: 1992.
3 Mutchler, D., Laxer, C. Using MultiMedia and GUI Programming in CS 1, SIGCSE Bulletin , Vol 28, Special Issue, 1996. pp 63-65.
4 Proulx, V, K., Rasala, R., Fell, H. Foundations of Computer Science: What are the and how do we tech them?, SIGCSE Bulletin , Vol 28, Special Issue, 1996. pp 42-48.
5 Wolz, U. Language Considerations in a Goal-Centered Approach to CS 1 and CS 2, To appear in the Proceedings of the Consortium for Computing in Small Colleges, Secon Annual Northeastern Conference , April 25, 1997.
6 Wolz, U., Wesigarber, S., Domen, D., McAuliffe, M., Teaching Introductory Programming In The Multi-Media World, SIGCSE Bulletin , Vol 28, Special Issue, 1996. pp 57 - 59
7 Wolz, U. and E. Conjura, Integrating Mathematics And Programming Into A Three Tiered Model For Computer Science Education, SIGCSE Bulletin , Volume 26, no. 1, March 1994 (pp 223 -227
8 Wolz, U., Domen, D., McAuliffe, M., http://www.tcnj.edu/~dummlib/
9 Wolz, U., Henry and the Closet Monsters, unpublished short story, 1996.