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 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 Användarnas allmänna datorkunskap Textfält förståeligt för alla Dubbelslider eller lista med flervalsmöjlighet mycket svårare Användarnas domänkunskap Vet man att bara vissa intervall är tillåtna så måste man inte designa lika noga Det kanske är mindre viktigt att bara ha givna alternativ att välja mellan Men det blir lätt fel även om man är kunnig forts 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 5
Några mönster Allmänt Mönster är förslag på fungerande lösningar 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 6
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 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 7
Structured Format 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. 8
Exempel forts bra? 9
Fill-in-the-Blanks 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. 10
Exempel Input Hints 11
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 Exempel 12
forts bra? Illustrated Choices 13
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 14
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. 15
Exempel forts 16
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. 17
Exempel NÅGRA HCI-BEGREPP 18
Shneidermans gyllene regler 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 (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 forts 8 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. 19
forts 8 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. Forts 8 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. 20
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 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 platformskonventioner. 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. 21
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. 22
Projekt Start idag Sista inlämningsdag för rapport 16 mars Betygsgrundande Design 35% Prototyp 35% Rapport 30% Grupper finns på hemsidan Uppgift Designa och prototypa en online-mataffär 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 23
Resurser Backend Färdigt sortiment 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. 24
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 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. 25
Deadlines etc Utvecklingen sker i 2 iterationer Framtagande av pappersprototyp Framtagande av mjukvaruprototyp Tider att tänka på Onsdag 12/2 maila kort rapport om arbetsplaner, se hemsidan Fredag 15/2 handledning på labbtiden. onsdag 20/2 - test av pappersprototyp på övningstiden. Det ska alltså finnas en färdig pappersprototyp då som kan testas. fredag 22/2 visa slutgiltig design på labbtiden Läsvecka 7 demo och användartest av prototypen. Lördag16/3 - inlämning av projektrapport Det tillkommer möjlighet till handledning under arbetets gång 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 26
Avslutningsvis Räkna inte med att detta går att genomföra på schemalagd tid Har man inte jobbat 25 timmar/vecka hittills så är det dags nu Har man inte läst ordentligt kan det bli mer Mer om rapporten kommer vid ett senare tillfälle Enjoy! Frågor? Att göra Jobba med design Analysera uppgiften Informationsarkitektur Visual framework Skissa Pappersprototyp Visa gärna denna nästa fredag Läsa Kapitel 8 i Tidwell Många mönster läs alla Uttömmande uppställning av olika kontroller 27