User Action Notation (UAN) 

    Introduction

    How should user-interface designs be represented?

    Design: cognitive process of envisioning problem solutions under constraints

    Representation: physical process of capturing design ideas for;
     

    • evaluation
    • communication
    N.B. difference in software engineering between the design of the interface and the design of the user’s interactions at the interface. We are talking about the latter, which should feed into the former, i.e. we distinguish constructional and behavioural design.

    Some constructional design techniques:
     

    • Object Oriented design methods
    • State Transition Diagrams
    • event driven programming
    • interaction by demonstration (embedded in UIMS and other interface building tools)
    Some behavioural design techniques:
     
    • GOMS
    • CLG
    • keystroke level
    • TAL
    • TAG
    However all these are more suited to analysis than generation and have no representation of feedback.

    Programmers shouldn’t (have to) design, so there is a need for detailed interaction design  representation.  User Action Notation (UAN) is intended to fulfil this requirement.

    History

    Developed at Virginia Tech in the 80's by Antonio Siochi, H. Rex Hartson and Deborah Hix.  Siochi is credited as the originator.  Grew out of a need experienced by implementors and interface designers in a development project, for a clear means of communication.

    Purpose

    "The UAN is intended to be written primarily by someone designing the interaction component of an interface, and to be read by all developers, particularly those designing and implementing the user interface software"
    [Hix & Hartson 1993, p. 152]

    It is intended as a mechanism for recording design which is;
     

    • precise
    • concise
    • unambiguous
    • detailed

    Description

    • A user- and task-oriented notation.
    • A way of representing behaviour of user and interface as they perform a task together.
    • Based on the user task as the primary element of analysis.
    • The complete interface is seen as hierarchy of unordered tasks.
    • Sequencing within one task is independent from that in others.
    • The lowest leve of detail records;
      • user actions
      • corresponding interface feedback
      • state change.
    • At all levels, usr actions and tasks are constrained by the following temporaral relations.
      • sequencing
      • interleaveing
      • concurrency
    • Supplemented by scenarios (sequences of screen pictures), state transition diagrams and design rationale notes.
    User tasks are shown as tables with the following headings:
     
    Task: <name of the task>
    USER ACTIONS
    INTERFACE FEEDBACK
    INTERFACE STATE
     

    The notation of user actions, interface feedback and interface state is left up to the users, but a standard notation is used by Hix et al.

    Elements of UAN

      Objects and actions

        M   = mouse button

        v   = down

        ^   = up

        [   ]   = context of some object, e.g. [line]midpoint or  [box]centrepoint

        ~   = move cursor

        K   = character input (Keyboard for simplicity)

        K”copy”   = literal command

        K(filename)   = variable

        K(user ID = [A-Z] [A-Z 0-9] +)   = use of regular expression to constrain input

      Feedback

        file icon!    = file icon highlights

        file icon-!    = file icon unhighlights

        application icon!!    = application file highlights differently

      Notes

      •  these are used as primitives: fine physical actions are assumed
      •  the notation is device independent, i.e. can move cursor via mouse, joystick etc
      • basics are cursor movement, switch-like devices (mouse buttons, key, foot pedal, suck and puff devices) and character input (keyboard, voice)
     

      More formalism

        Can use logic:

        ¥    = for all

        ¬   =  not

        = equals

        *  not equals

        file icon’   = selected icon

        box > ~   = box follows cursor

        box corner >> ~   = box corner “rubberbands” to cursor

        ~[x,y]*   = arbitrary number of repetitions, inc. 0

        ~[x,y]+   = 1 or more times (can also specify)

        plus: temporal relations, connection to computation

    Examples

    Task: select file
    USER ACTIONS
    INTERFACE FEEDBACK
    INTERFACE STATE
    ~[file icon'] Mv file icon'! 
    ¥file icon * file icon' : file icon-!    		 selected = file
    Mv
     
     
    Task: delete file
    USER ACTIONS
    INTERFACE FEEDBACK
    INTERFACE STATE
    ~[file icon'] Mv file icon'-! : file icon'! 
    ¥file icon * file icon' : file icon-!    		 selected = file
    ~[x,y]* outline( file icon') >~
    ~[wastebin icon] outline( file icon') >~ 
    wastebin icon!
    M^ erase( file_icon') 
    wastebin icon!!    		 selected = null
     
    For further extensive examples of UAN used as part of a design process see [Telford 1996].

     

    This page is maintained by Richard Griffiths and does not necessarily reflect the official position of the University of Brighton. 

    RG's teaching