Human Computer Interaction Lecture 08 [ Implementation Supportimranihsan.com/upload/lecture/HCI08 -...

4/7/2014

Human Computer Interaction – Lecture 08 [ Implementation Support ]

Imran Ihsan

Assistant Professor

www.imranihsan.com

aucs.imranihsan.com HCI08 - Implementation Support 1

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

4/7/2014

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

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

4/7/2014

roles of a windowing system

Architectures of windowing systems

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

4/7/2014

The client-server architecture

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

4/7/2014

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 – 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

4/7/2014

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

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)

4/7/2014

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

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

4/7/2014

UIMS tradition – interface layers / logical components

• linguistic: lexical/syntactic/semantic

• Seeheim:

• Arch/Slinky

presentation dialogue application

dialogue

lexical

physicalfunctional

func. core adaptor

Seeheim model

Presentation Dialogue

Control

Functionality

(application

interface)

USER APPLICATION

switch

lexical syntactic semantic

4/7/2014

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 presentation dialogue application

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

4/7/2014

what’s this?

Control

Application

Interface

USER APPLICATION

switch

the bypass/switch

rapid semantic feedback

direct communication between application

and presentation

but regulated by dialogue control

Control

Application

Interface

USER APPLICATION

switch

4/7/2014

more layers!

dialogue

lexical

physicalfunctional

func. core adaptor

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

lexical

physicalfunctional

func. core adaptor

4/7/2014

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

MVC model - view - controller

controller

4/7/2014

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

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)

4/7/2014

PAC presentation - abstraction - control

abstraction presentation

control

Implementation of UIMS

• Techniques for dialogue controller • menu networks • state transition diagrams

• grammar notations • event languages

• declarative languages • constraints

• graphical specification

– Will discuss in detail in coming lectures

• 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 aucs.imranihsan.com HCI08 - Implementation Support 28

4/7/2014

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

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)

4/7/2014

Summary

Levels of programming support tools

• Windowing systems – 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

Human Computer Interaction Lecture 08 [ Implementation Supportimranihsan.com/upload/lecture/HCI08 -...

Documents

Transcript of Human Computer Interaction Lecture 08 [ Implementation Supportimranihsan.com/upload/lecture/HCI08 -...

MCWP 3-24 Assault Support.pdf

Lecture 3 EC Value and Implementation

AST.DT.069.c_en BOWEX - Assembling on fix support.pdf

OTDOA User Plane Location Support.pdf

fm 1-0 Human Resources Support.pdf

MP - Chapter 9 - Airline and Airport Support.pdf

Lecture 1 uml with java implementation

Riser Clamp Support.pdf

Lecture 4 Combinational Logic Implementation Technologies

Firepro Router tech support.pdf

Social Support.pdf

Lecture 17 Directory Concepts and Implementation

Lecture Slides: Lecture Implementation

MCWP 3-23 Offensive Air Support.pdf

24-GSM Support.pdf

LISEGA STD SUPPORT.pdf

TasteTech Statement of Support.pdf Motorline Letter of ...€¦ · Cater Park Businesses Statement of Support.pdf WoE LEP Statement of Support.pdf ... which can only be good for business

EECS150 - Digital Design Lecture 8 - CMOS Implementation ...cs150/sp10/Lecture/lec08...EECS150 - Digital Design Lecture 8 - CMOS Implementation Technologies Feb 11, 2010 John Wawrzynek

Dell OpenManage Essentials Device Support.pdf

EECS150 - Digital Design Lecture 8 - CMOS Implementation ...inst.cs.berkeley.edu/~cs150/sp10/Lecture/lec08-cmos.pdf · Lecture 8 - CMOS Implementation Technologies Feb 11, 2010 ...