4.6

15-­‐09-­‐21 Tvetydighet: vad är figur och vad är bakgrund i en TNM040 Kommunika4on och användargränssni= HT2015, FÖ4 design… TNM040 HT2015
TNM040 HT2015
När man designar för en telefon/pla=a måste man tänka på a= och hur dessa ska hållas i handen, det handlar inte ”bara” om vad som visas på skärmen. c TNM040 HT2015
En människas fingertopp är ca 16-­‐20mm. (När vi använder en touchskärm är det som a= navigera med en prinskorv :-­‐) TNM040 HT2015
Kontroll för a= ändra layout är för liten för a= man ska kunna trycka på den/träffa den med säkerhet. Tänk på: •  Storlek (1x1cm rekommenderas, oZast mindre i standarder för olika pla[ormar ) •  Mellanrum •  TESTA Knapparna är 4llräckligt stora men det är för litet mellanrum mellan ”dela” och ”edit”. Knappar med bra storlek och bra mellanrum. Undvik a= det här händer! TNM040 HT2015
TNM040 HT2015
1 15-­‐09-­‐21 tou
ch Hur vi når informa4on på en skärm Hur vi når informa4on på en skärm •  Placera sådant som är vik4gt/intressant/som ska ske just nu där det är lä= a= nå, och gör kontrollerna stora. •  Placera sådant som används oZa längst ned (överst på Android för a= undvika a= man trycker på fysiska knappar istället). Tänk på var du placerar informa4on/navigering. Ska vara lä= a= se och nå, synas tydligt och inte döljas av fingrar. Heller inte vara ”jobbig” a= använda. Tänk på a= det vi når lä= kanske vi inte ser lä=! Placera knappar som inte används oZa/som ger ”allvarliga fel” på ställen som är svåra a= nå. TNM040 HT2015
TNM040 HT2015
Hur vi når informa4on på en skärm •  Placera saker som inte görs så oZa på ställen som är svårare a= nå. •  Gör medvetet vissa saker svåra a= göra. –  Tex sådant som ändrar informa4on, tar bort informa4on etc. TNM040 HT2015
TNM040 HT2015
Ta reda på behov, presentera förslag, KOMMUNICERA, visualisera, testa, “gör om och gör rä=”. TNM040 HT2015
TNM040 HT2015
2 15-­‐09-­‐21 Prototypning Prototyper •  Urtyp, urbild, grundform, förlaga, testmodell – 
– 
– 
– 
– 
– 
– 
– 
träbit kartongmodell skisser storyboard (bildmanus) powerpoint-­‐presenta4on videosimulering programvara med begränsad funk4onalitet prototypverktyg •  Low-­‐fidelity •  High-­‐fidelity h=p://www.invisionapp.com TNM040 HT2015
TNM040 HT2015
TNM040 HT2015
TNM040 HT2015
Designprinciper Normans principer •  Hur uppfa=ar vi, ser vi, tolkar vi och känner igen objekt i gränssni=et? –  Färg –  Form –  Storlek –  Ljusstyrka, kontrast –  Symboler –  Struktur, mönster –  Placering En bra design: •  ger klar affordans –  kan jag använda något? •  har signifiers –  hur och var? •  har god synlighet –  ser jag det? •  stödjer god mappning –  hur hänger saker ihop? –  vad händer om jag gör så här? –  vad kan jag göra, vart kan jag gå? •  ger god feedback Förstår vi a= de kan/ska användas? Förstår vi hur de ska användas? Förstår vi varför de ska användas? –  vad händer, hände? Donald Norman. (2013). The design of everyday things TNM040 HT2015
TNM040 HT2015
3 15-­‐09-­‐21 Norman's huvudexmpel är dörrar. För vissa dörrar är det omöjligt a= se om man ska dra eller trycka för a= komma in/ut, hos andra är det uppenbart. Affordans • 
• 
• 
• 
• 
Upplevd egenskap/kvalitet hos e= objekt Gör användningen av, vad något är 4ll för, uppenbart Bara genom a= 4=a på något ska användare veta hur det ska användas Uppenbarhet, 4llhandahållande har föreslagits av Computer Sweden. Generellt: –  när en affordans hos en produkt matchar dess avsedda användande, är produkten lä= a= använda –  när en affordans hos en produkt föreslår andra handlingar än de som objektet är designat för är det lä= a= man gör fel och instruk4oner/bilder etc. är nödvändiga •  Utny=jar användarens grundläggande kunskaper om hur människan, världen och naturen fungerar. •  Förmedlar ledtrådar 4ll användaren •  "When simple things need labels or instruc4ons, the design is bad.“ Norman, D. 2013. The design of everyday things. TNM040 HT2015
Affordans • 
• 
• 
• 
• 
• 
Signifiers En ver4kal scrollist i e= gränssni= afforderar rörelse upp och ner. Affordans är en ledtråd som föreslår a= en handling är möjlig. När affordans är uppenbar är det lä= a= veta hur man kan interagera med något. 3D knappar erbjuder ”klickbarhet” Sliders erbjuder musen/fingret a= glida över dem Check box – erbjuder a= klicka i den? Eller är affordans en konven4on? –  Alltså något vi lär oss? Bestäms av kultur, ins4nkt, mental modell tex en hyperlänkad text är något vi lärt oss hur den fungerar. ”Affordance is oZen more about conven4ons than about reality” Norman, D. 2013. The design of everyday things. TNM040 HT2015
TNM040 HT2015
Signifiers – signaler/indikatorer •  Alterna4v/komplement 4ll affordans – 
– 
– 
– 
– 
Affordans avgör/visar/erbjuder vilka handlingar som är möjliga En signifiers kommunicerar var dessa kan äga rum En signal som guidar användaren Ger ledtrådar Tecken, ljud etc. som kommunicerar rä= beteende •  Norman defines a signifier as “some sort of indicator, some signal in the physical or social world that can be interpreted meaningfully”. Norman, D. 2013. The design of everyday things. TNM040 HT2015
Affordans •  Det går a= använda touch på hela skärmen. •  Man behöver visa var man ska göra det. TNM040 HT2015
h=p://uiobservatory.com/2011/
affordances-­‐of-­‐a-­‐traffic-­‐circle/ TNM040 HT2015
4 15-­‐09-­‐21 Hur ska man veta a= det finns mer sek4oner? Affordans + Signifier h=p://uiobservatory.com/2011/
affordances-­‐of-­‐a-­‐traffic-­‐circle/ TNM040 HT2015
Synlighet-­‐Visibility TNM040 HT2015
Synlighet? •  Saker och 4ng ska vara synliga i gränssni=et, så a= man vet vad man kan göra och hur man uppnår sina mål. •  Det ska vara uppenbart vad någon4ng är 4ll för, problem uppstår när vi inte kan se det. TNM040 HT2015
TNM040 HT2015
Synlighet-­‐Visibility Synlighet-­‐Visibility •  Visuell organisa4on av informa4on är oerhört vik4gt för läsbarhet och förståelse! (Se 4digare föreläsningar!) •  Tänk på densitet, färg, form etc. Exempel när vi inte ”kan se det”: Automa4ska kranar. •  Vi är inte säkra på hur de ska användas, vi måste gissa oss 4ll var händerna ska placeras. •  Synliga ra=ar, handtag, knappar etc. har ersa=s av osynliga och tvetydiga ak4va zoner. TNM040 HT2015
TNM040 HT2015
5 15-­‐09-­‐21 All4d synlighet? Synlighet-­‐Visibility •  A= dölja vissa funk4oner kan vara fördelak4gt i gränssni=sdesign (för a= undvika problem som har a= göra med densitet, plo=righet etc.). Ikoner för naviga4on behålls synliga vid scrollning. Tydligt, distraherande, hjälpsamt? •  Hålls osynligt 4lls det behövs men ingår i en grupp som är tydlig och fungerar som en “ledtråd". Men överväg ”syns det inte så finns det inte". TNM040 HT2015
TNM040 HT2015
Visibility -­‐ Synlighet Affordans, signifier, synlighet •  Bra visibility 4ll vänster (storlek, kontrast, ”white space” runt), något sämre 4ll höger. •  Den vänstra har en affordans 4ll a= man ska trycka på den (en ram) den andra erbjuder inte 4ll klick på samma sä= eZersom designen är pla=. Båda har en rela4vt dålig signal, förstår man vad ikonen säger, visar den vad man ska göra? Synligt vad som ska fyllas i. •  Fördel a= det sparar plats. •  Nackdel a= användaren måste radera vad som står i fältet för a= se ledtråden igen (om man exempelvis glömt vad som ska stå i fältet eZer e= avbro=). TNM040 HT2015
TNM040 HT2015
Återkoppling -­‐ Feedback Återkoppling -­‐ Feedback •  Ska ge informa4on om/visa systemets status. •  Återkoppla/skicka 4llbaka informa4on 4ll användaren om vad som verkligen hände/vilka handlingar som gjorts och vad resultatet blev av en handling. •  Ska vara tydlig, omedelbar och synkroniserad med den handling användaren utört. •  Återkoppling är mycket vik4g då användare väntar på a= en process ska bli klar. Dropbox visar en statusindikator när filer laddas upp. För sådana här händelser, där vänte4derna varierar mycket är en statusindikator mycket vik4g så a= användare inte behöver gissa hur lång 4d som återstår. Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable 4me. Nielsen, Jacob. 10 Usability Heuris4cs for User Interface Design. h=p://www.nngroup.com/ar4cles/ten-­‐usability-­‐heuris4cs/ TNM040 HT2015
TNM040 HT2015
6 15-­‐09-­‐21 Återkoppling -­‐ Feedback Återkoppling -­‐ Feedback •  Relevanta och begripliga felmeddelanden –  Ge informa4on om vad felet är och hur det ska åtgärdas Ge återkoppling via status på knappar. •  Vik4gt med kontrast mellan ak4va och inak4va 4llstånd/knappar. •  En knapp som visar a= den klickats på ger omedelbar återkoppling 4ll användaren. •  Se 4ll a= återkopplingen syns väl, även under e= finger (större än 1x1cm) TNM040 HT2015
Återkoppling -­‐ Feedback TNM040 HT2015
Respons4d •  Ska ge informa4on om/visa systemets status. •  Återkoppla/skicka 4llbaka informa4on 4ll användaren om vad som verkligen hände/vilka handlingar som gjorts och vad resultatet blev av en handling. •  Ska vara tydlig, omedelbar och synkroniserad med den handling användaren u?ört. Grundläggande rekommenda4oner angående respons4d har varit i stort se= de samma i över 30 år (Miller 1968; Card et al. 1991): • 
–  Upplevs som omedelbart –  Här går gränsen för a= användaren ska uppleva det som a= e= system reagerar omedelbart, innebär a= ingen särskild återkoppling behövs förutom a= förmedla resultatet. • 
1.0 sekund –  uppfa=ar en fördröjning men upplever inte något avbro= i tankekedjan –  handlar om gränsen för användarens flöde av tankar a= förbli oavbrutna, trots a= användaren märker förseningen. Normalt är ingen särskild återkoppling nödvändig under fördröjningar på mer än 0,1 men mindre än 1,0 sekund, men användaren förlorar känslan av a= agera direkt (på informa4on). Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable 4me. 0.1 sekund • 
10 sekunder –  ändrar agerande, byter uppgiZ –  handlar om gränsen för a= hålla en användares uppmärksamhet fokuserad. För längre förseningar, kommer användaren a= vilja utöra andra uppgiZer i väntan på a= något ska hända, så denne bör ges återkoppling som förmedlar vad som händer (så man vet vad man kan förvänta sig). Nielsen, Jacob. 10 Usability Heuris4cs for User Interface Design. h=p://www.nngroup.com/ar4cles/ten-­‐usability-­‐heuris4cs/ http://www.nngroup.com/articles/response-times-3-important-limits/
TNM040 HT2015
TNM040 HT2015
Återkoppling -­‐ Feedback Mappning – Mapping •  Andra typer av återkoppling förutom synlig sådan? •  Rela4on mellan objekt, handlingar. Rela4on mellan egenskap hos e= objekt och dess funk4on. •  Så fort man har någon form av objekt som sköter kontrollen av eller inställningarna för något annat objekt i e= gränssni= så ska det på något sä= vara uppenbart a= det första objektet kontrollerar det andra, dvs det ska finnas en en naturlig mappning (rela4on) mellan dem (kontrollobjektet och det objekt som påverkas). –  Audi4v – ljud –  Tak4l -­‐ känsel TNM040 HT2015
TNM040 HT2015
7 15-­‐09-­‐21 Mappning – Mapping Mappning – Mapping •  Naturliga mappningar drar fördel av fysiska analogier och kulturella standarder. Sekvenser/ordningar ska ske i en naturlig/logisk ordning (tex. uppifrån och ned, från vänster 4ll höger). •  Naturliga mappningar drar fördel av fysiska analogier och kulturella standarder. –  fysisk: e= reglage för volym förs uppåt om man vill höja ljudet (inte nedåt för det känns kons4gt) –  fysisk: e= reglage för volym förs uppåt om man vill höja ljudet (inte nedåt för det känns kons4gt) Knapp för lampa, behövs texten? TNM040 HT2015
Mappning – Mapping TNM040 HT2015
Mappning – Mapping •  Naturliga mappningar drar fördel av fysiska analogier och kulturella standarder. –  fysisk: e= reglage för volym förs uppåt om man vill höja ljudet (inte nedåt för det känns kons4gt) –  kulturell: röd innebär stopp, akta(?), grön innebär (gå/ok)? TNM040 HT2015
Mappning – Mapping TNM040 HT2015
Mappning – Mapping •  Rela4on mellan objekt, handlingar. Rela4on mellan egenskap hos e= objekt och dess funk4on. •  Så fort man har någon form av objekt som sköter kontrollen av eller inställningarna för något annat objekt i e= gränssni= så ska det på något sä= vara uppenbart a= det första objektet kontrollerar det andra, dvs det ska finnas en en naturlig mappning (rela4on) mellan dem (kontrollobjektet och det objekt som påverkas). •  Sekvenser/ordningar ska ske i en naturlig/logisk ordning (tex. uppifrån och ned, från vänster 4ll höger). •  Naturliga/tydliga mappningar Fllsammans med återkoppling är oerhört vikFgt för aG användaren ska kunna forma en bra mental modell av hur något fungerar. Ta bort dessa två egenskaper och det blir i stort seG omöjligt för användaren aG bilda sig en uppfaGning om hur denne ska använda sig av systemet. TNM040 HT2015
Otydligt vilken kontroll som styr vilken pla=a. TNM040 HT2015
8 15-­‐09-­‐21 Mappning – Mapping Mappning – Mapping •  Siffror är e= enkelt sä= a= visa rela4oner mellan något i en lista och dess ställe (”knappnål” etc.) på en karta. Tydligt vilken kontroll som styr vilken pla=a. TNM040 HT2015
TNM040 HT2015
Kri4sk analys av e= gränssni= Mappning – Mapping •  Hur hänger saker ihop? Vad kan jag göra, vart kan jag gå? Vad händer om jag gör så här? •  Funk4oner och delar som hör samman samlas på “e= ställe”, exempelvis relaterade funk4oner under samma rubrik/flik. UppgiZen består av en analys av e= användargränssni=. UppgiZen utörs i form av en rapport som innehåller en beskrivning av gränssni=et, en redogörelse av dess fördelar och nackdelar (analysen) och en slutsats och diskussion/e= avslutande stycke. Analysen ska göras med hjälp av den terminologi och begrepp som vi har diskuterat så här långt under kursen (se främst föreläsning 4). Känn dig fri a= använda allt från föreläsningar men observera a= begreppen affordans/signifier, synlighet, mappning och återkoppling måste användas. Vik4gt! Begreppen ska skrivas ut i texten när de används för a= förklara något. Exemplifiera (gärna) genom a= beskriva olika uppgiZer. Rapporten bör vara 1200 -­‐1500ord (min/max), 3-­‐5 sidor (min/max) beroende på antal och storlek av illustra4oner). (Textstorlek 11pt). Följ instruk4onerna i “A= skriva rapporter” UppgiZen utörs individuellt. Inlämning måndag 12 oktober Betyg U, 3-­‐5 Också exempel på en begränsning, vad som är 4llåtet vid e= visst 4llfälle. TNM040 HT2015
TNM040 HT2015
System Till exempel… • 
Välj e= gränssni=, exempelvis e= bokningssystem. •  Beskriv gränssni=et (hur det ser ut och fungerar), var det presenteras, beskriv dess syZe, varför det analyseras och hur analysen kommer a= genomföras, om hela eller delar av gränssni=et analyseras. •  Gå igenom och beskriv (både nega4va och posi4va aspekter) hur användaren interagerar med gränssni=et. –  Hur presenterar gränssni=et vad det är 4ll för och hur det bör användas för användaren? –  Vad kan användaren göra, hur visas det? –  Hur vet användaren vad denne ska göra först och däreZer vad händer då? –  Är det synligt? –  Vilka affordanser och mappningar presenterar gränssni=et ? –  Ger gränssni=et återkoppling 4ll användaren om si= 4llstånd och olika handlingar och hur fungerar det? •  Avsluta med dina övergripande resultat och vad du tycker om gränssni=et. •  Inkludera bilder för a= illustrera! TNM040 HT2015
TNM040 HT2015
9 15-­‐09-­‐21 A= skriva rapporter A= skriva rapporter Instruk4on för innehåll och struktur. Följ dessa! Finns på kurshemsidan under -­‐ Li#eratur. AG skriva rapporter Här följer några allmänna råd inför a= skriva en rapport och 4ps på hur du undviker vanliga misstag. Tänk också på a= du måste följa de särskilda instruk4oner som finns inför uppgiZen “Kri4sk analys” som gavs på föreläsning 4, se föreläsningsanteckningar på kurshemsidan. Hur du presenterar e= material bidrar 4ll det intryck det gör på den som läser det. Även om själva innehållet är bra så kommer en ostrukturerad eller slarvigt skriven rapport a= ge e= mindre bra intryck. TNM040 HT2015
TNM040 HT2015
A= skriva rapporter A= skriva rapporter Titel sida. En rapport har en 4telsida (förstasida) med 4tel, kursens namn, namn på förfa=aren 4llsammans med LiU-­‐ID och epostaddress. Ingen text ska finnas på baksidan av 4telsidan. IntrodukFon. En rapport börjar med en introduk4on; syZet är a= ge en bakgrund 4ll varför du skriver rapporten (men skriv inte bara a= det är för a= det är en del av en kurs utan beskriv varför det är intressant/vik4gt). Slutsats/Diskussion. En skriven rapport innehåller all4d en slutsats och en diskussion, det budskap du vill a= läsaren ska ha få= eZer a= ha läst din rapport. Den kan bestå av en summering, slutsatser och en diskussion kring dessa eller några slutliga påpekanden. IllustraFoner/bilder. I alla ovan nämnda delar av rapporten kan du inkludera illustra4oner i form av skärmdumpar, foton etc. för a= exemplifiera beskrivninar och öka förståelsen hos läsaren. Dessa måste all4d vara numrerade och ha en förklarande bildtext. Alla bilder måste också refereras 4ll i löpande text (exempelvis; se Bild 1, eller …vilket illustreras i Bild 2). Placera bilderna på e= sä= som ger god läsbarhet. Språk. Skriv fullständiga meningar och undvik (e= för) vardagligt språk och slang. Dessutom, innan du lämnar in di= arbete: Innehåll. Introduk4onen följs av själva innehållet i dokumentet. Det ska presenteras i en ordning som gör det lä= a= följa beskrivningar och resonemang, resultat, analys (och hur dessa leder 4ll) och slutsatser. E= förslag är a= använda numrerade rubriker/
underrubriker för a= strukturera dokumentet. Tänk på a= du måste tolka dina resultat för a= göra dem förståeliga för läsaren Till exempel, om du analyserar en hemsida är det inte 4llräckligt a= påstå: “Menyn innehåller 43 objekt ". Du måste skriva: " Menyn innehåller 43 objekt, vilket är alldeles för många eZersom antalet gör det svårt för användaren a= hi=a rä= alterna4v vid naviga4on i menyn." TNM040 HT2015
TNM040 HT2015
”För mycket luZ” A= skriva rapporter Gör en stavningskontroll. Gör en stavningskontroll (som di= ordbehandlingsprogram erbjuder) men läs också själv igenom din text ordentligt minst en gång. För a= garantera en god läsbarhet bör di= dokument vara skrivet så a= texten inte har mer än 12-­‐15 ord per rad (jämför med en bok eller det här dokumentet). Storleken på texten bör inte vara för liten, 11 punkter rekommenderas. Dokumentet bör vara “luZigt” men var inte frikos4g i onödan, (dvs rubriker behöver inte vara jä=estora, stycken kan vara ganska långa utan a= det blir jobbigt a= läsa och infoga inte blanka rader under rubriker och mellan stycken “i onödan”). TNM040 HT2015
TNM040 HT2015
10 15-­‐09-­‐21 ”För mycket luZ” A= skriva rapporter •  Ni behöver inte ange källa/li=eratur. •  Om det görs ska dessa hanteras på e= korrekt sä=. TNM040 HT2015
TNM040 HT2015
Närhet (gestaltlag) Betygskriterier •  Glöm inte a= läsa/kolla igenom din rapport! •  5 -­‐ Mycket bra rapport •  Introduk4on, beskrivning av systemet, analys och slutsats/diksussion är utörlig (tar upp det som angavs i instruk4on) och väl strukturerad, lä=läst, röd tråd, logisk ordning, illustra4oner, eventuella källor etc. hanteras väl och rapporten har angivet antal ord/sidor (ca…). •  4 – Bra •  Som ovan men med vissa brister: i introduk4on, i analys, i diskussion/
slutsats, i dokumenta4on vilket ger e= bra resultat och intryck men inte “fullt ut”. Eventuellt något kort eller lång rapport. •  3 – Ok/godkänd •  Här finns brister som ovan, flera stycken, allvarligare, eventuellt något kort rapport. •  U -­‐ allvarliga brister •  Följer inte instruk4on, delar saknas, analyserar/dokumenterar inte alla av de 4 principer/begrepp som ska användas, mycket korta=ad. TNM040 HT2015
TNM040 HT2015
Postlåda Lämnas in i Camilla Forsells postlåda, Täppan, plan 5. Utskriven på papper, inte via epost. Inlämning: Senast måndag 12 okt kl 10:00. TNM040 HT2015
TNM040 HT2015
11 15-­‐09-­‐21 Tack! Vi ses på torsdag 24 sept 8-­‐10. Introduk4on 4ll grupparbetet. TNM040 HT2015
12