by: FIDEL C.

ROMASANTA
Chapter 8
IMPLEMENTATION
SUPPORT
 IMPLEMENTATION SUPPORT

 programming tools
o levels of services for programmers
 windowing systems
o core support for separate and simultaneous user-system activity
 programming the application and control of dialogue
 interaction toolkits
o bring programming closer to level of user perception
 user interface management systems
o 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

o windowing systems
o interaction toolkits
o 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

three possible software architectures

o all assume device driver is separate
o differ in how multiple application management is implemented
1. each application manages all processes
o everyone worries about synchronization
o reduces portability of applications
2. management role within kernel of operating system
o 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:
o how to change input focus
o tiled vs. overlapping windows
o 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

o modal dialogue box
 easy with event-loop (just have extra read-event loop)
 hard with notification (need lots of mode flags)
o 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
o input and output
intrinsically linked
move press release move

Toolkits provide this level of abstraction

o programming with interaction objects (or
o techniques, widgets, gadgets)
o promote consistency and generalizability
o through similar look and feel
o amenable to object-oriented programming
 INTERFACES IN JAVA

 Java toolkit – AWT (abstract windowing toolkit)

 Java classes for buttons, menus, etc.

 Notification based;
o AWT 1.0 – need to subclass basic widgets
o AWT 1.1 and beyond -– callback objects

 Swing toolkit
o built on top of AWT – higher level features
o uses MVC architecture (see later)
 USER INTERFACE MANAGEMENT
SYSTEMS (UIMS)

 UIMS add another level above toolkits

o toolkits too difficult for non-programmers

 concerns of UIMS
o conceptual architecture
o implementation techniques
o support infrastructure

 non-UIMS terms:
o UI development system (UIDS)
o UI development environment (UIDE)
 e.g. Visual Basic
 UIMS AS CONCEPTUAL ARCHITECTURE

 separation between application semantics

and presentation
 improves:
o portability – runs on different systems
o reusability – components reused cutting costs
o multiple interfaces – accessing same functionality
o customizability – by designer and user
 UIMS TRADITION – INTERFACE LAYERS /
LOGICAL COMPONENTS

 linguistic: lexical/syntactic/semantic
presentation dialogue applicatio n

 Seeheim: dialogue
func. core
adaptor lexical

functio nal
core physical

 Arch/Slinky
 SEEHEIM MODEL

lexical syntactic semantic

Functionality
Dialogue
USER
USER Presentation (application APPLICATION
Control
interface)

switch
 CONCEPTUAL VS. IMPLEMENTATION

Seeheim
o arose out of implementation experience
o but principal contribution is conceptual
o concepts part of ‘normal’ UI language

… because of Seeheim …
… we think differently!

e.g. the lower box, the switch

 needed for implementation
presentation dialogue applicatio n

 but not conceptual

 SEMANTIC FEEDBACK

 different kinds of feedback:

o lexical – movement of mouse
o syntactic – menu highlights
o semantic – sum of numbers changes

 semantic feedback often slower

o use rapid lexical/syntactic feedback

 but may need rapid semantic feedback

o freehand drawing
o highlight trash can or folder when file dragged
WHAT’S THIS?
THE BYPASS/SWITCH

direct communication
between application
rapid semantic and presentation
feedback but regulated by
dialogue control
MORE LAYERS!

dialogue
func. core
adaptor lexical

functio nal
core physical
 ARCH/SLINKY

 more layers! – distinguishes lexical/physical

 like a ‘slinky’ spring different layers may be thicker
(more important) in different systems
 or in different components
dialogue
func. core
adaptor lexical

functio nal
core physical
 MONOLITHIC VS. COMPONENTS

 Seeheim has big components

 often easier to use smaller ones
o esp. if using object-oriented toolkits
 Smalltalk used MVC – model–view–controller
o model – internal logical state of component
o view – how it is rendered on screen
o controller – processes user input
MVC
MODEL - VIEW - CONTROLLER

view

model

controller
 MVC ISSUES

 MVC is largely pipeline model:

input  control  model  view  output
 but in graphical interface
o input only has meaning in relation to output
e.g. mouse click
o need to know what was clicked
o controller has to decide what to do with click
o but view knows what is shown where!
 in practice controller ‘talks’ to view
o separation not complete
 PAC MODEL

 PAC model closer to Seeheim

o abstraction – logical state of component
o presentation – manages input and output
o control – mediates between them

 manages hierarchy and multiple views

o 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

A P A P
C C

abstraction presentation

control

A P
A P
C
C
 IMPLEMENTATION OF UIMS
 Techniques for dialogue controller
• menu networks • state transition diagrams
• grammar notations • event languages
• declarative languages • constraints
• graphical specification

o for most of these see chapter 16

 N.B. constraints
o instead of what happens say what should be true
o 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
o draw components on screen
o set actions with script or links to program
 in use
o with raw programming most popular technique
o e.g. Visual Basic, Dreamweaver, Flash
 local vs. global
o hard to ‘see’ the paths through system
o 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)
 SUMMARY
Levels of programming support tools
 Windowing systems
o device independence
o multiple tasks
 Paradigms for programming the application
o read-evaluation loop
o notification-based
 Toolkits
o programming interaction objects
 UIMS
o conceptual architectures for separation
o techniques for expressing dialogue
THANKS!
Any questions?
You can find me at
[email protected]