INDIE 1.0: A model-driven approach

The first iteration of INDIE had a strong model of the tasks in a diagnosis scenario. The model was divided into several different modules:

• The Problem Selector: The students (or the application itself) choose a scenario to work on--in Volcano, it was which mountain to investigate, a decision the characters in the story made for the students.

• The Lab: The students run tests and talk to experts in the field, collecting information.

• The Argument Constructor: The students make a claim to the clients in the simulation, suggesting a course of action or a diagnosis (e.g., ``The volcano is going to erupt tomorrow.'')

• The Critiquer: The students hear feedback from the client, telling them what they did wrong and letting them ask questions about their mistakes.

Each one of these modules had a default interface layout, one or two ``screens'' for each. There were specific buttons for each kind of interaction--one button per scenario, one button per possible thing to say back to the client, and so forth. If authors wanted to add a scenario button, they would edit the problem-selection module to add another scenario, and a button would be automatically added to the scenario-selection screen.

A programmer (or a computer-savvy author) could edit the interface exclusively by modifying a LISP file that contained positions and sizes of each class of button. Art could be added there as well. Our goal was to automatically supply the interface so that authors could concentrate on the content--a template approach taken from work on GBS tools preceding INDIE's development [Korcuska 1998,Bell 1996].

 

Figure 4.1: A sample of the interface definition for Immunology's main page.

42#42

Authors found INDIE 1.0 very restrictive for several reasons. First, the tool built applications that didn't look the way they wanted them to look, and changing that ``look'' required the INDIE programming team to reprogram the interface.

More importantly, building the modules' model representations didn't work well. Authors, who had been drawing screens on paper and Powerpoint in the late stages of the idea phase, were suddenly forced to understand the INDIE model representation and construct objects in it. For example, in a walkthrough, to make a test show a result when run, authors had to explicitly construct:

• a test (such as electrophoresis)

• a scenario (such as a patient with sickle cell anemia)

• a prop that could be tested (such as a drop of blood)

• a table that specifies the results that occur when the student runs this test on this prop in this scenario

Unfortunately, all that the authors wanted to say was, ``When this button is pressed, play this movie.'' It seemed backwards to authors to build a program from the model outward to the interface. Defining interactions in the model (such as the results of tests, the relationship between available help and the tests, and getting critiquing running) required a fair amount of time, yet authors frequently rebuilt them due to design changes. In other words, rapid prototyping was difficult. Thus, design iterations took full-time consulting from the INDIE programming team and much planning by authors.

On one project slated to use this version of INDIE, project-assigned programmers built an interactive walkthrough in Supercard rather than INDIE. The walkthrough had no model. They did this because, like all teams, they had a limited amount of time, and it was easier and faster to mock something up in Supercard than to use INDIE.^9.1