1

Saturday, February 19

 Turn in User/Task Analyses  Cognitive Walkthrough  GUI Programming Fundamentals  Looking Forward SEng 5115 February 19, 2004

Walkthrough Analysis

2  Economical interface evaluation  low-fidelity prototype  development team • users optional  Effective, if  goal is improvement, not defense  some team members skilled  proper motivation SEng 5115 February 19, 2004

Cognitive Walkthrough

3  Goals  imagine user’s experience  evaluate choice-points in the interface  detect confusing labels or options  detect likely user navigation errors  Start with a complete walkthrough scenario  never try to “wing it” on a walkthrough SEng 5115 February 19, 2004

4

Tell a Believable Story

 How does the user accomplish the task  Action-by-action  Based on user knowledge and system interface SEng 5115 February 19, 2004

5

Best Approach

 Work as a group  don’t partition the task  Be highly skeptical  remember the goal!

 Every gap is an interface problem SEng 5115 February 19, 2004

6

Who Should Do the Walkthrough

 Designers, as an early check  Team of designers & users  remember: goal is to find problems  avoid making it a show  Skilled UI people may be valuable team members SEng 5115 February 19, 2004

How Far Along

 Basic requirements  description or prototype of interface  know who users are (and their experience)  a task description  a list of actions to complete the task (walkthrough scenario) • DO NOT try to create the action list on the fly!

 Viable once the scenario and interface sketch are completed SEng 5115 February 19, 2004 7

How to Proceed

 For each action in the sequence  tell the story of why the user will do it  ask critical questions • • • will the user be trying to produce the effect?

will the user see the correct control?

will the user see that the control produces the desired effect?

• • will the user select a different control instead?

will the user understand the feedback to proceed correctly?

SEng 5115 February 19, 2004 8

More on Questions

9  Some extras can be helpful:  What happens if the user is wrong? Feedback to self-correct?

 How would a former user of react here?

 Remember, the question is a way to help you see problems – it is a focus, not a blindfold.

SEng 5115 February 19, 2004

10

Walkthroughs are not Perfect

 They won’t find every problem  limited by nature • new users who know what task they need to accomplish • biased towards correct action sequence  limited in implementation • hard to shed the expertise of evaluators  A useful tool in conjunction with others SEng 5115 February 19, 2004

Exercise: Cognitive Walkthrough Analysis

 In non-project groups of 3-5  Users and Task to be announced  Scenario developed jointly  Perform walkthrough  identify problems  estimate error probabilities (25% intervals)  Remember who your users are!

SEng 5115 February 19, 2004 11

GUI Programming Fundamentals

13

Early Computer Interfaces

 Cards and Tapes  TTYs and “glass TTYs”  Full-Screen xmit interfaces  Full-Screen interactive interfaces SEng 5115 February 19, 2004

14

GUI Application Architecture

 High-level architecture  where GUI fits in application or suite of applications  Low-level architecture  how the GUI itself is constructed SEng 5115 February 19, 2004

High-Level Architecture

 Monolithic application  Client/server computing  Distributed modular applications 15 SEng 5115 February 19, 2004

Monolithic Applications

 Very common  often the application is 90-100% interface  perceived performance benefit to coupling  easy to implement  Implementation  either code is built in interface system, or  code (and/or interface) in C/C++  Drawbacks  consistency, other applications, no API 16 SEng 5115 February 19, 2004

Client/Server Computing

 Interface is client  interacts with user, communicates with server  Database-style application is server  client sends requests, database replies  sometimes (not often) database can initiate contact  Good API, separation, form support  Problems with high interactivity SEng 5115 17 February 19, 2004

18

Distributed Modular Applications

 Build application from many components  perform task with many applications  Method for sharing data  OLE, CORBA, Publish/Subscribe  Scripting for assembly  Visual Basic, Tcl, ...

SEng 5115 February 19, 2004

Low-Level Architecture X-Windows Model

Application Framework Toolkit X Library OS/Network OS/Hardware Device Drivers X Server Library Network February 19, 2004 19 SEng 5115

Event-Driven Programming

 Interactive programs  user drives interaction  quick response  Older, forms-based programs  submit/wait model  How quick?

 50 ms for some intense interaction SEng 5115 February 19, 2004 20

Event-Driven Programs

 No main flow of control  if needed, separate program  Setup, then process input, then clean up  Input handlers must be fast  handler responds to mouse click, key press  Core of program is event loop SEng 5115 February 19, 2004 21

The Event Loop

loop: ev = get_next_event(); h = find_hander(ev); h(ev); goto loop;  note: handlers are indexed in a table by event type, window, some detail SEng 5115 February 19, 2004 22

Program Structure

 Substantial initialization code  create objects (including screen objects)  register event handlers  do any setup processing  Event loop core  provided by most toolkits  Special cases  23 February 19, 2004

Program Objects

 Widgets  interface objects (scrollbar, button)  maintain local state  provide event handlers  provide set-up code  provide API and hooks for user code • • how to get value of scrollbar code to call when button is pressed SEng 5115 February 19, 2004 24

25

Registration for Events

 Generally handled by widgets  Typical system maps window, event type, some detail to handler routine  detail such as which key was pressed  windows may be hierarchical  handler receives a copy of the event for reference SEng 5115 February 19, 2004

UI Toolkits and Frameworks

 Programming at the low level is absurd  50-250 lines of code to manage a button on the screen • draw/redraw • • request relevant events polling loop for events  big applications would be almost impossible SEng 5115 February 19, 2004 26

Higher-Level Programming

 Toolkits provide  widgets • interface objects  event handling  geometry management • window layout  resource management • defaults, user overrides, internationalization SEng 5115 27 February 19, 2004

28

What’s a Widget?

 What is needed for a simple button?

 user interface  application programmer interface  reaction to environment • • available space defaults  event handling SEng 5115 February 19, 2004

Event Handling

 Toolkits automatically handle most events  widgets request/handle their events • provide callbacks for user code  event handlers are efficient  support for timer/file events  Toolkits provide event loop  special cases for menus/dialogs SEng 5115 February 19, 2004 29

Geometry Management

 How should windows be arranged?

 what about when the screen size (or top-level window size) changes?

 Size requests from objects (propagated)  Several strategies  fixed positions  rubber sheet  pack around a cavity  table-based layout SEng 5115 30 February 19, 2004

Geometry Management

 Fixed positions  easy to use: X, Y, width (W), height (H)  poor choice if window size can change  Rubber sheet  specify percentages for X, Y, W, H  some objects may not stretch  choice of anchor points in a region (top, bottom-left, center) SEng 5115 February 19, 2004 31

Pack Around a Cavity

 Useful for editors  object in cavity  controls around cavity  Easy to specify  side, perpendicular size  Several problems  cannot handle matrices file edit help hello there SEng 5115 February 19, 2004 32

33

Table-Based Layout

 Like spreadsheet with objects that can fill several cells  Specify which rows/columns get any extra space SEng 5115 February 19, 2004

General Process

 Two phases  Phase 1 • each window requests space from its parent • parents consolidate requests into a single one  Phase 2 • • space allocated at top level each parent divides space among children SEng 5115 February 19, 2004 34

Application Frameworks

 Application structure or architecture  higher-level objects, libraries  more interaction management  Better support for less code  declarative constraint programming  Portability  platform to platform  internationalization SEng 5115 February 19, 2004 35

GUI Tools

 GUI Builders  Data-specific tools  Visual Basic  PowerBuilder  Tcl/Tk  Java/AWT/Swing  others ...

SEng 5115 36 February 19, 2004

37

State of Practice

 Wide Variety of Interface Construction Tools  graphical layout editors  templates and object libraries  pre-defined high-level dialog support  Scripting Languages are still a Trend  Visual Basic, Tcl/Tk, etc  Still Behind State of Research SEng 5115 February 19, 2004

Constraint Programming

 Problem  each event may result in many interface changes  particularly in the case of highly responsive interfaces  e.g., buttons that are context-dependent  Example  video poker application • http://www.cs.umn.edu/Research/GIMME SEng 5115 February 19, 2004 38

Constraint Programming for Video Poker

 Hard Question: What is the Effect of “Bet One?”  changes all buttons, cards  Easy Questions  when is “Bet One” active?

• during payout and bet phase if bankroll is positive  what is its action?

• increment bet and decrement bankroll SEng 5115 February 19, 2004 39

Why/Why Not Constraint Programming?

 Why?

 localize distributed control  isolate critical program variables  more advanced constraint models  Why Not?

 not regularly available (won’t work with off the-shelf languages)  lack of training SEng 5115 February 19, 2004 40

41

Lessons on UI Programming

 Challenging Task  not well-supported by traditional training  New Paradigms  event-driven, constraints  even OO can claim a UI heritage SEng 5115 February 19, 2004

Looking Ahead

 Next week: Heuristic Evaluation  Prototypes and Walkthrough Scenarios Due 42 SEng 5115 February 19, 2004

First Prototype

   On paper Have enough copies for TA and each team member Key criteria -- level of detail needed for non-user evaluation  Needs to have all visible labels, menu items, controls to support walkthrough  Should identify planned shortcuts, error messages for heuristic eval SEng 5115 February 19, 2004 43

44

Scenarios

 Step-by-step instructions for completing two or more of the tasks in your prototype  Level of detail needed to accomplish without task knowledge  Cross check level of detail in prototype SEng 5115 February 19, 2004