--- Kamel/HCI_text.tex 2003/03/09 17:24:48 1.9 +++ Kamel/HCI_text.tex 2003/03/18 17:50:50 1.15 @@ -55,7 +55,7 @@ kommer användarna att med glädje byta, även om det kan innebära vissa initiala problem. - \subsection{Användandet av script vid mjukvaruproduktion} + \subsection[Script vid mjukvaruproduktion]{Användandet av script vid mjukvaruproduktion} Detta kan lätt tyckas att detta inte har med MDI att göra, men vi kommer att förklara detta lite senare. @@ -67,7 +67,7 @@ snabbt att skriva ner de kommandon som ser till att källfilerna ligger i en katalog, de kompilerade programmet i en, och hjälp filerna i en tredje (om - programmeringsspråket stödjer detta (t.ex. java API).\\ + programmeringsspråket stödjer detta (t.ex. Java API). %Eller är det svaret vi skall skjuta in? Men hur är detta något som är intressant ur en MDI @@ -105,46 +105,127 @@ \subsection{Prototyper och Mock-ups} - En mock-up är en form av prototyp. Den görs i ett - passande material, och beroende på vilken information - man har om den färdiga produkten så görs den med den - detaljnivå som är passande. Denna mock-up används sedan - för att testa om konceptet man har håller, och hur det - skall implementeras. En mock-up behöver inte vara för en - programvara, utan kan lika gärna vara för en fysisk - produkt, men i kursen har vi inriktat oss på programvara - då detta är det intressanta för oss. Då man skapat en - mock-up så tar man denna, och testar på en eller flera - tilltänkta användare, och lyssnar på deras åsikter om - den. När man har kommit förbi detta stadiet så kan man - bygga en lite mera avancerad prototyp för att vidare - utveckla produkten. En mock-up är vanligtvis (eller - i alla fall dom vi har gjort) ''dynamiskt statiska`` - vilket kan låta som en motsägelse, men vad vi menar med - det är att den görs dynamisk är att det går att byta - detaljer i mock-upen för att symbolisera interaktion. En - annan fördel med en mock-up framför en fungerade - prototyp är att en mock-up är gjord av ett billigt - material, och går snabbt att göra och göra om då man inser att - lösningen man har inte håller, utan behöver göras om för - att passa användaren och hans behov. + Det finns flera olika sätt att demonstrera en idé, men + den bästa brukar vara att kunna visa upp något. Det kan + vara bra att kunna berätta om idéen man har, men om man + kan ge kunden något han kan se, ta på, och till viss del + kunna interagera med så är det mycket enklare, dels att + sälja idén, dels att upptäcka fel och brister i den. + + Nu vet ju vi att vi bara har använt mock-ups i denna + kursen, men det vore synd att inte ta tillfället i akt + och prata lite om prototyper också. + + \subsubsection{Mock-up} + + En mock-up är en form av prototyp. Den görs i ett + passande material, och beroende på vilken information + man har om den färdiga produkten så görs den med den + detaljnivå som är passande. Denna mock-up används sedan + för att testa om konceptet man har håller, och hur det + skall implementeras. En mock-up behöver inte vara för en + programvara, utan kan lika gärna vara för en fysisk + produkt, men i kursen har vi inriktat oss på programvara + då detta är det intressanta för oss. Då man skapat en + mock-up så tar man denna, och testar på en eller flera + tilltänkta användare, och lyssnar på deras åsikter om + den. När man har kommit förbi detta stadiet så kan man + bygga en lite mera avancerad prototyp för att vidare + utveckla produkten. En mock-up är vanligtvis (eller + i alla fall dom vi har gjort) ``dynamiskt statiska'' + vilket kan låta som en motsägelse, men vad vi menar med + det är att den görs dynamisk är att det går att byta + detaljer i mock-upen för att symbolisera interaktion. En + annan fördel med en mock-up framför en fungerade + prototyp är att en mock-up är gjord av ett billigt + material, och går snabbt att göra och göra om då man inser att + lösningen man har inte håller, utan behöver göras om för + att passa användaren och hans behov. + + \subsubsection{Lågnivå prototyper} + + En lågnivå prototyp är en enkel prototyp, som snarare + syftar till att visa den grundläggande idéen. Den kan + vara en mock-up, eller något annat. En lågnivå + prototyp är något som går relativt snabbt att slänga + ihop, och brukar vanligtvis vara ganska så billig. Den + kan vara i ett material som är väldigt långt från den + färdiga produkten (en mock-up på en kartongbit är ju + väldigt långt från ett färdigt program på datorn, och + vi är ganska säkra på att man kan komma ännu längre om + man bara vill). + + Lågnivå prototypen använder man för att demonstrera en + idéer, koncept och dyl. Den kan inte till fullo + användas för att fånga alla krav, men i samverkan med + andra metoder (som t.ex. intervjuer, användningsfall + osv) kan man komma nära nog i många fall. + + \subsubsection{Högnivå prototyper} + + En högnivå prototyp är en ''bättre`` prototyp, oftast + så ligger den närmare den färdiga produkten än lågnivå + prototypen till utseende, och material (där det + finns). Det som främst skiljer en högnivå prototyp + från en lågnivå är att högnivån har funktionalitet + (verklig sådan, inte att man vänder blad). + + \subsubsection{Vilken väljer vi?} + + Marc Rettig (1994) anser att det är bättre att använda + lågnivå prototyper framför högnivå, detta för att: + + \begin{itemize} + \item Dom tar lång tid att göra + \item Kritiker och testar tenderar att kritisera + prototypen, och inte funktionaliteten i den. + \item Utvecklar drar sig för att göra om något dom + har lagt timmar (eller dagar) på att göra. + \item En mjukvaru prototyp kan sätta förväntningarna + för högt. + \item En enda bugg i prototypen kan sätta stop för + testningen av denna. + \end{itemize} + + Vi måste säga att vi håller med honom. En lågnivå + prototyp kan säga det mesta en högnivå kan, och det + den inte kan säga är det tveksamt om man kan få + tillbaka av den tid det tar att göra högnivå + prototypen (iallafall i de små projekt vi har jobbat + med hittills), det kan ju ändras om det är ett stort + projekt, men vi är inte helt säkra på det. En + prototyp skall endast ses som ett + utvecklingsverktyg, det är ju inget som utvecklar av + sig självt, på sin höjd kan det ju driva + utvecklingen framåt. + + Ett undantag bör dock göras. Om man kan utnyttja + prototypen, eller en ansenlig del av denna senare. + Om man t.ex. gör en prototyp av ett GUI, med begränsad + (eller igen) funktionalitet så kan man ju använda + detta i den färdiga produkten, förutsatt att det + faller väl ut. + + + + \subsection{Erfarenhet} Vi tror att vi kommer att använda någon form av - mock-uper efter denna kursen då en mock-up är ett snabbt + prototyper efter denna kursen då en lågnivå prototyp är ett snabbt sätt att visa hur man menar att GUI't skall se ut, och om man har ett förslag till ett GUI så är det enkelt att hitta funktionalitet som man har missat, och det kan även vara enklare att förklara vad man vill göra för en kund som inte kunskaper inom programvaruutveckling vad det är som man skall göra, och vad han får och inte får. - Han kan även ta mock-upen och visa för slutanvändarna, + Han kan även ta prototypen och visa för slutanvändarna, och dessa kan också komma till tals om hur produkten skall se ut, och dess funktionalitet. - \section {Designmönster} + \section{Designmönster} När man designar GUI'n så är det nästan omöjligt att - inte använda något/några design mönster. Dom flesta sätt + inte använda några design mönster. Dom flesta sätt att strukturera upp ett GUI följer de mönster som finns definierade. Detta märkte vi av på första laborationen när vi skulle identifiera mönster som vi hade använt i @@ -156,7 +237,7 @@ har sett programmet tidigare, eller ens ett program som liknar detta (till funktionalitet sett). - \emph{Ett väl-designat GUI låter användaren göra fel} + \emph{``Ett väl-designat GUI låter användaren göra fel''} (Grand, M. 1999)\\ Detta är viktigt därför att om det inte går att göra fel, eller viktigare att återhämta sig från ett fel utan en @@ -173,13 +254,13 @@ \subsection{Vikten av att känna igen sig i ett program} En viktig sak med att få användaren att känna igen sig - är att detta ger en ''säkerhets känsla`` i programmet, + är att detta ger en ``säkerhets känsla'' i programmet, användaren känner att han vet (i viss mån) hur han skall bära sig åt för att göra olika saker. Nästan alla program där man kan spara sitt arbete, öppna en fil med - gammalt arbete osv har detta i en meny märk ''Arkiv`` på + gammalt arbete osv har detta i en meny märk ``Arkiv'' på svenska, kommandon som kopiera, klistra in, gör om osv. - ligger under en meny ''redigera´´. Detta gör att en + ligger under en meny ``redigera''. Detta gör att en användare kan känna igen sig även om han aldrig har nyttjat programmet tidigare. @@ -190,7 +271,7 @@ inte så mycket bryr sig om tekniken bakom. Detta innebär dock att för att kunna designa något så - måste vi känna målgruppen och dess behov. Att jobba med + måste vi känna till målgruppen och dess behov. Att jobba med interaktions design är väldigt snarlikt till att jobba med en användarcentrerad lösning. Det går antingen att jobba med interaktions design om man har en färdig målgrupp som @@ -198,25 +279,31 @@ målgrupp, och skapar produkten därefter. Om man har en färdig målgrupp som har behov av en produkt - så är det ''enkelt`` att skapa denna då man hela tiden kan + så är det ``enkelt'' att skapa denna då man hela tiden kan rådfråga målgruppen, skapa mock-uper, prototyper osv, och - få direkt feedback på det man har gjort. + få direkt feedback på det man har gjort. Det finns undantag + då man inte kan skapa mock-uper och det är när själva slut + produkten är hemligstämplad och det finns andra aktörer på + marknaden som jobbar med samma område. Att då låta vanliga + användare komma i kontakt med sin design innebär att hemlig + information kan spridas till konkurrenterna om de nu råkas + få tag på samma testpersoner. En annan sak som är viktig, mycket viktig med Interaktions design är att den sker iterativt. \section{Konceptuella modeller} - \emph{Det viktigaste är att designa användarens + \emph{``Det viktigaste är att designa användarens konceptuella modell. Allt annat skall ses som underordnat för att göra modellen klar, tydlig och konkret. Detta är nästan tvärt emot hur den mesta - mjukvaran utvecklas.}(Liddle, David. 1996)\\ + mjukvaran utvecklas.''}(Liddle, David. 1996)\\ Preece, Rogers and Sharp 2002 definierar en konceptuell - modell som \emph{en beskrivning av det föreslagna + modell som \emph{``en beskrivning av det föreslagna systemet i termer av integrerade idéer och koncept om vad det skall göra, bete sig samt se ut som, som skall - förstås av användaren på rätt sätt}\\ + förstås av användaren på rätt sätt''} När man skapar en konceptuell modell så är det viktigt att man funderar över hur den slutliga produkten skall @@ -257,7 +344,7 @@ \item Instruera \item Konversera \item Manipulera och navigera - \item Utforska och surfa %är surfa en bra översättning av browsing? + \item Utforska och ögna igenom %är surfa en bra översättning av browsing? \end{itemize} När man instruerar så förklarar man vad man vill att systemet skall göra, man ger order. Detta kan ske t.ex. @@ -280,35 +367,64 @@ ofta kan man få ett resultat som blir närmare det användaren efterfrågar om man väljer att blanda flera aktiviteter. - \subsubsection{Instruera} - b + Detta är en relativt enkel modell att bygga upp, även om + det kan vara krångligt att bygga upp den på ett bra + sätt. Antingen kan man använda knappar, menyer osv för + att ge instruktioner, eller så kan man använda + textsträngar. En klar nackdel med denna modellen är att + om kommandona är långa (eller krångliga) kommer + användaren att glömma bort det, och behöva extra hjälp + när han skall nyttja denna. Detta är ett vanligt + mönster, och återfinns i flera produkter på ett sätt + eller ett annat. \subsubsection{Konversera} - a + Denna metoden är vanligast om det handlar om någon form + av expert system, eller sökfunktioner. En klar fördel + med att nyttja detta mönster är att även en människa med + små kunskaper inom både data, och ämnet som experten kan + kan ställa frågor, och få hjälp. En nackdel med detta + mönstret är att om användaren ställer frågor på ett sätt + som man inte har tänkt sig, eller som inte finns med i + informations basen så kan svaren till användaren bli + helt uppåt väggarna om man inte är noga med hur man + behandlar indatan. \subsubsection{Manipulera och navigera} - a - - \subsubsection{Utforska och surfa} - - a - - \subsection{Konceptuella modeller baserat på objekt} - - När man utgår från ett objekt så tar man ett objekt som - användaren kan relatera till, en bok, kaffe bryggare - eller dyl. Och sedan så gör man sin modell så att den - liknar det fysiska objektet. Det bör även gå att - manipulera objektet på ett vis som liknar det fysiska - objektet. Men man bör även tänka på vilka funktioner en - användare kan tänkas önska utöver dom som finns i det - verkliga objektet. Om man gör en ordebehandlare kan det - vara väldigt trevligt om denna klarar av att t.ex. - kompilera texten, rättstavning osv. + Visualisering måste innehålla mycket mer än att bara tillåta folk att ``se'' + information. Dom måste också kunna manipulera och fokusera sig på vad som är relevant + och känna igen det för att skapa ny information. Funktioner som hypertext (t.ex. HTML) + har blivit en dominant metod för att länka samman dokument, vilket tillåter användaren + att navigera sig genom dokument på ett väldigt dynamiskt och personligt sätt. + + \subsubsection{Utforska och ögna igenom} + + Hypertext är + en smidig metod för att söka efter information då man + kan länka vidare till djupare information då en + användare hittar något som intresserar. Nackdelen med + denna metod är att det kan bli grötigt, och att det + kan vara svårt att komma igång om man inte riktigt vet + vad man söker efter. Det ger däremot användaren en möjlighet + att hoppa runt på ett snabbt sätt mellan dokumenten tills + han/hon hittar det som söktes. + + \subsection{Konceptuella modeller baserat på objekt} + + När man utgår från ett objekt så tar man ett objekt som + användaren kan relatera till, en bok, kaffe bryggare + eller dyl. Och sedan så gör man sin modell så att den + liknar det fysiska objektet. Det bör även gå att + manipulera objektet på ett vis som liknar det fysiska + objektet. Men man bör även tänka på vilka funktioner en + användare kan tänkas önska utöver dom som finns i det + verkliga objektet. Om man gör en ordebehandlare kan det + vara väldigt trevligt om denna klarar av att t.ex. + kompilera texten, rättstavning osv. \subsection{Interface metaforer} @@ -321,7 +437,7 @@ produkter, så vi tänker inte gå in på denna så djupt. Dock så tror vi att det borde vara en bra metod att iallafall fundera på, men man måste nog vara försiktig så att man - inte gör ''hål`` i designen då man använder metaforer. + inte gör ``hål'' i designen då man använder metaforer. \section{Värdet av MDI}