CS789, Spring 2007
Lecture notes, Week 7
Dialogues, prompts, commands
Baecker and Buxton's list of dialogue styles:
- 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
- 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.
- Programming language (PL). The user provides a program, written in a
programming language. The interface is a program interpreter. Examples:
TeX, Unix shell.
- 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
- 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.
- 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
- 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.
- 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
- 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,
- 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
Any classification is fuzzy in at several ways:
- Different points of view yield different classifications. For example,
- vi is a AR interface.
- vi is a PL interface. The program is created while editting by a
syntax-directed editor, and executed as a result of the ":w"
- vi is a FF interface.
- 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?
- Interfaces are collections of components, each of which may use a
different dialogue style. For example, a typical spreadsheet has
- commands, etc.
- The classification is neither exhaustive, nor multually exclusive, nor
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
- 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
- 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?
- 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
- DM, GI -- as much information as possible displayed at a time.
- 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
- 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.
- 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
- 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
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
- Command alone
- unique command for each action to be carried out: e.g. "pwd",
- 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.
- 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
- 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
There is a variety of results that show desirable ways of structuring
commands. Here are a few examples.
- 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
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?
- sometimes order matters, e.g. cc -o prog prog.c -lm, cp a.out
- sometimes it doesn't, e.g. lpr -Pps News -h
- 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."
- 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
- 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
- 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
- Keywords win: most with novices, quite a bit with frequent
- 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.
- 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
- Hierarchies, orthogonal structures, regular expressions,
- Relationship to command implementation. E.g., how would you
implement each structure? Menus, forms, state machines, parse
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.
- Forms are integrators of information
- They encode values that are simultaneously valid and, at least
implicitly, the relationships between values.
Characteristics of forms:
- 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?)
- 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.
- 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
- 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
- novice reads prompts; expert uses position
Questions/comments about forms:
- 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
- Forms coexist well with other dialogue styles.
- What indicates the need for a form?
Design of forms
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:
- select: communicate choice to the system
Why might menus be useful?
- Allow user to find a command, suggestion
- Allow user to find the right form of a command, correction
- 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
- Which commands should be in menus?
- Where should the commands be?
- How should the commands be represented?
- What style of menus should we use?
Aspects of menu design
- static: the menus are fixed for all time (on screen or on input
- 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
- 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
- hybrid: multi-level menus that are different at different levels
- E.g. pull-down menus
- must become less permanent as you go down; why?
- 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
- Models of searching
- parallel search (mediated by memory or perception): T ~
- binary search (possible with ordered lists): T ~ d1 + d2 *
- linear search (when you have to read): T ~ e1 + e2 * n
- Models of hand motion (choice)
- Fitts law: T ~ a1 + a2 * log(n)
- Scrolling: T ~ b1 + b2 * n
- dominated either by processes that are O(n) or O(log(n)).
- Make into two-level hierarchical menu:
- level 1: m items n = m^2,
- level 2: m menus with m items each
- 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)
- no advantage to hierarchical menus: overhead makes it a bad
- linear processes exist (What does e2 > 0 mean for
- level 1: (b2 + e2) m
- level 2: (b2 + e2) m
- sum (because they're done one after the other): 2 * (b2 +
- compare to (b2 + e2 ) n
- it's possible to benefit, to find out when it's necessary
to keep the constants
- Hierarchical menus important when processing rate is slow, or
when overhead is high.
- Empirical studies, none of which use scrolling, find that
hierarchical menus are always a bad idea
- When does circular win?
- 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
- Linear are hard:
- when moving through levels
- Why? Think of what the hand motion is like. Think of the mistakes
you make most commonly.
- Circular win
- when there are many levels, with few alternatives per level,
- 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
- If the item position is memorized ordering shouldn't
- But then, is it worth having a menu at all?
- Need to look through the menu in order to recognize the
- But, alphabetical is useful for recall, not for
- Thus, novice menu use reinforces partial knowledge
- 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
- 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
- most needed for palettes (Why? Think about screen real estate.)
- extra description
- grouping marks
- grouping by hierarchy