mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-23 21:04:07 -06:00
updated 203 Notes
This commit is contained in:
Jet Hughes
parent
32ca252633
commit
f4269a4849
@ -11,6 +11,7 @@ Synchronicity - The Police - spotify:album:28eOriEfl7IGbQDNvWIWXK
|
||||
- [ ] info 201 lab 04
|
||||
- [ ] info 201 lab 06
|
||||
- [ ] change testing of contrast and brightness andie
|
||||
- [ ] fix 203 notes for disability services
|
||||
- [ ] work through 202 labs
|
||||
- [ ] 04
|
||||
- [ ] 05
|
||||
@ -19,7 +20,7 @@ Synchronicity - The Police - spotify:album:28eOriEfl7IGbQDNvWIWXK
|
||||
## Lecture/Labs
|
||||
|
||||
- [x] 10:00 Info203 Lecture
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [x] 11:00 Cosc201 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
|
||||
|
||||
@ -5,4 +5,4 @@ tags:
|
||||
- lecture
|
||||
---
|
||||
|
||||
|
||||
[heuristic-evaluation](notes/heuristic-evaluation.md)
|
||||
|
||||
@ -5,4 +5,21 @@ tags:
|
||||
- lecture
|
||||
---
|
||||
|
||||
- [wizard-of-oz](notes/wizard-of-oz.md)
|
||||
- [video-prototyping](notes/video-prototyping.md)
|
||||
- [storyboards-mockups-paper-prototypes](notes/storyboards-mockups-paper-prototypes.md)
|
||||
|
||||
# Paper protoypes
|
||||
|
||||
- brainstorming. e.g., 
|
||||
- refinement of design and communicating ideas. e.g., 
|
||||
- - evaluating interfaces
|
||||
|
||||
Example of previous years 203 work
|
||||
|
||||
|
||||
# Digital prototypes
|
||||
|
||||
Past 203 work
|
||||
|
||||
|
||||
|
||||
@ -5,4 +5,24 @@ tags:
|
||||
- lecture
|
||||
---
|
||||
|
||||
## 1 Wizard of OZ
|
||||
[wizard-of-oz](notes/wizard-of-oz.md)
|
||||
simulating machine behavior with human operators
|
||||
|
||||
## 2 Video prototyping
|
||||
[video-prototyping](notes/video-prototyping.md)
|
||||
|
||||
## 3 Creating and comparing alternatives
|
||||
create multiple ideas in parallel rather than one after the other
|
||||
|
||||
|
||||
|
||||
## Functional fixation
|
||||
|
||||
This is when you get tunnel vision about some design. This causes you to not consider other possible alternatives.
|
||||
|
||||
For example with nail problem, almost nobody consider using the nails it the way that is needed.
|
||||
|
||||
|
||||
## 4 Design heuristics
|
||||
|
||||
|
||||
@ -5,4 +5,47 @@ tags:
|
||||
- lecture
|
||||
---
|
||||
|
||||
## 1 Show system status
|
||||
- show system stats
|
||||
|
||||
- feedback depends on response time
|
||||
- <1s just show outcome
|
||||
- ~1s feedback that activity is underway
|
||||
- >>1s show fractional progress time
|
||||
|
||||
- 0.1 seconds --> feels instantaneusly
|
||||
- 1 second --> about the limit for flow to be uinteruippted
|
||||
- 10 seeconds --> the limit for keeping users attention
|
||||
|
||||
when:
|
||||
- when action is requried
|
||||
- show storage space
|
||||
- making changes
|
||||
- next steps --> user input required
|
||||
- completion --> some task has finished
|
||||
|
||||
|
||||
|
||||
## 2 familiar metaphors and language
|
||||
|
||||
|
||||
|
||||
imitating familiar real life
|
||||
|
||||
Categories
|
||||
- good
|
||||
- 
|
||||
- bad
|
||||
- 
|
||||
|
||||
## 3 user freedom and control
|
||||
|
||||
wan tt ogive th user the feelin thtey can freelyi explore the app
|
||||
and the freeodm to control i it
|
||||
|
||||
- general flow
|
||||
- undo/redo
|
||||
|
||||
e.g., 
|
||||
e.g., 
|
||||
|
||||
|
||||
@ -5,4 +5,116 @@ tags:
|
||||
- lecture
|
||||
---
|
||||
|
||||
# 1 Consistency and standards
|
||||
|
||||
|
||||
|
||||
good and bad
|
||||
- standards (user interface guidelines) are always chaning
|
||||
|
||||
differ between platforms
|
||||
evolve over time
|
||||
|
||||
e.g., menus
|
||||
|
||||
|
||||
|
||||
|
||||
general look of webpages evolves over time
|
||||
|
||||
### 1.1 Naming and teminology
|
||||
|
||||
|
||||
|
||||
this is bad
|
||||
you can ask users which categories they understand/know about
|
||||
|
||||
### 1.2 Data loss
|
||||
|
||||
|
||||
standard to minimise loss
|
||||
|
||||
## 2 Error Prevention
|
||||
|
||||
### 2.1 Bad input
|
||||
|
||||
|
||||
|
||||
correct human errors
|
||||
auto completion
|
||||
|
||||
### 2.2 helpful constraints
|
||||
|
||||
|
||||
|
||||
### 2.3 Suggestions and autocorrection
|
||||
|
||||
|
||||
|
||||
heavily abused by industry
|
||||
- they can influence suggestions
|
||||
|
||||
### 2.4 Forgiving formatting
|
||||
|
||||
|
||||
|
||||
- reduce errors
|
||||
-
|
||||
|
||||
## 3 recognition over recall
|
||||
|
||||
### 3.1 avoid codes
|
||||
|
||||
|
||||
|
||||
### 3.2 Recognition with previews or icons
|
||||
|
||||
|
||||
|
||||
### 3.3 use icons that promote recognition
|
||||
|
||||
|
||||
|
||||
## 4 Flexibility and efficiency
|
||||
|
||||
### 4.1 Choices
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
something with immediate effect can use switch
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
good defaults
|
||||
|
||||
|
||||
|
||||
4.2 shortcuts and advanced options
|
||||
|
||||
|
||||
|
||||
ambient information
|
||||
|
||||
|
||||
|
||||
proactivity
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 5 aesthetic and minimalistic design
|
||||
|
||||
|
||||
|
||||
|
||||
signal to noise
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -4,6 +4,9 @@ aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-04-15
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
# Traversals
|
||||
@ -100,4 +103,30 @@ public Arraylist<String> levelorder() {
|
||||
|
||||
if we use a stack then its the same as preorder.
|
||||
|
||||
# Balance
|
||||
# Balancing trees
|
||||
long branches are a problem
|
||||
the performance bounds for all BST operations are linear of the length of the longest branch of the tree
|
||||
|
||||
ideal shape is a similar to a heap (wide and shallow).
|
||||
|
||||
we want the longest branch to be $\theta(lg\ n)$
|
||||
|
||||
|
||||
one way is to do an iorder traversal and save to a sorted array. then construct a new tree by repeatedly bisecting the array. and recursively building the left and right subtrees
|
||||
|
||||
need some local operation that helps to restore balance
|
||||
|
||||
## Rotation operation
|
||||
|
||||
suppose that in this bst there is a longer chain in e than else where
|
||||
|
||||
|
||||
|
||||
imagine twisting d to be the root
|
||||
|
||||
|
||||
|
||||
changes are
|
||||
- b's right child is now c
|
||||
- d's left child is not b
|
||||
- b parent now points to d
|
||||
@ -4,4 +4,16 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
>HCI is the cycle of design, implementation, evaluation of user interfaces
|
||||
|
||||
|
||||
|
||||
>"fail fast so you can succeed sooner"
|
||||
|
||||
**Focus on people**
|
||||
|
||||
Good design is good
|
||||
Bad design costs lives, money, time
|
||||
Bad design can be easily avoided using basic ideas like consistency and feedback
|
||||
|
||||
Joy of good design: When interaction becomes "invisible" - intuitive**
|
||||
|
||||
@ -4,4 +4,86 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
ENIAC (one of the first programmable, electronic computers) 1946, and the first six programmers: Kay McNulty, Betty Jennings, Betty Snyder, Marlyn Meltzer, Fran Bilas, and Ruth Lichterman
|
||||
|
||||
|
||||
|
||||
DEC PDP-8 and TI 980 (1960’s), PDP-8 is an octal computer (switches in three-bit configurations), TI 980 is a hexadecimal machine (4-bit configuration). Not interactive
|
||||
|
||||
|
||||
|
||||
|
||||
Batch processing using punch cards, still not interactive (1950s -1970s)
|
||||
|
||||
|
||||
|
||||
IBM System/360 (mainframe computer in the 70s), Altair 8800 (one of the first home computers)
|
||||
|
||||
|
||||
|
||||
|
||||
visicalc (Dan Bricklin 1979), and Apple II (1977)
|
||||
|
||||
|
||||
|
||||
|
||||
Sutherland, Ivan Edward (January 1963). "Sketchpad: A man-machine graphical communication system, MIT press.
|
||||
|
||||
|
||||
|
||||
Sutherland, Ivan Edward (January 1963). "Sketchpad: A man-machine graphical communication system, MIT press.
|
||||
|
||||
|
||||
|
||||
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||
|
||||
|
||||
|
||||
|
||||
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||
|
||||
|
||||
|
||||
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||
|
||||
|
||||
|
||||
“The Mother of All Demos”, presented by Douglas Engelbart (1968) at (ACM/IEEE) Computer Society's Fall Joint Computer Conference See full demo: https://www.youtube.com/watch?v=yJDv-zdhzMY
|
||||
|
||||
|
||||
|
||||
“Dynabook” Alan C. Kay. (1972), “Personal Computer for Children of All Ages”
|
||||
|
||||
|
||||
|
||||
Apple Newton (1993) and Apple iPad (2010)
|
||||
|
||||
|
||||
|
||||
Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||
|
||||
|
||||
|
||||
Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||
|
||||
|
||||
|
||||
1992/93 - IBM Simon First smartphone Phone, pager, calculator, address book, fax machine, and e-mail device
|
||||
|
||||
|
||||
|
||||
Ramesh Raskar, Greg Welch, Matt Cutts, Adam Lake, Lev Stesin and Henry Fuchs (1998) "The Office of the Future : A Unified Approach to Image-Based Modeling and Spatially Immersive Displays,"
|
||||
|
||||
|
||||
|
||||
1981 - Steve Manns’s “Wearable Computing” Start of a series of prototypes for wearable computing, cyborgs, and mediated reality (-> Google Glass) www.wearcam.org, www.eyetap.org
|
||||
|
||||
|
||||
|
||||
Nokia N95 (2007) and Apple iPhone (2007)
|
||||
|
||||
|
||||
|
||||
Major innovations in HCI (Myers 1998)
|
||||
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ tags:
|
||||
#unfinished
|
||||
|
||||
Why to evaluate using 'outside' people:
|
||||
- how do we know if a [prototype](notes/prototyping.md)] is good
|
||||
- how do we know if a [prototype](notes/prototyping.md) is good
|
||||
- designer/developers are not 'fresh' -> they already have experience with the product
|
||||
- designer/developers don't know what real users will do
|
||||
|
||||
|
||||
@ -1,7 +0,0 @@
|
||||
---
|
||||
title: "hci"
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
|
||||
@ -4,4 +4,121 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
>"Heuristics are strategies derived from previous experiences with similar problems"
|
||||
jacob nielsen and rolf molich
|
||||
|
||||
help find usability problems
|
||||
small set of 3-5 evaluators examine UI
|
||||
independently check for compliance with usability principles
|
||||
different evaluators will find different problems
|
||||
evaluators only communicate afterwaards
|
||||
findings are aggregated at the end
|
||||
|
||||
|
||||
|
||||
## 1 when?
|
||||
- as part of need finding -> use experts to critique existing solutions
|
||||
- before user testing -> identify minor issues before user testing
|
||||
- before redesigning -> learn what works and what should change
|
||||
- when you know there are problems but you need evidence -> "provide you with ammunition for design"
|
||||
- before release -> smooth off rough edges
|
||||
|
||||
## 2 What
|
||||
### 2.1 Process
|
||||
#### 2.1.1 Overview
|
||||
Helps find problems in design
|
||||
- 3-4 evaluators examine UI
|
||||
- independent reviewers check for compliance with usability principles
|
||||
- each evaluator will find different problems
|
||||
- evaluators only communicate afterwards and the findings are aggregated
|
||||
can perform on working UI or sketches
|
||||
|
||||
#### 2.1.2 Phases
|
||||
1. pre evaluation training ⇒ give evaluators needed domain knowledge and information on the scenario
|
||||
2. evaluation ⇒ individuals evaluate then aggregate result
|
||||
1. first as individuals
|
||||
2. then sit all together and aggregate
|
||||
3. Severity rating ⇒ determine how severe each problem is (priority). Can do first individually and then as a group
|
||||
4. Debriefing ⇒ review with design team
|
||||
|
||||
#### 2.1.3 Individual
|
||||
dont look search for heuristics individually
|
||||
just go through the app (like a user). If we find issues, we assign them to categories
|
||||
|
||||
step through design several times
|
||||
- examine details, flow, an architecture
|
||||
- consult list of usability principles
|
||||
- … and anything else that comes to mind
|
||||
|
||||
which principles
|
||||
- Nielsen's heuristics
|
||||
- category specific heuristics
|
||||
- e.g., design goals, competitive analysis, existing designs
|
||||
|
||||
use violations for redesign/fix problems
|
||||
|
||||
multiple evaluators because no one finds everything
|
||||
some will always find more than others (Rule of thumb 5 evaluators find ~75% of problems)
|
||||
|
||||
#### 2.1.4 Severity rating
|
||||
- independently estimate after viewing
|
||||
- allocate resources to fix problems
|
||||
- estimate need for more usability tests
|
||||
|
||||
0. not problem
|
||||
1. cosmetic problem
|
||||
2. minor usability problem
|
||||
3. major
|
||||
4. catastrophe
|
||||
|
||||
#### 2.1.5 Debreifing
|
||||
- with evaluators observers and dev team
|
||||
- discuss general characteristics of UI
|
||||
- suggest potential imporvements
|
||||
- dev team estimate effort to fix
|
||||
- brainstorm solutions
|
||||
|
||||
### 2.2 Nielsen's ten heuristics
|
||||
visibility of system status
|
||||
match between system and world
|
||||
user control and freedom
|
||||
consistency and standards
|
||||
error prevention
|
||||
recognition rather than recall
|
||||
flexibility and efficiency of use
|
||||
aesthetic and minimalist design
|
||||
help users recognize, diagnose, and recover from errors
|
||||
help and documentation
|
||||
|
||||
### 2.3 Heuristic evaluation vs user testting
|
||||
|
||||
heuristics | user testing
|
||||
----------------- | --------------
|
||||
faster | slower
|
||||
1-2 hrs each |
|
||||
results pre-interpreted |
|
||||
^ done by experts |
|
||||
less accurate | more acurate
|
||||
does not take into account actual users | can find issues that experts might not have
|
||||
|
||||
value to alternate methods
|
||||
^ find dfferent issues
|
||||
|
||||
|
||||
|
||||
### 2.4 Extra tips how to individual
|
||||
- at least two passes each
|
||||
- first get get feel for flow
|
||||
- second to focus on specific elements
|
||||
- if a system is "walk up and use" or evaluators are already domain expers ⇒ no assistance is needed
|
||||
- otherwire might supply evaluators with scenarios
|
||||
- each evaluators should list issues separately
|
||||
- risk of repeating problematic aspect
|
||||
- may not be possible to fix all problems
|
||||
- where problems may be found
|
||||
- single location in UI
|
||||
- two or more locations that need to be compared
|
||||
- problem with overall structure
|
||||
- something is missing
|
||||
- ambiguous with early prototypes
|
||||
- sometimes ....
|
||||
|
||||
@ -14,7 +14,6 @@ links: [[notes/info-203]]
|
||||
- [interviewing](notes/interviewing.md)
|
||||
- [user-experience](notes/user-experience.md)
|
||||
- [usbability](notes/usbability.md)
|
||||
- [hci](notes/hci.md)
|
||||
- [storyboards](notes/storyboards.md)
|
||||
- [personas-and-scenarios](notes/personas-and-scenarios.md)
|
||||
-
|
||||
@ -4,4 +4,64 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
## 1 Use Cases
|
||||
- [evaluating-designs](notes/evaluating-designs.md)
|
||||
- [requirements-elicitation](notes/requirements-elicitation.md)
|
||||
- [needfinding](notes/needfinding.md)
|
||||
|
||||
## 2 Overview
|
||||
- direct and stuctured
|
||||
- semi structured
|
||||
- usually top down
|
||||
- effective for high level interface evaluation
|
||||
- need careful planning, experts, difficult to analyse
|
||||
- not a controlled experiment technique
|
||||
|
||||
## 3 Conducting an interview
|
||||
### 3.1 Choosing participants
|
||||
- some is better than none
|
||||
- get pople who are representive of users
|
||||
- users of existing similar system
|
||||
- non-users -> why people arent using a system
|
||||
- e.g., lecture support system
|
||||
- teachers
|
||||
- students
|
||||
- staff
|
||||
- admins
|
||||
- parents
|
||||
- freshman
|
||||
- phd
|
||||
- international domestic
|
||||
- stronger and weaker
|
||||
|
||||
#### 3.1.1 Recruiting
|
||||
- Craiglist (in US)
|
||||
- your network
|
||||
- cheaper for less speciales users
|
||||
- if you can convince people you are imporving the world they might volunteer
|
||||
- if they think is is for profict they will expect to be paid
|
||||
- if you cant pay -> you cant use a token of appreciation
|
||||
|
||||
### 3.2 Process
|
||||
- introduce yourself explaint he purpose
|
||||
- the interview is about them, not you?
|
||||
- begin with open, unbiased questions-> then follow up
|
||||
- ask the questions, and let them answer
|
||||
- have breaks and give them time
|
||||
- have a clear separation between the general introduction, the actual interview, and post inteview discussions
|
||||
|
||||
### 3.3 Questions to avoid:
|
||||
- leading questions
|
||||
- what would they do / like / want in a hypothetical scenario
|
||||
- how often they do things
|
||||
- how much they like things on an absolute scale
|
||||
- avoid binary questions
|
||||
|
||||
## 4 Pros/cons
|
||||
+ free and open answers
|
||||
+ sense of active contribution
|
||||
+ oppportunity for follow up
|
||||
- time consuming and resource intensive
|
||||
- dependent of commication skills of analyst
|
||||
- location/schedule can make this impractical
|
||||
|
||||
|
||||
58
content/notes/needfinding.md
Normal file
58
content/notes/needfinding.md
Normal file
@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "needfinding"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
how to start imporving or designing inerface
|
||||
how to identify the gap or use interface issues
|
||||
|
||||
needdfinding tries to identify issues, often through observational studies (qualitative)
|
||||
|
||||
> "the trick [challenge] to finding ideas is to convince yourself that everyone and everything has a story to tell"
|
||||
> "The other trick if finding out the difference between power and knowledge. You dont start at the top if you want to find a story, you start in the middle. Because its the people in the middle that do the work"
|
||||
> "self conciousness is the enemy of interestingness"
|
||||
> -malcolm gladwell
|
||||
|
||||
## 1 Methods
|
||||
- [participant-observation](notes/participant-observation.md)
|
||||
- Apprenticeship
|
||||
- set a partnership with the people to be observed
|
||||
- be taught the steps in the process
|
||||
- observe the practives
|
||||
- validate what you are observing with those observed as you go along
|
||||
- e.g.,
|
||||
- apprenticeship is eVision user
|
||||
- task: find in which room INFO203 is
|
||||
- problem: I do not have a timetable in eVision like students
|
||||
- allows you to capture the context of use and the issues and needs
|
||||
- what do people do now
|
||||
- what values and goals do people have
|
||||
- how are these particular activities embedded in the larger context
|
||||
- similarities and differences across people
|
||||
- other types of context that are relevant -> time of day, social context
|
||||
|
||||
- [interviewing](notes/interviewing.md)
|
||||
- avoid leading questions
|
||||
- choose sample representative of real users
|
||||
- often impractical
|
||||
- can be structured or semi-structured
|
||||
- effective for high level
|
||||
|
||||
- Longitudinal studies
|
||||
- sporadic use -> when the product is used rarely
|
||||
- used when you cannot use observational studies
|
||||
- diaries
|
||||
- scale better than direct observation (less time consuming)
|
||||
- give people a diary to copmlete
|
||||
- structred task
|
||||
- can use journals, camera, voice, video
|
||||
- tailor the recording to the context
|
||||
- may require practice, training, reminding
|
||||
- use of ntifications, digital calendars, phone calls
|
||||
- Experience sampling
|
||||
- use txt, phone calls , calendars, notifications to recieve feeback or actively remind people
|
||||
- choose interval depending on study context
|
||||
|
||||
|
||||
@ -4,4 +4,25 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
## 1 Techniques
|
||||
- think-aloud
|
||||
- co-operative evaulation
|
||||
- paper and pencil protocol
|
||||
- audio recording
|
||||
- video recording
|
||||
- computer logging
|
||||
- user notebooks
|
||||
- post-talk walkthroughs
|
||||
|
||||
## 2 Disadvantages
|
||||
- observation bias exists
|
||||
- coding schemes
|
||||
- laborioua and difficult
|
||||
- experts needed, training needed
|
||||
- often a mix of multiple techniques
|
||||
- automatic protocol analysis tools available (esp. in usability labs)
|
||||
|
||||
## 3 Use Cases
|
||||
[needfinding](notes/needfinding.md)
|
||||
[evaluating-designs](notes/evaluating-designs.md)
|
||||
[requirements-elicitation](notes/requirements-elicitation.md)
|
||||
@ -4,4 +4,30 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
# Prototyping
|
||||
Quickly creating a minimal, functioning approximate version of an idea, which reveals potential issues(feedback) that may be hard to predict(unknown unknows) otherwise
|
||||
|
||||
>"The way to have a good idea is to have lots of ideas" - Linus Pauling
|
||||
|
||||
> "Prototypes are questions. Ask lots of them"
|
||||
|
||||
Rapid Prototyping can be compared to simulated annealing
|
||||
|
||||
## 1 Goals
|
||||
- minimise time spent
|
||||
- maximise information gained
|
||||
- cost of change increases with time
|
||||
- help [stakeholders](stakeholders) understand ideas
|
||||
|
||||
## 2 Traits of a good prototype:
|
||||
- not fully complete
|
||||
- easy to change/create
|
||||
- retired/evolved quickly
|
||||
|
||||
## 3 Insights gained from prototyping
|
||||
- Feel -> Form
|
||||
- Implementation -> Function
|
||||
- Role -> Overall Experience
|
||||
|
||||
|
||||
|
||||
|
||||
@ -4,4 +4,54 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
Fidelity will increase over time.
|
||||
|
||||
|
||||
## Storyboarding
|
||||
focus on the **task**
|
||||
communicate flow
|
||||
not about pretty pictures
|
||||
use timelimits ≈10 mins
|
||||
|
||||
### shows
|
||||
- settings
|
||||
- people
|
||||
- environment
|
||||
- task
|
||||
- sequence
|
||||
- steps
|
||||
- what leads a user to use the app
|
||||
- what task
|
||||
- satisfaction
|
||||
- why do they use the app
|
||||
- what do they accomplish
|
||||
- what needs does the system fill
|
||||
|
||||
### Benefits
|
||||
- holistic focus
|
||||
- avoids commitment to an interface
|
||||
- helps get stakeholders onthe same page
|
||||
|
||||
### Examples
|
||||
|
||||
|
||||
|
||||
## Paper prototyping
|
||||
mockup of UI on computer
|
||||
|
||||
|
||||
|
||||
### tips
|
||||
- store materials in one place
|
||||
- work quickly
|
||||
- complex parts of interfaces can be verbally roleplayed
|
||||
- backgrounds can be used to contain protoypes and provide context
|
||||
- you can mix and match hardware and software
|
||||
- when appropraite include matching OS elements
|
||||
|
||||
- get users to add to the design
|
||||
- get stakeholders incolved
|
||||
|
||||
|
||||
## Digital mockups
|
||||
|
||||
|
||||
@ -4,4 +4,8 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
The extent to which a product cn be used by specifies users to achieve specified goals with effectivenesss, efficiency, and satisfaction in a specified context of use.
|
||||
|
||||
Usability is how well a product can be used by specific users to achieve goals effectively efficiently and with satisfaction in a specific context
|
||||
|
||||
|
||||
|
||||
@ -4,4 +4,8 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
> "encompasses all aspects of the end users interaction with the company, its services, and its products" - Jakob Nielsen and Don Normann
|
||||
|
||||
Marketing, branding, etc.
|
||||
|
||||
|
||||
|
||||
@ -4,4 +4,37 @@ tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
## 1 benefits
|
||||
- cheap and fast
|
||||
- great communication
|
||||
- can serve as spec for devs
|
||||
- ties interface design to tasks
|
||||
|
||||
## 2 fidelity
|
||||
low-fi 2-5min brainstorm
|
||||
mid-fi 1-4 paper prtotypes video
|
||||
hi-fi slick +fancy for investors/management
|
||||
|
||||
## 3 shows
|
||||
- like a storyboard, the whole tasks
|
||||
- motivvationa and success
|
||||
- draw on tasks you've observed
|
||||
- illustrate importand tasks
|
||||
- help scope minimum viable poduct
|
||||
- forces you to make design decisions in a new way
|
||||
|
||||
## 4 steps
|
||||
- outline (maybe use storyboards)
|
||||
- fin to extemporize
|
||||
- equiment
|
||||
- a camera (not fancy needed)
|
||||
- people
|
||||
- realistic location
|
||||
- focus on the message more than production values
|
||||
|
||||
## 5 considerations
|
||||
- silent(with title cards) or with audio
|
||||
- audio can be finicky
|
||||
- interface can be anything
|
||||
- mockups, paper prototypes, code
|
||||
- can show success and failure of interfaces an failure
|
||||
|
||||
@ -5,3 +5,59 @@ tags:
|
||||
---
|
||||
|
||||
|
||||
making interactive app quickly with minimal code
|
||||
|
||||
simulate interactive behaviour with human operators
|
||||
|
||||
- make interactive app without much code
|
||||
- front end interface
|
||||
- remote wizard controls user interface
|
||||
- makes sense with is faster/cheaper/easier than making the real thing
|
||||
- get feedback from users people
|
||||
- hi-fi users think its more real
|
||||
- low-fi: more license to suggest changes
|
||||
|
||||
## 1 making wizard protoypes
|
||||
- find scenarios to protoypes
|
||||
- create UI skeleton
|
||||
- develop hooks for wizard input
|
||||
- decide where and how the wizard will provide input
|
||||
- remember not to fake stuff that it not feasible in real life
|
||||
- rehearse wizard rile with colleague
|
||||
|
||||
## 2 running wizard protoypes
|
||||
- practivce with friend
|
||||
- recruit users
|
||||
|
||||
- two roles:
|
||||
- facilitator ⇒ pprovides tasks and takes notes
|
||||
- wizard ⇒ operaties interface
|
||||
|
||||
- user feedback
|
||||
- think aloud
|
||||
- retrospective
|
||||
- heuristic evaluation
|
||||
|
||||
- debrief users
|
||||
|
||||
|
||||
## 3 used throughout development
|
||||
user can do less and less and the prototyp comes closer to realisation
|
||||
|
||||
## 4 advatages
|
||||
- fast
|
||||
- variable
|
||||
- more real than papar prototypes
|
||||
- finds bugs and pronlems with design
|
||||
- places user at center
|
||||
- can envision challenging to built application
|
||||
- ability to look foward and "use" tech that isn't created yet
|
||||
|
||||
|
||||
## 5 Disadvatages
|
||||
- simulations may misrepresent otherwire imperfect tech
|
||||
- mya simulate techs that not not exist (and mnay never)
|
||||
- require training and can be inconsistent
|
||||
- playing the wizard can be exhausting
|
||||
- some features are difficult to simulate
|
||||
- may not be appropriate
|
||||
|
||||
Loading…
Reference in New Issue
Block a user