COSC346 User Interfaces Lecture 23: User Interface Models

1
COSC346 User InterfacesLecture 23 User
Interface Models
2
Bad User Interfaces

• Result from lack of
• responsibility,
• interest,
• time,
• effort,
• expertise,
• consistency,
• tools.

3
Good User Interfaces

• Result from
• design and evaluation from a human perspective.
• However
• design can rarely be detached from implementation.

4
Current User Interfaces

• stuck in a GUI rut,
• not particularly flexible,
• very fragile,
• technological, not human perspective.
• implementing a new style is very difficult,
• implementing with code is very bad.

5
Separable User Interfaces

• The user interface should be independent of the
  functional aspects of the system that the user
  interface serves.
• User Interface Management Systems (UIMS)
• development tools to automate the implement-ation
  of user interfaces from abstract specifications.

6
Seeheim Model for UIMS
One of the first models proposed (in 1983) to
show what parts would be required in order to
generate a user interface automatically. It does
not show how a UIMS should be structured or
implemented.
7
Extended Seeheim
8
Extended Seeheim

• Knowledge-based modules
• contain information about the problem, the
  users environment and the characteristics of the
  end-user,
• enable a cooperative system.
• Provided a blueprint for a UIMS, allowing the
  ideas to be tested in practice.

9
Limitations of these models

• No provision for needs of individual users,
• Limited power in specification techniques.

10
Interface Development Tools

• tools that provide programming support for
  implementing interactive systems --Dix et al.,
  1993
• tools should minimize the effort it takes to
  translate the semantics (meaning) of the
  interface design into the semantics of the
  toolkit -- Baecker et al., p313

11
Interface Development Tools
tools that help a developer convert interface
specifications into an interactive system and
that support all phases of system refinement
including prototyping, implementation, testing,
maintenance and system enhancement Baecker et
al., p314.
12
No More Code!

• User interface design is iterative.
• Writing code is hard.
• Writing code again and again is bad.
• The development process for user interface
  implementation should involve an abstract
  specification automatically translated into an
  implementation.

13
User Interface Design Process
Design LayoutandStoryboarding
The aim here is to generate ideas quickly and
simply with minimal effort.
Prototyping
Prototypes illustrate different styles or
approaches to implementation.
Implementation
Implementation should be generated automatically
from abstract specification.
14
Another Perspective
Design
Implementation
15
The Role of Tools

• Coordinate design sources,
• Support rapid prototyping,
• Allow for predictive evaluation,
• Support iterative design.

A formal model makes predictions about usability
actual usage data can be recorded to measure and
compare usability in practice.
16
Rapid Prototyping

• Build One to Throw Away,
• Build part of a system,
• Build limited functionality.

Aim is to explore ideas, to allow choices to be
made between alternatives and to evaluate
possible options.
17
Evaluation

• Evaluate usability by observing real end-users
  interacting with the system record and evaluate
  usage data.
• Make formal specifications of the user interface
  and predict usability according to formal models.

18
GOMS Model

• Goals - what the user wants to achieve,
• Operators - basic single actions,
• Methods - different ways to reach a goal,
• Selection - how methods are chosen.
• Model and predict skilled user behaviour in
  computer-mediated tasks.

19
Keystroke-level Model

• Code the user model of a task in terms of
  fine-grained operations.
• Estimate time to complete task
• Press Key or Button 0.8 - 1.2 sec
• Point to target with mouse 1.10 sec
• Home hands on keyboard 0.40 sec

20
Example
Method R (Replace) Terminate type-in mode K
ESCPoint to target word and select it H
mouse P word K RBInvoke Replace command H
keyboard M K RType new word M 4.5 K
wordTerminate replace command K ESCPoint to
last input word and select H mouse P word K
RBRe-enter type-in mode H keyboard M K I
21
Texecute 4 tM 10.5tK 4tH 2tP tK time to
type a character 0.8 - 1.2sectH time to home
on a device 0.4 sectM mental preparation
1.35 sectP time to point to target 1.1
secTexecute 29.7sec
22
Mouse Design

• Xerox workstations had 3-button mouse,
• Xerox Star had 2-button mouse,
• Apple Macintosh had 1-button mouse.
• WHY?

23
The 1-Button Mouse

• GOAL To minimise the number of mouse buttons
• easy to operate,
• to keep the mouse small,
• to reduce button confusion.
• SOLUTION run experiments for novice users and
  use the Keystroke-level model to predict expert
  performance.

24
Result

• Original versions of Xerox star used 3-button
  mouse.
• Keystroke model showed that 2-button mouse was
  optimum.
• 1-button mouse reduced button confusion at the
  cost of increased selection errors.

25
Another Perspective
If we separate user interface code and
application code, the jobs of interface design
and prototyping can also be separated from
implementation design and prototyping. In other
words, we can enable teamwork by a group of
individuals with diverse skills. This will
involve communication, empower-ment and ownership.
26
Programming Teams
Encourage open lines of communication in a team.
Focus on positive evaluation, not negative
criticism. Empower individuals by allocating
respons-ibility to team members for different
parts of a project.
27
Programming Teams
People get ownership of their part of the project
because they are empowered and communicating
clearly... not because they have grabbed hold
of that piece of the pie in some bizarre power
struggle.
28
Another Perspective

• Groupware is software that encourages
  collaboration between individuals. The
  capabilities of a groupware toolkit cluster into
  two categories
• programmer-centred design requirements,
• human-centred design requirements.

29
Another Perspective
Specialised toolkits that separate out
functionality are required. It is incredibly
difficult to build effective systems for
collaborative work using single-user user
interface toolkits.
30
Summary

• Design and implementation are separate.
• User interface models should be
• abstract specifications written in declarative
  languages,
• used to generate code automatically,
• flexible enough to be individually-tailored,
• designed iteratively.

31
Resources

• http//www.sigchi.org/bulletin/1997.3/reynolds.htm
  l
• http//www.interaction-design.org/
  encyclopedia/uims_user_interface_management_system
  .html
• http//en.wikipedia.org/wiki/User_interface_manage
  ment_systems
• Readings in Human-Computer Interaction Toward
  the Year 2000. (R. M. Baecker, J. Grudin, W. A.
  S. Buxton S. Greenberg eds.) Morgan-Kaufman,
  1995.
• Human Computer Interaction. Finlay, J., Abowd, G.
  and Beale, R. Prentice-Hall International, 1993.

32
Next Lecture
Data Visualisation