CS789, Spring 2007

Lecture notes, Week 11

Context

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?

1. Synchronization of context is essential for communication.
2. Building context is a slow process, and requires slow changes.
   • Think about montage in the movies.
   • Think about security, contrasting ordinary travel with teleportation

   Context depends on continuity: in time, in space.

   • Weather forecasting: what's the most accurate weather forecast?
3. Context is really big.
4. It depends on memory.

State and History

Memory

Why is memory important?

1. Mode of user access to interfaces
   • Reading documentation is just loading memory
   • Practicing actions is just enhancing memory
2. Foundation of context, which interacts with perception to inform us about the world
   • We perceive the present. Unperceivable stuff is not included in our personal present.
   • 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?

• selective
  • The door carrying experiment shows that context determines what is remembered.
• dynamic
  • `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.

• the immediate past: information that is partially processed
• the distant past: things that produced long-term alterations

• The blister as a memory of digging the garden (without proper equipment)
• A reference book as a memory of things known about something.

What are the components of memory?

1. Immediate sensory store
   • one per sensory modality: echoic, etc.
   • uninterpreted
   • replayable
   • 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
2. 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.
3. Long-term store
   • "infinite" capacity
   • more labile than most people think, much reconstruction done unconsciously
   • not over-written, just gets dim
   • addressed by content, like a search engine: Frank Harris example

There is an extremely subtle interaction between perception and memory

• slide from one to the other seamlessly
• check one against the other

1. to make external augmentations of memory as effective as memory itself
   • reliability?
   • ease of access?

   You say Google: what's the correct response?

2. to make new windows into the world as effortless to use as direct perception
   • precision?
   • ease of integration with memory?

   You say `videoconference': what's the correct response?

Navigation

Navigation has three components

1. knowing where you are,
2. knowing where you want to be, and
3. 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 context?

1. Dead reckoning
   • Know the starting place very well
     • e.g., .login, .cshrc
   • Add each subsequent change of position
     • cd ...
   • Waypoints are an important complement to dead reckoning.
     • pwd
   • Dead reckoning plus waypoints are the usual way that we give strangers directions.
     • Why do women do it better than men?
2. Location finding
   • Present a complete set of landmarks, distances, etc
   • e.g., Macintosh finder, Windows explorer
   Note that landmarks have to be associated with a map: of what to what?

How does a user know where they want to be?

1. They were there before.
2. They were `told' about it.

How does a user know how to get there?

1. Point to point
2. Plan = map

Two styles of interface

1. History-oriented: system presents history, user constructs state
2. State-oriented: system presents state, user remembers history

1. Perception shows us some of the state, as it exists right now.
2. 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.
3. Perception interacts with memory to bring things up to date. How much of this process needs attention? Not much.
4. What happens when significant inconsistencies are detected between memory and perception?

Tests for interface style

1. Canonical

   • % ls
     a1 a2 a3
     % rm a2
     % ls
     a1 a3

   • Do the two ls outputs match or not?
   • Is the screen live or dead?
2. Suppose you are editting a file,
   • compile it without saving,
   • What gets compiled?
3. Suppose you are reading mail,
   • new mail arrives,
   • How and when does the mail list update?
4. Most systems are hybrids, but close to one or the other.

Essential characteristics

• history is changeless; state changes constantly
• history is sequential; state is simultaneous
• history is temporal; state is spatial

Illustrative examples

• 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 change it?
• State is used to update memory. What happens if you fail to synchronize it?

Characteristic strengths of history-oriented interfaces

• easy for user to remember sequences, because attention is required for long-term memory
• easy to add scripting capabilities: because it's easy to understand sequential dependencies
• easy to penetrate below the UI, because the computation really is serial

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

• 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

1. by teleportation to a well-known place
2. 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

Scripting

In a given context do a sequence of operations

• Each operation changes the context
• Script writer must think about
  1. 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

• record/playback

Undo

Checkpoint/rollback

• user controls the points at which state is saved
• can be extended across the entire operating system

Autosave

• user controls granularity, illustrates the importance of defaults

Undo

• implementation controls the granularity
• pros and cons of small granularity
• pros and cons of large granularity

Redo

• Users usually want redo to be selective. Why is that hard?
• Redo(Undo) ?= Undo(Undo)

Return to:

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