cmps115 class 6 : user interface design
DESCRIPTION
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). - PowerPoint PPT PresentationTRANSCRIPT
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