Title: A Negotiation Architecture for Fluid Documents
1A Negotiation Architecture for Fluid Documents
2From UIST 98
- http//www.acm.org/pubs/citations/proceedings/uist
/288392/p123-chang/
3Never 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
4Fluid documents
- Assumes primary and secondary material
- footnotes, annotations, or hyperlinks
- Provides a nice mechanism for presenting
secondary material on demand
5What 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
6Video Demonstration
- From UIST 98 video proceedings
7Advantages
- 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
8Initially primary material is focus
- Takes most of space
- Captures most of users attention
- Secondary represented by small visual cue only
9Shifting focus
- Shifting focus to secondary material increase
salience - Increase size
- Move to prominent place
- Boldface
- etc.
10Primary material must adjust
- Reduce salience
- Examples
- Decrease size
- Move away from center
- Fade to a lighter shade
11Negotiation 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
12Initial 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
13UI 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
14Adjusting Material
- Most of work here
- Skip for a second
15Animated transition
- Short (1/2 second)
- overlaps reaction time
- Smooth changes
- maintain continuity
- maintain perception of object constancy
- this is a critical property
16Adjusting 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
17Providing space
- Several approaches (for text)
- Block movement (splitting)
- Deformation
- change interline spacing, warp
- Outside allocation
- place secondary away from anchor
- visually connect (line)
18Providing 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
19Multiple expansions (and nesting)
- May require changes in all participants
- Negotiation gets harder
- Algorithm will deal with this piece-wise to keep
simple
20Negotiation
- 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
21Negotiation -- 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
22Negotiation -- 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?
23Negotiation -- 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
24Negotiation -- 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
25Negotiation -- 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
26Negotiation 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
27Encapsulation 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
28Encapsulation of Negotiation
- Each potential primary object (essentially all)
also has set of space-making strategies - Similar story on capabilities and encapsulation
29Negotiation Steps
- Four steps in negotiation
- Initial proposal (by secondary)
- Guideline selection (by primary)
- Presentation strategy choice (sec)
- Space-making strategy choice (prim)
30Negotiation -- 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
31Negotiation -- 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
32Negotiation -- 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
33Negotiation -- 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
34Negotiation -- Presentation Strategy Choice
- Secondary sends back proposal with final choice
- Specific GChar only
35Negotiation -- 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
36Negotiation
- 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.)
37Negotiation
- 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
38Negotiation
- 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
39Recap
- 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)