CS789, Spring 2005, Lecture notes, Week 10
CS789, Spring 2005
Lecture notes, Week 10
I don't know what it is, but I know it when I don't see it.
Context is `all the rest': the things that aren't stated explicitly.
What's important about context?
- Synchronization of context is essential for communication.
- Building context is a slow process, and requires slow changes.
- Think about montage in the movies.
- Think about security, contrasting ordinary travel with
Context depends on continuity: in time, in space.
- Weather forecasting: what's the most accurate weather forecast?
- Context is really big.
- It depends on memory.
State and History
Why is memory important?
- Mode of user access to interfaces
- Reading documentation is just loading memory
- Practicing actions is just enhancing memory
- Foundation of context, which interacts with perception to inform us
about the world
- We perceive the present. Unperceivable stuff is not included in our
- We remember the past. This memory is highly distributed, existing
in human brains and in human artifacts. Artifacts must be perceived,
and what's the cost of doing so?
- The present is not very big when measured as a time interval, but
it's extremely rich. For example, it includes the current state of
our memory, so we could say that it includes the entire past. Can we
say the same about the future?
Really, there's no such thing as memory; there's just how you brain happens
to be, right now. But how it is right now is conditioned by what happened in
- The door carrying experiment shows that context determines what is
- `Who voted for President Kennedy in 1960?' The answers show the
malleability of memory.
- What did your kitchen look like before you painted it shows the
purpose of memory, and why it's right for memory to be dynamic.
Memory also exists outside the brain
- the immediate past: information that is partially processed
- the distant past: things that produced long-term alterations
Notice how this memory involves inference.
- The blister as a memory of digging the garden (without proper
- A reference book as a memory of things known about something.
What are the components of memory?
- Immediate sensory store
- one per sensory modality: echoic, etc.
- addressed by name/location: what I just heard, saw, felt, etc.
- not automatically interpreted, depends on attention
- not erased by interpretation, but easily over-written
- Short-term memory
- very limited capacity
- interpreted, chunk-size matters
- easily over-written
- addressed as "the buffer": what I'm remembering, right now! (Or
what I am thinking about, right now!)
- not automatically transferred to long-term store, depends on
rehearsel and attention.
- Long-term store
- "infinite" capacity
- more labile than most people think, much reconstruction done
- not over-written, just gets dim
- addressed by content, like a search engine: Frank Harris
There is an extremely subtle interaction between perception and memory
Our goal in the interface is
- slide from one to the other seamlessly
- check one against the other
- to make external augmentations of memory as effective as memory itself
- ease of access?
You say Google: what's the correct response?
- to make new windows into the world as effortless to use as direct
- ease of integration with memory?
You say `videoconference': what's the correct response?
Navigation has three components
- knowing where you are,
- knowing where you want to be, and
- knowing how to get from here to there.
How does a user know where he or she is? How does a user know the current
- Dead reckoning
- Know the starting place very well
- Add each subsequent change of position
- e.g., .login, .cshrc
- Waypoints are an important complement to dead reckoning.
- Dead reckoning plus waypoints are the usual way that we give
- Why do women do it better than men?
- Location finding
Note that landmarks have to be associated with a map: of what to
- Present a complete set of landmarks, distances, etc
- e.g., Macintosh finder, Windows explorer
Two styles of interface
In the real world what happens
- History-oriented: system presents history, user constructs state
- State-oriented: system presents state, user remembers history
- Perception shows us some of the state, as it exists right now.
- Memory retains state as it existed at particular times in the past.
Sometimes memory is transformed to make it more like the future. Memory
is not a very reliable guide to what things are like right now, but it's
a lot better than nothing.
- Perception interacts with memory to bring things up to date. How much
of this process needs attention? Not much.
- What happens when significant inconsistencies are detected between
memory and perception?
Tests for interface style
- Suppose you are editting a file,
- compile it without saving,
- What gets compiled?
- Suppose you are reading mail,
- new mail arrives,
- How and when does the mail list update?
- Most systems are hybrids, but close to one or the other.
- history is changeless; state changes constantly
- history is sequential; state is simultaneous
- history is temporal; state is spatial
- History is endless paper scroll; state is bitmapped graphics Crt.
- History is a Unix pipeline; state is an interactive window system.
How do users use this information?
- History refreshes, tests and corrects memory. What happens if you
- State is used to update memory. What happens if you fail to synchronize
Characteristic strengths of history-oriented interfaces
- easy for user to remember sequences, because attention is required for
- easy to add scripting capabilities: because it's easy to understand
- easy to penetrate below the UI, because the computation really is
Characteristic strengths of state-oriented interfaces
- easy for the novice, because
- it is similar to ordinary life: the state-of-the-world updates
asynchronously, and in parallel
- the novice doesn't know what to remember
- easy for the expert, because already known (committed to memory) parts
of the state can be ignored.
- a well-designed interface shows exactly whatever state is needed to
predict the action of commands that can occur in the current context
Important crutches for history-oriented interfaces
The general prinicple behind this idea is that we recover from errors in one
of two ways
- scroll buffers on soft-copy displays
- simple tools for determining state; e.g., pwd, echo
- simple tools to obtain a known state; e.g., cd, <ESC> in vi
- commands that invert other commands; e.g., cd .. inverts cd mydirectory
(usually, sh versus bash), undo
- commands that commute
Multiple reverses tend to be unpredictable, because our memory of exactly how
things were doesn't extend very far.
- by teleportation to a well-known place
- by reversing the last change(s) to get back to a state we remember
Important crutches for state-oriented interfaces
- commands that depend on well-defined subsets of state
- access to well-defined subsets of state
- well-structured state, like structured data
- commands that take us back to an earlier state: e.g., undo
In a given context do a sequence of operations
- Each operation changes the context
- Script writer must think about
- The most general context in which the script should work: i.e.
what's guaranteed to be true
- Scripting languages resolve ambiguities by context.
Users write programs in scripting languages
- user controls the points at which state is saved
- can be extended across the entire operating system
- user controls granularity, illustrates the importance of defaults
- implementation controls the granularity
- pros and cons of small granularity
- pros and cons of large granularity
- Users usually want redo to be selective. Why is that hard?
- Redo(Undo) ?= Undo(Undo)