Design och konstruktion av grafiska gränssnitt Olof Torgersson Interaktionsdesign Tillämpad informationsteknologi Chalmers/GU Project Backend Evaluering Idag Kom på övningen på onsdag med prototyp Boka tid för handledning på fredag! (Snart) 1
http://ixdcth.se/courses/2015/dat216/backend IMAT-BACKEND Grunder IMatDataHandler Singleton IMatDataHandler.getInstance() Facade Samlad ingång till bakomliggande funktioner Grundläggande funktionalitet Ladda/spara data Komma åt produkter Komma åt Customer, CreditCard, User Komma åt ShoppingCart Komma åt orderhistorik Ta fram bilder Hantera favoriter 2
Grunder, forts Customer, CreditCard, User getcustomer getcreditcard getuser Enkla klasser Ger ett objekt av varje, mer behövs inte Innehåll sparas Anropa shutdown() när programmet avslutas ShoppingCart getshoppingcart() Tillståndet sparas Lite metoder för att lägga till/ta bort innehåll addshoppingcartlistener Kan lägga till en lyssnare som meddelas när kundvagnen ändras Implementera ShoppingCartListener shoppingcartchanged(cartevent evt) Vad som ändrades och om det var lägga till eller ta bort Räcker oftast att veta attnågot ändrades Rita om kundvagn 3
Product Behållare med namn, pris, kategori, enhet etc för produkter Skapas automatiskt när backenden läser in data Varje produkt har ett unikt id ProductCategory Enumeration med de kategorier som finns som default Javadoc ger översättning för vissa ShoppingItem Produkt + mängd Bra för att lägga till 3st eller 4,5 kilo av något till kundvagnen Konstruktor för 1 produkt och för produkt + mängd ShoppingItem(Product product, double amount) 4
Hitta produkter IMatDataHandler har ett antal metoder för att plocka fram produkter List<Product>findProducts(String s) Produkter med matchande namn List<Product>getProducts() Alla produkter List<Product>getProducts(ProductCategory pc) Alla produkter i en viss kategori Product getproduct(int idnbr) Produkt med ett visst id-nummer Order Motsvarar en beställning IMatDataHandlern skapar automatiskt ett Order-objekt när man gör en beställning placeorder() placeorder(boolean clearcart) Alla ordrarsom gjorts sparas automatiskt och läses in vid omstart För att göra orderhistorik behöver man alltså bara hantera hur ordrar visas upp 5
Mer IMatDataHandlern tillhandahåller godtyckligt skalade bilder för produkter getimageicon(product p) getimageicon(product p, Dimension d) getimageicon(product p, int width, int height) Dessa går bra att sätta som bilder på knappar, labels etc seticon För den som vill ha favoriter så stöds det Arkitektur API Frågor? Arkitektur Ha flera forms i implementationen! Ingen arkitektur Extralager ovanpå IMatDataHandler Extralager + central controller Extralager + flera controller Inget extralager flera controller Extralager på central director + flera controller 6
Demo Extralager ovanpå IMatDataHandler Flera controllers Användbarhet Oftast vill man att ens produkter ska ha hög användbarhet Det finns ett antal standardfaktorer man tittar på Sen undersöker man produkten för att förbättra dessa Usability a product should be Effective to use (effectiveness) Efficient to use (efficiency) Safe to use (safety) Having good utility (utility) Easy to learn (learnability) Easy to remember (memorability) 7
Bra? Interaktionsdesignspraxis Fastställ behov och krav loop Utveckla alternativa designförslag Bygg interaktiva prototyper för kommunikation och analys Utvärdera designen baserat på prototyperna end loop Utvärderingstekniker kommer in under hela processen då utvärdering sker i varje varv Val av utvärderingsteknik beror bl a på hur långt man kommit i utvecklingen 8
Utvärdering Utvärdering är något som bör pågå kontinuerligt under utvecklingsprocessen Interaktionsdesignsprocessen har en utvärderingsfas i varje cykel Tidig utvärdering kan göra att man undviker att lägga resurser på att utveckla fel produkt Kollar på funktionalitet och användbarhet Avser såväl design som implementering Mål med utvärdering Utvärdera systemets funktionalitet Alla önskade funktioner finns Alla funktioner är lätta att nå Alla funktioner motsvarar användarnas förväntningar Utvärdera systemets effekt på användaren Lätt att lära Trevligt att använda (satisfaction) Excise/overload Identifiera specifika problem Detaljer som inte funkar som förväntat Viktigt att korrigera innan release 9
Huvudkategorier Utvärdering av experter Designer Usability-expert Mäter inte hur systemet verkligen funkar utan bara om det är designat enligt bästa rådande principer Utvärdering med faktiska användare Testar om systemet faktiskt funkar för avsedda personer Fältstudier Laboratorieexperiment Expertutvärdering Utvärdering av experter kan utföras under hela designprocessen och är förhållandevis enkelt och billigt 4 metoder Cognitive walkthrough Heuristic evaluation Use of models Use of previous work 10
Cognitive Walkthrough Jmfr code walkthrough där man stegar igen delar av koden för att se vad som händer Främst inriktat på att man kan lära sig systemet genom att utforska det Det är så de flesta gör En expert walks through/stegar sig igenom olika uppgifter för att hitta eventuella problem Genomgången stöds av ett formulär Efteråt sammanställer man eventuella problem Det är förstås mycket viktigt att detta görs systematiskt Cognitive Walkthrough, forts För cognitive walkthrough behövs En prototyp Behöver inte vara färdigt system, men nära hur man tänkt sig En beskrivning av uppgiften användaren ska utföra En fullständig lista över de steg användaren behöver göra för att utföra uppgiften Info om vem användarna är och vilken kunskap och erfarenhet testarna kan anta att de har. 11
Cognitive Walkthrough, forts För varje steg i listan ovan försöker testarna besvara följande frågor 1. Motsvarar handlingen användarens mål i den givna situationen? Är det man ska göra det man vill? 2. Kommer användarna att se att handlingen som ska utföras finns tillgänglig? T ex syns meny/knapp man ska använda? 3. När användaren hittat rätt handling, kommer de att veta att det är den de behöver? Det är en sak att en knapp syns en annan att man förstår att den ska användas 4. När handlingen utförts kommer användaren förstå den feedback som ges? Dvs vet man om man lyckats eller ej? Heuristic Evaluation Man identifierar en uppsättning användbarhetskriterier (heuristics) Kollar på Nielsens 10 heuristics Sen låter man experter utvärdera designen och undersöka om de principer man valt följs Flera utvärderare som testar oberoende 3-5 utvärderare fångar 75% av problemen Kan användas på specifikationer, prototyper och färdiga system Enkelt och billigt Exempel från verkligheten 12
Jakob Nielsens heuristics Jakob Nielsen välkänd usability-guru, se www.useit.com Detta är ytterligare en 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 undooch 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. 13
Nielsens heuristics, forts Flexibility and efficiency of use Shortcuts & accelerators 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 steg att göra och inte vara för stor. 14
Exempel från verkligheten Lite närmare Vad kan dessa betyda? 15
Modeller och tidigare arbete Model-based evaluation Använder kognitiva eller designmodeller för design GOMS Goals, operators, methods, selection Förutspå problem utifrån modellen Även andra varianter som dialogmodeller Use of previous work Dyrt göra studier Man kan därför söka i litteraturen efter tidigare arbeten som stöder eller motsäger den design man föreslår Designmönster kan vara ett exempel Utvärdering med användare Expertutvärdering är mycket användbart men kan inte ersätta faktiska tester med riktiga användare Görs ofta i senare faser av utvecklingen I början måste man förstås lära känna sina användare också Kräver typiskt någon forma av system att testa Huvudkategorier Labstudier Fältstudier 16
Labstudier Fördelar Tillgång till specialutrustning Inga störningar från miljön Nackdelar Kontexten saknas Man kanske studerar saker som aldrig sker på riktigt Svårt att observera samarbete Lämpligt Om systemet används på farligt eller svåråtkomligt ställe Man vill studera kontrollerad manipulation Fältstudier Fördelar Naturlig omgivning Kontext (observation kan störa/ändra) Studier över lång tid möjliga Nackdelar Störningar, distraktion Oväsen Lämpligt När kontext är viktig Studier över lång tid 17
Experimental Evaluation Kontrollerad utvärdering av specifika aspekter av interaktion Bevisa att något är på ett visst sätt Utvärderaren väljer en hypotes som ska testas Man ställer upp ett experiment där vissa förhållanden undersöks genom att man varierar vissa saker och håller andra konstanta Sen mäter man och mappar resultat på de olika förhållanden experimentet görs under Faktorer i experiment Deltagare Vem representativa, tillräckligt många Statistisk analys minst 10 Variabler Saker man varierar och mäter Hypotes Det man vill visa Experimentdesign Hur man utför experimentet 18
Variabler Independent variable (IV) Något man ändrar för att framställa olika villkor Stil på GUI:t Antal menyelement Dependent variable (DV) Något som mäts i experimentet Tid Antal fel Antal klick Hypotes Förutsägelse/antagande om resultatet Uttrycks i termer av IV och DV T ex antalet fel kommer att öka när fontstorleken minskar Null hypothesis Säger att ingen skillnad kommer att kunna iakttas Antalet fel påverkas inte av fontstorlek Målet är att motbevisa detta 19
Experimentdesign Within groups design Varje deltagare utför experimentet under samtliga villkor Kan leda till överförande av inlärning Mindre kostsamt Inga problem från olika användare Between groups design Varje deltagare deltar bara under ett villkor Inga problem med överfört lärande Fler deltagare behövs Variation bland användare kan påverka resultat Analys av data För att visa att resultaten man får är giltiga gör man typiskt statistisk analys på materialet Typ 95% säkert att fontstorlek påverkar antalet fel Innan man börjar bör man Spara originaldata Titta på datan Val av statistisk metod beror på Typ av data Vilken information man vill ha ut Typiska kategorier av data Diskret ett ändligt antal värden Kontinuerlig godtyckliga värden 20
Analys av data, forts Vad är man ute efter? Finns det (verkligen) en skillnad? Hur stor är skillnaden? Hur korrekt är resultatet/uppskattningen Statistiska metoder är en vetenskap i sig och ingår inte i denna kurs. Man kan skumma igenom texten för att få en bild av vad det handlar om. FÄLTSTUDIER 21
Observationsmetoder För att samla in information om faktisk användning samlar man ofta in data genom att observera användare när de använder systemet. Typiskt utförs specificerade uppgifter Det finns lite olika metoder: Think aloud Cooperative evaluation Protocol analysis Automated analysis Post-task walkthroughs Think aloud Tänka högt Man iakttar användaren när han/hon utför uppgifter Användaren uppmanas att beskriva vad han gör och varför, vad man tror händer etc Fördelar Enkelt, kräver inte mycket expertis Kan ge värdefulla insikter Kan visa hur systemet faktiskt används Nackdelar Subjektivt Selektiv info Att beskriva samtidigt kan påverka hur man gör saker 22
Cooperative evaluation Variation på tänka-högt Experten deltar mer aktivt i utvärderingen, samarbetspartner Anändare och utvärderare kan ställa frågor till varandra under hela session Fördelar Mindre begränsat och enklare att använda Användaren uppmuntras att kritisera systemet Mer möjligheter till förklaringar/följdfrågor Protokollanalys Nyttan av observationsmetoder beror på hur bra man kan notera och samla in det som kommer fram. Kallas protokoll Analys kan utföras på flera sätt Papper o penna billigt, begränsat till skrivhastighet Ljudinspelning bra för tänka högt, synka med notes svårt Video bra data, kräver utrustning, inkräktar Dataloggar automatiskt, diskret, mycket data att analysera User notebooks mest för studier över tid Ofta blandar man flera metoder i verkligheten Audio/video-transkription är inte enkelt 23
Frågetekniker Att ställa frågor till användarna ofta bra sätt att få information Resultat subjektiva Även mycket användbart under tidiga faser för att skapa en bild av användarna och deras behov Två huvudkategorier Intervjuer Enkäter/frågeformulär Intervjuer Analytiker ställer frågor till användarna en och en med förberedda frågor Informellt, subjektivt, ganska billigt Fördelar Kan anpassas till situationen Man kan gå vidare och utforska frågor på djupet Kan få fram användarnas åsikter och oförutsedda problem Nackdelar Mycket subjektivt Tar lång tid 24
Intervjuer, forts Det är viktigt att förbereda frågor i förväg Ofta delar men in intervjuer i 3 kategorier Structured interview Man har vissa förberedda frågor och ställer bara dessa Semi-structured Man har förberedda frågor men går också vidare med följdfrågor för att utforska svar vidare Open Mer som en diskussion Semi-structured antagligen vanligast Enkäter En uppsättning bestämda frågor som ges till användare Fördelar Snabbt och når en stor användargrupp Kan analyseras mer rigoröst Nackdelar Mindre flexibelt Går mindre på djupet 25
Enkäter, forts Behöver noggrann design Vilken information efterfrågas Hur ska svaren analyseras Typer av frågor Allmänna Öppna (open-ended) Skalära Flerval Rankade Frågetyper Allmänna Samlar in bakgrund om användaren Ålder, kön, yrke, bostadsort, datorvana Öppna Möjlighet att skriva vad man vill Kan du föreslå förbättringar för gränssnittet? Svåra att analysera men kan ge information man inte tänkt på Skalära Det är lätt att rätta till fel 1-5 Skalan viktig, 1-3 kan var för lite, 1-10 för mycket 1-5 eller 1-7 funkar ofta bra 26
Frågetyper, forts Flerval Ett antal rutor eller checkboxar Ofta bra för att samla information om tidigare erfarenheter Ja/nej är ett specialfall Rankade Ordna ett antal alternativ Bra för att ta reda på vad man föredrar Frågeformulär bör testas innan man skickar ut dem av 4-5 användare Det är vanligt med låg svarsfrekvens (20-30%) Påverkar förstås hur representativa svaren kan anses vara Välja evalueringsmetod När i processen: Typ av evaluering: Hur objektiv: Typ av mätningar: Nivå på information: Grad av interference: Resurser som finns: design vs implementation laboratorie vs fält subjektiv vs objektiv kvalitativa vs kvantitativa hög nivå vs låg nivå obtrusive vs unobtrusive tid, deltagare, utrustning, expertis 27