Interacting with the tool

Authors take the content they have gathered using other tools (such as paper, word processors, video cameras, and spreadsheets), and enter it into INDIE. INDIE then outputs a structured object database (or a complete application) representing all the content (Figure 3.1). This contains questions, answers, pointers to pictures (stored elsewhere on a hard disk, network, or CD-ROM), pointers to movies (also stored elsewhere), an interface, and the objects that define the interactions between all of these parts.

  

Figure 3.1: The flow of interaction with INDIE. Authors work with the tool, which then outputs an object database that is used by the INDIE engine.

3#3

The goals of the INDIE tool are to help authors:

• Construct interfaces: Authors can put together the look and feel of their application so they can test and demonstrate it without writing code by using the built-in interface builder. Once the interface is tested and edited, they can use it by running it with an interface executor. They are able to use this interface in the final application without any reimplementation.

• Enter and keep track of data: Authors are able to add content incrementally without losing sight of their end product. This means providing good database tools for entering, organizing, cataloging, and finding individual pieces of information quickly.

• Structure the student's interaction: A good GBS tool comes with a model of a particular interaction--in INDIE's case, it is that students will explore a virtual world, collect facts, and submit reports to a client, and along the way hear experts tell stories relevant to what they're doing. The tool suggests types and classes of information that authors need to collect and fill in.

Not having these facilities would cost time, accuracy, and effort and might render a project incapable of being completed.