Additional model actions

To say that authors were satisfied with just the interface manipulations that triggers allow is a bit misleading. Yes, triggers did everything authors asked, but INDIE developers added quite a bit to triggers in the form of model actions (Chapter 5). Model actions happened to be a convenient place for INDIE developers to add small bits of interface code that may or may not be used in other applications.

The list of these interface-only ``non-model model actions'' can be broken into two major classes. First, there are those that were needed for one or two interactions but were genuine extensions:

• Set and Reset Cursor Model Actions: On, say, a button click, authors can have the cursor turn into a specified icon like a thermometer or hypodermic needle.

• Pop Button Model Action: This takes a group of ``radio'' buttons (buttons that cannot be pressed at the same time) and unselects all of them. This was used often to restore state after a student finishes a scenario or resets the game. It can also be used to push any one button in a group.

• Toggle Model Action: This sets a group of two-state buttons to look pressed or unpressed (or some combination of the two). Authors used this, like the Pop Model Action, for restoring interface state for new scenarios.

These actions are reusable from project to project (and most of them were), and were entirely normal, even if they weren't really ``model'' actions. INDIE developers could have easily put these in a separate category from model actions called, for example, ``Additional interface actions'' and separated non-model model actions from model actions. We didn't mostly because authors generally didn't find it confusing.

The second class of these extensions are those that keep track of some sort of state in the GBS that isn't in the model and was necessary for some specific part of a particular GBS:

• Push Most Recently Pushed Model Action: This model action is a counteraction to the ``pop'' model action, which makes the radio button most recently pushed look pushed. Nutrition authors felt they needed this extension because they had multiple entry points to the ASK system. If students had browsed the ASK system from the top level general topics, the zoomer (or topic) buttons looked pushed to indicate how the student had found that part of the ASK system. Students could also look into the ASK system for specific topics in a just-in-time manner, such as reading up on ``Alcohol'' while supporting a claim about the patient's drinking habits.

  Authors wanted students to be able to use the just-in-time help separately from their top-level zoomer, so students wouldn't lose their place when treating the ASK system like a textbook even while looking specifics up as if it were a reference manual.

• Click Leftmost Active Argument Tab Model Action: One designer wanted the program to open the folder automatically to the first claim the student had chosen to work on in a multi-argument system. If the student chose more than one argument to start work on, which one should it pick? We decided to default to opening the argument whose tab was farthest to the left on screen, and thus this model action came into existence--it simulated a ``click'' on the leftmost active argument tab. Since this is extremely specific to that application's interface, over half the code involved in writing this model action was to produce readable errors for authors when they used the action in the wrong sort of interface.

• Video To Text Model Action: Medical students tend to be fairly busy, and doctors even more so, and video is a slow way to transmit information. Authors in Nutrition requested that the student be able to click between video mode and text summary for any answer. This model action should have probably been made part of the answer-viewer modgit, except that this allowed artists to make the video-to-text button blend in better with the surrounding environment.

The last action (video-to-text) is purely an interface matter, but the first two imply that INDIE wasn't keeping track of what task the student is doing. Students' actions are semantically meaningful to the interface--they are either browsing the ASK system from the top level and need a trail of bookmarks, or they are jumping to a specific place. A proposal for a task-tracking interface in INDIE is discussed in Chapter 8.