![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
}](https://image.slidesharecdn.com/chapter6implementationsupport-200910022155/85/Chapter-6-implementation-support-11-320.jpg)
Chapter 6 implementation support
- 2. 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
- 3. 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
- 4. 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
- 5. ROLES OF A WINDOWING SYSTEM
- 6. 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
- 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 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
- 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. SEEHEIM MODEL Presentation Dialogue Control Functionality (application interface) USERUSER APPLICATION switch lexical syntactic semantic
- 19. 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
- 20. 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
- 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 • 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
- 24. 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)
- 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 • 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
- 28. 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)