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
delfirome@yahoo.com
