Using Computational Critics to Facilitate Long-term Collaboration in User
Interface Design
Uwe Malinowski
Kumiyo Nakakoji

Presented by Katie Albers

I.      Abstract
A.      UI design and User adaptation are an ongoing collaborative process
B.      It is important to view these elements as part of the same process
over the life and evolution of a product
1.      to that end, their environment is:
a.      design medium
i.      identifies possible problematic situations
1.      for end users
2.      for designers
b.      communication medium
i.      asynchronous communication
ii.     critiquing messages trigger articulation of design rationales
iii.    design rationales provide background context for adaptation and
redesign of system

II.     Introduction
A.      Issues of user interface development
1.      Symmetry of ignorance between designers and users
a.      Lack of common language for discussion
b.      Each group lacks knowledge of the other's domain
2.      distribution of necessary knowledge between designers and users
a.      knowledge about user interface design
b.      knowledge of application domain
3.      design tasks are ill-defined and open-ended
a.      Design and understanding are intertwined in critical and mysterious ways
b.      iteration of design/use cycle leads to greater understanding of
each phase
B.      Process
1.      development of interface by designers in collaboration with users
2.      users can customize system to specific needs
3.      designers redesign interface to respond to inconsistencies and
inefficient modifications
C.      Computational critiquing component of knowledge-based,
domain-oriented design environment
1.      supports designers and users by identifying potentially problematic
situations and presenting relevant design knowledge
2.      facilitates long-term collaboration among designers and users by
triggering recording design rationales

III.    Framework
A.      Process
1.      Designer designs interface
2.      User uses interface
3.      user adapts interface
4.      designer cleans up adapted interface, creating new interface
5.      etc
B.      Critiquing mechanism
1.      monitors status of design and informs people of possible breakdowns
2.      provides people with knowledge relevant to identified breakdowns
3.      encourages people to articulate design rationale
4.      provides end-users with necessary support during adaptation
5. and 2 provide knowledge whether or not you know it exists
6. adds to the knowledge base
7.      increased knowledge-base closes understanding gap between users and
designers

IV.     Scenario
A.      Elements
1.      Traffic management system (streets and trains)
a.      Must show graphical representation of objects
b.      Each objects must have certain functionality
2.      Focus on order of elements in pop-up menus
B.      Process
1.      Initial design
a.      ordered pop-up elements alphabetically
b.      exception for "display video" since not all elements of that type
have that capability
2.      Knowledge base warns of inconsistency because Schedule Screen and
Traffic Light are semantically analogous to end-users
3.      Designers record reason for change to knowledge base
4.      Design is released to end-users
5.      Users modify
a.      Users change order to reflect frequency of use
b.      System moans about consistency
c.      User asks what it's talking about
d.      System explains why consistency is important
e.      Users say "oh, we get it, that's nice, but who cares."
f.      Users document their reasons for not caring
6.      Designers redesign
a.      Designers question users' change to system
b.      They check knowledge base for reasons
c.      Based on users rationale they redesign other menus to reflect
frequency of use rather than the alphabet (in coordination with users)
d.      Designers add frequency of use as a critiquing criterion to the
knowledge base

V.      Scenario illustrates
A.      How critiquing system closes knowledge gaps
1.      Presents each side with rationale for
B.      How different kinds of problems fire critiquing system
1.      Both queries fired same information, but presented differently
a.      "domain distinctions"
i.      link critiquing rules with argumentation
ii.     rules defining semantic correspondences

VI.     Prototype
A.      on Macintosh
B.      built on Agentsheets
C.      Critiquing component
1.      Rules -- if....then
2.      Manager
a.      Monitors all actions
b.      Identifies all applicable rules
i.      user interface design principles
1.      maximum # of items in menu
2.      depth of cascading menus
ii.     Completeness of design according to spec
1.      required functions
2.      required objects
iii.    Consistency of interface
1.      same name = same function=same location
iv.     Rules that are application domain specific
1.      topological relationship of user interface objects allowed in domain
c.      Messages identified as having all conditions "true" are displayed
d.      Messages have options for Where, Explain, Reject
i.      Where: highlights all objects related to currently displayed messages
ii.     Reject: Disables rules for current situation
iii.    Explain: Displays explanation of rule






h