--- Kamel/HCI_text.tex 2003/03/09 18:21:20 1.13 +++ Kamel/HCI_text.tex 2003/03/09 22:02:01 1.14 @@ -105,39 +105,120 @@ \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. @@ -312,7 +393,7 @@ helt uppåt väggarna om man inte är noga med hur man behandlar indatan. - \subsubsection{Manipulera och navigera} + \subsubsection{Manipulera och navigera} 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 @@ -322,7 +403,16 @@ \subsubsection{Utforska och ögna igenom} - a + 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. Detta ä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. \subsection{Konceptuella modeller baserat på objekt}