Support for the Development of Interactive Systems

1. 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: +39 06 49918548 • Web: http://www.dis.uniroma1.it/~kimani • E-mail: kimani@dis.uniroma1.it • Tutorial Resources: http://www.dis.uniroma1.it/~kimani/teaching.html

2. 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

3. HCIDevelopment 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

4. HCIDevelopment 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).

5. HCIDevelopment 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

6. HCIDevelopment 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.

7. HCIDevelopment 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.

8. HCIDevelopment 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 itselfe.g., programming on the Macintosh. • Notification based • The main control loop does not reside in the application itselfe.g., a C program with XViewer notifier.

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

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

11. HCIDevelopment 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

12. HCIDevelopment 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?

13. HCIDevelopment 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

14. HCIDevelopment 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?

15. HCIDevelopment 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).

16. HCIDevelopment 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).

17. HCIDevelopment 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.

18. HCIDevelopment 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: • Presentation (has both input and output). • Abstraction represents application semantics. • Control handles communication and maintains consistency between Presentation and Abstraction.

19. HCIDevelopment Support Main UIMS Conceptual Architectures The Main UIMS Models

20. HCIDevelopment 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.