05-830, User Interface Software, Spring, 1997
Lecture 14,   April 14, 1997
Copyright © 1997 - Brad Myers

UIMS Techniques 1:
Menu Trees,
Transition Networks,
Grammars

(only about 1/2 hour)

Overview

• The term "User Interface Management System" associated with older systems that represent the dialog of the interface in a formal language.
• Thus, most of the following UIMSs define a special (textual or graphical) language for programming the UI.
• This is primarily only the input from the user to the computer, not the reverse.
  • Human-human dialog is symetric, but not computer-human dialogs
• Original forms were: menu trees, transition networks, grammars, and events.
• Issues: Formal range vs. effective range
  • What can conceivably be represented vs. what is convenient and understandable.

Menu Trees

• Also called "Dialog Trees"
• Hierarchy of menus
• picture, Olsen  UIMS book, p. 116  (Fig 7:1) (Dan R. Olsen, Jr., User Interface Management Systems: Models and Algorithms, Morgan Kaufmann, San Mateo, CA, 1992.)
• Used in Kasik's "TIGER" UIMS, which was used for years to create Boeing's CAD tools
  • Interface is "command-line style" with menus to choose the keywords
    • Prefix
    • Operator defines the parameters that will come
  • Very large number of commands, e.g. 10 ways to draw a circle
  • Special facilities for jumping around the tree, and doing the right sematic actions
  • Aborting commands

Transition Diagrams

• Set of states and set of arcs.
• Probably the earliest UIMS:
  • William Newman's "Reaction Handler" in 1968
• Simplest form, arcs are user input events.
  • arcs can be extended by listing feedback (output) and semantic actions on the arcs
  • actions usually written in a conventional language (e.g. C)
  • picture, Olsen, p. 37 (Fig 3:1)
• Often, represented textually:
  • picture, Olsen p. 38
• Sub-diagrams
  • To help modularize and simplify large networks
  • if call themselves, then "recursive transition network"
    • Picture Olsen, p. 41(Fig 3:4)
  • Problem: when to enter and leave the sub-dialog:
    • don't want to use up a token
• "Pervasive states" to handle help, abort, undo, etc.
  • "Escape" transitions to abort (permanently leave) a dialog
    • picture, Olsen p. 53 (Fig 3:11)
  • "Re-enter" sub-dialogs for temporary excursions that return to same place. E.g., help, use calculator, etc.
    • picture, Olsen p. 55 (Fig 3:12)
  • Transitions are taken if no specific arcs from node
• "Augmented transition networks"
  • local variables
  • function on arcs can determine transitions
  • "guards" determine whether transition is legal
  • "conditional transitions" calculate where to go
    • picture, Olsen p. 57 (Fig 3:14)
  • upgrades the power to context-free-grammar
• Transition Networks, in general, used in various UIMSs:
  • Research: Newman's "reaction handler", Jacob's RTN, Olsen's "Interactive Pushdown Automata", etc.
  • Commercial: IDE's RAPID/USE, Virtual Prototypes's VAPS
  • VAPS uses spreadsheet interface to the ATN
    • Pictures
• Evaluation:
• Good
  • Make explicit the interpretation of all events in each state
  • Emphasize the temporal sequence of user and system actions (unlike grammars)
  • Natural and easily understood if small
    • easy to teach, learn, and read
  • Appropriate for some parts of GUIs: widget behaviors, dialog box transitions, etc.
• Bad
  • Does not scale: 150 commands with 3 or 4 states each
    • explosion of lines and states for normal interfaces: "maze of wires"
  • unordered inputs
    • picture, Olsen p. 91 (Fig 6:1)
  • Textual form is like GOTO-based assembly language
  • Communication through global variables
  • Doesn't handle GUI mode-free style well
  • What to do with un-specified input? crash, ignore input
  • Doesn't address output

Grammars

• Context-free grammars good for describing textual dialogs which have a formal syntax.
  • alphabet of symbols
  • sentences - legal sequences of symbols
  • language - set of all legal sentences
  • grammar - set of terminals, set of non-terminals, set of productions, start symbol
  • context-free-grammar: all productions of the form
    <a> ::= B where <a> is a single nontermimal, and B is a non-empty string of terminals and/or non-terminals
• Example: syntax of Lisp floating point numbers:
  • picture, Lisp book, p 17
• Non-terminals, terminals. Listed in order.
• Iteration by recursion, unless support *, +
• Essentially the same power as STNs, certainly ATNs.
• Eliminates the need to specify a lot of states as in STN
• Attach semantic actions to the parsing of non-terminals
  • But not clear when processed: bottom-up or top-down
• Used in only a few UIMSs:
  • Olsen's "SYNGraph"
    • special features for Undo and Cancel (Rubout)
  • others using YACC+LEX
• Evaluation:
• Good
  • Handles complex dialogs
  • Handles both lexical and syntactic levels
• Bad
  • Unintuitive for developer
  • Hard to know where to attach semantic actions
  • Bad error recovery: can't push forward looking for ";"
  • Doesn't address output
  • Doesn't handle GUI mode-free style well

Back to 05-830 main page