Design och konstruktion av grafiska gränssnitt

Transkript

1 Design och konstruktion av grafiska gränssnitt Olof Torgersson Interaktionsdesign Tillämpad informationsteknologi Chalmers/GU 1

2 Idag Fortsatt om användare Mentala modeller vs implementationsmodeller Personas Postures Organisera innehåll Lite mönster Kod bakom lab 1 Problem Kopieringsmaskinen gick inte Behöver dela ut utdrag ur Cooper 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 2

3 Modeller Implementation Model User Mental Model Represented Model Implementation Model Hur programmet är implementerat Klasser Databaser Händelser (Film vs TV) 3

4 User Mental Models Eller Conceptual models Hur användarna tänker på systemet Skiljer sig ofta från hur det faktiskt funkar El Mobiltelefoner Celler i Excel. Represented Models Eller presenterad modell Den modell programmet faktiskt visar för användaren Denna måste ligga så nära användarens som möjligt Hur tänker man Vad kan man Vilka förutfattade meningar har man etc 4

5 Implementation vs Mental Mjukvara byggs alltför ofta på implemenetationsmodellen Designerns uppgift är att ta reda på användarens mentala modell Designa efter den Se till att detta implementeras Ju närmare desto bättre Exempel Boolean Logic Användare förstår inte matematiskt tänkande Exempel AND och OR Betyder inte samma sak i vanligt och formellt språk Visa alla studenter från Partille AND Kungälv Resultat tomt Visa alla studenter från Partille OR Kungälv Det man antagligen menar 5

6 Personas Vad gör man med resultatet från användarstudier? Anteckningar, inspelningar Hela poängen är att det ska hjälpa design Modell Vanligt inom allt möjligt Ekonomi Fysik Ger en bild av verkligheten som ökar förståelse En modell av en användare skapad utifrån användarstudier kallas persona Tanke Produkt för många olika användare Gör den så bred som möjligt så den passar alla? Effekten snarare att den inte passar någon Grejen är att hitta rätt användare att designa för Personas är modeller av användare där man tänkt igenom olika grupper Prioritera och designa utifrån dessa 6

7 Olika mål En produkt? 7

8 Fördelar Personas kan användas för att Bestämma vad en produkt ska göra och hur den ska fungera. Personas mål utgör grunden för design. Kommunicera med stakeholders, utvecklare, andra designers. Stärka konsensus och engagemang inom gruppen lättare att relatera till än feature-lists och flödesdiagram Mäta hur bra designen är utgå ifrån vad personan skulle tycka och prova Bidra till utveckling av marknadsföring och försäljningsplaner Hjälper till att undvika The elastic user Self-refential design Edge cases forts The elastic user Genom att spika användarens egenskaper i en persona undviker man att låta användarens egenskaper förändras efter vad man känner för för tillfället Self-referential design Utvecklarna mappar sina egna önskemål, motiv, kunskaper etc på produkten. Personas hjälper till att unvidka detta Edge cases Specialfall. Saker som kan hända men typiskt inte gör det för den persona man designar för. Dessa ska inte ha fokus i design. 8

9 Mer personas Personas bygger på användarstudier Hur mycket man vet avgör kvalité Personas presenteras som individer Gunnar, 22, IT-student Ökar inlevelseförmåga hos designers Personas representerar grupper av användare Specifik grupp användare Specifik applikation Beteendemönster Personatyper Primary Typiska målgruppen. Helst en Secondary Kompletterar primary med variationer Supplemental Behoven täcks av grupperna ovan T ex illustration Customer Användare!= kund Served Personer som påverkas av produkten Negative Visa vad man inte täcker 9

10 DESIGN Software Postures Talat om Beginners Intermediates Experts En komplementerande bild är att dela in program i Sovereign Transient Alla dessa parametrar ger input för design 10

11 Posture Ungefär: inställning, attityd, (hållning) Ett programs posture är något som måste bestämmas tidigt Är det Försynt Kaxigt Neutralt Tråkigt Färgglatt Hjälpsamt? Oavsett vilket, så ska det vara det av en orsak baserat på användarstudier. Mer posture Ett program kan ha flera olika postures för olika grupper Ett programs olika delar kan ha olika postures beroende på hur/ av vem/hur ofta/ etc de används Det bör dock finnas en överordnad posture 11

12 Platform Platform måste bestämmas tidigt också Givetvis olika program för Mobil Desktop Web Kiosk Game-console Etc Vad har vi? Användarstudier Användarmodeller Mentala modeller Platform Posture Typiska kategorier Intermediate Expert Novice 12

13 Postures enligt Cooper Soverign Posture Enväldig, härskande, suverän attityd/hållning Transient Posture Kortvarig, flyktig, övergående attityd/hållning Bara 2 kategorier, men kan vara användbart ändå Sovereign Posture Program som används under en längre tid med användarens fulla uppmärksamhet (helskärm) Utför ett antal relaterade uppgifter med dem under denna tid Exempel Word Excel NetBeans Vertical Applications Program för en smal niche (ofta specialbyggda) Journal och tidsbokning Videoaffär, bibliotek 13

14 Egenskaper Sovereign Intermediates vanligaste användare Optimera för fullscreen Körs under längre period Låt saker ta den plats som behövs Använd minimal visuell stil Konservativ stil Tröttnar på flärd/flashiga grejor Van -> saker kan vara ganska små Rich visual feedback Statusbar Titlebars etc Rich input Menyer, kortkommandon, drag&drop etc Exempel 1 14

15 Exempel 2 Egenskaper Transient Kommer och går En väl avgränsad uppgift Kort tid Användargränssnittet måste visa tydligt vad man ska göra Simple clear and to to the point Utför biuppgift Ta inte upp mer plats än vad som behövs (från sovereign) Bright and clear Kan ha ett starkare visuellt uttryck Men se till att instruktioner finns och är tydliga 15

16 Mer Keep it simple Ett fönster Inga små fippliga knappar etc Behövs det många dialogrutor har man designproblem Kom ihåg användarens val Kort tid Enklare om allt är likadant nästa gång Exempel 16

17 Användarstudier Användarmodeller Mentala modeller Platform Posture Sovereign Transient Typiska kategorier Intermediate Expert Novice Next Organizing the Content Vad har vi? Demo Card Layout Add to palette 17

18 Organisera innehåll Tidwell kap 2 Har det vi pratat om + kanske några scenarios Och sen då? Skissa? Börja organisera upp innehåll kan vara bättre Information architecture 2 ansatser Dividing Stuff Up Logisk kategorisering utan gränssnittstankar Physical Structure Olika sätt att dela in in sidor/fönster/paneler Dividing Stuff Up Har en massa features som ska organiseras Substantiv och verb Nouns and verbs Saker och handlingar Saker Arrangera Presentera Webbsidor etc Handlingar Interaktionsdesign handlar om att hälpa användaren att hitta nästa sak att göra Programmets struktur ska stödja vad man ska göra 18

19 Vanliga kategorier Lista av objekt inbox med mail, adressbok Lista av handlingar Köpa, sälja, bläddra Lista av ämneskategorier (subject categories) Hälsa, vetenskap, nöje, teknik Lista av verktyg Kalender, adressbok, schema, anteckningar Valet bör utgå från allt man vet om användarna Olika delar av en applikation kan fungera enligt olika principer Lista av objekt Visa olika samlingar Mail Bilder Sökresultat Olika alternativ Sorterad lista Tabeller Träd Kartor (med objekt) 19

20 Lista av handlingar Vad vill du göra? (istället för vad vill du arbeta med) Handlingarna kan göras begripliga Vilka ska de vara? Menyer och verktygsfält kan vara användbara Lista av ämneskategorier Vanligast på webben Massa olika kategorier av grejer att kolla på Svårare med applikationer där man ska göra saker 20

21 Lista av verktyg Utgå från lista med verktyg för olika saker Mobilmeny har ofta en sådan organisation Blanda inte ihop verktyg och handlingar Physical Structure Dags att börja organisera i fönster/kontroller Först övergripande ansats Ett fönster? Flera fönster? Ett fönster som byter sidor? Flera paneler i ett fönster? Alla på en gång? Inget enkelt svar Användning/användare styr Vad är man van vid? Behöver man jobba med annat samtidigt Vilka delar måste finnas tillgängliga på samma gång? 21

22 Några vanliga Multiple Windows Tiled Panes One-Window paging De två första tillåter mycket mer frihet för användaren Är detta bra eller dåligt? 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 22

23 (13) two-panel selector Vad Två paneler bredvid varandra. I den ena finns någon form av lista användaren kan välja från. I den andra visas innehållet. När Man har en lista av objekt (kategorier, handlingar). Varje objekt har ett intressant innehåll. Man vill kunna visa både strukturen på listan och det enskilda objektet. Displayen man jobbar med måste vara tillräckligt stor. Varför (kortversionen) Detta är en vanlig konvention som användare förstår Hur Placera listan ovanför eller till vänster och det som visas nedanför eller till höger. När användaren väljer i listan visas motsvarande objekt omedelbart upp (1 klick). Se till att det är uppenbart i listan vad som är valt. Exempel 23

24 (15) one-window drilldown Vad Visa alla applikationens vyer/sidor i samma fönster. När man väljer ett alternativ byts hela ytan ut mot den nya sidan. När Programmet består av många olika sidor (organiserade linjärt eller hierarkiskt) att navigera genom och man har en liten skärm eller det blir enklare för användarna på detta sätt. Varför Enkelt. Allting finns på en skärm. Alla vet hur man navigerar på webben som funkar på detta sätt. Hur Organisera innehållet i lagom stora delar. Förse dessa med lämpliga navigationskontroller. Se till att man kan komma tillbaka. Andra mönster som Breadcrumbs kan vara till hjälp. Exempel 24

25 Läs också (14) canvas + palette (16) alternative views (visa?) (18) extras on demand Att göra Titta igenom alla Swing-komponenter Veta vad som finns och vad de gör Swing-tutorial på nätet Läsa Preface och kapitel 1 i Tidwell Läsa kapitel 2 i Tidwell Kan hoppa över mönster 19 & 20 Läsa Cooper om Mental Models Läsa Cooper om Posture Läsa Cooper om Personas Än så länge är summan av detta utgångspunkt för design byggs på efterhand Nästa gång Fler designmönster Swing/Appframework 25