Transcript Designing Usable Systems - University of Cape Town

Human-Computer Interaction
-3
Programmer Support
Gary Marsden
([email protected])
July 2002
University of Cape Town
Gary Marsden
Slide 1
Unit Objectives
 We shall cover
– Abstract terminals
– Toolkits
– UIMS
 Rationale:
– About 50% of coding effort in an application is
related to the interface
– WIMP interfaces are the most common, it is
therefore essential to understand the
programming paradigms behind these
University of Cape Town
Gary Marsden
Slide 2
In the beginning...
 Programming languages were based on
– Input - process - output
 This is clearly useless as an interactive
computing paradigm
 Therefore old languages were upgraded with
toolkits and APIs to make them cope with
WIMP interfaces
 As WIMPs standardised, so did the
extensions
University of Cape Town
Gary Marsden
Slide 3
Interactive Extension
 At the most basic level a language must
– Respond to some event (mouse click, etc.)
– Draw things on the screen
 This is too low level and error prone
 For the rest of the lecture we will look at
higher level abstractions for programming
interfaces
University of Cape Town
Gary Marsden
Slide 4
Key Elements
 Hardware independence is essential
– Abstract keyboard, screen & pointing device
 Therefore programmer works to an abstract
terminal
– Easier and more portable
– Device manufacturers build drivers to work to
abstract specification
 Each window system has its own ‘imaging
model’
– PDF, GKS, PHIGS or just pixels
University of Cape Town
Gary Marsden
Slide 5
Interactivity
 Interactive interfaces require concurrency
– This is hard to program
 Windows systems support several
instantiations of the abstract terminal
 Concurrency issues handled by window
system
 System also provides active screen regions
for each application (i.e. a window)
University of Cape Town
Gary Marsden
Slide 6
Implementing Windows
 One approach is to put the window
management code in the operating system
(as it deals with resource allocation anyway)
– Ties applications to OS
 More flexible to move management to a
separate application
– Generic across all OSs
– “Client-server” architecture
– But slow!
University of Cape Town
Gary Marsden
Slide 7
Overview
University of Cape Town
Gary Marsden
Slide 8
Reality
 Most window systems have evolved and are
part separated, part integrated
 A common example of a client-server system
is X-11 from MIT
University of Cape Town
Gary Marsden
Slide 9
X11
 Based on a network protocol (X)
 Each client runs a local abstract terminal
 The server
–
–
–
–
Does permissions for single/multi application windows
Interprets screen requests from clients
Routes user events to correct client
Minimises traffic using ID numbers
 The client
– Runs a window manager
– Managers can be wildly different
 X11 - nice but slow and hard to use
University of Cape Town
Gary Marsden
Slide 10
Application Programming
 We need to look at how the client is
programmed
– I doubt you will write a window manager
 Read-evaluation is one paradigm (Mac)
– Server is responsible for routing events
– Client is sent event ‘record’ containing details
• E.g. right mouse button clicked at 100,154
– Client has complete control of processing
– Programmer has to code event responses for
every event
– Basically a continuous loop
University of Cape Town
Gary Marsden
Slide 11
Read-Evaluation overview
University of Cape Town
Gary Marsden
Slide 12
Notification Based
 In a notification based system, applications
register the events they are interested in
 Centralised notifier receives all events and
dispatches appropriately
 Applications use callback procedures which
are associated with each event
 Control is passed to the callback, which
passes it back to the notifier on completion
University of Cape Town
Gary Marsden
Slide 13
Notifier Overview
University of Cape Town
Gary Marsden
Slide 14
Toolkits
 A window systems is fine for coping with
events and screens, but still low-level
 There are issues with input & output
integration
 We want to program with interaction objects
– “Widgets” which live in families called “Toolkits”
University of Cape Town
Gary Marsden
Slide 15
Flavours
 Toolkits come in many flavours
University of Cape Town
Gary Marsden
Slide 16
Toolkit Programming
 You can glue the components together to
form meta-widgets, then glue these to form
whole applications
 Very OO
 You get consistency across applications
– Look and feel
 Often come with style guides
– Mac thought police
 Account for 50% of code in most applications
University of Cape Town
Gary Marsden
Slide 17
UIMS
 User Interface Management Systems sit on
top of toolkits
 Idea is to separate application semantics
from interface
– MVC in smalltalk
 For my PhD, I basically argued against this
approach
– Got away with it
– HyperCard is king of integrating semantics and
interface
University of Cape Town
Gary Marsden
Slide 18
Future Developments
 Grammar Notations - UIML
 State transition diagrams
 Event languages
 Declarative Languages
 Constraints
 Graphical Programming
University of Cape Town
Gary Marsden
Slide 19
Summary
 You should now have a good idea of:
–
–
–
–
–
Abstractions for graphics systems
The role of abstract terminals
Event based programming
Toolkits
UIMS
University of Cape Town
Gary Marsden
Slide 20