CHAPTER 6
IMPLEMENTATION
SUPPORT
IMPLEMENTATION SUPPORT
• programming tools
• levels of services for programmers
• windowing systems
• core support for separate and simultaneous user-
system activity
• programming the application and control of
dialogue
• interaction toolkits
• bring programming closer to level of user perception
• user interface management systems
• controls relationship between presentation and
functionality
INTRODUCTION
How does HCI affect of the programmer?
Advances in coding have elevated programming
hardware specific
 interaction-technique specific
Layers of development tools
• windowing systems
• interaction toolkits
• user interface management systems
ELEMENTS OF WINDOWING
SYSTEMS
Device independence
programming the abstract terminal device drivers
image models for output and (partially) input
• pixels
• PostScript (MacOS X, NextStep)
• Graphical Kernel System (GKS)
• Programmers' Hierarchical Interface to Graphics
(PHIGS)
Resource sharing
achieving simultaneity of user tasks
window system supports independent processes
isolation of individual applications
ROLES OF A WINDOWING SYSTEM
ARCHITECTURES OF WINDOWING
SYSTEMS
There are three possible software architectures
• all assume device driver is separate
• differ in how multiple application management is
implemented
1. each application manages all processes
• everyone worries about synchronization
• reduces portability of applications
2. management role within kernel of operating system
• applications tied to operating system
3. management role as separate application
maximum portability
THE CLIENT-SERVER
ARCHITECTURE
X WINDOWS ARCHITECTURE
X WINDOWS ARCHITECTURE (CTD)
• pixel imaging model with some pointing mechanism
• X protocol defines server-client communication
• separate window manager client enforces policies for
input/output:
• how to change input focus
• tiled vs. overlapping windows
• inter-client data transfer
PROGRAMMING THE APPLICATION - 1
READ-EVALUATION LOOP
repeat
read-event(myevent)
case myevent.type
type_1:
do type_1 processing
type_2:
do type_2 processing
...
type_n:
do type_n processing
end case
end repeat
PROGRAMMING THE APPLICATION - 1
NOTIFICATION-BASED
void main(String[] args) {
Menu menu = new Menu();
menu.setOption(“Save”);
menu.setOption(“Quit”);
menu.setAction(“Save”,mySave)
menu.setAction(“Quit”,myQuit)
...
}
int mySave(Event e) {
// save the current file
}
int myQuit(Event e) {
// close down
}
GOING WITH THE GRAIN
• system style affects the interfaces
• modal dialogue box
• easy with event-loop (just have extra read-event
loop)
• hard with notification (need lots of mode flags)
• non-modal dialogue box
• hard with event-loop (very complicated main loop)
• easy with notification (just add extra handler)
beware!
if you don’t explicitly design it will just happen
implementation should not drive design
USING TOOLKITS
Interaction objects
• input and output
intrinsically linked
Toolkits provide this level of abstraction
• programming with interaction objects (or
• techniques, widgets, gadgets)
• promote consistency and generalizability
• through similar look and feel
• amenable to object-oriented programming
move press release move
INTERFACES IN JAVA
• Java toolkit – AWT (abstract windowing toolkit)
• Java classes for buttons, menus, etc.
• Notification based;
• AWT 1.0 – need to subclass basic widgets
• AWT 1.1 and beyond -– callback objects
• Swing toolkit
• built on top of AWT – higher level features
• uses MVC architecture (see later)
USER INTERFACE MANAGEMENT
SYSTEMS (UIMS)
• UIMS add another level above toolkits
• toolkits too difficult for non-programmers
• concerns of UIMS
• conceptual architecture
• implementation techniques
• support infrastructure
• non-UIMS terms:
• UI development system (UIDS)
• UI development environment (UIDE)
• e.g. Visual Basic
UIMS AS CONCEPTUAL
ARCHITECTURE
• separation between application semantics
and presentation
• improves:
• portability – runs on different systems
• reusability – components reused cutting costs
• multiple interfaces – accessing same functionality
• customizability – by designer and user
UIMS TRADITION – INTERFACE
LAYERS / LOGICAL COMPONENTS
• linguistic: lexical/syntactic/semantic
• Seeheim:
• Arch/Slinky
SEEHEIM MODEL
Presentation
Dialogue
Control
Functionality
(application
interface)
USERUSER APPLICATION
switch
lexical syntactic semantic
CONCEPTUAL VS.
IMPLEMENTATION
Seeheim
• arose out of implementation experience
• but principal contribution is conceptual
• concepts part of ‘normal’ UI language
… because of Seeheim …
… we think differently!
e.g. the lower box, the switch
• needed for implementation
• but not conceptual
SEMANTIC FEEDBACK
• different kinds of feedback:
• lexical – movement of mouse
• syntactic – menu highlights
• semantic – sum of numbers changes
• semantic feedback often slower
• use rapid lexical/syntactic feedback
• but may need rapid semantic feedback
• freehand drawing
• highlight trash can or folder when file dragged
MONOLITHIC VS. COMPONENTS
• Seeheim has big components
• often easier to use smaller ones
• esp. if using object-oriented toolkits
• Smalltalk used MVC – model–view–controller
• model – internal logical state of component
• view – how it is rendered on screen
• controller – processes user input
MVC
MODEL - VIEW - CONTROLLER
model
view
controller
MVC ISSUES
• MVC is largely pipeline model:
input  control  model  view  output
• but in graphical interface
• input only has meaning in relation to output
e.g. mouse click
• need to know what was clicked
• controller has to decide what to do with click
• but view knows what is shown where!
• in practice controller ‘talks’ to view
• separation not complete
PAC MODEL
• PAC model closer to Seeheim
• abstraction – logical state of component
• presentation – manages input and output
• control – mediates between them
• manages hierarchy and multiple views
• control part of PAC objects communicate
• PAC cleaner in many ways …
but MVC used more in practice
(e.g. Java Swing)
PAC
PRESENTATION - ABSTRACTION - CONTROL
abstraction presentation
control
A P
C
A P
C
A P
C A P
C
IMPLEMENTATION OF UIMS
• Techniques for dialogue controller
• menu networks • state transition diagrams
• grammar notations • event languages
• declarative languages • constraints
• graphical specification
• for most of these see chapter 16
• N.B. constraints
• instead of what happens say what should be true
• used in groupware as well as single user interfaces
(ALV - abstraction–link–view)
see chapter 16 for more details on several of these
GRAPHICAL SPECIFICATION
• what it is
• draw components on screen
• set actions with script or links to program
• in use
• with raw programming most popular technique
• e.g. Visual Basic, Dreamweaver, Flash
• local vs. global
• hard to ‘see’ the paths through system
• focus on what can be seen on one screen
THE DRIFT OF DIALOGUE
CONTROL
• internal control
(e.g., read-evaluation loop)
• external control
(independent of application semantics or
presentation)
• presentation control
(e.g., graphical specification)

Chapter 6 implementation support

  • 1.
  • 2.
    IMPLEMENTATION SUPPORT • programmingtools • levels of services for programmers • windowing systems • core support for separate and simultaneous user- system activity • programming the application and control of dialogue • interaction toolkits • bring programming closer to level of user perception • user interface management systems • controls relationship between presentation and functionality
  • 3.
    INTRODUCTION How does HCIaffect of the programmer? Advances in coding have elevated programming hardware specific  interaction-technique specific Layers of development tools • windowing systems • interaction toolkits • user interface management systems
  • 4.
    ELEMENTS OF WINDOWING SYSTEMS Deviceindependence programming the abstract terminal device drivers image models for output and (partially) input • pixels • PostScript (MacOS X, NextStep) • Graphical Kernel System (GKS) • Programmers' Hierarchical Interface to Graphics (PHIGS) Resource sharing achieving simultaneity of user tasks window system supports independent processes isolation of individual applications
  • 5.
    ROLES OF AWINDOWING SYSTEM
  • 6.
    ARCHITECTURES OF WINDOWING SYSTEMS Thereare three possible software architectures • all assume device driver is separate • differ in how multiple application management is implemented 1. each application manages all processes • everyone worries about synchronization • reduces portability of applications 2. management role within kernel of operating system • applications tied to operating system 3. management role as separate application maximum portability
  • 7.
  • 8.
  • 9.
    X WINDOWS ARCHITECTURE(CTD) • pixel imaging model with some pointing mechanism • X protocol defines server-client communication • separate window manager client enforces policies for input/output: • how to change input focus • tiled vs. overlapping windows • inter-client data transfer
  • 10.
    PROGRAMMING THE APPLICATION- 1 READ-EVALUATION LOOP repeat read-event(myevent) case myevent.type type_1: do type_1 processing type_2: do type_2 processing ... type_n: do type_n processing end case end repeat
  • 11.
    PROGRAMMING THE APPLICATION- 1 NOTIFICATION-BASED void main(String[] args) { Menu menu = new Menu(); menu.setOption(“Save”); menu.setOption(“Quit”); menu.setAction(“Save”,mySave) menu.setAction(“Quit”,myQuit) ... } int mySave(Event e) { // save the current file } int myQuit(Event e) { // close down }
  • 12.
    GOING WITH THEGRAIN • system style affects the interfaces • modal dialogue box • easy with event-loop (just have extra read-event loop) • hard with notification (need lots of mode flags) • non-modal dialogue box • hard with event-loop (very complicated main loop) • easy with notification (just add extra handler) beware! if you don’t explicitly design it will just happen implementation should not drive design
  • 13.
    USING TOOLKITS Interaction objects •input and output intrinsically linked Toolkits provide this level of abstraction • programming with interaction objects (or • techniques, widgets, gadgets) • promote consistency and generalizability • through similar look and feel • amenable to object-oriented programming move press release move
  • 14.
    INTERFACES IN JAVA •Java toolkit – AWT (abstract windowing toolkit) • Java classes for buttons, menus, etc. • Notification based; • AWT 1.0 – need to subclass basic widgets • AWT 1.1 and beyond -– callback objects • Swing toolkit • built on top of AWT – higher level features • uses MVC architecture (see later)
  • 15.
    USER INTERFACE MANAGEMENT SYSTEMS(UIMS) • UIMS add another level above toolkits • toolkits too difficult for non-programmers • concerns of UIMS • conceptual architecture • implementation techniques • support infrastructure • non-UIMS terms: • UI development system (UIDS) • UI development environment (UIDE) • e.g. Visual Basic
  • 16.
    UIMS AS CONCEPTUAL ARCHITECTURE •separation between application semantics and presentation • improves: • portability – runs on different systems • reusability – components reused cutting costs • multiple interfaces – accessing same functionality • customizability – by designer and user
  • 17.
    UIMS TRADITION –INTERFACE LAYERS / LOGICAL COMPONENTS • linguistic: lexical/syntactic/semantic • Seeheim: • Arch/Slinky
  • 18.
  • 19.
    CONCEPTUAL VS. IMPLEMENTATION Seeheim • aroseout of implementation experience • but principal contribution is conceptual • concepts part of ‘normal’ UI language … because of Seeheim … … we think differently! e.g. the lower box, the switch • needed for implementation • but not conceptual
  • 20.
    SEMANTIC FEEDBACK • differentkinds of feedback: • lexical – movement of mouse • syntactic – menu highlights • semantic – sum of numbers changes • semantic feedback often slower • use rapid lexical/syntactic feedback • but may need rapid semantic feedback • freehand drawing • highlight trash can or folder when file dragged
  • 21.
    MONOLITHIC VS. COMPONENTS •Seeheim has big components • often easier to use smaller ones • esp. if using object-oriented toolkits • Smalltalk used MVC – model–view–controller • model – internal logical state of component • view – how it is rendered on screen • controller – processes user input
  • 22.
    MVC MODEL - VIEW- CONTROLLER model view controller
  • 23.
    MVC ISSUES • MVCis largely pipeline model: input  control  model  view  output • but in graphical interface • input only has meaning in relation to output e.g. mouse click • need to know what was clicked • controller has to decide what to do with click • but view knows what is shown where! • in practice controller ‘talks’ to view • separation not complete
  • 24.
    PAC MODEL • PACmodel closer to Seeheim • abstraction – logical state of component • presentation – manages input and output • control – mediates between them • manages hierarchy and multiple views • control part of PAC objects communicate • PAC cleaner in many ways … but MVC used more in practice (e.g. Java Swing)
  • 25.
    PAC PRESENTATION - ABSTRACTION- CONTROL abstraction presentation control A P C A P C A P C A P C
  • 26.
    IMPLEMENTATION OF UIMS •Techniques for dialogue controller • menu networks • state transition diagrams • grammar notations • event languages • declarative languages • constraints • graphical specification • for most of these see chapter 16 • N.B. constraints • instead of what happens say what should be true • used in groupware as well as single user interfaces (ALV - abstraction–link–view) see chapter 16 for more details on several of these
  • 27.
    GRAPHICAL SPECIFICATION • whatit is • draw components on screen • set actions with script or links to program • in use • with raw programming most popular technique • e.g. Visual Basic, Dreamweaver, Flash • local vs. global • hard to ‘see’ the paths through system • focus on what can be seen on one screen
  • 28.
    THE DRIFT OFDIALOGUE CONTROL • internal control (e.g., read-evaluation loop) • external control (independent of application semantics or presentation) • presentation control (e.g., graphical specification)