1. Support for the Development of Interactive Systems
HCI
Support for the Development of Interactive Systems
Presenter
Kimani, Stephen
Universita' di Roma "La Sapienza"
DIS
Via Salaria 113
Piano 2, Stanza 233
00198 Roma
Italy
Phone:
Web:
Tutorial Resources:
Opening Slide

2. Support for the Development of Interactive Systems
HCI
Support for the Development of Interactive Systems
Roadmap
Abstraction levels
Windowing Systems
UI Toolkits
UIMS
Other high level tools
Some conventions in these slides:
+ stands for advantage
- stands for disadvantage
Opening Slide

3. HCI Development Support
Abstraction Levels
Level Support Tools/Environments
High level --- GUI Builders (e.g., Flash, Visual C++, Visual Basic,
Visual Age, JBuilder), UIMS (e.g., UIDE), Seeheim- based, MVC-based, PAC-based
--- UI Toolkits e.g., XViewer, Java AWT, OSF/Motif,
Macintosh Toolbox, Software Development Toolkit
for Microsoft Windows
Low level --- Windowing Systems e.g.,
MS Windows 98/NT/2000/ME/XP,
X Window system, Apple Macintosh OS
Introduction

4. HCI Development Support
Windowing Systems
Introduction
A windowing system manages shared hardware resources and
multiple applications/contexts e.g., by separating them into different parts
of the screen.
It appropriately channels input from the input devices (e.g., keyboard and mouse)
and manages output operations on the display.
Examples of events
Window events (e.g., window resize, window move, window maximize,
window close, etc), keyboard events (e.g., key press, key release, etc),
mouse events (e.g., button press, mouse move).
Introduction

5. HCI Development Support
Windowing Systems
Level Support Tools/Environments
High level --- GUI Builders (e.g., Flash, Visual C++, Visual Basic,
Visual Age, JBuilder), UIMS (e.g., UIDE), Seeheim- based, MVC-based, PAC-based
--- UI Toolkits e.g., XViewer, Java AWT, OSF/Motif,
Macintosh Toolbox, Software Development Toolkit
for Microsoft Windows
Low level --- Windowing Systems e.g.,
MS Windows 98/NT/2000/ME/XP,
X Window system, Apple Macintosh OS
Introduction

6. HCI Development Support
Windowing Systems
Important features of windowing systems
Independence from the specifics of (/having to program) hardware devices
The programmer writes commands to an abstract terminal.
An abstract terminal understands a more generic language and can be translated to the language of many other specific hardware devices.
A particular windowing system has a fixed generic language for the abstract terminal.
The generic language is called (the abstract terminal’s) an imaging model.
Examples of imaging models: PostScript, Pixels, GKS, PHIGS.
Managing multiple applications/tasks
Windowing systems share the resources (/devices) of a single hardware configuration with several copies of an abstract terminal.
Each abstract terminal behaves as an independent process and the windowing system coordinates the concurrent processes.
Introduction

7. HCI Development Support
Windowing Systems
Possible architectures
Implement and replicate the management of the multiple processes/tasks within each of the separate applications.
Each application has to resolve the difficult issues of synchronization conflicts with the shared hardware devices/resources.
Also reduces the portability of individual applications.
Implement the management of the multiple processes/tasks within the kernel of the operating system (centralized).
Frees individual applications from the management role.
Applications must still be developed with the specifics of the particular operating system in mind.
Implement the management of the multiple processes/tasks as a separate application in its own right. An interface to other applications that is generic across all operating systems (i.e. client-server architecture). e.g., X Window system.
Introduction

8. HCI Development Support
Windowing Systems
Client-Server architecture
Two basic ways to specify the flow of control within an application:
Read-evaluation loop
The flow of control is in the application itself e.g., programming on the Macintosh.
Notification based
The main control loop does not reside in the application itself e.g., a C program with XViewer notifier.
Introduction

9. HCI Development Support
Client-Server Architecture
Read-Evaluation Loop
Programmer must
program such control
over every possible
event that the
application will
receive.
Introduction

10. HCI Development Support
Client-Server Architecture
Notification based
Programmer
free from the
disadvantage
above.
Difficult to
incorporate
some control
features.
Introduction

11. HCI Development Support
Toolkits
Level Support Tools/Environments
High level --- GUI Builders (e.g., Flash, Visual C++, Visual Basic,
Visual Age, JBuilder), UIMS (e.g., UIDE), Seeheim- based, MVC-based, PAC-based.
--- UI Toolkits e.g., XViewer, Java AWT, OSF/Motif,
Macintosh Toolbox, Software Development Toolkit
for Microsoft Windows
Low level --- Windowing Systems e.g.,
MS Windows 98/NT/2000/ME/XP,
X Window system, Apple Macintosh OS
Introduction

12. HCI Development Support
Toolkits
Toolkit
It provides a set/library of ready-made interaction objects/widgets/gadgets.
The programmer can use those objects to develop application programs.
Little or no programming effort is required e.g., the objects come with a predefined behavior.
Examples of interaction objects: text box, menu, message box, radio button, list box, etc.
Interaction objects are usually flexible (can be tailored).
Interaction objects are amenable to instantiation and inheritance cf oo p.
toolkits can enforce consistency in user interface design.
programmer can exploit oo benefits e.g., build complex objects from simple ones.
Toolkits provide a limited range of interaction objects, thus limiting the types of interactive behavior allowed.
Toolkits are expensive to create and still difficult to use.
?Most toolkits are oo structured, is the actual application program oo?
Introduction

13. HCI Development Support
User Interface Management Systems (UIMS)
Level Support Tools/Environments
High level --- GUI Builders (e.g., Flash, Visual C++, Visual Basic,
Visual Age, JBuilder), UIMS (e.g., UIDE), Seeheim- based, MVC-based, PAC-based.
--- UI Toolkits e.g., XViewer, Java AWT, OSF/Motif,
Macintosh Toolbox, Software Development Toolkit
for Microsoft Windows
Low level --- Windowing Systems e.g.,
MS Windows 98/NT/2000/ME/XP,
X Window system, Apple Macintosh OS
Introduction

14. HCI Development Support
UIMS
User Interface Management Systems (UIMS)
Also referred to as User Interface Development Systems (UIDS).
Our notion of UIMS entails:
Architecture: a conceptual architecture for the structure of an interactive system with a separation between application semantics and presentation.
Implementation: techniques for implementing an application separated from the presentation and supporting communication between them.
Follow-up: techniques for managing, implementing and evaluating a run-time interactive environment.
?Why do you think some people prefer referring to UIMS as UIDS?
?Why separate the application semantics from the presentation?
Introduction

15. HCI Development Support
UIMS
User Interface Management Systems (UIMS)
Three components of an interactive system:
presentation
application
dialog control (for handling/regulating communication between the application and the presentation)
Recall the two basic ways to program the flow of control within an application in a client-server architecture: a) Read-evaluation loop. b) Notification based.
Note that in b) the dialog control is external to the application.
Since UIMS often promote the separation between the application and the presentation, most of them fall into b). They do not, however, all use callbacks (see client-server architecture).
Introduction

16. HCI Development Support
Main UIMS Conceptual Architectures
Seeheim Model
Presentation (for the appearance of the user interface – handles both input and output for the user).
Application interface (the view of the application semantics).
Dialog control (for communication between the above two).
Introduction

17. HCI Development Support
Main UIMS Conceptual Architectures
Seeheim Model
Some concerns with the Seeheim model:
It did not provide any real directions for how future UIMS should be built. The upper component (bypasser) was intended to show that for efficiency reasons, an explicit dialog control could be bypassed. The bypasser has to do with implementation concerns and thus should not appear in the conceptual architecture (i.e. the figure).
It cannot readily take advantage of an oo (architectural) approach.
Introduction

18. HCI Development Support
Main UIMS Conceptual Architectures
The Main UIMS Models
Seeheim Model:
Presentation (has both input and output).
Application interface (the view of the application semantics).
Dialog control (for communication between the above two).
Model-View-Controller (MVC) framework (e.g. within Smalltalk, Java Swing)
Controller handles input.
View handles output.
Model represents application semantics.
Presentation-Abstraction-Control (PAC) model:
Abstraction represents application semantics.
Control handles communication and maintains consistency between Presentation and Abstraction.
Introduction

19. HCI Development Support
Main UIMS Conceptual Architectures
The Main UIMS Models
Introduction

20. HCI Development Support
Other High-Level Tools
GUI Builders
(e.g., Flash, Visual C++, Visual Basic, Visual Age, JBuilder)
Some identify themselves as
the designer's Studio, Environment, Desk, Workbench, etc.
Common trade-off with high-level tools
Ease of use versus Power.
?Similarities and Differences between MVC and PAC models.
Introduction