Teachers in Charge: Model-Based Authoring of Educational Software

Keywords:

Introduction AND MOTIVATION

The novel contribution of GBS Builder to HCI is to extend model-based generation of interfaces as it applies to educational software: (1) GBS Builder is a specialized, rather than generic, model-based authoring tool; and (2) GBS Builder generates the interface interactively with the designer, rather than automatically.

BACKGROUND AND RELATED WORK

In applying model-based generation to creating educational software, the key question is: Will these tools generate software that helps teach based on sound educational principles? The answer is no for at least two reasons. First, most model-based generation tools aim for generality, resulting in interfaces with limited, generic styles (usually form- or menu-based). This is because they often use layout rules that map generic domain object types to graphical widgets (e.g. a choice becomes a check box widget [2]). By contrast, educational software may require complex, engaging and highly artistic interfaces, tailored to the specific underlying educational model.

Secondly, easing interface construction by automation gives the designer little control over design decisions [5] and assumes simple, clear-cut mapping between domain objects and interface widgets. By contrast, instructional software may be complex, and have numerous design choices, requiring the human in the loop to design the software successfully. This suggests a need to generate the interface interactively, allowing designers control over intermediate design decisions, while shielding them from low-level detail. GOAL-BASED SCENARIO BUILDER The central tenet of Goal-Based Scenarios is that skills are best learned in the context of performing a task [9]. In educational software based on the GBS model, the student assumes a simulated role, performs a task, and as a byproduct, acquires the intended skills and concepts. Currently, GBS Builder embodies a specialized model of Goal-Based Scenarios, where the mission of the student is specialized to investigation tasks (as opposed to design or simulation tasks, say).

We illustrate the key features of Goal-Based Scenario Builder in terms of an example of a prototype GBS authored with the tool by a pair of middle school teachers. The teachers wanted to build a GBS to teach chemistry skills and concepts, and decided to create an "Arson Investigator" GBS, where the student, as a forensic chemist, helps investigate the cause of a fire.

GBS Builder is a specialized, rather than generic, authoring tool. GBS Builder embodies a specific educational model, an interface tailored to that model, and an exemplar piece of software of that model. The model provides an overview of what the software is intended to achieve. The investigative GBS model is divided into five phases: Problem: providing the student with their role and task; Do: performing the investigation; Decide: forming conclusions; Communicate: conveying a decision; and Wrap-Up: seeing the consequences of the investigation and decision. The interface is designed to help the student play their simulated role and perform their task through viewing movies, running animations, and asking questions of videotaped experts when needed. To provide an overview of how the interface relates to the model, the tool provides a map of how each graphical screen fits into a phase and its subphases. The tool also provides design rationale to explain how each screen component fits into the whole. The exemplar piece of the software makes all this concrete. The exemplar currently in the tool is a "Sickle Cell Counselor" GBS [1], where the student assumes the role of a genetics counselor, advising clients about the risks of the disease for their offspring.

The teachers authored "Arson Investigator" by copying and editing sections of "Sickle Cell Counselor" (e.g., instead of taking blood to determine the presence of a Sickle Cell gene, the chemist takes a drape sample to test for the presence of an accelerant). They were aware, through the map, of how the interface was linked to the model (e.g., sampling a piece of drape was linked to the `extract sample' subphase of the `Do' phase).

GBS Builder generates the interface interactively with the designer, rather than automatically. The teachers built each phase of the GBS by filling out each screen and component with appropriate content (e.g. a movie of how a drape sample is collected) using the model and exemplar as guide. This is in contrast to working solely with the model and then generating the interface automatically after the fact.

EVALUATION AND CONCLUSION

Next, we performed early user testing with a group of nine elementary and middle school teachers from the Wilmette school district in suburban Chicago. These teachers used the tool to build, in pairs, four prototype GBS's in two months. This time we did not provide the teachers with a facility to make unconstrained changes to their GBS. As a result, all four GBS's kept to the model of investigative GBS. Through focus groups, surveys, and informal interaction, we learned that although the teachers found the guidance of an exemplar extremely helpful, they also felt constrained by it. That led us to redesign the tool to allow minor cosmetic changes which would not change the gist of the GBS, and provide more, and varied, exemplars. We also learned that editing the interface while providing a link to the model does not always provide a sufficient overview. We are now providing some high-level design facilities separate from the interface (e.g. a causal map of the Investigation).

Goal-Based Scenario Builder is one step towards putting educators back in charge of education, in order to improve education.

Acknowledgments