Transition diagrams

Menu trees are incomplete because they do not show the entire structure of pos-sible user actions! such as returns to the previous menu, jumps to the starting menu! or detours to error handling or help screens. This is as adding all these transitions would clutter the clean structure of a menu tree. However, for some aspects of the design process! more precise specification of every possi-ble transition is required. Also, for many nonmenu interaction styles, there is a set of possible states and permissible transitions among the states that may not form a tree structure. For these and other circumstances, a more general design notation, known astransition diagrams,has been used widely.

Typically! a transition diagram has a set ofnodesthat represent system states and a set oflinksbetween the nodes that represent possible transitions. Each link is labeled with the user action that selects that link and possible computer responses. The simple transition diagram in Figure 5.1 (Wasserman and Shew-make, 1985) represents a numbered menu-selection system for restaurant reviews that shows happens when the user selects numbered choices: 1 (add a restaurant to the list), 2 (provide a review of a restaurant), 3 (read a

+

3D" '1'

'3'

Figure 5.1

Transition diagram for a simple menu system. (Wasserman and Shewmake, 1985.)

review), 4 (get help, also accessed by a?), 5 (quit), or any other character (error message). Figure 5.2 shows its text form. Figure 5.3 shows another form of tran-sition diagram that displays frequencies along the links.

Many forms of transition diagrams have been created with special notations to fit the needs of specific application areas, such as e-commerce or word pro-cessing. Tools for creating and maintaining transition diagrams, dataflow dia-grams, and other graphical displays are part of most software design tools, such as the IBM Rational Suite of products. In most systems, the diagrams are created by direct-manipulation actions, but designers can get textual outputs of the tran-sition diagrams as well.

Unfortunately, transition diagrams get unwieldy as system complexity grows, and too many transitions can lead to complex spaghetti-like displays.

One improvement is to replace a state transition node 'with a screen print, to give readers a better sense of movement through the displays and dialog boxes. Such overviews are helpful in design and in training.

Designs for interfaces with hundreds of dialog boxes, or for web sites with hun-dreds of screens, are easier to study when hung on the wall. In one memorable

node start

cs, r2, rv, C_' Interactive Restaurant Guide' ( SV, r6, c5, 'Please make a choice:

r+2, c10, '1: Add new restaurant to database', r+2, clO, '2: Give review of a restaurant

r+2, clOt '3: Read reviews for a given restaurant',

r+2, clO, '4: Help't r+2, clO, '5: Quit', r+3,cS, 'Your choice:

node help

CSt r5, cO, 'This program stores and retrieves information on', r+l, cO, 'restaurants, with emphasis on San f,

1, cO1 IYou can add or update information about restaurantsI1

r+l, cO, 'already in the database, or obtain information about' r+l, cO, 'restaurants, including the reviews of others.', r+2, cO, 'To continue, type RETURN.'

node error

r$-l, rv, 'Illegal sv, 'Please type a number from 1 to 1 /

r$, 'Press RETURN to continue.' node clean

r$-l, cl,r$,cl node

r$,cl,rv, 'Please make a choice',sv, tomark_A node quit

cs, 'Thank you very much. Please try this program again', nl, 'and continue to add information on restaurants.' arc start single_key

Text form of Fig. 5.1. Additional information is providedbythe comment lines.

350 of a satellite-control system were pasted on three walls of a room, revealing the disparate styles of the design teams of the six modules, overvie'w diagrams may be squeezed onto a single sheet of

for manuals, or printed as a poster to hang on users' walls.

0.05

Figure 5.3

Sample transition diagram fortile-manipulation actions. Link labels indicate how fre-quently each transition is made.

Transition diagrams translate directly into finite-state automata, which are well studied in computer science. Several properties can be verified automati-cally, such as reachability (is there a possible path to reach all states?) or liveli-ness there a way out from all states?). However, user-centered properties such as the visibility of system status are notoriously hard to express and verify in terms of automata (Dix et a1., 1998).

5.2.4

Although transition diagrams are effective for following flow or action and for keeping track of the current state and current options, they can rapidly become large and confusing. Modularity is possible if nodes are included with sub-graphs, but this strategy works well only with orderly, one-in, one-out graphs.

Transition diagrams also become confusing when each node must show links to a help state, jumps back to the previous or start state, and a quit state. Concur-rency and synchronization are poorly represented by transition diagrams, although some variations, such as petri-nets, can help. An appealing alternative is stateclzarts (Hare!, 1988), which have several virtues in specifying interfaces.

Because a grouping feature is offered through nested roundtangles (Fig. 5.4), repeated transitions can be factored out to the surrounding roundtangle.

Extensions to statecharts-such as concurrency, external interrupt events, and user actions-are represented in Ilogix's Statemate, is a user-interface tool

based on statecharts. The Unified Modeling Language (UML), an emerging industry standard for visualizing and documenting software systems (Booch et a1.,1998) also uses statecharts to specify the behavior of general programs; thus they should be familiar to software engineers.

Statecharts can also be extended with dataflow and constraint specification, plus embedded screen prints to show the visual states of graphical widgets (Carr,1994). For example, in the simple case of a secure toggle switch there are five states, so showing the visual feedback on the statechart with triggering events on the arcs helps readers to understand what is happening (Fig. 5.5).

Specifications are useful to ensure consistency between the design of the user interface and its implementation, but they would become more widely used if they were linked to interface-building tools. Linking specifications to building tools and evaluation tools has been the goal of user-interface management sys-tems (Myers,1995)and model-based systems (Szekely,1996).However, this goal has not yet been achieved, and most model-based systems remain academic prototypes. Novel approaches are still appearing, such as "scenario-based pro-gramming," which is based on specifying scenarios of behavior from widget-level formal specification of interface actions and feedback (Harel and Marelly, 2003). This system allows designers to create dialog boxes with graphic ele-ments and then specify how user actions generate system changes. They can also specify what scenarios are allowed or forbidden, allowing these specifica-tions to be tested against the final implementation.

Banktransactions enter

Figure 5.4

Statechart of simplified bank transaction system showing grouping of states.