Design och konstruktion av grafiska gränssnitt Olof Torgersson Interaktionsdesign Tillämpad informationsteknologi Chalmers/GU Getting input from users Några gyllene regler Projektintro Idag Obs extra redovisningsmöjlighet för lab 2 på onsdag 1
GETTING INPUT FROM USERS Allmänt Design bör ta hänsyn till alignment, grouping etc för att skapa ett harmoniskt och förståeligt intryck För val av specifika kontroller kan uppställningen i Tidwells bok (s 344-355) vara nyttig En av flera? Flera av flera? Tal i intervall? Sen finns det några principer till 2
Principer Se till att användarna förstår vad som efterfrågas och varför Använd språk som är anpassat till användarna Om det är en massa information förklara varför den behövs Använd tooltips för t ex knappar som används för input Om det går ställ inte frågan alls Detta är samma som Cooper säger Man kanske avbryter flow Det kanske går att gissa eller fylla i ett standardvärde för att minska arbete Principer, forts Kunskap i världen är mer korrekt än kunskap i huvudet Går det att erbjuda en lista att välja från så gör det Kan man ha en visuell presentation så använd den Måste man ha ett visst format, visa det tydligt Se upp för direktmappningar från implementationsmodellen Glöm inte användarens mentala modell Data i implementationen kanske inte passar Designa först mappa mot implementationen sen Användartesta Gäller för allt Ofta räcker det med ett ganska litet antal personer (typ 5) 3
Principer, forts Valet av kontroll påverkar vad användaren förväntar sig så välj rätt Radiobox flervalsalternativ Textfält kort öppet svar Ge inte möjlighet att skriva fel T ex 15 när bara 1-10 är tillåtet Få aldrig användaren att känna sig dum Välja kontroll Boken tar upp ett stort antal möjliga kontroller för olika situationer Kontroller för att välja en av två möjliga Kontroller för att välja N objekt där N är litet Kontroller för att välja N objekt i godtycklig ordning Kontroll för att skriva en rad text Läs tillräckligt för att ha god uppfattning om möjligheter sen kan man slå upp i en designsituation 4
Faktorer att ta hänsyn till Tillgängligt utrymme Platskraven varierar mycket mellan olika kontroller Faktorer att ta hänsyn till Användarnas allmänna datorkunskap Textfält förståeligt för alla Dubbelslider eller lista med flervalsmöjlighet svårare 5
Faktorer att ta hänsyn till Användarnas domänkunskap Ex. ett textfält med intervall 0-10 Men det blir lätt fel även om man är kunnig Faktorer att ta hänsyn till Förväntningar från andra program The applications that are easy to use are designed to be familiar Bold/Italic/Underline vanligt som butcons, radioknappar blir konstigt Dvs man måste kunna sin verktygslåda Tillgänglig teknik Alla plattformar har inte samma kontroller Web begränsad iphone specialdesignade 6
Några mönster Allmänt Mönster är förslag på fungerande lösningar Beskriver hur man kan kombinera kontroller och text för att de blir lättare att använda Måste anpassas efter situationen Nytta Kan man många är chansen större att man hittar något lämpligt för en given situation Ger en vokabulär för att diskutera design Studera/reflektera kring program man använder Är beprövade Forgiving Format 7
Forgiving Format Vad Tillåt användaren skriva lite vad som helst och låt sedan programmet tolka det intelligent När Programmet efterfrågar data som kan skrivas på många olika sätt, blandningar av format, tecken, stora/små bokstäver etc Man vill att UI ska hållas rent och enkelt Varför Användaren vill bara få något gjort utan att fundera på format det blir helt enkelt mycket enklare Hur Se Vad. Sen måste man se till att det går att förutse tillräckligt bra vad användaren kan tänkas skriva så att det går att tolka Exempel 8
Structured Format 9
Structured Format Vad Använd flera textfält istället för ett för att visa strukturen på data När Inmatning av med ett givet och känt format. T ex kreditkortsnummer. Funkar inte om det kan finnas variation. Varför Strukturen visar för användaren vad som ska matas in Hur Använd ett antal textfält som motsvarar strukturen. Dessa bör inte vara längre än vad som behövs. När användaren matat in allt i ett fält flyttas man automatiskt till nästa. Exempel 10
forts bra? Fill-in-the-Blanks 11
Fill-in-the-Blanks Vad Ordna en eller flera inputkontroller i en fras, där inmatning innebär att man fyller i hål i frasen. När Man ska mata in något och detta blir tydligare och snyggare än vanliga label/inputarrangemeng. Varför Metoden är självförklarande. Användare klarar intuitivt av att fylla i hål i fraser. Tydligare än en massa förklaringar. Hur Jobba ordentligt med frasen. Mönstret funkar bäst med textfält, dropdowns o dyl som passar bra in i en text visuellt. Exempel 12
Input Hints Input Hints Vad Placera en text eller ett exempel bredvid ett inmatningsfält för att visa hur det ska användas När Det är inte helt självklart hur vad man ska skriva i ett fält och man vill inte skriva en lång förklarande label Varför Användarna slipper gissa. Vet man vad det ska stå behöver man inte kolla på input-hinten Hur Placera en kort text under eller bredvid inmatningsfältet. Det kan vara bra att använda en mindre font än för fältets label 13
Exempel amazon.com forts bra? 14
Input prompt Input prompt Vad Fyll i textfält eller drop-down med text som förklarar vilken sorts information som ska fyllas i eller väljas. När När man inte kan ha något default värde. Använd annars Good Defaults Varför Underlättar att förstå vilken sorts information som man begär av användaren Hur Börja med verb, avsluta med substantiv ex. Skriv namn Välj datum. Texten försvinner då man börjar skriva eller väljer. 15
Exempel Illustrated Choices 16
Illustrated Choices Vad Använd bilder istället för ord för att visa tillgängliga val När Användaren skall välja mellan ett antal objekt som skiljer sig visuellt Varför En bild säger mer än tusen ord + det blir snyggare Hur Visa bilder som motsvarar vad användaren får. Tekniken kan användas i bl a menyer, listor, knappar, tabeller osv. Borta ur kapitel 8 Exempel 17
Exempel Exempel 18
Good Defaults Good Defaults Vad När det är möjligt fyll i sannolika värden i förväg När I alla fall när man begär in information från användaren. Speciellt då det finns sannolika svar, eller då det är troligt att systemet vet vad som borde vara mest lämpligt. Varför Minskar användarens arbete. Kan också göra det mycket enklare om användaren är osäker och bara behöver bekräfta systemets val. Hur Ange default-värden för textfält, comboboxar etc. Kan göras dynamiskt eller statiskt. Var noggrann med att inte fylla i värden som sannolikt måste ändras. 19
Exempel Exempel 20
Exempel Exempel 21
Password strength meter Vad Ge användaren omedelbar bekräftelse på hur säkert ett lösenord är. När När användaren ska välja ett nytt lösenord Varför Säkerheten Hur Visuell och text indikering till höger om eller under textfältet. Uppdatera Password strength meter 22
Exempel Exempel 23
Same-Page Error Messages Same-Page Error Messages Vad Placera felmeddelanden direkt på inmatningssidan. Placera ett meddelande överst och helst också nära de faktiska felen När Designen tillåter att man faktiskt kan skriva fel eller utelämna information. Gör det så enkelt som möjligt att rätta till när det inträffar. Varför Den traditionella metoden är att slänga upp en dialogruta med ett felmeddelande (ofta modal). När man stängt den är informationen borta Bättre med information i kontext Hur Se Vad. Om felmeddelandena finns vid felet behöver man inte leta och fundera. 24
Exempel Exempel 25
För er som vill veta mer Luke Wroblewski: Web Form Design: Filling in the Blanks Web form design practices - Luke W http://formulate.com.au/ Smashing Magazine - web forms NÅGRA HCI-BEGREPP 26
Några HCI-begrepp Syfte: samla ihop en användbar mängd principer som kan tillämpas i de flesta sammanhang. Lite allmänbildning att känna till Bra att ha i bakhuvudet Låter självklara, men man kan kolla om man uppfyller dem Shneidermans gyllene regler (1) Strive for consistency. Försök alltid vara konsekvent, använd samma terminologi överallt, använd konsekventa färger, former, fonter, designmönster etc (2) Cater to universal usability Försök ta hänsyn till användarnas olikheter inklusive kompetens och eventuella funktionshinder 27
Shneidermans gyllene regler (3) Offer informative feedback För varje sak användaren gör ska systemet ge feedback. För vanliga och mindre saker kan den vara mindre markant, för ovanliga och större mer tydlig (4) Design dialogs to yield closure Följder av handlingar ska designas med en början, mitt och slut. Tydlig feedback vid avslut gör att användarna kan spänna av och veta att de är klara (och börja förbereda sig för nästa handling). T ex så för e-handelssajter användaren från val av produkter till checkout med en tydlig bekräftelsedialog som avslutar transaktionen. Shneidermans gyllene regler (5) Prevent errors Så långt det är möjligt designa systemet så att användaren inte kan göra fel. T ex disabla olämpliga menyval, tillåt inte text i sifferfält, välj från dropdowns istället för att skriva etc. Om man gör fel ska det vara enkelt att korrigera felet och man ska inte behöva ge all information igen. Felaktiga handlingar bör lämna systemets tillstånd oförändrat. (6) Permit easy reversal of actions Så långt det är möjligt ska det alltid gå att reversera handlingar. Detta lugnar användarna då de vet att de går att ordna misstag och uppmuntrar därför till utforskande. 28
Shneidermans gyllene regler (7) Support internal locus of control Erfarna användare vill känna att de har kontroll över GUI:t och att det svarar på deras handlingar. De vill inte ha överraskningar i form av oväntade beteenden och irriteras över långa inmatningar, svårighet att hitta information och att inte kunna uppnå önskat resultat. (8) Reduce short-term memory load Människans korttidsminne kan hålla typ 7+-2 saker. Detta är inte mycket. Därför måste man t ex se till att man inte måste hålla saker i minnet från en sida till en annan. Jakob Nielsens heuristics Jakob Nielsen välkänd usability-guru, se www.useit.com Detta är en annan uppsättning principer det är allmänbildning att ha hört talas om. Tänkta bl a för att kunna användas i utvärdering Fungerar också som designprinciper 29
Jakob Nielsens heuristics Visibility of system status Systemet ska alltid hålla användaren informerad om vad som sker Match between system and real world Systemet ska alltid följa användarens modell och termer istället systemmodell och terminologi. Följ real-world conventions. User control and freedom Användare väljer ofta fel väg och behöver nödutgång för att komma tillbaka enkelt. Stöd undo och redo. Nielsens heuristics, forts Consistency and standards Man ska inte behöva fundera på om saker betyder vad de brukar. Följ plattformskonventioner. Error prevention Ännu bättre än felhantering är att se till att inga problem uppstår. Leta efter problemsituationer och begär konfirmation för farliga handlingar Recognition rather than recall Minimera användarens minnesbelastning genom att visa det som kan utföras. Man ska inte behöva komma ihåg saker från en dialog till en annan. Instruktioner ska vara synliga eller lättåtkomliga när det behövs. 30
Nielsens heuristics, forts Flexibility and efficiency of use Shortcuts o accelarators kan ofta snabba upp interaktionen för erfarna användare. Erbjud möjlighet att anpassa vanliga actions. Aesthetic and minimalist design Dialoger ska inte innehålla information som är irrelevant eller sällan behövs. Varje bit onödig information slåss om uppmärksamhet med den relevanta informationen och minskar dess synlighet Nielsens heuristics, forts Help users recognize, diagnose and recover from errors Felmeddelanden ska uttryckas på vanligt språk (inga felkoder), tala om precis vad problemet är och föreslå en konstruktiv lösning Help and documentation Även om det är bäst om systemet kan användas utan hjälp så kan den behövas. Hjälp ska vara lätt att nå, lätt att söka i, fokuserad på användarens uppgift, lista konkreta stega att göra och inte vara för stor. 31
PROJEKT Projekt Start idag Sista inlämningsdag för rapport 21 mars Betygsgrundande Design 35% Prototyp 35% Rapport 30% Grupper finns i PingPong Uppgift Designa och prototypa en online-mataffär 32
Projekt I princip utförs projektet i 2 iterationer framtagande av en pappersprototyp framtagande av en mjukvaruprototyp Ni kommer att testa båda två under övningar Övning 3: imat pappersskisser Övning 4: imat pappersprototyp test Övning 5: Cognitive walktrough Viktiga datum Tisdag10/2 - Skicka ett mail till Peter med kort sammanfattning om hur ni planerar att utföra projektet och vem ska jobba med vad Onsdag 11/2 Övning 3, skapa skisser över imat. Måndag 16/2 Presentation av backend på föreläsning. Onsdag 18/2 Övning 4, Test av er pappersprototyp. Det ska alltså finnas en färdig pappersprototyp då som kan testas. Fredag 20/2 Handledning på labbtiden. Visa upp slutdesign. Onsdag 4/3 Övning 5, test av er design. Fredag 6/3 Handledning på labbtiden. Torsdag 12/3 Projektredovisning i halvklasss Fredag 13/3 Projektdemo (funktionalitet) Lördag 21/3 Inlämning av projektrapport och kod. 33
Målgrupp Folk i karriären med mycket begränsad tid för handling Givna personas Stefan Svantesson 36, säljare och foodie Alexandra Rodriquez 35, systemutvecklare Backend Presenteras senare Färdigt sortiment Resurser 34
Krav Applikationen ska vara designad för den givna användargruppen Funktioner som ska finnas Användarna ska kunna ange sina uppgifter inklusive adress och betalningssätt och att dessa sparas tills nästa gång man använder programmet. Man ska kunna välja varor att köpa ur affärens sortiment. Man ska kunna genomföra ett köp av de valda varorna. Programmet ska kunna visa en historik över tidigare inköp. Extensions Man kan förstås ha fler funktioner, t ex Att man kan spara och återanvända inköpslistor Att man kan markera produkter ur sortimentet som favoriter och sedan få fram dessa Att man kan välja bort ointressanta produkter så att de inte visas nästa gång man ska handla 35
Backend API:t presenteras senare för att undvika implementationstänk. Features man kan förvänta sig inkluderar Spara användaruppgifter Lista alla produkter Lista olika slags urval av produkter Söka bland produkter Plocka fram bilder som visar produkter En varukorg där man kan lägga valda produkter Sparande av utförda inköp. Backenden vet ingenting om GUI:t utan hanterar bara data. Att tänka på Läs hela texten om projektet på hemsidan Glöm inte att designa för givna personas Kan vara bra med en primary persona Rekapitulera vad som gåtts igenom i kursen och ta med det i designprocessen Snart gått igenom hela boken Diskutera hur ni ska jobba skolan, hemma etc? Arbetsroller kan vara bra t ex Projektledare Designansvarig Mjukvaruansvarig Grafikansvarig Rapportansvarig 36
Rapporten Rapporten ska beskriva arbetet och er prototyp. Reflektioner över designval är viktiga. Om några mönster ur Tidwell använts så ska t ex detta anges i beskrivningen av designen. Ta med både första iterationen, pappersprototyp, och andra iterationen mjukvaruprototyp. Av speciellt intresse är förändringar av designen mellan iteration 1 och 2, och tankar kring slutresultatet, dvs. vad som fungerar bra och vad som skulle kunna förbättras. Rapporten Rapporten får inte vara längre än 12 sidor. I ett appendix ska anges vad varje medlem i projektet bidragit med. Ett exempel på hur man kan lägga upp rapporten finns på hemsidan. 37
Avslutningsvis Räkna inte med att detta går att genomföra på schemalagd tid Har man inte jobbat 20 timmar/vecka hittills så är det dags nu Har man inte läst ordentligt kan det bli mer Enjoy! Frågor? Jobba med design Analysera uppgiften Informationsarkitektur Visual framework Skissa Pappersprototyp Att göra Läsa Kapitel 8 i Tidwell Många mönster läs alla Uttömmande uppställning av olika kontroller 38