Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
157 Cards in this Set
- Front
- Back
|
Signifiers |
Ledtrådar man letar efter när man står inför något okänt
-Vad vi kan göra = funktionallitet -Hur vi kan göra det = Interaktion
|
|
|
Pliancy |
Att indikera att något på skärmen är klickbart eller på annat sätt manipulerbart
Static object hinting - Att ett objekt kommunicerar alltid sin manipulerbarhet. Ex att knappar är ritade i “3D” Dynamic visiual hinting - Att ett objekt ändrar utseende när markören passerar över det Pliant response hinting - Att ett pbjekt ändrar utseende när man integrerar med det Cursor hinting - Markören ändrar utseende
|
|
|
Feedback |
Reaktioner på vad användaren gör eller har gjort. Visa status etc.
Visuell feedback - Objekt ändrar utseende för att visa att de ör valda eller för tillfället aktiva Audio feedback - genom ljud. man bör undvika negativ feedback modal feeback - visar vilket mode/läga man är i. tex popup modeless feedback - samma men avbryter inte användaren. Tex sladden på batteriikonen när man laddar. understrukna felstavade ord m.m.
|
|
|
Affordance |
Att indikera att något på skärmen är klickbart eller på annat sätt manipulerbart
Egenskaper hos ett föremål som visar hur man använder det
|
|
|
Flow |
När allt flyter på utan störningar
|
|
|
Excise |
De där extra interaktionerna som inte har något med målet att göra men som ändå måste utföras.
Mål - Ta bilen till jobbet Excise - öppna garagedörren, stänga garagedörren, köra ut, tanka på vägen etc.
Visuel excise - rörigt GUI. onödiga bilder etc.
|
|
|
Goal Directed Design |
Google - “Focus on the user and all else will follow
|
|
|
Coopers mål |
Life goals - Vem vill avnändaren vara? Leva bra liv, lyckas, populär, snygg, respekterad End goals - Vad användaren vill göra? Hitta musik man tycker om, hitta bästa priset, hålla kontakt med vänner/familj Experience goals - Hur användaren vill känna sig? Ha roligt, känna sig smart, cool, fokuserad, produktiv |
|
|
Vanligaste målet enligt cooper: |
Inte känna sig som en idiot |
|
|
Typer av användare och varför de är viktiga
|
Nybörjare är viktiga - Vi vill behålla dem för att de skall bli |
|
|
Hur tänker vi? Människor vs Datorer |
Människor - Mönsterigenkänning, Kasualitet(orsakssamband, Många parallella kontinuerliga tankeprocesser, Dåligt minne |
|
|
Mentala modeller - Det människor tillämpar |
tror saker fungerar på ett visst sätt, svårt för hård data, vill ha samband Implmentationsmodeller - Det datorer tillämpar Hårdam maskinnära data, kodstruktur, informationsarkitetkur Representativa modeller - Mellanting EX: Implementation: 0, 102, 204 Representativ: Blå |
|
|
Metaforer |
dokument = textfil, Sax = klipp ut, Mapp = där vi har filer(Mendre bra eftersom man inte har mappar i mappar i mappar)
Bra men kan bli rörigt. Word har en skrivmaskin men är mer än så. När man tar in metoforer från olika domäner blir det rörigt. Photoshop har från bild, måleri och magi |
|
|
Idiom |
Något man måste lära sig. inte listas ut som metafor.
Välkända är Play, pause och Stop
|
|
|
Från spec till design Lång process |
Bakgrundforskning: Vad, vilka, var, när? Modellering: Vilka mål, vilka är de huvudsakliga användarna? Funktionanalys: scenarios, use cases, objectives designa ramverk: själva interaktionsdesignen Förbättra design: look and feel testa, förbättra, dokumentera, supporta |
|
|
Skapa ramverk |
Definera kontext hur skall GUI:t användas? Definera 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 Keypaths Skapa interaktionssek- venset. Fundera på /se över layout Validering Funkar det här som vi tänkt nu då? Testa, testa, testa... |
|
|
Vad är ett designmönster? |
Förslag på fungerande lösningar, måste anpassas efter situationen Nytta – Kan man många mönster ä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 |
|
|
Vad finns det för nytta med ett designmönster? |
Kan man många mönster är chanser större att man hittar ett för den givna situationen
Ger en vokabulär för att diskutera design
Studera/reflektera kring program man använder
Är beprövade
|
|
|
Tidwell - Organisera innehåll
|
Hur skall gränssnittet organiseras?
Vilka objekt skall visas?
Hur är de kategoriserade och ordnade?
Vad vill användaren göra med dem? |
|
|
Tidwell - Struktur |
Organisera i fönster och kontroller – 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 ärman van vid? - Behöver man jobba med annat samtidigt - Vilka delar måste finnas tillgängliga på samma gång? - Posture |
|
|
Tidwell - Posture |
Transient posture – Applikationer som används kort tid för små uppgifter – Färre funktioner, enklare och tydligare • Byta låt, kolla väder, hitta en fil
|
|
|
Varje enskild sida gör i huvudsak en av följande: |
– Visa upp en sak – Visa en lista av saker – Tillhandahålla verktyg för att skapa något – Genomföra en uppgift
|
|
|
Tidwell - Mönster - Feature Search and Browse |
Vad? Tre element på sidan: • En huvudartikel (feature) • En sökruta • En lista med saker att bläddra i När? Man har långa listor som passar för att söka och bläddra och samtidigt vill erbjuda något direkt för att ”fånga” användaren. Varför? Väldigt vanligt mönster som finns överallt. Söka och bläddra kompletterar varandra bra samtidigt som sidan blir mer engagerande med en feature Hur? • Feature i Center Stage (kap 4) • Sökruta som är lätt att hitta • Lista nära feature som är lätt att hitta. |
|
|
Tidwell - Mönster - Wizard |
Vad? Led användaren genom gränssnittet för att utföra en uppgift steg för steg i en bestämd ordning När? Lång och komplicerad uppgift där användaren behöver hjälp och är beredd att släppa kontrollen. Varför? Gör en komplicerad uppgift lättare genom att dela in den i flera steg. Hur? • Dela upp information • Navigation • Karta |
|
|
Tidwell - Mönster - Alternative Views |
Vad? Låt användaren välja mellan flera olika vyer som är väsentligt olika När? Applikationer som visar upp någon form av strukturerat innehåll som kan ses på olika sätt Varför? En vy räcker inte för att fungera bra för allt som behövs. Genom att ”byta lins” ges fler möjligheter och mer/ annan information. Hur? Designa speciella vyer för scenarios som inte fungerar bra med standardvyn. Visa dessa istället för standardvyn. Placera en ”switch” för att byta vyer på något lämpligt ställe. |
|
|
Tidwell - Mönster - Canvas Plus Palette |
Vad? En tom canvas tillsammans med en palett med ikoner. Användaren klickar på paletten för att skapa objekt på canvasen. När? Applikationer som innehåller en grafisk editor, man skapar nya objekt i något virtuellt utrymme. Varför? Beprövad och väldigt vanlig design med bra mappning till verkliga objekt. Hur? En stor tom yta visas för användaren och runtom visas paletter med ikoner. |
|
|
Tidwell - Mönster - Many Workspaces |
|
|
|
Cooper - Menyer |
Karta över alla funktioner i programmet - Vad kan jag göra? - Vad kan jag inte göra? Bör inte ha mer än en nivå Namn - Tillräckligt långa - Beskrivande Kortkomando/Accelerators - Ctrl-S - Se till att det som förväntas finns - Följ standards Mnemonics/Access keys - (Alt + F + S) = File -> Save - Gör komplett Ikon - Koppla samman knapp i toolbar och meny Disabeled items |
|
|
Cooper - Standardmenyer |
File - öppna, stänga. Överväg document/Song istället för File Edit - Cut, Copy, Paste etc Window - Arrangera om fönster eller dokument(fler för att det skall vara nödvändigt) Help |
|
|
Cooper - Andra vanliga menyer |
View - vad som skall visas etc Insert - nya saker i dokument, tabeller bilder etc Format - font, stil, storlek, justering Tools - Mer kraftfulla funktioner - Stavningskontroll - funktioner för power-users |
|
|
Cooper - Toolbars |
Get erfarna användare snabb åtkomst till vanliga funktioner Icon buttons- ikon + button Ofta anpassning- och flyttbara Skiljs åt med separator Disable när de inte gäller- ta inte bort, detta förvirrar användaren Fler kontroller - Combobox, Visa state |
|
|
Cooper - The Ribbon |
merge mellar toolbar och menyer
|
|
|
Cooper - Menyer |
Använd menyer som en karta över programmet • Inaktivera menyval som inte kan väljas • Var konsekvent med användning av ikoner • Skriv ut accelerators i meny (CTRL-S) • Skriv ut mnemonics/ access keys (File, Save) |
|
|
Cooper - Toolbars |
Snabb tillgång till de viktigaste funktionerna • Mycket funktionalitet på liten yta • Inaktivera val som inte kan väljas • Använd Tooltips • Tänk igenom ikonval |
|
|
Cooper - Storlek och tomrum |
Free layout - placera saker där de ska vara och hoppas på det bästa Storlek – Man kan sätta preferred-, maximum- och minimumSize – Layout Managers måste inte bry sig om detta • Mellanrum – Kan sättas i vissa Layoutmanagers inte i andra – Osynliga komponenter som tar plats – Osynliga Borders • Man kan sätta Borders på det mesta • Låter man dem vara ”osynliga” fungerar det som mellanrum • Kan ha vilken storlek som helst |
|
|
Cooper - BorderLayout |
• Fem områden; top, bottom, left, right och center. • Allt extra utrymme hamnar i center |
|
|
Cooper - BoxLayout |
Lägger komponenter på rad eller i kolumn |
|
|
Cooper - CardLayout |
Användbart för att byta panel i samma fönster • Tabbed Panes kan vara ett alternativ – Vilket som är lämpligt beror på sammanhang |
|
|
Cooper - FlowLayout |
Standardlayout i JPanel om man inte anger något annat • Lägger ut komponenter i rad så länge det finns plats och byter sedan rad |
|
|
Cooper - GridBagLayout |
• Avancerad layout för handkodning • Grid av celler där varje komponent kan spänna över flera celler • Rader kan ha olika höjd, och kolumner olika bredd |
|
|
Cooper - GridLayout |
|
|
|
Tiddwell - Mönster - Button Groups |
Vad? Placera relaterade action i grupper av knappar som är alignade och visuellt lika. Skapa flera grupper om fler än 3-4 st. När? Behöver visa många actions i gränssnittet och gruppera dessa på ett logiskt sätt. Cancel, Ok, Apply Varför? Gruppen gör gränssnittet lättare att förstå eftersom gruppen står fram som en enhet. Närhet och likhet viktiga principer Hur? Använd verb eller verbfraser som titlar, gruppera och låta alla knappar ha samma storlek och utseende. Finns det en primär action kan denna stå ut. |
|
|
Tiddwell - Mönster - Action Panel |
Vad? Som komplement till menyer visa ett antal relaterade actions på en panel med rik visuell design som alltid är synlig När? Man behöver visa många actions. Att bara ha dem i en meny eller popup-meny gör dem inte tillräckligt synliga. Det är inte ont om skärmutrymme. Varför? • Synlighet och presentation • Logisk sett en meny men större synlighet och större frihet för design. Hur? Avsätt en del av gränssnittet för action-panelen. Oftast vid sidan eller under. Inte för långt bort från det den påverkar. Låt panelen vara dynamisk. |
|
|
Tiddwell - Mönster - Prominent ”Done” Button |
Vad? Placera knappen som markerar slutet på en transaktion i slutet av gränssnitten visuella flöde. Gör den stor och ha en bra beskrivande text. När? Man behöver en knapp som OK, Skicka, Fortsätt etc. Mer generellt används det för att avsluta varje steg i en process som att handla online eller fylla i ett formulär. Varför? Ett tydligt sista steg ger användarna en känsla av avslut. De behöver inte fundera på om man är klar eller inte. Det ska vara självklart. Hur? Använd en knapp som ser ut som en knapp. Det är bättre med text som talar om vad som görs än en ikon. Placera knappen i slutet av sidans visuella flöde och gör den tydlig mot andra komponenter. |
|
|
Det är tre saker som definerar “formen” på ett GUI |
Gruppering av element Balans
Grid och alignment(dvs hur komponenter är utlagda på ett osynligt rutnät) |
|
|
Tidwell - Gruppering |
-Vi grupperar saker för att visa hur de hör ihop
-På så vis blir det enklare för användaren att hitta relaterade funktioner
-Ett exempel är menyer, ett annat grupperingen av ikoner på “the Ribbon” |
|
|
Tidwell - Gruppering - Närhet(priximity) |
Saker som är nära varandra uppfattas som att de hör ihop
|
|
|
Tidwell - Gruppering - Likhet(similarity) |
|
|
|
Tidwell - Gruppering - Linjering(continuity) |
Vi vill forma linjer och kurvor som skapas genom sammanslagning av mindre enheter
|
|
|
Tidwell - Gruppering - Closure |
Vi letar efter former och kan “fylla i” det som saknas |
|
|
Tidwell - Balans |
Balanslinje någonstans genom layouten med lika mycket “tyngd” på båda sidor av linjen |
|
|
Tidwell - Alignment och grid
|
Grid är ett (osynligt) rutnär som man placerar saker på
Alignment(justering) är helt enkelt att försöka linjera saker längs rutnätet |
|
|
Tidwell - Viktning |
Viktigaste överst och indenterade saker är alltid mindre viktiga och hör ihop med det som är indenterat
visual flow - övre vänstra hörnet till nedre högra
|
|
|
Tidwell - Fokal/fix-punkter |
Mer synliga punkter på en sida. Ha inte för många då de tar ut varandra
|
|
|
Tidwell - Designmodell - Visual Framework |
Att det visualla utseendet (färger, fonter) och layout är någorlunda enhetligt i hela applikationen När – Applikationer eller sajter med många olika sidor (typ allt). Man vill att det ska sitta ihop Varför – Enhetlig design av varje sida gör att man känner igen sig och inte behöver anstränga sig lika mycket. Hur – Skapa en genomgående look-and-feel för alla sidor i applikationen • Färger, fonter, stil på text • Navigation • Layout-grid |
|
|
Tidwell - Designmodell - Center stage |
Att man har det centrala dokumentet i mitten
Vad – Placera den viktigaste delen i den största delen av fönstret. Placera sekundära verktyg och innehåll runt om. När – Det finns en huvuduppgift som användaren jobbar med, redigera dokument, utföra en uppgift etc. Varför – Led direkt användaren till den viktigaste delen av sidan. Sedan är det enklare att ta in vad som finns runtomkring. Hur – Center stage-delen bör vara åtminstone dubbelt så bred och hög som något annat. – Huvuddelen måste inte vara i mitten, bara den är stor nog
|
|
|
Tidwell - Designmodell - Grid of Equals |
Att man arrangerar liknande element /liknande innehåll i ett rutnät.
När – Sidan innehåller många objekt med liknande innehåll och vikt Varför – Rutnät som ger varje objekt samma utrymme understryker att de är likvärdiga. Ser snyggt och prydligt ut Hur – Designa varje element. Typiskt inte bara som ren text utan bilder, rubriker etc. Skapa ett rutnät med en eller flera rader |
|
|
Tidwell - Designmodell - Titled Sections |
Att skapa olika grupper av innehåll genom att förse dem med en visuellt tydliga titel och sen placera alla på samma sida
När – Det finns en massa innehåll på en sida och man vill göra det tydligare att förstå genom att gruppera det. Varför – Tydliga sektioner gör innehållet lättare att ta in. Visuellt tydliga titlar gör det också enklare att snabbt se det viktigaste. Hur – Se först till att få rätt indelning och ge dem bra namn. Sen väljer man representation – boxar, titlar med särskilda färger, stor font, avgränsning med tomrum… |
|
|
Tidwell - Designmodell - Module Tabs |
När – Det finns för mycket material på en sida och det går att göra en uppdelning där det räcker att se en del åt gången. Varför – Uppdelningen i olika kort gör att varje enskilt kort kan göras enkelt att hantera. Tabbar är en vanlig konvention för användarna. Hur – Dela upp informationen i lämpliga delar. Se till att man inte måste byta fram & tillbaka. Välj lämpliga namn för varje sektion. Välj en presentation t ex tabbar, vänsterkolumn med val… |
|
|
Tidwell - Designmodell - Right/Left Alignment |
Att högerjustera labels i vänsterkolumnen och vänsterjustera objekten i högerkolumnen
|
|
|
Tidwell - Designmodell - Liquid Layout |
Att anpassa innehållet när sidans storlek ändras så att det tillgängliga utrymmet alltid fylls.
När – Närhelst man har en sida man kan tänka sig att man vill ändra storlek på, ofta för att kunna se mer information Varför – För de flesta program kan man inte förutsäga hur stor yta de kommer att uppta pga olika fönsterstorlekar, andra fönster på skärmen etc. Därför bör programmet anpassa sig elegant. Hur – Fundera ut hur fönstret bör anpassas. I center stage är det t ex lämpligt att huvudytan blir större och annat behåller sin storlek. När ytan blir för liten kan man ha scroll-bars. Java har rätt bra stöd. |
|
|
Navigation |
Navigation är (nödvändig) excise Idealet vore att inte ha någon navigation alls men… -…Då kan man inte göra komplexa programvaror -…Eller hålla sig med komplexa informationsstrukturer
Navigation är ”som att gå in i ett nytt rum” -Man måste reorientera sig -Det hjälper om man varit där förr -Det hjälper om där ser ut ungefär som man -förväntat sig (coherency)
Ju mindre navigation desto bättre -Ha så få fönster som möjligt -Ha ”important tools close at hand”
Undvik långa navigationskedjor -Och tillhandahåll genvägar… särskilt tillbaka/hem
Försök alltid eliminera onödiga steg |
|
|
Navigation - Hub and spoke |
|
|
|
Navigation - Fully connected |
|
|
|
Navigation - Stepwise |
|
|
|
Navigation - Pyramid |
|
|
|
Navigation - Multilevel |
|
|
|
Navigation - Flat |
|
|
|
Navigation - Global Navigation |
Att använda en liten del av varje sida/skärm till att visa en uppsättning knappar/länkar som leder till programmets olika delar
När – När man har ett antal olika avdelningar /sidor/ verktyg /modes och där man kan vilja byta mellan dessa Varför – Det ger användaren en översikt och hjälp att utforska. På webben är detta en konvention, men det är även användbart i vanliga gränssnitt. Hur – Organisera först upp innehållet. Det får inte finnas för många olika delar. Designa en navigeringspanel som är samma överallt och som finns på samma ställe. Markera var man är nu tydligt. |
|
|
Navigation - Clear Entry Points |
Att bara ha några få ingångar till programmet. Dessa är uppgiftsorienterade och tydliga.
När – (Uppgiftsbaserade) program som används sällan. Om uppgiften är uppenbar kan det bara vara ett irriterande extrasteg Varför – När man startar ett program kan man mötas av ett komplicerat GUI med massor av möjligheter där det inte är uppenbart vad man ska göra. Hjälp användaren förbi detta steg. Hur Visa ett antal tydliga ”dörrar” när programmet startar. Därifrån går man vidare till det man ska göra. Dörrarna kan vara ikoner, text etc, men de ska kunna förstås av förstagångsanvändare |
|
|
Navigation - Sequence-Map |
Visa på varje sida i en sekvens en karta över alla steg, med markering för var man är nu.
|
|
|
Navigation - Breadcrumbs |
Att visa hela den (hierarkiska) vägen tillbaka till huvudsidan
När – Användarna navigerar runt, vanligen kombinerat med one-window drilldown. Kan kombineras med sökning Varför – Hjälper användaren att förstå var han/hon är. Spåret ger en bild av en del av applikationen. Fungerar även om man inte navigerat dit. Hur – Placera en sekvens av text eller bilder nära toppen på sidan som visar vägen från toppen till nuvarande sida. Man kan typiskt |
|
|
Navigation - Modal Panel |
Att bara visa en sida och kräva att användaren ska utföra vad det nu är som begärs på den sidan När – Programmet är i ett tillstånd där det inte kan fortsätta utan input från användaren – I princip aldrig annars! Varför – Tvingar användaren att handla Hur – Typiskt en panel/dialog ovanpå det vanliga GUI:t. Allt annat blockeras för interaktion. – Markera tydligt vägarna ut |
|
|
Getting input from users |
Se till att användaren förstår vad som efterfrågas och varför - anpassat språk - mycket info? förklara varför - tooltip Om det går ställ inte frågan alls - kanske avbryter flow - standardvärde Välj rätt kontroller - radiobox, flervalsalternativ - textfält, kort öppet svar - ge inte möjligheten att skriva fel - användaren får aldrig känna sig dum |
|
|
Input - 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 – Man vill att UI ska hållas ”rent” och enkelt 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 |
|
|
Input - 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. |
|
|
Input - 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. |
|
|
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 |
|
|
Input prompt |
Vad – Fyll i textfält eller drop-down med text som förklarar vilken sorts information som ska fyllas i eller väljas. När – När man inte kan ha något default värde. Använd annars ”Good Defaults” Varför – Underlättar att förstå vilken sorts information som man begär av användaren Hur – Börja med verb, avsluta med substantiv ex. Skriv namn Välj datum. Texten försvinner då man börjar skriva eller väljer. |
|
|
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. |
|
|
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. |
|
|
Password strength meter |
Vad – Ge användaren omedelbar bekräftelse på hur säkert ett lösenord är. När – När användaren ska välja ett nytt lösenord Varför – Säkerheten Hur – Visuell och text indikering till höger om eller under textfältet. Uppdatera |
|
|
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. |
|
|
Shneidermans gyllene regler |
(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 |
|
|
Shneidermans 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. |
|
|
Shneidermans 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. |
|
|
Shneidermans 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. |
|
|
Jakob Nielsens heuristics |
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. |
|
|
Jakob Nielsens heuristics |
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. |
|
|
Jakob Nielsens heuristics |
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 |
|
|
Jakob Nielsens heuristics |
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. |
|
|
Pappersprototyper |
Vad? – Man skapar en pappersversion av sitt GUI och använder för att testa och utvärdera innan man börjar programmera.
-Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person ”playing computer,” who doesn’t explain how the interface is intended to work.
Varför? – Snabbt enkelt och billigt – Kan fånga massor av problem innan man börjar kodar |
|
|
Skiss |
En skiss visar bara hur det ser ut – Ingen interaktion – Ofta flera olika förslag – Generera idéer – Övning 3 |
|
|
Wireframe |
En wireframe visar layout – Skelett – Kan visa interaktion – Visar innehåll men oftast ingen riktig data |
|
|
Wireframe |
|
|
|
Storyboard |
En skiss visar en serie av interaktioner – Ingen interaktion – Temporal aspekt – Förstå hur en uppgift utförs och hur GUI:t kan stödja detta |
|
|
Storyboard |
|
|
|
Pappersprototyp |
En pappersprototyp kan man interagera med – Klicka genom att peka Sedan byter man till hur det ser ut efter klick
– Skriva kan man göra direkt Sen kanske man byter vy beroende på kommando – Vid menyval visar man menyer – Klickar man (genom att peka) på en dropdown visas en lista |
|
|
Pappersprototyp |
|
|
|
Planera test |
-Vilka användare vill man testa på?
-Vilka delar av gränssnittet vill man testa? --Kan inte testa allt
-Skapa 3-5 uppgifter som användarna ska göra --Lista saker som kan utföras, vilka är viktigast? --Lista egna frågor som rör designen --Välj de mål som ni tycker bäst besvarar och täcker era frågor och gör dessa till en testuppgift. ”Välj ut 10 låtar du tycker om och för över till din mobiltelefon”
-Varje uppgift bör ha ett tydligt slut, användaren bör förstå när uppgiften är klar. |
|
|
TidWell - Listor – vad gör man? |
-Vilken/vilka? Få en överblick Bläddra igenom, jämföra Hitta specifik sak Sortera och filtrera Arrangera om i listan
-Vad man ska göra påverkar vilket/vilka mönster som är relevanta och som lämpar sig bäst. |
|
|
TidWell - Listor – saker att fundera på |
-Längd Finns det ett slut? Hur mycket kan man visa?
-Ordning Någon naturlig sortering? Vill användaren ändra på denna? I så fall till vad?
-Gruppering Kan man gruppera elementen? Är denna gruppering naturlig eller måste den förklaras? Finns det olika sätt att gruppera, ska användaren själv få gruppera element?
-Saker i listan Är objekten simpla eller komplexa? Är de lika eller väldigt olika? Finns det en bild knuten till varje element? Vad i objekten är viktigast för användaren och kan dessa sorteras / filtreras?
-Interaktion Hur mycket ska visas av varje element i listan? Vad kan/ska man göra med listan Jämföra, välja för närmare inspektion, utföra en uppgift? Ska man kunna välja flera objekt samtidigt?
|
|
|
Tidwell - Mönster i listor
Two-Panel Selector |
|
|
|
Tidwell - Mönster i listor
One-Window Drilldown |
|
|
|
Tidwell - Mönster i listor
One-Window Drilldown - Problem |
-Kognitiv börda Jobbigare när hela fönstret laddas om, jämfört med bara en del av det
-Pogosticking Kan bli bättre genom att låta användaren gå direkt till nästa och förra elementet i listan. |
|
|
Tidwell - Mönster i listor
List Inlay |
|
|
|
Tidwell - Mönster i listor
Thumbnail Grid |
|
|
|
Tidwell - Mönster i listor
Carousel
|
|
|
|
Tidwell - Mönster i listor
Row Striping |
|
|
|
Tidwell - Mönster i listor
Cascading Lists |
|
|
|
Tidwell - Mönster i listor
Tree Table |
|
|
|
Tidwell - Mönster i listor
Pagination |
|
|
|
Tidwell - Mönster i listor
Alphabet Scroller |
|
|
|
Utvärdering - Cognitive Walkthrough |
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. |
|
|
Utvärdering - Cognitive Walkthrough |
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? |
|
|
Utvärdering - 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 |
|
|
Utvärdering - 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. |
|
|
Utvärdering - Jakob Nielsens heuristics |
-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. |
|
|
Utvärdering - Jakob Nielsens heuristics |
-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 |
|
|
Utvärdering - Jakob Nielsens heuristics |
-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. |
|
|
Utvärdering - Modeller och tidigare arbete |
|
|
|
Utvärdering - Utvärdering med användare |
|
|
|
Utvärdering - Labstudier |
|
|
|
Utvärdering - Fältstudier |
|
|
|
Utvärdering - Experimental Evaluation |
|
|
|
Utvärdering - Faktorer i experiment |
|
|
|
Utvärdering - Variabler |
|
|
|
Utvärdering - Hypotes |
|
|
|
Utvärdering - Experimentdesign |
|
|
|
Utvärdering - Analys av data |
|
|
|
Utvärdering - Analys av data, forts |
|
|
|
FÄLTSTUDIER - Observationsmetoder |
|
|
|
FÄLTSTUDIER - Think aloud |
|
|
|
FÄLTSTUDIER - Cooperative evaluation |
|
|
|
FÄLTSTUDIER - Protokollanalys |
|
|
|
FÄLTSTUDIER - Frågetekniker |
|
|
|
FÄLTSTUDIER - Intervjuer |
|
|
|
FÄLTSTUDIER - Intervjuer, forts |
|
|
|
FÄLTSTUDIER - Enkäter |
|
|
|
FÄLTSTUDIER - Enkäter, forts |
|
|
|
FÄLTSTUDIER - Frågetyper |
|
|
|
FÄLTSTUDIER - Frågetyper, forts |
|
|
|
Välja evalueringsmetod |
|
|
|
Utseendet spelar roll |
Användaren trivs bättre - Ökar chansen att man vill prova igen - Ökar chansen att man få gott rykte - Ökar tiden användaren spenderar på sidan Användaren får större tolerans - Ökar chansen att man har överseende med småproblem Väldesignad software tar hänsyn till utseendet, språk och dess ton lika mycket som till kvalitén (kodning) Produkter och websidor stödjer också ”branding”. Interface kan skapa emotionell respons. |
|
|
Visuell design |
Kognitivt inbyggda fenomen - Hjärnan uppfattar vissa saker automatiskt (preattentive variables) -Vissa reaktioner kan förutses Känslor och instinktiva reaktioner spelar in också - Kultur - Förväntningar - Erfarenheter osv... Vad använder man då och hur? |
|
|
Färg |
|
|
|
Färg |
Färg är det bland det första vi ser. Det är bra att fundera ut ett färgschema Grundregler Använd mörk förgrund mot ljus bakgrund eller tvärtom - För att testa skillnaden kan man göra om till gråskala Använd aldrig röd kontra grön för kritiska distinktioner - Upp till 10% av alla män har någon form av färgblindhet |
|
|
Bakgrund och kontrast |
Ljus eller mörk bakgrund? - Gör stor skillnad - Ljusa klart vanligast - Vanliga kontroller funkar bäst på dessa - Mörka - fräckare, dyster, energisk - Finns undantag - Sketchflow , Photoshop t.ex. Skarpa kontraster - Spänning o styrka Mindre kontrast - Lugnande och avslappnande |
|
|
Färgmättnad |
Mättade eller rena (saturated) färger Klara, briljanta, skarpa gula, röda, gröna etc - Framkallar energi, livlighet, värme… - Vågade och har karaktär Också tröttande för ögat - Vanligast att ha max 1 eller 2 mättade färger - Resten omättade, nedtonade |
|
|
Färgblindhet |
|
|
|
Färgblindhet |
Förmedla aldrig information med enbart färg - Använd istället medföljande text, form eller något annat. - Undvik röd-gröna kombinationer - Testa, testa, testa! |
|
|
Mönster: Visual Framework |
Vad - Designa varje sida med samma grundläggande layout, färg, stil. När - Applikationer eller sajter med många olika sidor (typ allt). Man vill att det ska sitta ihop Varför - Konsistent design av varje sida gör att man känner igen sig och inte behöver anstränga sig lika mycket. Bidrar till branding också. Hur - Skapa en genomgående look-and-feel för alla sidor i applikationen - Färger, fonter, stil på text - Navigation - Layout-grid |
|
|
Mönster: Deep Background |
Vad - Placera en bild i bakgrunden som ger intryck av att finnas bakom övriga gränssnittselement När - Man har en layout med ett antal distinkta GUI-element som inte är särskilt överbefolkad och vill att det ska vara intressantare än med vanlig vit/grå bakgrund Varför - Lyckas man göra en bakgrund som ser ut att finnas bakom så kan det vara snyggt helt enkelt Hur - Lite överkurs. Boken talar om soft focus, color gradients, depth cues och no strong focal points |
|
|
Mönster: Few hues, many values |
Vad - Välj en, två eller max 3 huvudkulörer (hues). Skapa en färgpalett genom att ha olika varianter av dessa När - Man skapar en färgpalett och vill undvika ett splittrat intryck, men ha någon slags karaktär Varför - Alltför många färger, speciellt klara och mättade gör lätt GUI:t överlastat och stökigt. Färgerna slåss om användarens uppmärksamhet. Hur - Välj ett par färger (svart o vitt räknas inte) Sen kan man ha ett stort antal inom dessa färger om det krävs. Verktyg som visats kan vara användbara för detta. |
|
|
Preattentive variables (färg, storlek mm) |
- Saker som uppfattas direkt av människor utan vidare tänkande - Fortsättning på föregående om visual flow, grouping etc - Bra att känna till vid design |
|
|
Preattentive variables |
|
|
|
Preattentive variables |
|
