A Negotiation Architecture for Fluid Documents

1
A Negotiation Architecture for Fluid Documents
2
From UIST 98

• http//www.acm.org/pubs/citations/proceedings/uist
  /288392/p123-chang/

3
Never enough screen space

• This paper looks at making fluid documents
• dynamically change the allocation of space (and
  other saliency resources) between primary and
  secondary materials
• Architecture to implement this
• based on negotiation of (potentially conflicting)
  requirements

4
Fluid documents

• Assumes primary and secondary material
• footnotes, annotations, or hyperlinks
• Provides a nice mechanism for presenting
  secondary material on demand

5
What the system does

• Mediate salience (visual prominence) of primary
  and secondary material
• Allow user to smoothly change focus between them
• Animation important
• Specific techniques for modifying and sharing
  salience

6
Video Demonstration

• From UIST 98 video proceedings

7
Advantages

• Good use of space (user driven)
• Minimal shift of attention
• Close to primary
• In context
• Attempts to disturb primary presentation as
  little as possible
• Smooth transitions between views
• Lightweight interactive control

8
Initially primary material is focus

• Takes most of space
• Captures most of users attention
• Secondary represented by small visual cue only

9
Shifting focus

• Shifting focus to secondary material increase
  salience
• Increase size
• Move to prominent place
• Boldface
• etc.

10
Primary material must adjust

• Reduce salience
• Examples
• Decrease size
• Move away from center
• Fade to a lighter shade

11
Negotiation process to decide who will do what

• Four Steps
• 1) Start with only visual cue (anchor) for
  supporting material
• 2) Reader indicates interest in supporting,
  triggering shift
• 3) Negotiate salience properties
• 4) Animate to new state

12
Initial Visual Cue

• Can follow various conventions
• Underlined most common
• Also footnote marker
• Could also present small preview
• Anything that represents the secondary material
  in small and unobtrusive way

13
UI for Expressing Interest

• Needs to be lightweight
• Stated (but not obtained) goal just as easy as
  looking at it
• System uses rollover dwell
• Roll away and display reverts
• Click to hold secondary material open

14
Adjusting Material

• Most of work here
• Skip for a second

15
Animated transition

• Short (1/2 second)
• overlaps reaction time
• Smooth changes
• maintain continuity
• maintain perception of object constancy
• this is a critical property

16
Adjusting Material

• Primary and secondary adjust display to change
  saliency and shift focus
• Biggest aspect provide space for secondary
• Also pick displays that fit the space have
  right saliency

17
Providing space

• Several approaches (for text)
• Block movement (splitting)
• Deformation
• change interline spacing, warp
• Outside allocation
• place secondary away from anchor
• visually connect (line)

18
Providing space

• More approaches (for text)
• Overlay
• Reuse of space
• May have extra space left over from some other
  space allocation
• Combing techniques
• e.g., move interline space
• e.g., interline space overlay

19
Multiple expansions (and nesting)

• May require changes in all participants
• Negotiation gets harder
• Algorithm will deal with this piece-wise to keep
  simple

20
Negotiation

• Primary and secondary material may be of
  different types with different kinds of display
  capabilities
• All examples are text, but the architecture
  handles general things
• Two parts dont have specific knowledge of all
  other types built in

21
Negotiation -- GChar Objects

• Uses a GChar object
• Graphical Characteristics
• Describes desired/proposed/granted display
  properties
• Always includes space, but normally also includes
  other salience properties (e.g., color)
• Exact properties are display type dependent

22
Negotiation -- GChar Objects

• Primary Secondary may be different display
  types
• Again encapsulated -- one type does not know
  about every other type
• would make new types very hard
• How do they communicate capabilities and
  requirements?

23
Negotiation -- GChar Objects

• Solution is to use hierarchical classes of GChar
  objects
• All subclass of GChar
• which has only size information
• Specific display types add additional information
  to specific subclasses
• e.g. text adds color and font info
• Communicate via closest superclass of the GChars
  that two objects use

24
Negotiation -- GChar Objects

• Two kinds of GChar objects used
• Specific / Exact (SpecificGChar)
• used for specific proposal / result
• Range (RangedGChar)
• use to communicate acceptable bounds for various
  properties

25
Negotiation -- Proposal Objects

• Proposal object has (at least)
• SpecificGChar
• for preferred state
• RangedGChar
• for acceptable range
• These always include space aspects
• May also include other aspects
• e.g. color, font properties

26
Negotiation Objects

• Process of negotiation represented by a
  Negotiation object
• Used to represent result
• Drives animation return animation
• Used as basis for future negotiation
• Basically a cache

27
Encapsulation of Negotiation

• Each material object has a list of possible
  presentation strategies
• Typically a prioritized list
• Each can evaluate a RangedGChar
• can it do it
• what is closest / best that fits it
• Display strategy info remains encapsulated in
  each object

28
Encapsulation of Negotiation

• Each potential primary object (essentially all)
  also has set of space-making strategies
• Similar story on capabilities and encapsulation

29
Negotiation Steps

• Four steps in negotiation
• Initial proposal (by secondary)
• Guideline selection (by primary)
• Presentation strategy choice (sec)
• Space-making strategy choice (prim)

30
Negotiation -- Initial Proposal

• Secondary indicates to primary that it would like
  to expand
• Submits a Proposal object
• SpecificGChar a priori preferred size salience
  properties
• RangedGChar sizes and properties it can do
  display with

31
Negotiation -- Guideline Selection

• Primary determines which subclass of GChar to use
• Considers its set of space making strategies
• Tentatively picks one
• Typical policy one with most space
• Tries to provide most flexibility

32
Negotiation -- Guideline Selection

• Sends a proposal back
• Ranged the guidelines
• max space that can be given
• property ranges with most leeway
• Specific a specific recommendation
• takes into account preferred state of both
  primary and secondary
• important for expressing properties

33
Negotiation -- Presentation Strategy Choice

• Secondary picks a final presentation strategy
• Original choice may work
• May have to consider its list of possible
  presentations to find one
• Fits within space given
• As close as possible to suggested properties

34
Negotiation -- Presentation Strategy Choice

• Secondary sends back proposal with final choice
• Specific GChar only

35
Negotiation -- Space-Making Strategy Choice

• Based on final choice of secondary, primary picks
  a space-making strategy
• May be tentative choice
• May be able to do better if secondary did not use
  all its space, etc.
• Strategy does placement

36
Negotiation

• Critical details of decision algorithms embedded
  in objects
• Allows type specific strategies, but still
  fitting in general framework
• Set of strategies for each type
• Neither dictates, but not symmetrical
• E.g., secondary never knows about primarys
  presentation (size, etc.)

37
Negotiation

• Multi-level negotiations handled pair-wise
• Negotiation with grandparent is handled inside
  guideline and space choice steps of parent
• Negotiation with grandchildren similarly handled
  inside initial and presentation choice steps
  of child

38
Negotiation

• Negotiation stops after one round of four steps
• can fail ? fallback strategy
• e.g., separate window
• claimed rare because primaries build to provide
  wide ranges
• Could renegotiate based on knowledge of needs
• still limited rounds ? fail ? fallback strategy

39
Recap

• Good use of space
• Keeps disruption of attention to a minimum
• Negotiation makes best use of available resources
• Architecture encapsulates details ? allows
  extension

40
(No Transcript)