Who would you rather have decide what's wrong with your sick child? A first-time doctor who had passed a written test about disease treatment, or a first-time doctor who had done several hundred similar realistic diagnoses in a ``diagnosis simulator?''
One can see intuitively that for many domains, students should be working in environments where students are performing the same tasks as they would have if they were experts instead of students. This approach to learning environments, called authentic environments, has been suggested in literature as early as the start of the 20th century [Farnham-Diggory 1992].
Naturally, throwing students into authentic environments without any
help wouldn't necessarily be a good learning
experience--for example, one needs to have access to information
about medicine when learning how to be a doctor. Students need
frequent help, such as asking questions to experts (a sort of apprenticeship arrangement [Collins, Brown, and Newman 1989]). They also need
tasks where they will encounter new and interesting problems. In our
diagnosis simulator, one would like students to run into a large
number of different cases, so that any real-life diagnosis they
have to do is likely to be just like a diagnosis they have done in
simulation [Kolodner and Jona 1991].
Computers have the potential to be platforms for this kind of learning environment. Computers are reactive, infinitely patient, provide fast access to knowledge, and can (with hard work by the designer) bring joy and interest to a student.
One kind of software that fits the description above is called a ``Goal Based Scenario'' (GBS) [Schank et al. 1993]. In a GBS, students are put in the role of someone who has a task that they need to accomplish and an authentic simulated environment in which to work. Students have access to experts at every step of their work. Our ``diagnosis simulator'' is a kind of GBS--students are put in the role of a real doctor who has a sick patient that they need to diagnose. They can ask questions of other doctors as they do it, and the patient responds in a realistic way to the doctor's questions and tests.
We can further define a subclass of educational software: diagnosis problems, or ``investigate-and-decide,'' where students need to examine the facts in a case, then marshal them to make some decision. Examples besides medicine include predicting future volcano and weather behavior, determining whether or not a painting is a forgery, figuring out why a car won't start, and even auditing paperwork. In all of these, students spend a large part of their time working on the case while talking with experts to find out how the domain works (such understanding geology or weather).
For such educational software to have any noticeable impact on education, however, educators need to build tens of thousands of diagnosis GBSes in thousands of domains. In the field of medicine alone, students would need GBSes with numerous cases in all medical specialties. Unfortunately, building such a large number of GBSes hasn't been possible. Building GBSes is a long, delicate dance between educators, experts (such as doctors or scientists), artists, and programmers.
From the experience of the Institute for the Learning Sciences (ILS), it can take several years and hundreds of thousands of dollars to build a GBS. [Bareiss 1998] Thus, if we want to affect the educational landscape in a major way, we need to develop cheaper ways to build such software than inventing each program individually from scratch.
One way to speed up development is to come up with software tools that structure and automate the development of GBSes. INDIE, the software that is the central subject of this dissertation, is such a tool. When we say ``tool,'' we mean a piece of software that takes content (the knowledge that authors have about a domain) and interface elements (pictures, movies, and layouts) and produces a standalone program that students can use.
| 3#3 |
Many available applications fit this description of a tool, including simply a programming language and a compiler. Since this tool needs to be broadly accessible, however, we must expand our audience to non-programmers. In INDIE's case, our audience was professional GBS-building staff and graduate students at ILS.