CMPS115 Class 6 : User Interface Design

1

CMPS115 Class 6 : User Interface Design• Due today

– Scenarios – Decomposing paper

• Next class– Deliverable: Requirements

• look at template and at example at link in deliverable webpage

– Introduction to Software Architecture by Garlan and Shaw (read and review only pages 1-16)

2

User Interface Design Principles ideas for this and following slides from Pressman’s Software Engineering, 6/e 2005

• Put the user in control• Keep the user’s memory load controlled• Consider issues of consistency

3

User Quote (user in control)

“What I really would like is a system that reads my mind.

It knows what I want to do before I need to do it and makes it very easy

for me to get it done.

That’s all, just that.”

4

Control

• Who’s in Control?– Does user adapt to computer’s model of task?– Does computer adapt to user’s model of task?

• Consider the novice user• Consider the knowledgeable, intermittent user• Consider the knowledgeable, frequent user

5

User maintains control when:

• You’ve provided for flexible interaction• You’ve allowed for interaction to be interrupted

and undoable• You’ve allowed for interface to be customized to

user’s skill level• You’ve hidden technical internals (no OS

commands needed)• You don’t force user into unnecessary actions• You’ve designed for direct interaction with objects

on the screen

6

User’s memory load

• Make UI show state with visual cues• Use meaningful defaults that can be

reset/set• Provide meaningful shortcuts• Make visual layout reflect real world task

7

Consistency

• Use the same design standard throughout all screens

• Use the same input techniques throughout all screens

8

UI analysis and design

• Model the user, task, and environment• Design the interface• Construct the interface • Validate the interface

• Iterate through these, with each pass elaborate additional requirements and resulting design

9

User analysis

• Interview the users or representatives of the users

• Interview sales, marketing, or support staff about user characteristics

10

Ask questions to understand the users

• Trained professionals, technicians, clerical, manufacturing users?

• Level of education• Learn from written materials or is class needed?• Expert typists or phobic• Age range• One gender predominates?• Compensation for users for their work is how?• Use during normal work hours or until job is done?• Integral part of job or infrequent use?• What is primary language of users?• What are consequences of mistakes?• Are users subject matter experts?• Knowledge about underlying technology needed?

11

Environment analysis

• What will be the physical location of the sw?

• Will user be sitting, standing, walking?• Will user be dedicated to this task/multi-

users required for this task?• Will there be noise, light, or space

impairments?

12

Task analysis

• What tasks will be done while user is working?

• What work is performed in special circumstances?

• What special domains are used during work?

• What is the sequence of workflow?

13

Using use cases - identify tasks and subtasksExample - computer-aided design for interior design

• Tasks– Furniture layout– Fabric selection– Wall/widow coverings

sel.– Presentation to user– Costing– Shopping

• Subtasks for furn. layout– Floor plan drawing given

room dimensions– Locate windows and

doors– Scaled drawings of furn.– Move furniture around

floor plan– Provide 3-D view of floor

plan with furniture for user

14

Objects derived from use cases

• Select physical objects from use case narratives

• Categorize into classes• Define details of the attributes of each

class• Determine operations on each of these

objects

15

Task workflow analysis

• When different user groups and user roles are to use software

• Use flow diagram called swimlane diagram• Column for each role• Bubbles for processes, flows for data• Flows between columns represent interactions

between processes of different roles• Look and feel of UI for different roles may be

different

16

Analysis for presentation of content

• Content may be from– Other parts of the application– Database accessible from application– External to application

• Format of content– Consistent location for same types?– Customizable location?– Identification of content?– Handling of large datasets? Summary available?– Color?– Error handling?

17

Steps for UI design

• Parse use cases - objects (nouns) and operations (verbs)

• Sketch set of screens• Test UI• Iterate last 2 steps

18

Common design issues

• Response time• Help• Error handling• Command and menu labeling• Consider accessibility for special needs - www

consortium Web Content Accessibility Guidelines• Internationalization guidelines are available -• www-306.ibm.com/able/access_ibm/disability.html

19

responsiveness

• Length of response time – 1 sec acceptable– More than that - use progress bar and ‘busy

icon’• Variability

– 1 sec is better than from 0.2 sec to 3.0 sec

20

Design of help features

• Provided for all features or just subset?• Available at all times?• How to request? • How presented? Window, print doc, 2-lines• How to return to normal operations?• How is help info structured? Flat,

hierarchical, hypertext

21

Command and menu labels

• Easy to remember labels? How to remind?• What is form of commands? Control seq or

typed word?• Will all menu items have commands?• Customizable and shortcuts available?• Self-explanatory labels• Do submenu items fit logically under menu

items?

22

Test the UI

• Review material from M. Rettig’s paper “Prototyping For Tiny Fingers”

23

Summary

• Weak UI may cause failure of acceptance of system

• Follow 3 principles of UI design– User in control– Reduce memory load– Consistency

• Development involves – Analysis (user, task, environment)– Design (use cases drive sketches)– Evaluate and iterate

24

Bjarne Stronstrup (designer and implementor of C++)

• “I have always wished that my computer would be as easy to use as my telephone.

• My wish has come true.• I no longer know how to use my

telephone.”

25

Client/Server Responsiveness Design project issues

• Local/Remote awareness– Server may balk; client should keep running smoothly – Optimistic response (correct if server updates otherwise)

• Threading– User thread services UI

• collects events, changes control state, posts events• not to be used for game action!

– Game thread runs engine• calculates local world based on local events and server data

– I/O thread handles network