The GBS design process

Staff and students (fully identified and described in chapter 6) working in teams at the Institute for the Learning Sciences have built numerous GBSes, with and without INDIE. Based on these projects, we have divided GBS development into the following stages:

1.

Pre-tool: Authors collect information from experts and books in preparation for doing a full design. At this point, they usually work on whiteboards or notebooks. They choose a domain that would make a good GBS, and then choose a scenario within that domain.

2.

Storyboard: Authors concretely envision what the program will look like. Typically they use paper or programs like Powerpoint [Microsoft 1996] to make a linear sequence of screens, each screen showing one or two mouse clicks in the demonstration. Authors start with the scenario introduction--an interesting set of screens and movies that grab a student's attention and sets him or her up to solve the scenario's problem. Tests and remediation are usually quite sketchy, however, with only one or two tests drawn out in storyboards. Remediation is shown happening perhaps once, and authors usually don't yet have a plan for how it will work.

3.

First walkthrough: Authors animate their storyboard, this time doing a higher-fidelity mockup of the interface. For projects not built in a tool, this is often built with Director [Macromedia 1998] or Supercard [Allegiant 1994], with working buttons, some movies, and functional art. The path through the program is still mouse-click to mouse-click and extremely linear, and there are only a few tests implemented and almost no critiquing. Frequently, teams use programmers to build this stage. Some expert video is shot but most of it has not been indexed into the ASK system.

4.

Prototype of first scenario: A nearly-complete scenario is built. Most of the application is designed and approved, but the artifact built often supports only two or three different paths through the content (often corresponding to different demo lengths for different audiences). The application is implemented on the final delivery platform. Tests and critiquing are ironed out (and at this stage, as critiquing becomes more clear, the list of tests and their results usually goes through some upheaval).

5.

Shrinkwrapped system: This is a delivery-level system, called ``shrink-wrapped'' because ideally it could be put on a shelf in a store and sold. Full content is available, all tests are running, the critiquer is complete, and enough supporting material has been entered such that all claims can be successfully supported or disconfirmed.

Applications will go through several iterations within stages and across them--this is not a list of steps, but a list of stages.

An important observation is that frequently projects never get past the first few stages. Students building GBSes for class projects, depending on the project size, have between one and five months to work on a project. This is generally not enough time to build shrinkwrapped systems. Often ILS staff or graduate students build prototypes as research projects or proposals, and after the proposal is demonstrated, the project never gets any further.

Investing time at the beginning of a project in model infrastructure can pay off later when finishing the program. However, if the project isn't going to be finished, why spend the time on infrastructure? This problem was key to the failure of INDIE 1.0.