From f4269a4849177436c7cdfc997d5816d559f34104 Mon Sep 17 00:00:00 2001 From: Jet Hughes Date: Tue, 12 Apr 2022 12:34:57 +1200 Subject: [PATCH] updated 203 Notes --- content/daily_notes/2022-04-12.md | 3 +- content/notes/07-heuristic-evaluation-cont.md | 2 +- ...r-prototypes-wiz-of-oz-video-prototypes.md | 17 +++ content/notes/10-design-heuristics-1.md | 20 +++ content/notes/11-design-heuristics-2.md | 43 +++++++ content/notes/12-design-heuristics-3.md | 112 +++++++++++++++++ .../notes/13-bst-traversals-and-balance.md | 31 ++++- content/notes/big-picture.md | 12 ++ content/notes/birth-of-hci.md | 82 ++++++++++++ content/notes/evaluating-designs.md | 2 +- content/notes/hci.md | 7 -- content/notes/heuristic-evaluation.md | 117 ++++++++++++++++++ content/notes/info-203-outline.md | 1 - content/notes/interviewing.md | 60 +++++++++ content/notes/needfinding.md | 58 +++++++++ content/notes/participant-observation.md | 21 ++++ content/notes/prototyping.md | 26 ++++ .../storyboards-mockups-paper-prototypes.md | 50 ++++++++ content/notes/usbability.md | 4 + content/notes/user-experience.md | 4 + content/notes/video-prototyping.md | 33 +++++ content/notes/wizard-of-oz.md | 56 +++++++++ 22 files changed, 749 insertions(+), 12 deletions(-) delete mode 100644 content/notes/hci.md create mode 100644 content/notes/needfinding.md diff --git a/content/daily_notes/2022-04-12.md b/content/daily_notes/2022-04-12.md index a5ff849bf..09be75df9 100644 --- a/content/daily_notes/2022-04-12.md +++ b/content/daily_notes/2022-04-12.md @@ -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 diff --git a/content/notes/07-heuristic-evaluation-cont.md b/content/notes/07-heuristic-evaluation-cont.md index 41f1c4a4d..c16e1793d 100644 --- a/content/notes/07-heuristic-evaluation-cont.md +++ b/content/notes/07-heuristic-evaluation-cont.md @@ -5,4 +5,4 @@ tags: - lecture --- - +[heuristic-evaluation](notes/heuristic-evaluation.md) diff --git a/content/notes/09-paper-prototypes-wiz-of-oz-video-prototypes.md b/content/notes/09-paper-prototypes-wiz-of-oz-video-prototypes.md index fb50f5526..d3653f7f9 100644 --- a/content/notes/09-paper-prototypes-wiz-of-oz-video-prototypes.md +++ b/content/notes/09-paper-prototypes-wiz-of-oz-video-prototypes.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., ![](https://i.imgur.com/IKIEHon.png) +- refinement of design and communicating ideas. e.g., ![](https://i.imgur.com/A7paq38.png) +- - evaluating interfaces + +Example of previous years 203 work +![](https://i.imgur.com/NvgJA8n.png) + +# Digital prototypes + +Past 203 work +![](https://i.imgur.com/d4b22ZM.png) diff --git a/content/notes/10-design-heuristics-1.md b/content/notes/10-design-heuristics-1.md index 387e3a3ba..71091831b 100644 --- a/content/notes/10-design-heuristics-1.md +++ b/content/notes/10-design-heuristics-1.md @@ -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 + +![](https://i.imgur.com/zPrMKlz.png) + +## 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. +![](https://i.imgur.com/h1c095B.png) + +## 4 Design heuristics diff --git a/content/notes/11-design-heuristics-2.md b/content/notes/11-design-heuristics-2.md index 08bce7797..c01cf2173 100644 --- a/content/notes/11-design-heuristics-2.md +++ b/content/notes/11-design-heuristics-2.md @@ -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 + +![](https://i.imgur.com/QzHRh9Z.png) + +## 2 familiar metaphors and language +![](https://i.imgur.com/sdNv98E.png) +![](https://i.imgur.com/IbIBK5t.png) + +imitating familiar real life + +Categories +- good + - ![](https://i.imgur.com/7wRRBii.png) +- bad + - ![](https://i.imgur.com/vDKOuOo.png) + +## 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., ![](https://i.imgur.com/zF5LDVx.png) +e.g., ![](https://i.imgur.com/eqfs1D6.png) diff --git a/content/notes/12-design-heuristics-3.md b/content/notes/12-design-heuristics-3.md index 3a0c62a66..bdee8e18a 100644 --- a/content/notes/12-design-heuristics-3.md +++ b/content/notes/12-design-heuristics-3.md @@ -5,4 +5,116 @@ tags: - lecture --- +# 1 Consistency and standards + +![](https://i.imgur.com/H8rlxo7.png) + +good and bad +- standards (user interface guidelines) are always chaning + +differ between platforms +evolve over time + +e.g., menus + +![](https://i.imgur.com/IfaMADw.png) +![](https://i.imgur.com/HqYzadh.png) + +general look of webpages evolves over time + +### 1.1 Naming and teminology + +![](https://i.imgur.com/3PwEOmn.png) + +this is bad +you can ask users which categories they understand/know about + +### 1.2 Data loss +![](https://i.imgur.com/23IxWiN.png) + +standard to minimise loss + +## 2 Error Prevention + +### 2.1 Bad input + +![](https://i.imgur.com/54tVH7B.png) + +correct human errors +auto completion + +### 2.2 helpful constraints + +![](https://i.imgur.com/n4HT5L9.png) + +### 2.3 Suggestions and autocorrection + +![](https://i.imgur.com/c2l9MWy.png) + +heavily abused by industry +- they can influence suggestions + +### 2.4 Forgiving formatting + +![](https://i.imgur.com/ldZUMer.png) + +- reduce errors +- + +## 3 recognition over recall + +### 3.1 avoid codes + +![](https://i.imgur.com/B8sJxd6.png) + +### 3.2 Recognition with previews or icons + +![](https://i.imgur.com/UBmJl6Y.png) + +### 3.3 use icons that promote recognition + +![](https://i.imgur.com/adjt5nv.png) + +## 4 Flexibility and efficiency + +### 4.1 Choices + +![](https://i.imgur.com/lUBB7EN.png#invert) +![](https://i.imgur.com/1OaTaPg.png#invert) +![](https://i.imgur.com/8KaFDme.png#invert) + +something with immediate effect can use switch +![](https://i.imgur.com/COR8E7w.png#invert) + +![](https://i.imgur.com/EQbB1Ep.png#invert) +![](https://i.imgur.com/QhFssbP.png#invert) +![](https://i.imgur.com/PG2Iu9a.png#invert) + +good defaults + +![](https://i.imgur.com/pj5Ztij.png) + +4.2 shortcuts and advanced options + +![](https://i.imgur.com/0OG7qRx.png) + +ambient information + +![](https://i.imgur.com/s2zyIws.png) + +proactivity + +![](https://i.imgur.com/gmDLWMO.png) +![](https://i.imgur.com/Izu8bQX.png) +![](https://i.imgur.com/hiGeXW3.png) + +## 5 aesthetic and minimalistic design + +![](https://i.imgur.com/Oywxwgq.png) +![](https://i.imgur.com/xgfgEtm.png) + +signal to noise + +![](https://i.imgur.com/6bLaHS6.png) +![](https://i.imgur.com/qF21SST.png) diff --git a/content/notes/13-bst-traversals-and-balance.md b/content/notes/13-bst-traversals-and-balance.md index 5ed59f5ea..ef385a13f 100644 --- a/content/notes/13-bst-traversals-and-balance.md +++ b/content/notes/13-bst-traversals-and-balance.md @@ -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 levelorder() { if we use a stack then its the same as preorder. -# Balance \ No newline at end of file +# 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 + +![100](https://i.imgur.com/SmDsZd1.png) + +imagine twisting d to be the root + +![100](https://i.imgur.com/6MoYHX1.png) + +changes are +- b's right child is now c +- d's left child is not b +- b parent now points to d \ No newline at end of file diff --git a/content/notes/big-picture.md b/content/notes/big-picture.md index 0e98bd52b..1b0f31bad 100644 --- a/content/notes/big-picture.md +++ b/content/notes/big-picture.md @@ -4,4 +4,16 @@ tags: - info203 --- +>HCI is the cycle of design, implementation, evaluation of user interfaces +![](https://i.imgur.com/SMtW2Zb.png) + +>"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** diff --git a/content/notes/birth-of-hci.md b/content/notes/birth-of-hci.md index f0747c68a..1557536ea 100644 --- a/content/notes/birth-of-hci.md +++ b/content/notes/birth-of-hci.md @@ -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 +![](https://i.imgur.com/w6khmh5.png) + +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 + +![](https://i.imgur.com/XBP75oa.png) + + +Batch processing using punch cards, still not interactive (1950s -1970s) + +![](https://i.imgur.com/qsu2duq.png) + +IBM System/360 (mainframe computer in the 70s), Altair 8800 (one of the first home computers) + +![](https://i.imgur.com/dAYc8ru.png) + + +visicalc (Dan Bricklin 1979), and Apple II (1977) + +![](https://i.imgur.com/zXmd89L.png) + + +Sutherland, Ivan Edward (January 1963). "Sketchpad: A man-machine graphical communication system, MIT press. + +![](https://i.imgur.com/0I0xCKL.png) + +Sutherland, Ivan Edward (January 1963). "Sketchpad: A man-machine graphical communication system, MIT press. + +![](https://i.imgur.com/PkQWnPU.png) + +1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display” + +![](https://i.imgur.com/XPPjzNS.png) + + +1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display” + +![](https://i.imgur.com/cvhyx7u.png) + +1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display” + +![](https://i.imgur.com/yYAxe2d.png) + +“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 + +![](https://i.imgur.com/u9McBxK.png) + +“Dynabook” Alan C. Kay. (1972), “Personal Computer for Children of All Ages” + +![](https://i.imgur.com/8IlrB6e.png) + +Apple Newton (1993) and Apple iPad (2010) + +![](https://i.imgur.com/cpLSLUm.png) + +Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star + +![](https://i.imgur.com/ccSlueJ.png) + +Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star + +![](https://i.imgur.com/GY8teow.png) + +1992/93 - IBM Simon First smartphone Phone, pager, calculator, address book, fax machine, and e-mail device + +![](https://i.imgur.com/PmVH5Xt.png) + +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," + +![](https://i.imgur.com/7HLtUzS.png) + +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 + +![](https://i.imgur.com/pJtEw93.png) + +Nokia N95 (2007) and Apple iPhone (2007) + +![](https://i.imgur.com/RZ2K6pv.png) + +Major innovations in HCI (Myers 1998) + +![](https://i.imgur.com/uwGf8NN.png) diff --git a/content/notes/evaluating-designs.md b/content/notes/evaluating-designs.md index 58777a951..85b3b118e 100644 --- a/content/notes/evaluating-designs.md +++ b/content/notes/evaluating-designs.md @@ -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 diff --git a/content/notes/hci.md b/content/notes/hci.md deleted file mode 100644 index ce16ab188..000000000 --- a/content/notes/hci.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "hci" -tags: -- info203 ---- - - diff --git a/content/notes/heuristic-evaluation.md b/content/notes/heuristic-evaluation.md index e3c2af90e..e69d12536 100644 --- a/content/notes/heuristic-evaluation.md +++ b/content/notes/heuristic-evaluation.md @@ -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 + +![](https://i.imgur.com/DfmaHlI.png) + +## 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 + +![](https://i.imgur.com/YgGkBqg.png) + +### 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 .... diff --git a/content/notes/info-203-outline.md b/content/notes/info-203-outline.md index 47e5f30a7..0a79a9312 100644 --- a/content/notes/info-203-outline.md +++ b/content/notes/info-203-outline.md @@ -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) - \ No newline at end of file diff --git a/content/notes/interviewing.md b/content/notes/interviewing.md index 610ebfefc..c374c880b 100644 --- a/content/notes/interviewing.md +++ b/content/notes/interviewing.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 diff --git a/content/notes/needfinding.md b/content/notes/needfinding.md new file mode 100644 index 000000000..f12d1db71 --- /dev/null +++ b/content/notes/needfinding.md @@ -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 + + \ No newline at end of file diff --git a/content/notes/participant-observation.md b/content/notes/participant-observation.md index f0e4c807c..f216c066a 100644 --- a/content/notes/participant-observation.md +++ b/content/notes/participant-observation.md @@ -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) \ No newline at end of file diff --git a/content/notes/prototyping.md b/content/notes/prototyping.md index f2b3a1b75..84309991e 100644 --- a/content/notes/prototyping.md +++ b/content/notes/prototyping.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 + +![](https://i.imgur.com/DU7fMJz.png) +![](https://i.imgur.com/aR9yOeI.png) diff --git a/content/notes/storyboards-mockups-paper-prototypes.md b/content/notes/storyboards-mockups-paper-prototypes.md index 5838ae546..2e421f0ea 100644 --- a/content/notes/storyboards-mockups-paper-prototypes.md +++ b/content/notes/storyboards-mockups-paper-prototypes.md @@ -4,4 +4,54 @@ tags: - info203 --- +Fidelity will increase over time. +![200](https://i.imgur.com/7qmn859.png) +## 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 +![](https://i.imgur.com/9PzIGWg.png) + + +## Paper prototyping +mockup of UI on computer +![](https://i.imgur.com/aGq3VKp.png) + + +### 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 +![](https://i.imgur.com/LOSt7gZ.png) diff --git a/content/notes/usbability.md b/content/notes/usbability.md index 39d65a5c6..16f7d3da9 100644 --- a/content/notes/usbability.md +++ b/content/notes/usbability.md @@ -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 + +![](https://i.imgur.com/da2LAxG.png) diff --git a/content/notes/user-experience.md b/content/notes/user-experience.md index 252acf8fe..c3781fef7 100644 --- a/content/notes/user-experience.md +++ b/content/notes/user-experience.md @@ -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. + +![](https://i.imgur.com/oA6p1ZH.png) diff --git a/content/notes/video-prototyping.md b/content/notes/video-prototyping.md index e5ad6a787..492e780e5 100644 --- a/content/notes/video-prototyping.md +++ b/content/notes/video-prototyping.md @@ -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 diff --git a/content/notes/wizard-of-oz.md b/content/notes/wizard-of-oz.md index 7db654861..17c439d6b 100644 --- a/content/notes/wizard-of-oz.md +++ b/content/notes/wizard-of-oz.md @@ -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