11 |
\large{av}\\ |
\large{av}\\ |
12 |
\LARGE{Jonas Petersson \& Mathias Börjesson}\\\vspace{.4in} |
\LARGE{Jonas Petersson \& Mathias Börjesson}\\\vspace{.4in} |
13 |
\large{Institutionen för programvaruteknik och datavetenskap\\ |
\large{Institutionen för programvaruteknik och datavetenskap\\ |
14 |
Blekinge Tekniska Högskola\\\vspace{.03in} |
Blekinge Tekniska Högskola\\\vspace{.03in}} |
15 |
\texttt{e-mail:}\\ |
\texttt{e-mail:}\\ |
16 |
\emph{jopd01@student.bth.se}}\\ |
\emph{jopd01@student.bth.se}\\ |
17 |
\emph{tb00mbo@student.bth.se}\\ |
\emph{tb00mbo@student.bth.se}\\ |
18 |
\end{centering} |
\end{centering} |
19 |
\newpage |
\newpage |
67 |
snabbt att skriva ner de kommandon som ser till att |
snabbt att skriva ner de kommandon som ser till att |
68 |
källfilerna ligger i en katalog, de kompilerade |
källfilerna ligger i en katalog, de kompilerade |
69 |
programmet i en, och hjälp filerna i en tredje (om |
programmet i en, och hjälp filerna i en tredje (om |
70 |
programmeringsspråket stödjer detta (t.ex. java API).\\ |
programmeringsspråket stödjer detta (t.ex. Java API).\\ |
71 |
|
|
72 |
%Eller är det svaret vi skall skjuta in? |
%Eller är det svaret vi skall skjuta in? |
73 |
Men hur är detta något som är intressant ur en MDI |
Men hur är detta något som är intressant ur en MDI |
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 |
|
|
237 |
har sett programmet tidigare, eller ens ett program som |
har sett programmet tidigare, eller ens ett program som |
238 |
liknar detta (till funktionalitet sett). |
liknar detta (till funktionalitet sett). |
239 |
|
|
240 |
\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''} |
241 |
(Grand, M. 1999)\\ |
(Grand, M. 1999)\\ |
242 |
Detta är viktigt därför att om det inte går att göra fel, |
Detta är viktigt därför att om det inte går att göra fel, |
243 |
eller viktigare att återhämta sig från ett fel utan en |
eller viktigare att återhämta sig från ett fel utan en |
254 |
\subsection{Vikten av att känna igen sig i ett program} |
\subsection{Vikten av att känna igen sig i ett program} |
255 |
|
|
256 |
En viktig sak med att få användaren att känna igen sig |
En viktig sak med att få användaren att känna igen sig |
257 |
är att detta ger en ''säkerhets känsla`` i programmet, |
är att detta ger en ``säkerhets känsla'' i programmet, |
258 |
användaren känner att han vet (i viss mån) hur han skall |
användaren känner att han vet (i viss mån) hur han skall |
259 |
bära sig åt för att göra olika saker. Nästan alla |
bära sig åt för att göra olika saker. Nästan alla |
260 |
program där man kan spara sitt arbete, öppna en fil med |
program där man kan spara sitt arbete, öppna en fil med |
261 |
gammalt arbete osv har detta i en meny märk ''Arkiv`` på |
gammalt arbete osv har detta i en meny märk ``Arkiv'' på |
262 |
svenska, kommandon som kopiera, klistra in, gör om osv. |
svenska, kommandon som kopiera, klistra in, gör om osv. |
263 |
ligger under en meny ''redigera´´. Detta gör att en |
ligger under en meny ``redigera''. Detta gör att en |
264 |
användare kan känna igen sig även om han aldrig har |
användare kan känna igen sig även om han aldrig har |
265 |
nyttjat programmet tidigare. |
nyttjat programmet tidigare. |
266 |
|
|
271 |
inte så mycket bryr sig om tekniken bakom. |
inte så mycket bryr sig om tekniken bakom. |
272 |
|
|
273 |
Detta innebär dock att för att kunna designa något så |
Detta innebär dock att för att kunna designa något så |
274 |
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 |
275 |
interaktions design är väldigt snarlikt till att jobba med |
interaktions design är väldigt snarlikt till att jobba med |
276 |
en användarcentrerad lösning. Det går antingen att jobba |
en användarcentrerad lösning. Det går antingen att jobba |
277 |
med interaktions design om man har en färdig målgrupp som |
med interaktions design om man har en färdig målgrupp som |
279 |
målgrupp, och skapar produkten därefter. |
målgrupp, och skapar produkten därefter. |
280 |
|
|
281 |
Om man har en färdig målgrupp som har behov av en produkt |
Om man har en färdig målgrupp som har behov av en produkt |
282 |
så är det ''enkelt`` att skapa denna då man hela tiden kan |
så är det ``enkelt'' att skapa denna då man hela tiden kan |
283 |
rådfråga målgruppen, skapa mock-uper, prototyper osv, och |
rådfråga målgruppen, skapa mock-uper, prototyper osv, och |
284 |
få direkt feedback på det man har gjort. |
få direkt feedback på det man har gjort. Det finns undantag |
285 |
|
då man inte kan skapa mock-uper och det är när själva slut |
286 |
|
produkten är hemligstämplad och det finns andra aktörer på |
287 |
|
marknaden som jobbar med samma område. Att då låta vanliga |
288 |
|
användare komma i kontakt med sin design innebär att hemlig |
289 |
|
information kan spridas till konkurrenterna om de nu råkas |
290 |
|
få tag på samma testpersoner. |
291 |
|
|
292 |
En annan sak som är viktig, mycket viktig med Interaktions |
En annan sak som är viktig, mycket viktig med Interaktions |
293 |
design är att den sker iterativt. |
design är att den sker iterativt. |
294 |
|
|
295 |
\section{Konceptuella modeller} |
\section{Konceptuella modeller} |
296 |
|
|
297 |
\emph{Det viktigaste är att designa användarens |
\emph{``Det viktigaste är att designa användarens |
298 |
konceptuella modell. Allt annat skall ses som |
konceptuella modell. Allt annat skall ses som |
299 |
underordnat för att göra modellen klar, tydlig och |
underordnat för att göra modellen klar, tydlig och |
300 |
konkret. Detta är nästan tvärt emot hur den mesta |
konkret. Detta är nästan tvärt emot hur den mesta |
301 |
mjukvaran utvecklas.}(Liddle, David. 1996)\\ |
mjukvaran utvecklas.''}(Liddle, David. 1996)\\ |
302 |
Preece, Rogers and Sharp 2002 definierar en konceptuell |
Preece, Rogers and Sharp 2002 definierar en konceptuell |
303 |
modell som \emph{en beskrivning av det föreslagna |
modell som \emph{``en beskrivning av det föreslagna |
304 |
systemet i termer av integrerade idéer och koncept om |
systemet i termer av integrerade idéer och koncept om |
305 |
vad det skall göra, bete sig samt se ut som, som skall |
vad det skall göra, bete sig samt se ut som, som skall |
306 |
förstås av användaren på rätt sätt}\\ |
förstås av användaren på rätt sätt''}\\ |
307 |
|
|
308 |
När man skapar en konceptuell modell så är det viktigt |
När man skapar en konceptuell modell så är det viktigt |
309 |
att man funderar över hur den slutliga produkten skall |
att man funderar över hur den slutliga produkten skall |
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. |
367 |
ofta kan man få ett resultat som blir närmare det |
ofta kan man få ett resultat som blir närmare det |
368 |
användaren efterfrågar om man väljer att blanda flera |
användaren efterfrågar om man väljer att blanda flera |
369 |
aktiviteter. |
aktiviteter. |
|
|
|
370 |
\subsubsection{Instruera} |
\subsubsection{Instruera} |
371 |
|
|
372 |
a |
Detta är en relativt enkel modell att bygga upp, även om |
373 |
|
det kan vara krångligt att bygga upp den på ett bra |
374 |
|
sätt. Antingen kan man använda knappar, menyer osv för |
375 |
|
att ge instruktioner, eller så kan man använda |
376 |
|
textsträngar. En klar nackdel med denna modellen är att |
377 |
|
om kommandona är långa (eller krångliga) kommer |
378 |
|
användaren att glömma bort det, och behöva extra hjälp |
379 |
|
när han skall nyttja denna. Detta är ett vanligt |
380 |
|
mönster, och återfinns i flera produkter på ett sätt |
381 |
|
eller ett annat. |
382 |
|
|
383 |
\subsubsection{Konversera} |
\subsubsection{Konversera} |
384 |
|
|
385 |
a |
Denna metoden är vanligast om det handlar om någon form |
386 |
|
av expert system, eller sökfunktioner. En klar fördel |
387 |
|
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 |
389 |
|
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 |
391 |
|
som man inte har tänkt sig, eller som inte finns med i |
392 |
|
informations basen så kan svaren till användaren bli |
393 |
|
helt uppåt väggarna om man inte är noga med hur man |
394 |
|
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 |
a |
Funktioner som hypertext (t.ex. HTML) har blivit en |
407 |
|
dominant metod för att länka samman dokument, vilket |
408 |
\section{Värdet av MDI} |
tillåter användaren att navigera sig genom dokument |
409 |
|
på ett väldigt dynamiskt och personligt sätt. Detta är |
410 |
Det kanske kan verka abstrakt, och som något som bara tar |
en smidig metod för att söka efter information då man |
411 |
tid att hålla på med MDI, och allt man kan göra inom detta |
kan länka vidare till djupare information då en |
412 |
(mock-ups osv), men faktum är att den tid (och de pengar) |
användare hittar något som intresserar. Nackdelen med |
413 |
man lägger ner på MDI tjänar man igen ganska så fort. |
denna metod är att det kan bli grötigt, och att det |
414 |
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
kan vara svårt att komma igång om man inte riktigt vet |
415 |
fånga design fel, eller till och med logik fel, och ju |
vad man söker efter. |
416 |
tidigare man kan hitta fel, desto billigare blir dom att |
|
417 |
avhjälpa. |
\subsection{Konceptuella modeller baserat på objekt} |
418 |
|
|
419 |
En annan viktig sak att tänka på med MDI är att man kan på |
När man utgår från ett objekt så tar man ett objekt som |
420 |
ett sätt använda det som en reklam tavla för sitt företag, |
användaren kan relatera till, en bok, kaffe bryggare |
421 |
om man gör en extraordinär lösning på något så kommer |
eller dyl. Och sedan så gör man sin modell så att den |
422 |
detta att sprida sig, men det kommer ännu mer att sprida |
liknar det fysiska objektet. Det bör även gå att |
423 |
sig om man gör dåliga MDI lösningar. Ett företag som |
manipulera objektet på ett vis som liknar det fysiska |
424 |
tidigare har köpt en produkt som kanske är bra, bara det |
objektet. Men man bör även tänka på vilka funktioner en |
425 |
att de inte kan nyttja den kommer inte att köpa en produkt |
användare kan tänkas önska utöver dom som finns i det |
426 |
till av samma företag som den förra. |
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} |
431 |
|
|
432 |
|
Denna metod går ut på att man tar och försöker efterlikna |
433 |
|
en välkänd metod, eller något som användaren känner igen |
434 |
|
för att manipulera systemet. Det handlar oftast om att man |
435 |
|
försöker abstrahera bort hur datorn gör, och istället |
436 |
|
likna det vi något som man känner igen. Dock så är boken |
437 |
|
vi har väldigt kritisk mot denna metoden att utveckla |
438 |
|
produkter, så vi tänker inte gå in på denna så djupt. Dock så |
439 |
|
tror vi att det borde vara en bra metod att iallafall |
440 |
|
fundera på, men man måste nog vara försiktig så att man |
441 |
|
inte gör ``hål'' i designen då man använder metaforer. |
442 |
|
|
443 |
|
\section{Värdet av MDI} |
444 |
|
|
445 |
|
Hela ämnet kanske kan verka abstrakt, och som något som bara tar |
446 |
|
upp tid att hålla på med, men faktum är att den tid (och de pengar) |
447 |
|
man lägger ner på MDI tjänar man igen ganska så fort. |
448 |
|
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
449 |
|
fånga design fel, eller till och med logik fel, och ju |
450 |
|
tidigare man kan hitta fel, desto billigare blir dom att |
451 |
|
avhjälpa. |
452 |
|
|
453 |
|
En annan viktig sak att tänka på med MDI är att man kan på |
454 |
|
ett sätt använda det som en reklam tavla för sitt företag, |
455 |
|
om man gör en extraordinär lösning på något så kommer |
456 |
|
detta att sprida sig, men det kommer ännu mer att sprida |
457 |
|
sig om man gör dåliga MDI lösningar. Ett företag som |
458 |
|
tidigare har köpt en produkt som kanske är bra, bara det |
459 |
|
att de inte kan nyttja den kommer inte att köpa en produkt |
460 |
|
till av samma företag som den förra. |
461 |
|
|
462 |
|
Även om själva funtionaliteten i applikationen (eller vad |
463 |
|
det nu är som skapats) kanske är helt banbrytande och |
464 |
|
ruskigt innovativ så kanske inte produkten kan säljas |
465 |
|
ändå, på grund av att användarna helt enkelt inte klarar |
466 |
|
av att använda den för att gränssnittet är alldeles för |
467 |
|
klumpigt, långsamt och förvirrande. \emph{``Jag fattar inte varför man år 2000 ska behöva |
468 |
|
vänta ibland en sekund innan telefonen fattar att man |
469 |
|
vill hoppa ett steg till vänster i menyerna.''}(Mats |
470 |
|
Ekstrand, 2000-09-20 i en recension av Ericssons R310) |
471 |
|
Man brukar säga att utseendet inte spelar någon roll, |
472 |
|
men när det gäller MDI så spelar det stor roll. Det första |
473 |
|
man möts av när man får/köper en produkt är gränssnittet, |
474 |
|
må det så vara en knappsats, touchscreen eller ett flashigt GUI. |
475 |
|
|
476 |
\end{document} |
\end{document} |