Design och konstruktion av grafiska gränssnitt Olof Torgersson Interaktionsdesign Tillämpad informationsteknologi Chalmers/GU
Idag Project Backend Evaluering Onsdag test pappersprototyp Alla grupper måste närvara Handledning enligt särskilt schema på fredag Obligatoriskt! Möjlighet till vanlig handledning i labsalen Kursutvärdering
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
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 vara lägga till eller ta bort Räcker oftast att veta att något ändrades Rita om kundvagn
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)
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 ordrar som 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
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
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)
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
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 och 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
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
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.
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
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 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.
Nielsens heuristics, forts Flexibility and efficiency of use Shortcuts & 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.
Exempel från verkligheten
Vad kan dessa betyda? Lite närmare
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
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
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
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
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
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
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
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
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
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
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
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: design vs implementation Typ av evaluering: laboratorie vs fält Hur objektiv: subjektiv vs objektiv Typ av mätningar: kvalitativa vs kvantitativa Nivå på information: hög nivå vs låg nivå Grad av interference: obtrusive vs unobtrusive Resurser som finns: tid, deltagare, utrustning, expertis
PROJEKTRAPPORT
Allmänt Max 12 sidor Viktigast Reflektion kring arbetet och designen/resultatet Beskriva produkten Använd bilder för att visa designen 12 sidor försvinner lätt Deadline 15/3 kl 23.59
Innehåll Man måste inte organisera rapporten på ett visst sätt. Men följande är en möjlighet Titelsida Abstrakt Innehållsförteckning 1 Inledning 2 Bakgrund (kanske inte behövs) 3 Koncept (översiktlig beskrivning av imat) 4 Realisering (design och implementationsprocessen) 4.1 Pappersprototyp 4.2 Test och utvärdering 4.3 Mjukvaruprototyp 5 Resultat (beskrivning av slutresultatet) 6 Diskussion
forts 1 Inledning Sidan 1 Startar berättelsen Hellre I dagens samhälle erbjuds alltfler tjänster på internet.. än Detta är en projektrapport på kursen Sammanfattar lite om problemställning och arbete 2 Bakgrund Kanske inte behövs Här kan man berätta lite av varje som sätter rapporten i ett sammanhang Kan också behandla liknande andra saker som gjorts
forts 3 Koncept Översiktlig beskrivning Konceptet är en online mataffär för äldre Någon bild 4 Realisering Beskriv hur arbetet genomfördes 4.1 Pappersprototyp Om pappersprototypen och hur den utvecklades 4.2 Test och utvärdering Om testning och vilka eventuella ändringar som gjordes 4.3 Mjukvaruprototyp Om byggandet av programmet
forts 5 Resultat Beskriv er prototyp och de tankar och designmönster som ligger bakom 6 Diskussion Diskutera er prototyp och arbetet med att ta fram den. Reflektera kring vad som är bra och mindre bra Ta upp förslag på förbättringar
Vad har vi? Användarstudier, mentala modeller, personas Platform & Posture kategorier intermediate, expert, novice Organisera innehåll Feature, Search & Browse, Wizard Minimera navigation & Navigationsmönster clear entry points, global navigation Visuell hierarki, grouping & alignment visual framework, titled sections, module cards Ett antal olika sätt att utföra handlingar och affordances Button groups, action panel Shneidermans och Nielsens principer Getting input from user En massa kontroller, Structured format, input hints Flow & excise tips/regler för att undvika krångel Lists of Things Summan av detta saker att utgå från i en top-down process
Att göra Jobba med design Pappersprototyp Börja koda Struktur Flera paneler Olika LayoutManagers?