0% found this document useful (0 votes)
6 views

Slides

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

Slides

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 161

Informatics 131

Human-Computer Interaction

David G. Kay
[email protected]
http://www.ics.uci.edu/~kay/courses/131/Slides.pdf
Acknowledgements and caveat
These slides draw liberally, with permission, from the
Informatics 131 slides of Prof. Alfred Kobsa.

Caveat (beware): At best, PowerPoint slides are only a pale


imitation of the entirety of a class meeting. In Informatics 131
in particular, the lectures will cover topics beyond what
appears in these slides. Don’t rely on them as a substitute for
attending class.
Informatics 131 Overview
• The field of HCI
• Human characteristics
• Development and evaluation methodology
• Menu of technologies
• Guidelines and results
Why are we here?
• User interfaces matter: for efficiency, for
convenience, for commercial success, even
for life and death
• People time is more expensive than
computer time
• Everyone has stories of bad user interfaces
• Further examples •
What is HCI?
• Narrowly: 1 user, 1 computer
– Focus on software, layout and operation of UI
• Broadly: people and computers
– Users’ mental processes, work practices
– Training; collaboration; management
– Social/organizational/health issues
Six aspects of HCI
• Human abilities (perception, memory, …)
• Technologies (windowing, mouse, VR, …)
• Design methods (prototyping, lifecycles, …)
• Evaluation methods (experiments,
observation, …)
• Guidelines and results (what has been proven to
work in particular situations, e.g., typography)
• Implementation tools and techniques (Infx 133)
Informatics 131’s place in the
spectrum

• CS 161 [eternal]
• CS 151-2, 132-3, 141-2A-3A [verifiable but
subject to technology changes]
• Informatics 111-3-5, 121-2-3 [software focus]
• Informatics 131 [user focus]
• Informatics 161 [social focus, few experiments
possible]
Infx 131 Recurring Themes

• People are diverse, unpredictable, messy,
and ill-understood
• You (the designer) may not be qualified to
know what the user needs
• You have to evaluate constantly, at every
stage of development
• The later you are in the development cycle,
the more it costs to make changes
How did we get here?
• Once, it was enough if the system just
worked (most of the time)
• Once, the burden was on the user
• Today, you have to care: Success of a
product (and well-being of users) depends
on good UI
Administrative Stuff
• Syllabus
• Your “HCI Notebook”: Carry it with you
always!
How do we know a UI is good?
• Analyze using “common sense”
• Develop a theory of “human cognitive
processing” to predict users’ problems
• Test the UI on actual users; problems arise
– Generalize findings, develop guidelines for
avoiding problems: Usability Engineering
• But how can we know it’s problem-free?
Usability goals
• Satisfaction (utility, effectiveness, experience)
• Safety/robustness
• Efficiency (time, movement)
• Learnability
• Memorability
Usability principles/heuristics
(Jakob Nielsen)
• Visibility of system •
Recognition over recall
status •
Flexibility and
• Match between efficiency of use
system and real world •
Aesthetic and
• User control and minimalist design
freedom

Help users recognize,
• Consistency and
diagnose, and recover
standards
from errors
• Error prevention

Help and documentation
Informatics 131 Overview
• The field of HCI
• Human characteristics
• Development and evaluation methodology
• Menu of technologies
• Guidelines and results
Human perception and cognition
• If we’re designing web sites for human
users, it only makes sense to know
something about “how people work”
• Our brains don’t just “take pictures”: They
process, select, categorize, model
Cognition
• Attention • •
• Perception/recognition
• Memory
• Learning
• Reading, speaking, listening
• Problem-solving, planning, reasoning,
decision-making
Gestalt principles
• Whole picture, perception in context
• Use these to reinforce meaning, guide user •
• Proximity •
• Similarity •
• Closure •
• Continuity • •
• Symmetry •
Memory
• Sensory, pre-attentive
• Short-term
• Long-term (with practice, repetition)

• Recognition vs. recall


• Active vs. passive learning
Pre-attentive processing
• Before you get to conscious attention
• Examples: length, width, size, number,
closure, color, intensity, flashing, direction
of motion • •
Conceptual/mental models
• Model: abstraction, simplification
• How user thinks of system/device/product
• Functional (how it works, how to use)
– Should match the task
• Structural (how it’s organized, built)
– Harder to acquire from experience
– Useful for extension, integration
• May not match reality
– Maybe that’s okay
Metaphors
• A package of elements
– Analogy with real-world items
– Draw on user’s knowledge, experience
• Metaphors only go so far
• Typewriter, desktop, book, filing cabinet • •,
office, library, building •, city •, agent •
Agents
• Another metaphor
• Abstract, animated, embodied/physical
• Credibility comes from
– Agency: take action, deliver results
– Responsiveness: infer goals, learn about user
– Predictability on basis of character
– Trustworthiness: consistent actions for character
Guidelines to Reduce Memory
Burden
• Use recognition instead of recall
• Help users chunk information
• Require as little short-term memory as
possible
• Consider users’ mental models
• Provide visual clues and memory aids
• Provide feedback: Let users know their
input was received
Affordances: giving a clue
• What the user can see that an object does
• Chairs afford sitting; handles afford pulling
• By now, many users are used to on-screen
conventions (affordances are just perceived)
– Learned conventions
– E.g., buttons and scrollbars—clear to novices?
– Metaphors, e.g. play/pause button
Pull the handle. Does the door open?
Twist the handle; it doesn’t turn. Is the room locked?
An affordance for pushing
An espresso machine in a
dentist’s waiting room

Text
The coffee capsule goes
under the clear plastic part of
the “bull’s eye.” How do
you insert it?
Human vision for color
• About 180º
of arc
• Light
reception
happens in
retina (back
of eye)
The retina
• Fovea (highest-
resolution area)
– Just 2º of arc
– 75% of visual
operations
• Not like a camera;
doesn’t take the
whole picture at
once •
Photo-
receptors
in retina

• Rods: Degrees of brightness; not in fovea


• Cones: Colors; in fovea mainly.
– Red-sensitive (64%): many in fovea
– Green-sensitive (32%): many in fovea
– Blue-sensitive (2%): not in fovea; evenly
distributed over retina
Guidelines based on physiology
• Avoid blue for small objects
• Blue is good for background
• Neighboring objects should not differ just
by amount of blue a a a
• Put small red and green objects in center
• Add other emphasis to red and green
warning signals on the periphery
• Black, white, yellow, blue OK on periphery
Graphical coding
• We can use differences in

color / shape / words / line width / size / …
to distinguish objects of the same type
(icons, controls, data, lines in a graph, …)

• Which features work best?

Table from Maguire (1987) •


Menu selection time
• Selection time = search time (“S”) +
– if using keyboard, time to press key(s)
– if using pointer, positioning time (“P”) +
activation time (e.g., to click mouse)
• For beginners searching menu size n:
– if label unknown, examine all items, S ~ n
– if label known, search linearly or randomly; in
either case, S ~ n
• Experts can remember position; S is constant
Menu positioning time (“P”)
• Fitts’ Law: P = C1 + C2(log2(2D/W))
– C1 and C2 are constants depending on device
– D is distance to the center of the target
– W is size (width) of the object (how much can
you miss its center by?)
• The time to acquire a target is a function of
the distance to and size of the target
• Screen edge: no chance to overshoot (size is
effectively infinite)
Learning modes (sensory input)
• Visual
• Auditory
• Kinesthetic

• Exercise from Saundra Sparling


Why is natural language hard?
UNDERSTANDING
(APPROP. RESPONSE)

• It’s hard to recognize •


Understanding (even
speech written language) is
– Continuous harder still
– Individual differences –
Paraphrase
– Rapid speech –
Ambiguity
(disambiguate by
providing context)
How interfaces affect users
• Design to evoke positive responses
– Feel at ease, enjoy experience, trust system
– Play to users’ emotions
• Avoid user frustration
– Gimmicks, error messages, overburdened users
• Anthropomorphism
Communication & collaboration
• People work in a social context
• Rules and conventions for social interaction
– Conversation (facilitate flow)
• Synchronous, asynchronous
– Coordination (facilitate action)
– Awareness of status
• Computer-supported cooperative work
• Ethnography: Observe people and describe
What affects trust?
• If less is at risk, less trust expected
• Perceived similarity: Users trust sites they
think reflect concerns similar to their own
• Status or standing: Social leader endorsement
• Consistent behavior: Actions match words?
• Certification: Doctors, e.g., are licensed
• Referrals: Users are likely to trust someone
they know (or someone like them, as above)
How to foster trust
• List what security precautions the site takes
• Observe good business practices (follow
through on delivery dates, return policy, ...)
• Have a privacy statement: what info is
gathered, how it will be used, allow opt-in
or opt-out of use
HP Cooltown • (ubiquitous comp.)
• What inferences does the system make?
• What connections are necessary?
• What are possible pitfalls?
• What’s your (emotional) reaction?
Informatics 131 Overview
• The field of HCI
• Human characteristics
• Development and evaluation methodology
• Menu of technologies
• Guidelines and results
HCI design
• Many roles (HCI designers, graphic
designers/artists, tech writers, user reps,
management reps, programmers)
• Determining users’ needs, requirements
• Must precede coding
• Guidelines to follow
• Evaluation throughout process
User-centered design
• Early focus on users (cognitive, behavioral,
attitudinal characteristics) and tasks
• Actual measurement: observe, record,
analyze users’ reactions and performance
• Iterative design: find problems, fix them,
test again
• Users’ involvement in process
User-centered design
• Affects product acceptance and success
• Makes users active stakeholders
• Manages expectations
• Gets head start on training
• Communicates without sales hype
• Provides vital information about needs,
requirements, usability
Traditional software development
“waterfall model”
This is not how we do user-centered HCI design
ID process (Preece)
• Identify needs, establish requirements
• Develop alternative designs (unlike
software design)
• Build interactive versions of designs
(prototypes)
• Evaluate designs
• Iteration is inevitable
ID process model (Preece)
Identify needs/
establish
requirements

(Re)Design
Evaluate

Build an
interactive
version

Final product
HCI design process (McCracken)
• Needs analysis
• User and task analysis
• Functional analysis
• Requirements analysis
• Setting usability specifications
• Design
• Prototyping
• Evaluation
DESIGN

PROTOTYPE

EVALUATE

MEET USER READY TO


SPECIFICATIONS? IMPLEMENT
NO YES
Doing user-centered design
• Who are the users (and other stakeholders)?
• What are their needs and requirements?
• Are there external (environmental)
considerations?
• Where do we find users to test our design?
• How do we measure success/usability?
Identify all the stakeholders
• Primary (directly interacting) users, but also:
• Secondary users (e.g., grocery customer)
• Managers
• Recipients of product’s results
• Purchasing decision makers
• Competitors’ users
Human users are diverse
• Physically (hand size, height, strength,
coordination, disabilities)
• Cognitively
• Culturally
• Experientially
• Motivationally
Needs and requirements
• Want to understand users, task, context
• Kinds of requirements
– Functional: what it does
– Non-functional: e.g., memory reqts, delivery time
– Data: what info is stored, in what form
– Environmental: physical, social, org’l context
– User: what users will be like
– Usability: what balance of factors
Gathering requirements data
• Questionnaires
• Interviews
• Workshops and focus groups
• Naturalistic observation
• Studying documentation
• Choose based on kind of task, on data
provided, cost, time required, what analyst
needs to know
Problems gathering data
• Identifying, involving stakeholders
• Availability of key stakeholders
• Ownership of reports, versions
• Communication (with users, within team)
• Domain info hard to get or articulate
• Political problems in organization
• Changes in economic or business situation
Data gathering guidelines
• Focus on identifying stakeholder needs
• Involve all stakeholder groups, more than
one person from each
• Combine techniques; use props, prototypes
• Run a pilot session (user testing!)
• Decide how to record data (audio, video,
notes)
Data analysis
• Don’t let data get stale
• Do this iteratively, too
• Decide which tools, how much formalism
– Quantitative vs. qualitative
– Scenarios (narrative) and personas
– Use cases (describe interaction with system,
alternative paths)
– “Essential use cases,” “hierarchical task
analysis” (more formal methods)
HCI design process (again)
• Identify needs and requirements (using some
evaluation techniques, e.g. observation)
• Design alternative solutions
• Build interactive prototypes
• Evaluate the prototype designs
• Repeat as needed
• Implement the final design
Generating alternative designs
• No automatic way to come up with ideas
• What kind of interaction (instructing,
conversing, manipulating, exploring)?
• Look at similar systems, at very different
systems
• Build up your repertoire, your toolbox;
expose yourself to a lot of things.
• Techniques: brainstorming, attribute listing
and variation, …
Prototyping
• Present ideas for evaluation without getting
in too deep (in time, money, commitment)
• Use sketches, storyboards, slide shows,
video simulations, physical objects, mock-
ups, skeleton software
• Build model of work flow, task design,
screen layout, information display, difficult
or critical aspects
High-fidelity prototyping
• Same materials as final product
• Realistic-looking results
• Tools include MacroMedia Director,
Dreamweaver, VB, …
• Users’ expectations and focus?
Low-fidelity prototyping
• Unlike the final form
• Quick, cheap, easily changeable
• Examples
– Sketches
– Index cards
– Storyboards
– Sticky notes
• Paper prototyping • • •
Prototyping considerations
• Models necessarily omit detail
• Horizontal vs. vertical approach (breadth
vs. depth)
• Other tools
– “Wireframe” systems (e.g., balsamiq.com,
gomockingbird.com)
– Scripting languages (e.g., Tcl/Tk)
Do it: Design a system for
reserving movie or theater tickets
• Groups of 3 or 4: each of you will act as a
user and as a designer
• Don’t be constrained by existing systems
• Determine the context, requirements, tasks
• Come up with two alternative designs and
(low-fidelity) prototypes of each
• Deliverables: A five-minute overview of
your alternatives and highlights
(innovations, hard decisions, disagreements)
Do it: Design a UI for a home
automation system
• Assume wireless addressing of appliances.
Platform: Choose computer or smartphone.
• Groups of about 5
• Determine the context, requirements, tasks
• Come up with (low-fidelity) prototype
• Deliverable: 5 min. overview of your
design’s highlights (innovations, hard
decisions, disagreements); paper sketch with
date and group members’ names
Evaluation
• Formative vs. summative
• Four paradigms
– Informal feedback
– Walkthroughs
– Field studies
– Predictive evaluation
• Goals: find problems or new opportunities,
check conformity with guidelines,
standards, requirements, …
Evaluation planning
• Determine high-level goals
• Explore questions to be answered
• Choose evaluation paradigm and techniques
• Identify practical issues
• Decide how to handle ethical issues
• Evaluate, interpret, and present results
Designing a study
• Reliability: results are repeatable
• Validity: measuring what you want to measure
• Biases: should not be introduced by process
• Scope: breadth of findings’ applicability
Interviews
• Structured/scripted vs. unstructured/open-ended
• Avoid long, compound questions
• Avoid unfamiliar terms
• Avoid questions that embody assumptions
• Avoid biases
• Intro, warm-up, main body, cool-off, closing
Questionnaire development
• Paper vs. electronic, closed vs. open-ended
• Checkboxes, rating scales, prose responses
• Design
– Start off-line even if goal is electronic
– Questions all positive, all negative, mixed
– Pilot-test questions for clarity, sufficient space
– Consider analysis
Increasing questionnaire response
• Expect 20%–40% rate (less online)
• Make purpose clear
• Promise anonymity
• Design well
• Offer short version
• Provide stamped return envelope
• Follow up
• Provide incentive
Expert critiques
• Heuristic evaluation w/ guidelines (Nielsen)
– Brief 3–5 experts
– Each works separately 1–2 hours, two passes
– Debrief experts together
• Cognitive walkthrough
– Tell expert assumptions, context, task
– Expert walks through prototype w/ usage scenarios
– Will user know what to do? Will user see correct
action is available? Will user understand response?
Observing users
• In the lab
– Walkthroughs with low-fi prototypes
– Instrumented sessions with higher-fi systems
• In the field
• Consider, as always, who’s involved, their
goals, their actions, their feelings, the
relevant objects and events
Usability walkthroughs
• Make an explicit test scenario (test plan)
• Test the test (pilot study)
• Recruit subjects
• Conduct test
• Debrief subjects
Roles in walkthroughs
• Greeter gets user settled
• Facilitator talks to user during testing
• Computer (a person) manipulates interface
elements
• Observer(s) take notes
User testing
• A part of usability testing
• Smaller-scale, less formal, more focused than
full-blown usability research
• Can be quantitative: time to complete,
number of errors, number of help requests,
number of users completing task successfully
• Can include keystroke-level monitoring
• How many users?
Le mieux est l’ennemi du bien.
(The best is the enemy of the good.)

—Voltaire
[“Dramatic Art” in Philosophical Dictionary, 1764]
Evaluation exercise
• Start with your ticket reservation system
• Decide on the one aspect that most needs
testing/evaluation (maybe a controversial issue
in your group)
• Design an evaluation plan to test that aspect
(give specific task, technique, design)
• Describe your plan on one page (informally,
possibly with outline or sketches)
• Present to the class
• Turn in page with names of group
Informatics 131 Overview
• The field of HCI
• Human characteristics
• Development and evaluation methodology
• Menu of technologies
• Guidelines and results
Interaction styles (traditional)
• Command entry
• Menus
• Direct manipulation
• Form fill-in
• Natural language
Interaction styles (new)
• Immersive/virtual reality
• Ubiquitous/pervasive computing
• Robotics
Conceptual models for activities
• Giving instructions
• Conversing
• Manipulating, navigating
• Exploring, browsing
Direct manipulation
• GUI objects representing task objects/funcs
• Pointing device
• Based on consistent metaphor
• Congruent operations, always available
• Immediate feedback
• Form of icon or cursor on rollover can
indicate possible operations
Interface hardware (I/O devices)
• Appropriate for users’ tasks
• Suitable for intended work environment
• Match user’s physical characteristics
– age, dexterity, impairments, injury avoidance •
• Match user’s psychological characteristics
– computer skills, capacity for learning
Survey of output devices
• Printers, of course; 3D printers
• Displays (CRT, LCD, …)
– Wearable • • • or room-scale • •
• Audio (speech or non-speech)
• Tactile •
• Olfactory •
• Specialized for disabilities (e.g., Braille •)
Survey of input devices
• Keyboards: QWERTY, Dvorak •, chording • •,
thumb •, numeric, arrows; split/concave •
• Pointers: Mouse, trackball • •, trackpad, joystick,
pen •, 3D •
• Touchscreen
• Speech input
• Handwriting, gestures, “Graffiti” •
• Data gloves • •, data suits, 3D trackers
• Accelerometers, gyroscopes, proximity sensors
• Specialized for disabilities
Hand-held devices
• Often used without watching (“eye-less”), so
highly tactile keypads helpful (Cf. iPhone)
• Highly targeted info (personalization)
• New interaction paradigms:
– Motion-invariant displays •
– Touchscreen dragging (page-flipping) •
– Hand mirror metaphor •
– Keyhole/flashlight metaphor
Informatics 131 Overview
• The field of HCI
• Human characteristics
• Development and evaluation methodology
• Menu of technologies
• Guidelines and results
Design principles (indep. of style)
• Consistency (internal, •
User control
external) •
User diversity,
• Advance information • personalization •
• Immediate feedback • •
Shortcuts for experts
• Easy reversal (undo •) •
Online help •
• Error prevention, help • •
Learning aids •
• Minimal short-term
memory
How do we organize information?
• How do users group concepts together?
• How do we name the groups?
• How do the groups relate to each other?
Organizational schemes
• Exact: alphabetical, chronological,
geographical
• Inexact/ambiguous: topical, task-oriented,
audience-specific
• Combinations
Organization structures
• Shape can be hierarchical, linear/multipath,
network/web, matrix
• Unrestricted
linking makes
orientation hard
• Network/web
structures hard
for beginners
• Database •
Hypermedia and the WWW
• Nodes (info in many media)
• Visible links to other nodes
• HCI view: navigation between pages,
information presentation, multimedia layout
• More than just HCI design • • • •
Visual organization principles
• Use proximity, alignment, consistency,
contrast to good effect
• More closely related things should be closer,
aligned, consistent
• Less closely related: further, contrasting
• Every difference (in size, color, type,
placement) should have a reason or meaning
HCI for Web (Farkas & Farkas)
• 1.1: All links indicate they’re links •
• 1.2: Help viewers notice links
• 1.3: Links clearly indicate destinations
• 2.1: Effective breadth and depth in hierarchies •
• 2.2: Add secondary/shortcut links where
approp.
• 2.3 Allow branches to converge where approp.
• 2.4 Reveal underlying information structure •
HCI for Web (Farkas & Farkas) 2
• 3.1: Clear, conspicuous orientation at top •
• 3.2: Support exploration • • • •
• 4.1: Use site maps for structure and direct
access • • •
• 4.2: Provide search facility or index for
direct access
• 4.3: Provide links to home page throughout
“Information scent”
• Link should “smell right” to user: confidence
before clicking, feel closer afterwards
• Practical measure (Spool 1998):
– Ask users before clicking what they think they’ll get
– Ask how confident they are (–2 to +2)
– Ask users after clicking if they felt closer (–2 to +2)
– Add the two figures
– Accumulate those sums as you go from link to link;
the result should keep increasing
Advance information
• What’s possible now? What will happen next?
What can I do now?
• Prevent errors, unexpected results
• Guidelines
– Give visual indicators, not just text •
– Distinguish unselectable menu items, objects
– Change cursor shape •
– Show submenus on rollover •
– Show data entry format • •
– Indicate long operations, ask permission •
Feedback
• User action, system reaction (ideally < 0.1 sec)
• Guidelines
– Highlight items on rollover
– Mark selected items •
– Show path in navigation hierarchy
– Report errors immediately
– Use status or progress indicators
– Use visual, auditory, and tactile modes
– Make reaction time uniform
Undo
• Encourages users to explore functionality
• Guidelines
– Special-purpose undo (e.g., backspace)
supplements general
– Try to make everything undoable (external
effects clearer to users than internal)
– Multiple undo (undo/redo or linear sequence)
Error avoidance
• Provide advance information
• Keep dangerous controls away from
frequently used ones
• Warn users of irreversible effects; don’t
make them the default; request confirmation
• Turn safety options on by default
• Recognize errors and react ASAP
Error messages and actions
• Explain nature of problem, how user can
solve it (at least with correct examples)
• Describe in terms of user’s task
• Use polite language • • •
• On crash, give opportunity to save
• Support force quit and relaunch
Shneiderman’s error message
guidelines
• Avoid “fatal,” “invalid,” “bad”
• Avoid ALL CAPS, cryptic numbers
• Give control over audio feedback
• Give precise messages
• Provide context-sensitive help
Help: different types
• Tutorial or getting-started manuals
• Guided tours
• Reference manuals
• Reminders (reference cards, keyboard
templates, rollovers)
• Wizards (to walk through tasks)
• Tips
• On-line help (searchable)
Online help
• Available, consistent for all system functions
• Including currently unavailable options
• Situation-sensitive and concrete
• Written in terms of user’s task
• Not obscuring relevant items; movable
• Initially short with details on request
• Good ID reduces need for explicit help
Tours, tutorials, manuals
• Tour should be short, hit highlights
• Encourage active learning (e.g., user actions,
quizzes), address users directly, give examples
• Manuals are last-resort, comprehensive
sources
• Use tech writing specialists where possible
Command interface guidelines
• Use action words, verb first (move a b),
direct object as first argument
• Use congruent names (advance/retreat, not
move/back)
• Allow abbreviations, syntax flexibility,
aliases
• Provide command history (edit, re-enter
recent commands)
• Multiple args, wildcards, macros, scripts
Menu interaction overview
• Activities: navigation, selection, activation
• Selection: mouse, keys, key + return, touch
• Types of menus •:
– Text, graphical •, combination
– Linear, tabular •
– Static (e.g., menu bar), pull-down, pop-up
– Isolated, connected (hierarchical)
– Pie menus •
Menu item guidelines • •
• Head/title: short, meaningful, centered,
upper/lower case, clean design
• Show: selectable items, non-selectable
items, already-selected items, submenu
availability, how to select (besides mouse)
• Entries: short, meaningful, distinguishable
(most significant word first)
• Shortcuts (first letter); external consistency
Menu length, item order guidelines
• Keep short for beginners
• Group according to task
• Put frequent items near top for beginners
• When multiple selection allowed, group
frequent combinations
• Separate dangerous items from frequent ones
• As last resort, use alpha, time, numerical order
Menu dynamics guidelines
• Highlight item under cursor
• Show submenus of item under cursor
• Maintain indication of selected items
• Allow leaving without any selection
• Maintain positional constancy (grey out)
• Maintain visibility against all backgrounds •
Menu hierarchy guidelines
• Avoid deep nesting
• Top, bottom level menus can be longer
• Longer menus better when under pressure
• Avoid scrolling
• Construct hierarchy by theme
• As before: show submenus, moderate length,
external consistency, shortcuts to deeper items
Graphical menu guidelines
• Make items (icons) recognizable, distinct
• Emphasize global properties (form, color, size)
over fine details
– Abstract icons faster than concrete, text • •
• Give similar icons to similar objects/functions
• Use easily understandable (or learnable) icons
• Textual labels help beginners, infrequent users
Adaptable vs. adaptive menus
• Adaptable: user (or admin) can change
(shortcuts, hide/delete/move/duplicate items)
• Adaptive: automatic change (e.g., based on
usage frequency) violates constancy
Form design guidelines
• Allow entry in tables or labeled data fields •
• Left-align labels, fields, columns in tables •
• Arrange sequences in columns •
• Use meaningful, unambiguous labels
• Mirror layout of paper source document
• Use adequate white space • •
• Tell user expected form of data; indicate if
required
• Allow enough space for expected data
Data entry in forms
• Tab or return should move to next field
• Fill fields with default/most recent/inference
• Allow entry in arbitrary order
• Allow abbreviation/expansion
• Show alternatives if entry not unique •
• Don’t supply dangerous values as auto entries
• Detect, indicate, explain errors; allow multiple
corrections
• Don’t require re-entry of correct data
General screen guidelines
• Reflect structure of task, not of implementation
• Group info for coherent subtask on one screen
• With multiple, related screens
– Use same headlines
– Present necessary info on each screen in same place
– Allow navigation to previous screen, access to help,
ability to exit subtask or whole program
Special screen areas
• Title at top, distinguished
• Can use bottom for status info, explanation,
warnings
• Logos typically upper left or upper right
• Clocks (no seconds, no ticking)
Screen layout
• Use proximity, alignment, consistency, contrast
• Use adequate whitespace (60%–80%)
• Alternatives to whitespace for grouping:
– Lines
– Boxes
– Colored/shaded backgrounds
Guidelines for windows
• Windows make it easy to distinguish
– applications
– info or objects within applications
– events stacked in time (e.g., errors, dialogs)
• Tiled windows easiest for beginners, but
overlapping ones are far more flexible
• Signal which window is on top or active
– partial occlusion
– 3D effects (shadow, lighting) or graying out
Color depends on context
• Adds information, interest, emotion
• Perception affected by what other colors are
nearby •
• Cultural connotations
• Color harmony schemes (kuler.adobe.com,
colorschemedesigner.com)
Recommended uses of color
• Emphasis, grouping (especially as background)
• Coding discrete or continuous data • •
• Distinguishing window types
• Visual separation of overlapping graphics
• Depth in 3D graphics (red closer, blue farther)
• Warnings, status reports
• Increasing attractiveness (within guidelines)
Users with disabilities
• Manual/dexterity; visual; auditory; cognitive
• Various legal requirements to make software
and websites accessible:
– Americans with Disabilities Act (ADA •)
– 1998 amendment to Rehabilitation Act of 1973
(www.section508.gov •)
– Institutional directives (e.g., UCI’s Electronic
Communications Policy)
– Web Accessibility Initiative (www.w3.org/WAI •)
Vision
• Blindness, impaired vision, color blindness,
photosensitive epilepsy
• Technologies
– Screen-reading software
– Braille “displays”
– Descriptive audio
– Screen magnifiers (software, hardware)
– Vischeck.com • (software to simulate and
compensate for color blindness)
Considerations/guidelines (visual)
• Allow magnification
• Color-code only large areas
• Avoid frequent color switches
• Color deficiencies (“color blindness”): 8% of
European-descended males (0.5% of females)
see red/green as medium gray
– Design for monochrome first; add color for redun-
dancy; at least don’t just differ by red vs. green
• Special devices, software, design guidelines
Hearing
• Technologies
– Captioning
– American Sign Language (automatically generated
by an animated avatar, asl.cs.depaul.edu •)
Mobility
• Trouble with keyboard and/or mouse
• Caused by disease, injury, RSI, aging
• Technologies
– One-finger sequential typing for, e.g., Ctl-X
– Ignore brief or repeated keystrokes
– Move pointer using keyboard
– Predictive typing; cycle-until-stop
– Head/foot/mouth/gaze/speech control devices
Considerations/guidelines (manual)
• Provide access by keyboard and by pointer
• Provide alternative to simultaneous keystrokes
• Provide alternatives to voluminous data entry
(defaults, completion, aliases/shortcuts, cycling
through until user hits key to stop)
• Provide special devices
Evaluation of accessibility
• Try turning off images, sound, Java
• Try larger-than-normal font sizes
• Try smaller-than-normal screen or window
• Try monochrome display
• Try it without a mouse
• Try it with a text-only or voice browser
• Use Wave •, Bobby •, A-Prompt • tools
• Do user testing
Globalization
• They don’t call it world-wide for nothing
• Internationalization: Identify and isolate
culture-specific items
– Text
– Numbers (34.50 vs. 34,50, $ vs. £, units)
– Dates/times (y/m/d, AM/PM, time zones)
– Colors (different cultural connotations)
• Localization: Translate or create text
appropriate to a given location
Don’t rely on automated translation
• For 60 years, a goal of computing (still unmet)
• It’s far tougher than dog = perro = chien =
• Idioms, nuances, cultural issues, non-
overlapping grammatical categories
• Not just waiting for the next, faster machine:
We just don’t know enough about language
• (You shouldn’t rely on the grammar checker in
Word, for the same reason)
• Use professional human translators
Other tricky cultural issues
• Icons: Symbols and gestures differ
• Addresses
• Reading direction —> page layout
• Space for text (Exit, Salir, Quitter, Verlassen)
• User testing: in target locale and language
Virtual reality
• Three-dimensional objects and environments
• Multi-sensory input (visual, auditory, haptic)
• User feels immersed: user controls scene
movement, receives feedback
• Integrated technologies: displays, position
sensing for head/hand, force feedback, audio
input/output
Virtual reality applications
• Scientific exploration • •
• Architectural exploration •
• Augmented reality
• Training
• Virtual co-presence (meetings, entertainment)
Improving immersion
• Match input from at least two sensors
• Provide high refresh rate
• Minimize response time
• Provide stereoscopic vision
• Provide three-dimensional sound
Design a form
• Form groups of about 4 people
• Identify some mobile app (existing or new)
that might expect the user to enter form-
based data; any kind of app is okay
• Decide precisely what data you will ask the
user to enter
• Carefully design and sketch a form for
entering the data on the mobile device
• Turn in a sheet with group members’ names
Typography
• HCI for documents, affects effectiveness
• Display type vs. body type
– Quick recognition of letters, words, lines
• Great control now in user’s hands
– “With more power comes the power to mess up in
new and more spectacular ways.” —DGK
• Differences between displays and paper
• Less designer control for text on the WWW
Typography terms

From McCracken and Wolfe,


User-Centered Website Development
Font size: baseline to baseline

From McCracken and Wolfe,


User-Centered Website Development
Line spacing (leading) matters

From McCracken and Wolfe,


User-Centered Website Development
Serif vs. sans serif

Times New Roman


Georgia
Arial
Verdana
Monospace vs. proportional spacing

f("It’s")-1; // Courier
f("It’s")-1; // Andale

f(“It’s”)-1; // Times
f(“It’s”)-1; // Georgia
f(“It’s”)-1; // Helvetica
Typeface guidelines (characters)
• Mix upper and lower case
• Choose proportional spacing over monospace
• Use fonts with varying stroke width
• Choose serif over sans-serif fonts
– But on the web …
Margin justification
The sun did not shine, it was The sun did not shine, it was
too wet to play, so we sat in the too wet to play, so we sat in the
house all that cold, cold wet house all that cold, cold wet
day. I sat there with Sally, we day. I sat there with Sally, we
sat there, we two, and I said, sat there, we two, and I said,
“How I wish we had something “How I wish we had something
to do.” Too wet to go out and to do.” Too wet to go out and
too cold to play ball, so we sat too cold to play ball, so we sat
in the house. We did nothing at in the house. We did nothing at
all. all.

And then something went, And then something went,


“Bump!” How that bump “Bump!” How that bump
made us jump! We looked and made us jump! We looked and
we saw him step in on the mat. we saw him step in on the mat.
We looked and we saw him: We looked and we saw him:
The Cat in the Hat. And he said The Cat in the Hat. And he said
to us, “Why do you sit there to us, “Why do you sit there
like that?” like that?”

Rag-right Flush right


Typography/text guidelines
• Keep lines short (10–12 words; max chars
35? 50? 70?)
• Don’t justify margins
– Extra white space
– Justification and monospace fonts
• Consider extra leading
• Minimize number of fonts
• Use emphasis minimally
Graphic design critique

www.ics.uci.edu/~kay/whatswrong.pdf •
Information visualization
• Allows understanding of huge amounts of data
• Allows perception of unanticipated properties
• Reveals problems with data itself
• Facilitates understanding of large- and small-
scale features of data
• Facilitates hypothesis formation

Ware, Information Visualization


Edward Tufte (Yale)
• The Visual Display of Quantitative Information
• Envisioning Information
• Visual Explanations
• Beautiful Evidence
Tufte on graphical integrity
• Make physically measured representation
proportional to quantity being represented
• Use clear, detailed, thorough labeling
• Show data variation, not design variation
• Deflate and standardize monetary figures
• Dimensions in representation ≤ dimensions
in the data
• Don’t quote data out of context
Tufte on producing data graphics
• Above all else show the data
• Maximize the data-ink ratio
• Erase non-data-ink
• Erase redundant data-ink
• Revise and edit
Tufte on graphical excellence
• Well-designed presentation of interesting
data—substance, statistics, design
• Complex ideas communicated with clarity,
precision, efficiency
• Greatest number of ideas in the shortest
time with the least ink in the smallest space
• Multiple variables presented
• Data represented truthfully
What would Tufte say
about reducing his principles
to bullet points?
Informatics 131 Overview
• The field of HCI
• Human characteristics
• Development and evaluation methodology
• Menu of technologies
• Guidelines and results
End-of-quarter logistics
• Final exam
– Tuesday 11 September, 1:00–3:00, DBH 1431 (here)
– Covers the whole course, more or less evenly
– Mostly similar to midterm in form
– You may bring any paper materials, as before
• Please do the course evaluation on EEE
Looking forward
• Informatics 132, Project in HCI Requirements
and Evaluation
• Informatics 133, User Interaction Software
• Informatics 134, Project in UI Software
• Informatics 143, Information Visualization
• Informatics 153, Computer-Supported
Cooperative Work

You might also like