Lite info först Kom ihåg! Deadline på lab1 på onsdag. Övning 2 på onsdag: gör en kalender för olika slags användare
Förra veckan... GUI = Graphical User Interface (grafiskt användargränssnitt) Gör så här
Användare och designprocess Målorienterad design. Olika typer av användare. Mentala modeller, metaforer med mera. Att designa The interaction framework..
Om användare: Vad de vill, vilka de är, hur de tänker
Målorienterad design Cooper och många andra förespråkar Goal Directed Design - Google: Focus on the user and all else will follow (punkt 1 i Google s company philosophy ) Mål är det vi vill uppnå......inte medlen vi använder för att uppnå målet
Målpyramiden
Cooper mål Life goals vem användaren vill vara - leva ett bra liv, lyckas med någonting, vara populär, snygg, respekterad End goals vad användaren vill göra - Hitta musik som man tycker om, hitta det bästa priset, hålla kontakt med vänner och familj etc Experience goals hur användaren vill känna sig - Ha roligt, känna sig smart, cool, fokuserad, produktiv...
Målorienterad design Cooper: Det allra vanligaste målet för alla människor överallt i alla tider är ja vad då?
Målorienterad design Cooper: Det allra vanligaste målet för alla människor överallt i alla tider är ATT INTE KÄNNA SIG SOM EN IDIOT! Eller verka vara en! Glöm aldrig det.
Olika typer av användare Användare kan delas in i tre kategorier Vilka då?
Olika typer av användare Användare kan delas in i tre kategorier Nybörjare vanliga användare Experter
och varför ska vi bry oss om det?
och varför ska vi bry oss om det? Nybörjare är viktiga för vi vill behålla dem och förvandla dem till Vanliga användare är viktigast eftersom de är flest, och därför är det dem vi tjänar pengar på. Experter är viktiga eftersom det är de som bedömer, recenserar och rekommenderar programmet och eftersom de uppskattar förbättringar!
Olika stadier
Personas I sin designprocess använder man ofta personas, som får representera statistiken. De är påhittade personer med riktiga användar-karaktäristika - Ex två vanliga användare som har två olika mål med programmet - En expertanvändare - Alla har andra egenskaper också; jobb, bil, ålder, hobbies, familj (bild också!!!) - sätter namn på en kravspec - ej baserarade på påhittad data och stereotyper - informationen måste vara relaterad till vad användaren vill göra - Undviker self-referential design
Hur tänker vi? Människor Mönsterigenkänning Kasualitet (orsakssamband) Många parallella, kontinuerliga tankeprocesser Dåligt minne Datorer Räknar ut saker Behöver regler Diskreta processer Väldigt bra minne
Hur tänker vi? Människor tillämpar mentala modeller Vi tror att saker fungerar på ett visst sätt Det behöver inte vara sant :) Vi har svårt för hårda data och vill hellre ha samband Datorer tillämpar implementationsmodeller Hårda, maskinnära data Kodstruktur Informationsarkitektur 99 gånger dricker jag kaffe, 1 gång dricker jag te Det finns två fall
Mellantinget En representativ modell ligger någonstans mellan den mentala modellen och implementations-modellen Designerns uppgift är att skapa en representativ modell av systemet Eftersom det är väldigt bökigt och svårt att nå hela vägen fram till en användares mentala modell
Implementationsmodell 0, 102, 204
Representationsmodell Blå
Representationsmodell (fast närmare den mentala modellen) Blå
Mental model
GUI - exempel
Metaforer Ibland använder vi metaforer för att förklara en viss funktion för användarna Det är helt enkelt riktiga saker vars funktion eller beteende överensstämmer med något i GUIt Typiska GUI-metaforer är Att vi jobbar med dokument (och inte filer numera) Saxen som symboliserar klipp ut Att vi lagrar våra dokument i mappar (vilket är mindre bra eftersom man i verkligheten inte har mappar i mappar i mappar )
Metaforer är bra eftersom de ger enkla ledtrådar till vad något är, eller hur det kan användas men är också problematiska eftersom: De inte håller hela vägen (som mappar i mappar) De kan vara begränsande (tänk att se Word som en skrivmaskin enbart!) De oftast inte hänger med när man utökar systemet med nya funktioner för då kanske man lånar in metaforer från en annan domän och då blir det rörigt som i Photoshop där man blandar metaforer från foto, måleri och magi
Idiom är en lösning på detta Idiom kan inte listas ut, de måste läras in - Ursprungligen mystiska språkliga uttryck, t.ex. cool - Måste vara lätta att lära in (bra idiom lär man sig enbart en gång), måste fungera oberoende av kultur - GUIs är mestadels idiomatiska t.ex. gestures i touch skärmar, hyperlänkar, stäng-knappar (x) Disketten För oss är den en metafor men om den hänger kvar ett par decennier till kommer den att förvandlas till ett idiom
Välkända idiom
Välkända idiom Nästan alla typer av kontroller i GUIn
Sammanfattningsvis Designa för att användaren ska uppnå sitt mål så snabbt och enkelt som möjligt men glöm inte andra intressegrupper Designa för den vanlige användaren men glöm inte bort nybörjarna och experterna Försök göra representativa modeller som ligger nära användarnas mentala modell Använd bara riktigt bra metaforer
Me tired and sleepy need a break
Designprocessen: Att sno ihop ett GUI
Från spec till design Detta är egentligen en lång process Bakgrundsforskning: vad, vilka, var, när, hur? Modellering: vilka mål, vilka är de huvudsakliga användarna Funktionsanalys: scenarios, use cases, objectives Att designa ramverket, dvs själva interaktionsdesignen Att förbättra designen och lägga till look&feel Att testa, förbättra, dokumentera, supporta
Att skapa ett ramverk för interaktionsdesign Definiera kontext Hur och var ska GUIt användas? Definiera element Vad har vi för saker i systemet och vad kan man göra med dem? Gruppering Vilka element hör ihop, vad är viktigast Skissa Enkla layout-skisser som visar flöden och skärmelement Keypaths Skapa interaktionssekvenser. Fundera på /se över layout. Validering Funkar det här som vi tänkt nu då? Testa, testa, testa!
Vi testar!
Vi testar! Hotellbokingssystem 2-3 vanliga användare (kan Word, Excel, email) Det brukade vara Excel-filer 58 rum; 43 i huvudbyggnaden, 15 i ett annex (sidobyggnad) 2 sviter i huvudbyggnaden En hel del stammisar
1) Definiera kontext Hur och var ska gränsnittet användas? Är det en användare eller flera? Vilken är användningsmiljön? Vilken är användningssituationen? Hur ska information visas? Hur ska informtion matas in? För vårt hotell blir det..?
2) Definiera element Vilka saker har vi i systemet, och vad har de för egenskaper ( vad ska vara i databasen? ) Exempel på saker är sånt som användare, recept, filer Exempel på egenskaper blir då Funktioner Namn, login, lösenord, organisation, rättigheter Ingredienser, typ av rätt, instruktioner Vad vill vi kunna göra med sakerna? (Skapa, editera, flytta, ändra, koppla ihop? )Hur? För vårt hotell blir det..?
3a) Gruppering Vilka är de viktigaste sakerna? Vilka är de viktigaste funktionerna? Hur ska de grupperas på bästa sätt? Grupper, flikar, menyer Tänk på flow och sekvenser här finns det en naturlig ordning? För vårt hotell blir det..?
3b) Skissa Rita bara enkla former:) Börja översiktligt Börja med att dela in skärmen i olika områden, eller processen i olika steg Fyll på med innehåll GÖR ALLTID MER ÄN EN SKISS!!! Och kom ihåg: RÄTT ÄR BÄTTRE ÄN SNYGGT!
3c) Testa keypaths En key path är en vanlig eller trolig interaktions-sekvens som kan hjälpa till med layout & flow Exempel: att skriva ett mail Att öppna/skapa ett nytt mail (måste vara först) Att i någon ordning ange saker som Mottagare (måste) Ämne (måste inte) Innehållet (bör man väl ha ) Etc Att skicka (gör man sist) För vårt hotell blir det..?
Välj själv! :) Gruppera, skissa och skapa key paths kan man göra i vilken ordning som helst välj den som passar dig bäst! Oftast går man fram och tillbaka mellan aktiviteterna i en iterativ process. Validering Funkar det här som vi tänkt nu då? Testa, testa, testa! Gruppering Vilka element hör ihop, vad är viktigast Keypaths Skapa interaktionssekvenser. Fundera på /se över layout.
Validering Man kan hitta på alternativa key paths De mer ovanliga sakerna (exempelvis att radera alla mail i en inbox, eller rotera alla bilder i en mapp) Man kan försöka slå sönder key paths (gaming!) Kolla att man har med ovanliga men nödvändiga funktioner Att konfigurera nånting Lägga till användare För vårt hotell blir det..?
Iterera! De sista fyra stegen är iterativa!
Summering Definiera kontext Hur och var ska GUIt användas? Definiera element Vad har vi för saker i systemet och vad kan man göra med dem? Gruppering Vilka element hör ihop, vad är viktigast Skissa Enkla layout-skisser som visar flöden och skärmelement Keypaths Skapa interaktionssekvenser. Fundera på /se över layout. Validering Funkar det här som vi tänkt nu då? Testa, testa, testa!
Me tired and sleepy again need to go home and study
Do this Don t do this