implementation support system activity program m ing the - PDF document

Implementation support • programming tools chapter 8 – levels of services for program m ers • windowing system s – core support for separate and sim ultaneous user- implementation support system activity • program m ing the application and control of dialogue • interaction toolkits – bring program m ing closer to level of user perception • user interface m anagem ent system s – controls relationship between presentation and functionality Introduction Elements of windowing systems How does HCI affect of the program m er? Device independence program m ing the abstract term inal device drivers im age m odels for output and (partially) input Advances in coding have elevated programming • pixels hardware specific • PostScript (MacOS X, NextStep) � interaction-technique specific • Graphical Kernel System (GKS) • Programmers' Hierarchical Interface to Graphics (PHIGS) Layers of development tools Resource sharing – windowing system s – interaction toolkits achieving sim ultaneity of user tasks window system supports independent processes – user interface m anagem ent system s isolation of individual applications Architectures of windowing roles of a windowing system systems three possible software architectures – all assume device driver is separate – differ in how multiple application management is implemented 1. each application m anages all processes – everyone worries about synchronization – reduces portability of applications 2. m anagem ent role within kernel of operating system – applications tied to operating system 3. m anagem ent role as separate application m axim um portability 1

The client-server architecture X Windows architecture Programming the application - 1 X Windows architecture (ctd) read-evaluation loop • pixel im aging m odel with som e pointing mechanism • X protocol defines server-client com m unication repeat read-event(myevent) case myevent.type • separate window manager client enforces type_1: policies for input/ output: do type_1 processing type_2: – how to change input focus do type_2 processing ... – tiled vs. overlapping windows type_n: – inter-client data transfer do type_n processing end case end repeat Programming the application - 1 going with the grain notification-based void main(String[] args) { • system style affects the interfaces Menu menu = new Menu(); menu.setOption(“Save”); – m odal dialogue box menu.setOption(“Quit”); • easy with event-loop ( just have extra read-event loop) menu.setAction(“Save”,mySave) • hard with notification (need lots of mode flags) menu.setAction(“Quit”,myQuit) – non-m odal dialogue box ... } • hard with event-loop (very complicated main loop) • easy with notification (just add extra handler) int mySave(Event e) { // save the current file } beware! int myQuit(Event e) { if you don’t explicitly design it will just happen // close down implementation should not drive design } 2

Using toolkits interfaces in Java Interaction objects • Java toolkit – AWT (abstract windowing toolkit) – input and output intrinsically linked • Java classes for buttons, m enus, etc. • Notification based; move press release move – AWT 1.0 – need to subclass basic widgets Toolkits provide this level of abstraction – AWT 1.1 and beyond -– callback objects – programming with interaction objects (or – techniques, widgets, gadgets) • Swing toolkit – promote consistency and generalizability – built on top of AWT – higher level features – through similar look and feel – uses MVC architecture (see later) – amenable to object-oriented programming User Interface Management UIMS as conceptual architecture Systems (UIMS) • UIMS add another level above toolkits • separation between application sem antics and – toolkits too difficult for non-program m ers presentation • concerns of UIMS • improves: – conceptual architecture – portability – runs on different system s – im plem entation techniques – reusability – com ponents reused cutting costs – support infrastructure – m ultiple interfaces – accessing sam e functionality – custom izability – by designer and user • non-UIMS term s: – UI developm ent system (UI DS) – UI developm ent environm ent (UI DE) • e.g. Visual Basic UIMS tradition – interface Seeheim model layers / logical components lexical syntactic semantic • linguistic: lexical/ syntactic/ semantic Functionality Dialogue USER USER Presentation (application APPLICATION Control interface) presentation dialogue application • Seeheim: • Arch/ Slinky dialogue switch func. core lexical adaptor functional physical core 3

conceptual vs. implementation semantic feedback Seeheim • different kinds of feedback: – arose out of im plem entation experience – lexical – m ovem ent of m ouse – but principal contribution is conceptual – syntactic – m enu highlights – concepts part of ‘norm al’ UI language – sem antic – sum of num bers changes … because of Seeheim … • sem antic feedback often slower … we think differently! – use rapid lexical/ syntactic feedback e.g. the lower box, the switch • but may need rapid semantic feedback • needed for implementation – freehand drawing presentation dialogue application • but not conceptual – highlight trash can or folder when file dragged what’s this? the bypass/switch direct communication rapid semantic between application and presentation feedback but regulated by dialogue control Arch/Slinky more layers! • m ore layers! – distinguishes lexical/ physical dialogue • like a ‘slinky’ spring different layers may be thicker (m ore im portant) in different system s func. core lexical • or in different com ponents adaptor dialogue func. core lexical adaptor functional physical core functional physical core 4

MVC monolithic vs. components model - view - controller • Seeheim has big components view • often easier to use smaller ones – esp. if using object-oriented toolkits model • Smalltalk used MVC – model–view–controller – m odel – internal logical state of com ponent – view – how it is rendered on screen controller – controller – processes user input MVC issues PAC model • PAC model closer to Seeheim • MVC is largely pipeline m odel: – abstraction – logical state of com ponent input � control � m odel � view � output – presentation – m anages input and output • but in graphical interface – control – m ediates between them – input only has m eaning in relation to output • m anages hierarchy and multiple views e.g. mouse click – control part of PAC objects com m unicate – need to know what was clicked – controller has to decide what to do with click • PAC cleaner in many ways … – but view knows what is shown where! but MVC used m ore in practice • in practice controller ‘talks’ to view (e.g. Java Swing) – separation not com plete PAC Implementation of UIMS presentation - abstraction - control A P • Techniques for dialogue controller A P C C • menu networks • state transition diagrams • grammar notations • event languages • declarative languages • constraints • graphical specification abstraction presentation – for m ost of these see chapter 16 • N.B. constraints control – instead of what happens say what should be true – used in groupware as well as single user interfaces A P (ALV - abstraction–link–view) A P C C see chapter 16 for more details on several of these 5

graphical specification The drift of dialogue control • what it is • internal control – draw components on screen (e.g., read-evaluation loop) – set actions with script or links to program • external control • in use – with raw programming most popular technique (independent of application sem antics or presentation) – e.g. Visual Basic, Dreamweaver, Flash • presentation control • local vs. global (e.g., graphical specification) – hard to ‘see’ the paths through system – focus on what can be seen on one screen Summary Levels of programming support tools • Windowing system s – device independence – multiple tasks • Paradigms for programming the application – read-evaluation loop – notification-based • Toolkits – programming interaction objects • UIMS – conceptual architectures for separation – techniques for expressing dialogue 6