INDIE has had two major versions. Our approach to building investigate-and-decide GBSes in INDIE 1.0 used fixed knowledge frameworks that authors filled in with information about their topic, such as volcanoes. Tool developers implemented engines that ran on these frameworks and turned them into complete final products.
Most of the INDIE 1.0 tool development effort was focused on making the domain models robust and useful. Authors who had ideas that did not fit into the knowledge structures either changed their ideas or made the INDIE developers change the knowledge structure (and thus forced developers to redesign the engine).
INDIE 1.0, then, focused on the final products rather than on the authoring process. This had seemed successful, more or less, in INDIE's predecessor, GBSB [Bell 1996].2.2
5#5
Our2.3 experiences with INDIE 1.0 (and early implementations of 2.0) showed that authors usually had many problems with the knowledge-based framework. First:
6#6
Every domain INDIE teaches about is structured a little differently. Although the outline of the task is the same--get a problem, run some tests, get some results, make a claim--the structure of the domain is different. Domains vary in many ways, including:
A second major problem with INDIE 1.0 was:
7#7
Many projects are not taken to completion; authors frequently only get as far as demonstrations, prototypes, and even just a series of storyboards. Forcing authors to work inside a strict knowledge framework was inefficient for them. Faced with short deadlines and a tool that could only build complete products, authors working on proposals or prototypes tended to defect to more flexible tools that lacked the knowledge representation they would need when delivering final products.
Thus:
8#8
This means that though the tool should provide useful functionality that lets authors structure and shape their ideas, the tool should not force any one fixed representation on the author. Author-centeredness is not easily attainable. Our experience has been that it is very easy to get in authors' way, usually through over-representing a problem.
The discussions in this thesis, in most cases, start with our attempted implementation in INDIE 1.0, discuss its failing, and then show how we rectified those mistakes in INDIE 2.0. Several innovations led to INDIE 2.0's success, as described below.
As we built applications with INDIE 1.0 in several different domains, we found that each domain needed a different interface. Our solution in INDIE 2.0 was to provide a generic interface builder with an application-wide event-response table.
Events can exist either at the interface level (``Button A was pressed'') or the model level (``The student just got the result of test B''). A response is some interface action, such as a playing a movie or showing a new screen.
9#9
This event/response architecture allows authors to build trivial
interactions
quickly by using only interface events and
responses. If authors want to later fully implement their projects,
they can use the same datafile, art, and interface they had already
laid out, and then re-author their event/response pairs to have new,
model-based events.
In INDIE 2.0, authors could use special model-oriented widgets (called modgits) just as they would a button or other interface-only widget. Modgits had built-in interface and model functionality to act like necessary parts of the interface, such as lists of questions or notebooks full of evidence.
10#10
Modgits let authors put a scalable model in their applications as early as storyboards without inconveniencing them. These modgits were large enough chunks to be useful, but at a level where they would be relevant in every domain. We developed a library of modgits that encompassed the scope of INDIE applications.
INDIE 1.0 had a fixed critiquing model that had a limited set of responses. This model was fairly easy to use to build complete, robust critiquers. In testing it with authors, we found that authors had very precise pedagogical needs--teachers tend to know a fair number of common misconceptions and want to express specific things when students demonstrate them. Our robust critiquer was not powerful enough to give authors the ability to spot these misconceptions and respond to them.
INDIE 2.0 had a rule-based critiquer that let authors provide as little or as much feedback as they felt students needed (or was commensurate with author's level of design; storyboards clearly need less complex critiquing than final projects).
11#11
Although rule-based critiquers are themselves not novel, designing one that was straightforward enough for non-programmers to use and powerful enough to let them do everything they want is more interesting. We chose a rule structure that reflected our author's abilities.
12#12
All of these innovations have had one very important payoff:
13#13
When authors used INDIE 2.0, they didn't need to deal with programmers who generally have no formal educational expertise but require a lot of time and money. Knowledge engineers, guided by the abilities and built-in structure of INDIE 2.0, could work with their domain experts to build software directly. This has eliminated one of the costliest parts of investigate-and-decide GBS development.