CS789, Spring 2005

Lecture notes, Week 7

Dialogues, prompts, commands

Dialogue Styles

Baecker and Buxton's list of dialogue styles:

1. Action/reponse (AR). The user provides a series of commands, using command keys, and the system shows the result of each command as it's received. Examples; vi, emacs, ATM, locomotive console
2. Command line (CL). The user provides a typed or handwritten command, one line long, written in a specific input language. The interface is a command interpreter. Examples; DOS, Unix.
3. Programming language (PL). The user provides a program, written in a programming language. The interface is a program interpreter. Examples: TeX, Unix shell.
4. Natural language (NL). The user converses with the interface using a human language. The interface is an interlocutor, who accepts requests and provides feedback. Examples: Bell directory assistance, automated bus schedules.
5. Menu (MU). The user selects interface actions that are made available in lists called menus. The interface presents options, and carries them out on request. Examples: word processors, spreadsheets.
6. Form filling (FF). The user supplies data for different fields of a schema, using spatially separated locations on a display. The interface presents the locations, along with prompts, then processes it and provides feedback. Examples. spreadsheets, travel reservation systems.
7. Iconic (IC). The user gets information from the system as icons, small pictures that stand for interface entities. The interface arranges icons to show things about the system, and provides some operations on the icons. Examples. closed windows under X.
8. Direct manipulation (DM). The user manipulates iconic representations as though they are objects, but at a level of abstraction. The interface interprets user manipulations as actions to be performed on the system and provides state feedback iconically. Example. the Macintosh finder.
9. Graphical interaction (GI). The user handles and changes objects using the physical properties they exhibit on the display. The system changes its internal data structures accordingly. Examples. Adobe Illustrator, Xfig.
10. Window (WS). The user interacts with several interfaces at the same time. They are presented on a single display surface, isolated spatially one from another. The interface channels input and output to the appropriate interface, allowing the user to engage in several activities at once. Examples. X, Windows.

Classifying Dialogue Styles

1. Different points of view yield different classifications. For example,
   1. vi is a AR interface.
   2. vi is a PL interface. The program is created while editting by a syntax-directed editor, and executed as a result of the ":w" command.
   3. vi is a FF interface.
   4. Some seem more contrived than others. One of the most contrived, the second is probably the most accurate description of vi semantics. E.g. What does the compiler compile?
2. Interfaces are collections of components, each of which may use a different dialogue style. For example, a typical spreadsheet has
   • windows,
   • forms,
   • menus,
   • commands, etc.
3. The classification is neither exhaustive, nor multually exclusive, nor orthgonal

Families of similar dialogue styles

• Command/response (obvious turn-taking, based on command trigger input semantics): AR, CL, PL, NL, MU, FF
• Handle directly (continuous response, based on measure input semantics): IC, DM, GI. The programmer knows that there still is a command response loop, but it had better be kept small enough that the user doesn't notice it.
• Difference between menus and direct manipulation:
  • Menus: pointing is just a substitute for typing, with recall replaced by recognition
  • Direct manipulation: act directly on a graphical representation that shares appropriate characteristics, (e.g., length if we are going to elongate.), using recall rather than recognition.
  • Palettes: menus that determine manipulation type, substituting recognition for recall in some direct manipulation tasks.
  • Window systems are outside this classification.

Some Ways that Dialogue Styles Vary

1. Chunk size (increasing):
   • AR, MU, CL, NL, FF, PL. Here chunk size indicates the granularity of the exchange of control. Menus are at most phrases, but programming languages lecture! That is, granularity is temporal.
   • GI, DM, IC. We can get at graphical objects at very fine granularity, sometimes even with a magnifiying glass. Icons, at the other extreme, have no internal structure to get at. Here granularity is spatial.
2. Recognition/recall (recall increasing):
   • MU, NL, FF, PL, CL, AR. Natural language is assumed to have the complexity of human discourse, where we get continuous feedback as to whether or not we are being understood. Programming language interfaces at least break the making sense or not transaction into more than one step.
   • DM, IC, GI. To what extent are the possible operations explicitly exhibited by the interface? Is it systematic from style to style in the continuous response styles?
3. Output parallellism: the amount you can perceive at once, the independence of perception on order (parallelism increasing)
   • PL, CL, NL -- order is not under user control
   • MU, AR, IC -- partial information displayed at a time, order under user control
   • DM, GI -- as much information as possible displayed at a time.
4. Input parallellism: the number of different things you can do at once, the independence of state on input order (parallelism increasing)
   • PL, CL, MU, AR -- one thing at a time, complete one before starting another
   • NL, IC -- depend on multiple meanings encoded in language, on concurrently existing organizational schemes for icons
   • DM, GI -- input complexity limits doing several things at once.
5. History/state (state increasing):
   • (NL PL CL) FF (MU DM IC GI) Menu interfaces are examples where the history is usually completely destroyed with every operation. The exceptions occur in browsers, where history is so important that it is stored in menus, which look like little "glass teletypes".

Desirable Characteristics for Dialogues

Dialogues are, by their nature, extended. We must consider them in their entirety. In this sense there are a variety of properties that should be possessed by a dialogue, taken as a whole.

• Syntax. Parts of a dialogue acquire their meaning by virtue of their relationship to other parts. A little bit of knowledge can be combined into a great many different meanings.
• Reference. Components of dialogues refer, sometimes to things inside the system, sometimes to things outside the system. Reference depends on context. Context is created, in part, by earlier portions of the dialogue.
• Consistency. Things that happen in one context create expectations about how they will happen in other contexts. When such conditions are met we award the buzz-word "consistency". There is, however, no metric for consistency that is independent of human judgment, and it's easy to create examples where two consistency arguments contradict one another. Example, traffic sign on Dixie Road. Consistency can also get you into trouble. Quit buttons, for example.
• Congruence. Much meaning is created by analogy, often called metaphor in the user interface community. What English scholars call "not mixing your metaphors" lies very close to what is meant by congruence. For example, if you "enter" an application, you should "exit" from it; if you "start" an application you should "end" it; if you "open" an application, you should "close" it.

Structuring the Command Set

All the desirable characteristics above depend on structure in the interface.

The categories introduced below have significant overlap, and it is often possible to put an instance of a command into more than one category. This is similar to the matter of interpretation applied above to dialogue styles.

Building up syntactic structure

1. Command alone
   • unique command for each action to be carried out: e.g. "pwd", "whoami"
   • incorporate consistency, congruence, e.g., open/close for all applications (Note important role of UI toolboxes.)
   • Build commands from reusable parts as much as possible. e..g, rm, rmdir, lprm, and lprm, lpr, lpq.
2. Command plus arguments
   • Arguments are like objects of verbs (commands). There is an implied subject "you", which is who?
   • There are direct objects, e.g., "ls courses".
   • There are indirect objects, e.g., "ln courses/cs789 interaction". Note reversal of linguistic order. Possibly the notion of indirect object is not as good a one as the idea of many objects that have relationships to the verb denoted by prepositions. (Too bad Latin and Greek are now so seldomly taught.) Some prepositions are allowed with a given verb; others are not. A small subset of these relationships are denoted syntactically by indirect objects of differing types. This differs from one language to another.
   • The argument type sometimes modifies command semantics, e.g. "mv aaa bbb" when bbb is a directory or file. This is like natural language: "run a business" is a different run from "run in a race".
3. Commands plus options
   • Options are like adverbs. They modify verbs or verb phrases. E.g. "ls -l tmp".
   • In natural language context and position affect what is modified. E.g. "lpr -Pslate doc1 -Prubble doc2"

The benefit of command structuring is that it adds to the command repertoire (system richness) with minimal cost in terms of extra memory overhead for the user. To gain benefit from command structuring it is necessary that structuring principles should maximize congruency and consistency.

There is a variety of results that show desirable ways of structuring commands. Here are a few examples.

1. How should components be ordered?
   • Command (verb) first. Experiments show that this is best, but probably not for direct manipulation interfaces.
   • Options and arguments can be mixed
     • sometimes order matters, e.g. cc -o prog prog.c -lm, cp a.out xxxx
     • sometimes it doesn't, e.g. lpr -Pps News -h
     The observed complexity mirrors the complexity of natural language. How is this complexity handled in English? Is there a similar feature in command language interfaces?
   • Note the ambiguous role of options. Adverbs in English modify either verbs alone or verb phrases. Sometimes we would like to write "Shovel the sidewalk right away and the driveway later."
2. Arguments have distinct roles, usually indicated by ordering
   • argument multiplicity, e.g. cp aa bb cc dd.
     • Multiple arguments change the command semantics.
     • We can apply different options to different arguments, e.g. lpr -Fd aaa -Ft bbb. Here options clearly modify phrases.
   • argument ordering
     • Typical is from/to ordering. This is different from English, and had better be consistent
     • Compare "copy aaa bbb" with "overwrite bbb aaa" . Which is better? the consistent one! But how is consistency defined?
       • linguistically natural: based on linguistic distinction between arguments, e.g. direct, indirect object. (Which pairs of words go naturally together?)
       • congruency, which depends on the whole command set. Set up a systematic abstraction for argument positions, e.g. source, destination. Then choose command words that express the abstraction.
       • Obviously we should always (!) have both, but when there is a conflict the winner is congruency, by all measures (error rates, command times, help requests)
   • position versus keywords
     • Compare "copy aaa bbb" (no keywords) with "copy from aaa to bbb" (keywords). (Have to control the amount of typing, of course.)
     • Keywords win: most with novices, quite a bit with frequent users
     • It means that if you have typing to spare , put it into keywords rather than commands. If typing is not at issue, as in forms & menus, then put in keywords.
3. Command structure. This is like asking about processor architecture. But instead of asking "What is easy to implement in hardware?" or "Into what can we easily compile?" we are asking "What is easy for a user to understand?"
   • Hierarchies, orthogonal structures, regular expressions, grammars
   • Relationship to command implementation. E.g., how would you implement each structure? Menus, forms, state machines, parse trees?

---

Form-filling dialogues

Definition: fill in the blanks, then send

• System processes input, then responds.
  • Think about prompt, echo, trigger, acknowledgement
  • How big are the units?
  • Forms within forms
• Dialogue boxes are forms.
  • Filling is minimal.
• Forms are integrators of information
  • They encode values that are simultaneously valid and, at least implicitly, the relationships between values.

Characteristics of forms:

1. good for structured input
   • user understands the structure, which is made only partly explicit. (How is it made explicit? What parts are explicit? What parts of the structure in the information are implicit?)
2. can have complex remote semantics using very simple local semantics
   • forms can usually be handled by the lowest common denominator of the possible output devices, like html.
3. can effectively split different levels of processing
   • E.g., typos handled locally, meaning handled remotely; consistency between postal code address and phone number handled locally, package assembled remotely.
   • What do you have to do in order to do the local processing implied by these divisions?
   • depends on the amount of context that is put into the interface
4. novice reads prompts; expert uses position

Questions/comments about forms:

1. How can forms be changed inexpensively?
   • forms are distributed, change by broadcast: the interface usually controls the broadcast channels, can force the local interface components to pay attention; cost can be calculated
   • user knowledge & familiarity with a set of forms is also distributed: the interface only owns the broadcast channels if the users are all slaves to a single organization; cost is born by the user, and often is ignored
2. Forms coexist well with other dialogue styles.
   • What indicates the need for a form?

Design of forms

• Extensively studied
  • not by interface people
  • for paper forms

  Note the incentives for making forms clear.

• Key is to show relationships between entries
  • reduces errors
  • limits text on the form

  How is this done?

  • geometry - things "close together" are related
  • colour - things the same in colour are related
  • visual texture - like colour

Menus

What are menus? A method of presenting a list of alternatives, usually integrated with a method of selecting among them. (What are the presentation and selection methods in a restaurant? In a supermarket?)

The essence of the user's task:

1. search
2. discriminate/choose
3. select: communicate choice to the system

Why might menus be useful?

1. Allow user to find a command, suggestion
2. Allow user to find the right form of a command, correction
3. Faster than other methods of command input
   • We know this not to be true. How?
   • Or do we? When do the odds change?

Issues in menu design

1. Which commands should be in menus?
2. Where should the commands be?
3. How should the commands be represented?
4. What style of menus should we use?

Aspects of menu design

1. permanence:
   • static: the menus are fixed for all time (on screen or on input device)
     • permanent graphical menus are often called palettes. (Is it possible that the name palette is copyrighted by somebody? We seem to be seeing lots of weird substitutes like launch pad.) Permanent text menus seem not to have any special name.
     • On position-nullable input devices non-programmable menus can be placed by stencilling. (Doesn't this sound like a keyboard?)
   • hidable: menus stay until user actively makes them go away
     • default matters a lot
     • try to capture window functionality
     • push-pin idea
     • tear-off idea
   • dynamic, most commonly pop-up or hierarchical
     • Does it matter that menus cover things up? Or get covered up?
   • hybrid: multi-level menus that are different at different levels
     • E.g. pull-down menus
     • must become less permanent as you go down; why?
2. item arrangement:
   • one-dimensional: circular, linear
   • multi-dimenisonal, which means hierarchical
   • Interaction of circular/linear with hierarchical
     • pull-right versus blooming - the main effect is motor
   • When does hierarchical win? n: number of items in menu
     1. Models of searching
        1. parallel search (mediated by memory or perception): T ~ c
        2. binary search (possible with ordered lists): T ~ d1 + d2 * log(n)
        3. linear search (when you have to read): T ~ e1 + e2 * n
     2. Models of hand motion (choice)
        1. Fitts law: T ~ a1 + a2 * log(n)
        2. Scrolling: T ~ b1 + b2 * n
     3. dominated either by processes that are O(n) or O(log(n)).
     4. Make into two-level hierarchical menu:
        • level 1: m items n = m^2,
        • level 2: m menus with m items each
     5. no linear processes
        • level 1: (a2 + d2) log(m)
        • level 2: (a2 + d2) log(m)
        • sum (because they're done one after the other):
          2 (a2 + d2) log(m) = (a2 + d2) log(m^2) = (a2 + d2) log(n)
        • no advantage to hierarchical menus: overhead makes it a bad idea
     6. linear processes exist (What does e2 > 0 mean for hierarchies?)
        • level 1: (b2 + e2) m
        • level 2: (b2 + e2) m
        • sum (because they're done one after the other): 2 * (b2 + e2) m
        • compare to (b2 + e2 ) n
        • it's possible to benefit, to find out when it's necessary to keep the constants
     7. Hierarchical menus important when processing rate is slow, or when overhead is high.
     8. Empirical studies, none of which use scrolling, find that hierarchical menus are always a bad idea
   • When does circular win?
     1. What is hard about circular?
     • precision of movement at an angle?
     • representation of menu lables?
   • What is easy about circular?
     • compound movements
     • speed independence of movement
     • change direction when speed is slowest
     • muscle memory
3. Linear are hard:
   • when moving through levels
   • Why? Think of what the hand motion is like. Think of the mistakes you make most commonly.
4. Circular win
   • when there are many levels, with few alternatives per level, and
   • when users are highly familiar with the menu system

• item ordering:
  • alphabetical versus logical versus random orderings
  • novice users:
    • alphabetical fastest,
    • logical 35% slower,
    • random 4 times slower,
  • expert users:
    • alphabetical, logical about the same,
    • random slower, but not much
  • Interpretation:
    1. Experts:
       • If the item position is memorized ordering shouldn't matter.
       • But then, is it worth having a menu at all?
    2. Novices:
       • Need to look through the menu in order to recognize the command.
       • But, alphabetical is useful for recall, not for recognition!
       • Thus, novice menu use reinforces partial knowledge
    3. Conclusion. Menus are most helpful when the user knows a little, and help him or her to learn more.
• item contents:
  • commands, setting state
  • Good to keep these two well separated. "Grid on" means what?
  • Commands work well in menus
    • Because they are sequential.
    • Where do arguments come from?
    • in advance by selection, afterwards from a form
  • State works well in forms
    • Because state consists of many things that are simultaneously true.
    • To know how you want one part of the state you often must refer to other parts.
    • You can show all interdependent parts of state in a form.
• picking style:
  • prompt, echo, trigger, acknowledgement?
  • difference between selection methods
    • Activate menu on mouseUp; select on mouseUp
    • Activate menu on mouseDown; select on mouseUp
  • highlight selection (echo) in both styles
• assistance:
  • most needed for palettes (Why? Think about screen real estate.)
  • extra description
  • grouping marks
  • grouping by hierarchy

Return to:

• Bill Cowan's home page.
• Bill Cowan's teaching page.
• Bill Cowan's CS789 page.
• Bill Cowan's CS789 page for Spring 2005.