| 105 |
|
|
| 106 |
\subsection{Prototyper och Mock-ups} |
\subsection{Prototyper och Mock-ups} |
| 107 |
|
|
| 108 |
En mock-up är en form av prototyp. Den görs i ett |
Det finns flera olika sätt att demonstrera en idé, men |
| 109 |
passande material, och beroende på vilken information |
den bästa brukar vara att kunna visa upp något. Det kan |
| 110 |
man har om den färdiga produkten så görs den med den |
vara bra att kunna berätta om idéen man har, men om man |
| 111 |
detaljnivå som är passande. Denna mock-up används sedan |
kan ge kunden något han kan se, ta på, och till viss del |
| 112 |
för att testa om konceptet man har håller, och hur det |
kunna interagera med så är det mycket enklare, dels att |
| 113 |
skall implementeras. En mock-up behöver inte vara för en |
sälja idén, dels att upptäcka fel och brister i den. |
| 114 |
programvara, utan kan lika gärna vara för en fysisk |
|
| 115 |
produkt, men i kursen har vi inriktat oss på programvara |
Nu vet ju vi att vi bara har använt mock-ups i denna |
| 116 |
då detta är det intressanta för oss. Då man skapat en |
kursen, men det vore synd att inte ta tillfället i akt |
| 117 |
mock-up så tar man denna, och testar på en eller flera |
och prata lite om prototyper också. |
| 118 |
tilltänkta användare, och lyssnar på deras åsikter om |
|
| 119 |
den. När man har kommit förbi detta stadiet så kan man |
\subsubsection{Mock-up} |
| 120 |
bygga en lite mera avancerad prototyp för att vidare |
|
| 121 |
utveckla produkten. En mock-up är vanligtvis (eller |
En mock-up är en form av prototyp. Den görs i ett |
| 122 |
i alla fall dom vi har gjort) ``dynamiskt statiska'' |
passande material, och beroende på vilken information |
| 123 |
vilket kan låta som en motsägelse, men vad vi menar med |
man har om den färdiga produkten så görs den med den |
| 124 |
det är att den görs dynamisk är att det går att byta |
detaljnivå som är passande. Denna mock-up används sedan |
| 125 |
detaljer i mock-upen för att symbolisera interaktion. En |
för att testa om konceptet man har håller, och hur det |
| 126 |
annan fördel med en mock-up framför en fungerade |
skall implementeras. En mock-up behöver inte vara för en |
| 127 |
prototyp är att en mock-up är gjord av ett billigt |
programvara, utan kan lika gärna vara för en fysisk |
| 128 |
material, och går snabbt att göra och göra om då man inser att |
produkt, men i kursen har vi inriktat oss på programvara |
| 129 |
lösningen man har inte håller, utan behöver göras om för |
då detta är det intressanta för oss. Då man skapat en |
| 130 |
att passa användaren och hans behov. |
mock-up så tar man denna, och testar på en eller flera |
| 131 |
|
tilltänkta användare, och lyssnar på deras åsikter om |
| 132 |
|
den. När man har kommit förbi detta stadiet så kan man |
| 133 |
|
bygga en lite mera avancerad prototyp för att vidare |
| 134 |
|
utveckla produkten. En mock-up är vanligtvis (eller |
| 135 |
|
i alla fall dom vi har gjort) ``dynamiskt statiska'' |
| 136 |
|
vilket kan låta som en motsägelse, men vad vi menar med |
| 137 |
|
det är att den görs dynamisk är att det går att byta |
| 138 |
|
detaljer i mock-upen för att symbolisera interaktion. En |
| 139 |
|
annan fördel med en mock-up framför en fungerade |
| 140 |
|
prototyp är att en mock-up är gjord av ett billigt |
| 141 |
|
material, och går snabbt att göra och göra om då man inser att |
| 142 |
|
lösningen man har inte håller, utan behöver göras om för |
| 143 |
|
att passa användaren och hans behov. |
| 144 |
|
|
| 145 |
|
\subsubsection{Lågnivå prototyper} |
| 146 |
|
|
| 147 |
|
En lågnivå prototyp är en enkel prototyp, som snarare |
| 148 |
|
syftar till att visa den grundläggande idéen. Den kan |
| 149 |
|
vara en mock-up, eller något annat. En lågnivå |
| 150 |
|
prototyp är något som går relativt snabbt att slänga |
| 151 |
|
ihop, och brukar vanligtvis vara ganska så billig. Den |
| 152 |
|
kan vara i ett material som är väldigt långt från den |
| 153 |
|
färdiga produkten (en mock-up på en kartongbit är ju |
| 154 |
|
väldigt långt från ett färdigt program på datorn, och |
| 155 |
|
vi är ganska säkra på att man kan komma ännu längre om |
| 156 |
|
man bara vill). |
| 157 |
|
|
| 158 |
|
Lågnivå prototypen använder man för att demonstrera en |
| 159 |
|
idéer, koncept och dyl. Den kan inte till fullo |
| 160 |
|
användas för att fånga alla krav, men i samverkan med |
| 161 |
|
andra metoder (som t.ex. intervjuer, användningsfall |
| 162 |
|
osv) kan man komma nära nog i många fall. |
| 163 |
|
|
| 164 |
|
\subsubsection{Högnivå prototyper} |
| 165 |
|
|
| 166 |
|
En högnivå prototyp är en ''bättre`` prototyp, oftast |
| 167 |
|
så ligger den närmare den färdiga produkten än lågnivå |
| 168 |
|
prototypen till utseende, och material (där det |
| 169 |
|
finns). Det som främst skiljer en högnivå prototyp |
| 170 |
|
från en lågnivå är att högnivån har funktionalitet |
| 171 |
|
(verklig sådan, inte att man vänder blad). |
| 172 |
|
|
| 173 |
|
\subsubsection{Vilken väljer vi?} |
| 174 |
|
|
| 175 |
|
Marc Rettig (1994) anser att det är bättre att använda |
| 176 |
|
lågnivå prototyper framför högnivå, detta för att: |
| 177 |
|
|
| 178 |
|
\begin{itemize} |
| 179 |
|
\item Dom tar lång tid att göra |
| 180 |
|
\item Kritiker och testar tenderar att kritisera |
| 181 |
|
prototypen, och inte funktionaliteten i den. |
| 182 |
|
\item Utvecklar drar sig för att göra om något dom |
| 183 |
|
har lagt timmar (eller dagar) på att göra. |
| 184 |
|
\item En mjukvaru prototyp kan sätta förväntningarna |
| 185 |
|
för högt. |
| 186 |
|
\item En enda bugg i prototypen kan sätta stop för |
| 187 |
|
testningen av denna. |
| 188 |
|
\end{itemize} |
| 189 |
|
|
| 190 |
|
Vi måste säga att vi håller med honom. En lågnivå |
| 191 |
|
prototyp kan säga det mesta en högnivå kan, och det |
| 192 |
|
den inte kan säga är det tveksamt om man kan få |
| 193 |
|
tillbaka av den tid det tar att göra högnivå |
| 194 |
|
prototypen (iallafall i de små projekt vi har jobbat |
| 195 |
|
med hittills), det kan ju ändras om det är ett stort |
| 196 |
|
projekt, men vi är inte helt säkra på det. En |
| 197 |
|
prototyp skall endast ses som ett |
| 198 |
|
utvecklingsverktyg, det är ju inget som utvecklar av |
| 199 |
|
sig självt, på sin höjd kan det ju driva |
| 200 |
|
utvecklingen framåt. |
| 201 |
|
|
| 202 |
|
Ett undantag bör dock göras. Om man kan utnyttja |
| 203 |
|
prototypen, eller en ansenlig del av denna senare. |
| 204 |
|
Om man t.ex. gör en prototyp av ett GUI, med begränsad |
| 205 |
|
(eller igen) funktionalitet så kan man ju använda |
| 206 |
|
detta i den färdiga produkten, förutsatt att det |
| 207 |
|
faller väl ut. |
| 208 |
|
|
| 209 |
|
|
| 210 |
|
|
| 211 |
|
\subsection{Erfarenhet} |
| 212 |
|
|
| 213 |
Vi tror att vi kommer att använda någon form av |
Vi tror att vi kommer att använda någon form av |
| 214 |
mock-uper efter denna kursen då en mock-up är ett snabbt |
prototyper efter denna kursen då en lågnivå prototyp är ett snabbt |
| 215 |
sätt att visa hur man menar att GUI't skall se ut, och |
sätt att visa hur man menar att GUI't skall se ut, och |
| 216 |
om man har ett förslag till ett GUI så är det enkelt att |
om man har ett förslag till ett GUI så är det enkelt att |
| 217 |
hitta funktionalitet som man har missat, och det kan |
hitta funktionalitet som man har missat, och det kan |
| 218 |
även vara enklare att förklara vad man vill göra för en |
även vara enklare att förklara vad man vill göra för en |
| 219 |
kund som inte kunskaper inom programvaruutveckling vad |
kund som inte kunskaper inom programvaruutveckling vad |
| 220 |
det är som man skall göra, och vad han får och inte får. |
det är som man skall göra, och vad han får och inte får. |
| 221 |
Han kan även ta mock-upen och visa för slutanvändarna, |
Han kan även ta prototypen och visa för slutanvändarna, |
| 222 |
och dessa kan också komma till tals om hur produkten |
och dessa kan också komma till tals om hur produkten |
| 223 |
skall se ut, och dess funktionalitet. |
skall se ut, och dess funktionalitet. |
| 224 |
|
|
| 344 |
\item Instruera |
\item Instruera |
| 345 |
\item Konversera |
\item Konversera |
| 346 |
\item Manipulera och navigera |
\item Manipulera och navigera |
| 347 |
\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? |
| 348 |
\end{itemize} |
\end{itemize} |
| 349 |
När man instruerar så förklarar man vad man vill att |
När man instruerar så förklarar man vad man vill att |
| 350 |
systemet skall göra, man ger order. Detta kan ske t.ex. |
systemet skall göra, man ger order. Detta kan ske t.ex. |
| 380 |
mönster, och återfinns i flera produkter på ett sätt |
mönster, och återfinns i flera produkter på ett sätt |
| 381 |
eller ett annat. |
eller ett annat. |
| 382 |
|
|
| 383 |
\subsubsection{Konversera} |
\subsubsection{Konversera} |
| 384 |
|
|
| 385 |
Denna metoden är vanligast om det handlar om någon form |
Denna metoden är vanligast om det handlar om någon form |
| 386 |
av expert system, eller sökfunktioner. En klar fördel |
av expert system, eller sökfunktioner. En klar fördel |
| 387 |
med att nyttja detta mönster är att även en människa med |
med att nyttja detta mönster är att även en människa med |
| 388 |
små kunskaper inom både data, och ämnet som experten kan |
små kunskaper inom både data, och ämnet som experten kan |
| 389 |
kan ställa frågor, och få hjälp. En nackdel med detta |
kan ställa frågor, och få hjälp. En nackdel med detta |
| 390 |
mönstret är att om användaren ställer frågor på ett sätt |
mönstret är att om användaren ställer frågor på ett sätt |
| 391 |
som man inte har tänkt sig, eller som inte finns med i |
som man inte har tänkt sig, eller som inte finns med i |
| 392 |
informations basen så kan svaren till användaren bli |
informations basen så kan svaren till användaren bli |
| 393 |
helt uppåt väggarna om man inte är noga med hur man |
helt uppåt väggarna om man inte är noga med hur man |
| 394 |
behandlar indatan. |
behandlar indatan. |
| 395 |
|
|
| 396 |
\subsubsection{Manipulera och navigera} |
\subsubsection{Manipulera och navigera} |
| 397 |
|
|
| 398 |
a |
Visualisering måste innehålla mycket mer än att bara tillåta folk att ``se'' |
| 399 |
|
information. Dom måste också kunna manipulera och fokusera sig på vad som är relevant |
| 400 |
\subsubsection{Utforska och surfa} |
och känna igen det för att skapa ny information. Funktioner som hypertext (t.ex. HTML) |
| 401 |
|
har blivit en dominant metod för att länka samman dokument, vilket tillåter användaren |
| 402 |
a |
att navigera sig genom dokument på ett väldigt dynamiskt och personligt sätt. |
| 403 |
|
|
| 404 |
\subsection{Konceptuella modeller baserat på objekt} |
\subsubsection{Utforska och ögna igenom} |
| 405 |
|
|
| 406 |
När man utgår från ett objekt så tar man ett objekt som |
Funktioner som hypertext (t.ex. HTML) har blivit en |
| 407 |
användaren kan relatera till, en bok, kaffe bryggare |
dominant metod för att länka samman dokument, vilket |
| 408 |
eller dyl. Och sedan så gör man sin modell så att den |
tillåter användaren att navigera sig genom dokument |
| 409 |
liknar det fysiska objektet. Det bör även gå att |
på ett väldigt dynamiskt och personligt sätt. Detta är |
| 410 |
manipulera objektet på ett vis som liknar det fysiska |
en smidig metod för att söka efter information då man |
| 411 |
objektet. Men man bör även tänka på vilka funktioner en |
kan länka vidare till djupare information då en |
| 412 |
användare kan tänkas önska utöver dom som finns i det |
användare hittar något som intresserar. Nackdelen med |
| 413 |
verkliga objektet. Om man gör en ordebehandlare kan det |
denna metod är att det kan bli grötigt, och att det |
| 414 |
vara väldigt trevligt om denna klarar av att t.ex. |
kan vara svårt att komma igång om man inte riktigt vet |
| 415 |
kompilera texten, rättstavning osv. |
vad man söker efter. |
| 416 |
|
|
| 417 |
|
\subsection{Konceptuella modeller baserat på objekt} |
| 418 |
|
|
| 419 |
|
När man utgår från ett objekt så tar man ett objekt som |
| 420 |
|
användaren kan relatera till, en bok, kaffe bryggare |
| 421 |
|
eller dyl. Och sedan så gör man sin modell så att den |
| 422 |
|
liknar det fysiska objektet. Det bör även gå att |
| 423 |
|
manipulera objektet på ett vis som liknar det fysiska |
| 424 |
|
objektet. Men man bör även tänka på vilka funktioner en |
| 425 |
|
användare kan tänkas önska utöver dom som finns i det |
| 426 |
|
verkliga objektet. Om man gör en ordebehandlare kan det |
| 427 |
|
vara väldigt trevligt om denna klarar av att t.ex. |
| 428 |
|
kompilera texten, rättstavning osv. |
| 429 |
|
|
| 430 |
\subsection{Interface metaforer} |
\subsection{Interface metaforer} |
| 431 |
|
|