Layers were extremely useful to authors. They used layers frequently, far exceeding our original expectations. For technical reasons and convenience, authors usually had one main window with many layers. The layers are listed in a flat list.
|
How many layers did authors use? Table 6.2 summarizes results from several different applications. As we look at this table, we realize that in all of them except Volcano, there are just about exactly five graphical objects (i.e., widgets, windows, layers, and modgits) for every layer even as the total number of objects varied widely. (Note that Nutrition's prototype status and Immunology, also a prototype, share a similar interface and thus have similar numbers of graphical objects and layers). This implies that layer complexity was related to interface complexity.
Both Nutrition and Rembrandt had so many layers that the standard layer-browser was so large it would not entirely fit on the screen, which was not our expectation. Volcano, with its 2-to-1 ratio of graphical objects to layers was not far behind.
After looking at how authors ended up using layers, we can divide these exceedingly numerous layers into two categories:
Since there are 8 different screens on which notes can appear, this means there are 8 different yellow answer-viewers. Each one is listed on the flat list at all times, but they are rarely relevant at the same time, adding a lot of clutter to the screen and making it hard for authors to visualize layer interactions.
As seen in Figure 6.1, Nutrition authors created order on the flat list by listing the ``parents'' of each layer as part of their lineage, e.g. ``Compile:Iron:Iron feedback.''
For example, Nutrition authors wanted their testing phase to present a cheap screening test for diabetes (a 1 hour glucose challenge), and then if the patient fails it, give students the option of running a more expensive (but more accurate) test. Students normally accessed this expensive test on a pulldown menu. Authors wanted the more expensive test available only after students have done the cheap test.
Authors were forced to make two different pulldown menus, one with one expensive test available and one with the cheap test. Authors put the two menus on different layers. When students run the cheap test, if the patient fails it, it puts up the menu with the expensive test. The ``show most recently shown layer'' feature of triggers allowed navigation buttons to show one or the other. Thus, authors were using the interface (which layer was last shown) to keep track of what is really part of the model (which experiments the student has run). Volcano had trouble with this in its in-depth procedural experiment interaction (first put on the gas mask, then pick up the sampling device, etc., each step of which was a new layer).
This approach adds yet another layer to the flat list (as well as many repetitive widgets). For most GBSes, this sort of layer showing-and-hiding didn't get completely out of hand--if authors had to make more than a handful of these conditional layers for any particular situation, INDIE developers tended to grow the model somewhat to accommodate whatever conditionality authors needed. However, each single situation added to the explosion of layers.
Layers, then, were a mixed success--they did let authors quickly construct interfaces they liked, but as the interface grew complex, they tended to be more difficult to manage and sometimes took the place of a student model. In Chapter 8, we will examine ways that might help reduce ``layer clutter.''