This document provides an overview of software tools that can be used for interface design and evaluation. It discusses specification methods like grammars, selection trees, and state charts that can be used to formally model interfaces. It also covers interface building tools that allow rapid prototyping of interfaces using visual design. Furthermore, it outlines evaluation tools that can analyze interfaces for consistency, usability, and correctness. The document emphasizes that these tools help design interfaces earlier, allow non-programmers to specify interfaces, and provide feedback to improve interface quality.

1. Software Tools
Fall 2002

2. Outline
 Introduction
 Specification Methods
 Interface Building Tools
 Toolkits and Languages
 Evaluation Tools

3. Introduction
 Building interfaces that are usable by a
wide audience is hard
 ethnography
 participatory design
 UI architects need to simply and quickly
sketch a proposed interface
 for example, the W model requires frequent
prototypes

4. Introduction
 By designing and showing the UI before
the application itself is built, the application
will end up with a more consistent UI
 By being able to unambiguously describe
a UI and its transitions, the UI can be
discussed and modeled

5. Specification Methods
 Natural Language Specifications
 Ambiguous
 Easy
 Formal Specifications
 Unambiguous
 Defined grammar
 Ability to prove a specification is a valid
construct within the grammar

6. Specification Methods
 Grammars
 Menu Trees
 Transition Diagrams
 State Charts

7. BNF
 Backus-Naur Form
 <non-terminal> ::= <non-terminals> terminals
 i.e., a telephone number is represented by
 tel-num ::= (<area-code>) <exchange>-<local-
number>
 area-code ::= <digit><digit><digit>
 exchange ::= <digit><digit><digit>
 local-number ::= <digit><digit><digit><digit>
 digit ::= 0|1|2|3|4|5|6|7|8|9

8. BNF
 Incomplete
 Good to specify format, but fails to specify
content, such as valid exchanges or area
codes
 A second level of software is used to validate
content.
 Complex
 As a BNF grammar grows, it becomes very
complex and difficult to follow or change

9. Unix Command Structure
 Variant of BNF
 All capital letters is a non-terminal
 Non-terminal format is assumed
 Brackets denote optional arguments
 Ellipsis (…) denote “-or-more”
 [OPTION]… is 0 or more (Kleene closure or *-closure)
 SOURCE… is 1 or more (+-closure)

10. cp
 From a Debian 3.0r0 machine:
cp [OPTION]... SOURCE DEST
cp [OPTION]... SOURCE... DIRECTORY
cp [OPTION]... --target directory=DIRECTORY
SOURCE…

11. Other Variant Grammars
 make
JAVAC = /usr/bin/jikes
JAVA_HOME = /usr/lib/jsdk1.3
all: thyme-core chat swab
thyme-core:
$(MAKE) -f thyme-core/Makefile
chat:
$(MAKE) -f chat/Makefile
swab:
$(MAKE) -f swab/Makefile

12. Other Grammars
 XML
<?xml version=“1.0”?>
<system spec-file-version=“2.0”>
<init class=“some.init.InitComponent”/>
<parameters>
<parameter name=“tcc.init.classid”
value=“some.room.RoomComponent”/>
</parameters>
</system>

13. Multiparty Grammars
 Used for showing interaction between
more than one party (Shneiderman, 1982)
 Non-terminals labeled by the party which
generates it (i.e., U for user and C and
computer)
 Effective for text-oriented command
sequences which have repeated
exchanges

14. Multiparty Grammars
 Example
<Session> ::= <U: Opening> <C: Responding>
<U: Opening> :: LOGIN <U: Name>
<U: Name> :: <U: string>
<C: Responding> :: HELLO [<U: Name>]

15. Selection Trees
 Branching interaction
 Each tree node will branch to one or more
possibilities.
 Not necessarily a strict tree
 Acyclic
 Cyclic
 Tree
 Menu Selection Trees
 Dialog Selection Trees

16. Transition Diagrams
 More complete and general than selection trees
 general enough to show the complete interaction with
an application
 Directed graph
 Nodes represent states
 Links between nodes represent actions and the
application’s response
 NFA
 Becomes cumbersome as the represented
interaction grows.

17. State Charts
 Harel, 1988
 Extension of transition diagrams where related
actions are grouped into a subgraph (modularity)
 Only effective where the subgraphs have single
points of entry and exit
 For example, all bank transactions are within a
group. Then within that group, there are
separate groups for verification, withdrawal and
deposit.

18. User-Action Notation (UAN)
 Chase et. al., 1994
 Grammars and State diagrams fail to deal
with direct manipulation interfaces
 A user’s intended action depends on context
 Context can change quickly during runtime
 UAN is a high-level notation that focus a
user’s direct manipulation task (pointing,
dragging and clicking in WIMP interfaces)

19. UAN
 Syntax involves a user action, interface
feedback and interface state. i.e., deleting
a file:
User Action Interface Feedback Interface State
~[file], Mv file!, forall(file!):
file-!
selected = file
~[x,y]* outline(file) > ~
~[trash] outline(file) > ~,
trash!
M^ erase(file), trash!! selected = null

20. UAN
 ~ is the cursor. M is the mouse
 ~[object] is cursor movement to the specified
object (i.e., icon)
 object > ~ means move the object to the cursor
 Mv is press the mouse button
 M^ is release the mouse button
 object! is highlight the object
 object!! is dehighlight the object

21. Specification Methods
The Message
 grammars programatically specify the interface
actions available but fail to specify interaction.
 Selection trees show transitions between menu
items or dialogs
 Transition diagrams show transitions between
states for a complete application
 State charts group related actions into groups,
making the transition diagrams easier to follow
 UAN provides a notation to specify direct
manipulation tasks

22. Interface Building Tools
 Writing an application requires agreement
of several parties on the UI
 managers need to approve the design
 UI architects need to build it
 programmers need to be aware what they are
programming to
 users are asked for opinions on the interface

23. Interface Building Tools
 Let an interface be prototyped rapidly
 Let an interface be built by a non-
programmer
 Allow the application to be built using the
prototyped interface

24. Interface Building Tools
 Benefits of using interface building tools
 User-interface independence
 Separate presentation from logic
 Prototype multiple user interfaces
 Multiple-platform support
 Domain expert as user-interface architect
 Enforce standards
 Methodology and Notation
 Develop design methodology
 Talk about design
 Project management

25. Interface Building Tools
 Rapid prototyping
 Build and use multiple versions up front
 Low cost test, revise, test
 Usable user interfaces for users, managers and
customers to see and use early
 Software support
 Productivity
 Constraint and consistency checks
 Ease of maintenance
 Teams

26. Design Tools
 Slide Show
 paper and pen, PowerPoint, etc
 Visual editing tools
 HyperCard, Visual Basic, Delphi, etc
 Visual programming tools
 Prograph, LEGO Mindstorms

27. Interface Building Tools
Interface Builder
 Free tool included with MacOSX for
building user interfaces

28. Building Interfaces
The Message
 Tools let prototype mostly functional interfaces
quickly and cheaply
 Tools lets a domain expert build the interface
 Tools let the interface be discussed before the
investment has been made in the rest of the
application
 Showing the interface to management, users
and experts can be done early and often

29. Evaluation Tools
 Provide automated feedback to the
developer as to where the product is
inconsistent
 Warning signs
 automated analysis of where a UI might be
inconsistent or violating a standard

30. Evaluation Tools
 Tullis’ Display Analysis Program
 takes alphanumeric screen designs and
critiques them.
 percentage of upper-case letters
 density of text
 layout complexity
 Example of automated analysis

31. Evaluation Tools
 GOMS
 Simple Metrics
 number of widgets per window
 widget density
 can yield information about how complex the
interface is
 Style consistency

32. Evaluation Tools
 Web pages
 Validation
 Link checking
 Correctness
 *Unit (JUnit, NUnit, etc)
 defined testing of applications (regression testing)
 Cactus
 defined testing of UIs (regression testing of user
interfaces)

33. Evaluation Tools
The Message
 let the developer programatically
determine correctness of an interface
 give the developer feedback on
consistency of the interface
 allow comparison of interfaces

34. UI Toolkits
 Ease development by providing fully-
fleshed out UI components
 A UI component has two major parts
 The UI presentation (a button)
 The outlet (how the program is informed when
the button is pressed)

35. Toolkits
 TCL/Tk
 Motif
 Mac Toolbox
 MFC
 Java AWT / Swing

36. Prototyping languages
 Java
 Application / Applet language
 Cross platform. Intent is that all applications
act the same on all platforms
 Hypercard
 Movement between Cards (screens)
 Tcl/Tk
 Scripting language

37. Toolkits and Languages
The Message
 Toolkits provide UI widgets that can be
used to develop the application
 This lets the developer focus on building
the application, instead of the widgets
 Prototyping languages allow the rapid
development of prototype applications, but
trade can entail trade-offs

38. Next Time
 GroupKit
 THYME