| 7 |
\begin{centering} |
\begin{centering} |
| 8 |
\huge{HCI Text}\\ |
\huge{HCI Text}\\ |
| 9 |
\huge{DVC002: Människa-datorinteraktion (MDI), 5p}\\ |
\huge{DVC002: Människa-datorinteraktion (MDI), 5p}\\ |
| 10 |
\huge{2003, period 1}\\\vspace{.3in} |
\huge{Läsåret 2003-2004, läsperiod 1}\\\vspace{.3in} |
| 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-post:}\\ |
| 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 |
| 55 |
kommer användarna att med glädje byta, även om det kan |
kommer användarna att med glädje byta, även om det kan |
| 56 |
innebära vissa initiala problem. |
innebära vissa initiala problem. |
| 57 |
|
|
| 58 |
\subsection{Användandet av script vid mjukvaruproduktion} |
\subsection[Script vid mjukvaruproduktion]{Användandet av script vid mjukvaruproduktion} |
| 59 |
|
|
| 60 |
Detta kan lätt tyckas att detta inte har med MDI att |
Detta kan lätt tyckas att detta inte har med MDI att |
| 61 |
göra, men vi kommer att förklara detta lite senare. |
göra, men vi kommer att förklara detta lite senare. |
| 62 |
Tanken med att använda diverse script är främst att |
Tanken med att använda diverse script är främst att |
| 63 |
abstrahera krångliga kommandon (eller om man vill långa) |
kristallisera krångliga kommandon (eller om man vill långa) |
| 64 |
från användaren, och istället bara använda ett kort |
från användaren, och istället bara använda ett kort |
| 65 |
kommando. Detta innebär att det blir enklare att hålla |
kommando. Detta innebär att det blir enklare att hålla |
| 66 |
ordning på det man utvecklar då det i scriptet går |
ordning på det man utvecklar då det i scriptet går |
| 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 |
programmen i en, och hjälpfilerna 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? |
|
| 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 |
| 74 |
synpunkt?\\ |
synpunkt?\\ |
| 75 |
Jo, tanken var ju att ta alla dom krångliga kommandona, |
Jo, tanken var ju att ta alla dom krångliga kommandona, |
| 76 |
och helt enkelt byta ut mot ett kort script. Krasst sett |
och helt enkelt byta ut mot ett kort script. Krasst sett |
| 77 |
är detta grunden för MDI. Att ta något krångligt |
är detta grunden för MDI. Att ta något krångligt |
| 78 |
kommando, och byta ut mot ett lättare. |
kommando, och byta ut mot ett lättare. Eller kanske att på |
| 79 |
|
annat sätt underlätta användandet av en produkt vilket är |
| 80 |
|
det man bör sikta mot. |
| 81 |
|
|
| 82 |
\subsection{GUI design mönster} |
\subsection{GUI designmönster} |
| 83 |
|
|
| 84 |
GUI står för Graphical User Interface, eller grafiskt |
GUI står för Graphical User Interface, eller grafiskt |
| 85 |
användar gränsnitt på svenska. Ett GUI kan se ut på |
användargränsnitt på svenska. Ett GUI kan se ut på |
| 86 |
ett (nästan) oändligt antal sätt, men alla dessa följer |
ett (nästan) oändligt antal sätt, men alla dessa följer |
| 87 |
ett eller flera mönster för hur man använder dessa. Då |
ett eller flera mönster för hur man använder dessa. Då |
| 88 |
dessa mönster upprepas så är det viktigt för oss som |
dessa mönster upprepas så är det viktigt för oss som |
| 107 |
|
|
| 108 |
\subsection{Prototyper och Mock-ups} |
\subsection{Prototyper och Mock-ups} |
| 109 |
|
|
| 110 |
En mock-up är en form av prototyp. Den görs i ett |
Det finns flera olika sätt att demonstrera en idé, men |
| 111 |
passande material, och beroende på vilken information |
den bästa brukar vara att kunna visa upp något. Det kan |
| 112 |
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 |
| 113 |
detaljnivå som är passande. Denna mock-up används sedan |
kan ge kunden något han eller hon kan se, ta på, och till viss del |
| 114 |
för att testa om konceptet man har håller, och hur det |
kunna interagera med så är det mycket enklare, dels att |
| 115 |
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. |
| 116 |
programvara, utan kan lika gärna vara för en fysisk |
|
| 117 |
produkt, men i kursen har vi inriktat oss på programvara |
Nu vet ju vi att vi bara har använt mock-ups i denna |
| 118 |
då detta är det intressanta för oss. Då man skapat en |
kursen, men det vore synd att inte ta tillfället i akt |
| 119 |
mock-up så tar man denna, och testar på en eller flera |
och prata lite om prototyper också. |
| 120 |
tilltänkta användare, och lyssnar på deras åsikter om |
|
| 121 |
den. När man har kommit förbi detta stadiet så kan man |
\subsubsection{Mock-up} |
| 122 |
bygga en lite mera avancerad prototyp för att vidare |
|
| 123 |
utveckla produkten. En mock-up är vanligtvis (eller |
En mock-up är en form av prototyp. Den görs i ett |
| 124 |
i alla fall dom vi har gjort) ''dynamiskt statiska`` |
passande material, och beroende på vilken information |
| 125 |
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 |
| 126 |
det är att den görs dynamisk är att det går att byta |
detaljnivå som är passande. Denna mock-up används sedan |
| 127 |
detaljer i mock-upen för att symbolisera interaktion. En |
för att testa om konceptet man har håller, och hur det |
| 128 |
annan fördel med en mock-up framför en fungerade |
skall implementeras. En mock-up behöver inte vara för en |
| 129 |
prototyp är att en mock-up är gjord av ett billigt |
programvara, utan kan lika gärna vara för en fysisk |
| 130 |
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 |
| 131 |
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 |
| 132 |
att passa användaren och hans behov. |
mock-up så tar man denna, och testar på en eller flera |
| 133 |
|
tilltänkta användare, och lyssnar på deras åsikter om |
| 134 |
|
den. När man har kommit förbi detta stadiet så kan man |
| 135 |
|
bygga en lite mera avancerad prototyp för att vidareutveckla |
| 136 |
|
produkten. En mock-up är vanligtvis (eller |
| 137 |
|
i alla fall dom vi har gjort) ``dynamiskt statiska'' |
| 138 |
|
vilket kan låta som en motsägelse, men vad vi menar med |
| 139 |
|
det är att den görs dynamisk är att det går att byta |
| 140 |
|
detaljer i mock-upen för att symbolisera interaktion. En |
| 141 |
|
annan fördel med en mock-up framför en fungerade |
| 142 |
|
prototyp är att en mock-up är gjord av ett billigt |
| 143 |
|
material, och går snabbt att göra och göra om då man inser att |
| 144 |
|
lösningen man har inte håller, utan behöver göras om för |
| 145 |
|
att passa användaren och dess behov. |
| 146 |
|
|
| 147 |
|
\subsubsection{Lågnivåprototyper} |
| 148 |
|
|
| 149 |
|
En lågnivåprototyp är en enkel prototyp, som snarare |
| 150 |
|
syftar till att visa upp den grundläggande idéen. Den kan |
| 151 |
|
vara en mock-up, eller något annat. En lågnivåprototyp |
| 152 |
|
är något som går relativt snabbt att slänga |
| 153 |
|
ihop, och brukar vanligtvis vara ganska så billig. Den |
| 154 |
|
kan vara i ett material som är väldigt långt från den |
| 155 |
|
färdiga produkten (en mock-up på en kartongbit är ju |
| 156 |
|
väldigt långt från ett färdigt program på datorn, och |
| 157 |
|
vi är ganska säkra på att man kan komma ännu längre om |
| 158 |
|
man bara vill). |
| 159 |
|
|
| 160 |
|
Lågnivåprototypen använder man för att demonstrera |
| 161 |
|
idéer, koncept och dyl. Den kan inte till fullo |
| 162 |
|
användas för att fånga alla krav, men i samverkan med |
| 163 |
|
andra metoder (som t.ex. intervjuer, användningsfall |
| 164 |
|
osv) kan man komma nära nog i många fall. |
| 165 |
|
|
| 166 |
|
\subsubsection{Högnivåprototyper} |
| 167 |
|
|
| 168 |
|
En högnivåprototyp är en ''bättre`` prototyp, oftast |
| 169 |
|
så ligger den närmare den färdiga produkten än |
| 170 |
|
lågnivåprototypen till utseende, och material (där det |
| 171 |
|
finns). Det som främst skiljer en högnivåprototyp |
| 172 |
|
från en lågnivå är att högnivån har funktionalitet |
| 173 |
|
(verklig sådan, inte att man vänder blad). |
| 174 |
|
|
| 175 |
|
\subsubsection{Vilken väljer vi?} |
| 176 |
|
|
| 177 |
|
Marc Rettig (1994) anser att om man är tvungen att |
| 178 |
|
välja så är det är bättre att välja |
| 179 |
|
lågnivåprototyper framför högnivå, detta för att: |
| 180 |
|
|
| 181 |
|
\begin{itemize} |
| 182 |
|
\item Dom tar lång tid att göra |
| 183 |
|
\item Kritiker och testar tenderar att kritisera |
| 184 |
|
prototypen, och inte funktionaliteten i den. |
| 185 |
|
\item Utvecklar drar sig för att göra om något dom |
| 186 |
|
har lagt timmar (eller dagar) på att göra. |
| 187 |
|
\item En mjukvaru prototyp kan sätta förväntningarna |
| 188 |
|
för högt. |
| 189 |
|
\item En enda bugg i prototypen kan sätta stop för |
| 190 |
|
testningen av denna. |
| 191 |
|
\end{itemize} |
| 192 |
|
|
| 193 |
|
Vi måste säga att vi håller med honom. En lågnivåprototyp |
| 194 |
|
kan säga det mesta en högnivå kan, och det |
| 195 |
|
den inte kan säga är det tveksamt om man kan få |
| 196 |
|
tillbaka av den tid det tar att göra högnivåprototypen |
| 197 |
|
(iallafall i de små projekt vi har jobbat |
| 198 |
|
med hittills), det kan ju ändras om det är ett stort |
| 199 |
|
projekt, men vi är inte helt säkra på det. En |
| 200 |
|
prototyp skall endast ses som ett |
| 201 |
|
utvecklingsverktyg, det är ju inget som utvecklar av |
| 202 |
|
sig självt, på sin höjd kan det ju driva |
| 203 |
|
utvecklingen framåt. |
| 204 |
|
|
| 205 |
|
Vi anser att de projekt vi har jobbat med har varit |
| 206 |
|
så pass små att en högnivåprototyp inte skulle ha |
| 207 |
|
hjälp oss komma framåt, utan snarare tvärt om, men |
| 208 |
|
om man jobbar med större projekt så skall man nog |
| 209 |
|
inte underskatta värdet av en högnivåprototyp, dock |
| 210 |
|
så tror vi att det är viktigt att inte överskatta |
| 211 |
|
den heller. |
| 212 |
|
|
| 213 |
|
Ett undantag bör dock göras. Om man kan utnyttja |
| 214 |
|
prototypen, eller en ansenlig del av denna senare. |
| 215 |
|
Om man t.ex. gör en prototyp av ett GUI, med begränsad |
| 216 |
|
(eller igen) funktionalitet så kan man ju använda |
| 217 |
|
detta i den färdiga produkten, förutsatt att det |
| 218 |
|
faller väl ut. |
| 219 |
|
|
| 220 |
|
|
| 221 |
|
|
| 222 |
|
\subsection{Erfarenhet} |
| 223 |
|
|
| 224 |
Vi tror att vi kommer att använda någon form av |
Vi tror att vi kommer att använda någon form av |
| 225 |
mock-uper efter denna kursen då en mock-up är ett snabbt |
prototyper efter denna kursen då en lågnivåprototyp är ett snabbt |
| 226 |
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 |
| 227 |
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 |
| 228 |
hitta funktionalitet som man har missat, och det kan |
hitta funktionalitet som man har missat, och det kan |
| 229 |
ä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 |
| 230 |
kund som inte kunskaper inom programvaruutveckling vad |
kund som inte kunskaper inom programvaruutveckling vad |
| 231 |
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 eller hon får och inte får. |
| 232 |
Han kan även ta mock-upen och visa för slutanvändarna, |
Han kan även ta prototypen och visa för slutanvändarna, |
| 233 |
och dessa kan också komma till tals om hur produkten |
och dessa kan också komma till tals om hur produkten |
| 234 |
skall se ut, och dess funktionalitet. |
skall se ut, och dess funktionalitet. |
| 235 |
|
|
| 236 |
\section {Designmönster} |
Man kan även se en möjlighet till att kunden kan komma |
| 237 |
|
med flera direkta förslag på förändingar/förbättringar, |
| 238 |
|
eller till och med göra designen själv (eller delar av |
| 239 |
|
den). |
| 240 |
|
|
| 241 |
|
Dessutom så innebär en prototyp av något slag att man |
| 242 |
|
underlättar kommunikationen mellan utvecklaren och |
| 243 |
|
kunden, och eftersom kund och utvecklare ofta har olika |
| 244 |
|
kunskaper/erfarenheter innebär detta att man minskar |
| 245 |
|
risken för missförstånd, och kan rätta till eventuella |
| 246 |
|
designmissar i ett tidigt stadium. Prototypen kan även till |
| 247 |
|
viss del användas för att hitta saknad funktionalitet, |
| 248 |
|
dock så kan det vara svårare att hitta felaktig. |
| 249 |
|
|
| 250 |
|
\section {Designmönster} |
| 251 |
När man designar GUI'n så är det nästan omöjligt att |
När man designar GUI'n så är det nästan omöjligt att |
| 252 |
inte använda något/några design mönster. Dom flesta sätt |
inte använda något/några designmönster. De flesta sätt |
| 253 |
att strukturera upp ett GUI följer de mönster som finns |
att strukturera upp ett GUI följer de mönster som finns |
| 254 |
definierade. Detta märkte vi av på första laborationen |
definierade. Detta märkte vi av på första laborationen |
| 255 |
när vi skulle identifiera mönster som vi hade använt i |
när vi skulle identifiera mönster som vi hade använt i |
| 256 |
ett program vi själva hade gjort långt innan vi hade |
ett program vi själva hade gjort långt innan vi hade |
| 257 |
hört talas om MDI, och dess betydelse. En anledning till |
hört talas om MDI, och dess betydelse. En anledning till |
| 258 |
att man använder design mönster är att om flera program |
att man använder designmönster är att om flera program |
| 259 |
ser ut likadant, och uppför sig likadant så kommer |
ser ut likadant, och uppför sig likadant så kommer |
| 260 |
användaren att känna sig hemma i det, även om han aldrig |
användaren att känna sig hemma i det, även om han eller hon aldrig |
| 261 |
har sett programmet tidigare, eller ens ett program som |
har sett programmet tidigare, eller ens ett program som |
| 262 |
liknar detta (till funktionalitet sett). |
liknar detta (till funktionalitet sett). |
| 263 |
|
|
| 264 |
\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''} |
| 265 |
(Grand, M. 1999)\\ |
(Grand, M. 1999)\\ |
| 266 |
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, |
| 267 |
eller viktigare att återhämta sig från ett fel utan en |
eller viktigare att återhämta sig från ett fel utan en |
| 269 |
försiktigt, men trots detta kommer användaren att göra |
försiktigt, men trots detta kommer användaren att göra |
| 270 |
många fel (eller snarare så är det så det upplevs då alla fel gör |
många fel (eller snarare så är det så det upplevs då alla fel gör |
| 271 |
skada). Men om GUI't låter användaren återhämta sig om han |
skada). Men om GUI't låter användaren återhämta sig om han |
| 272 |
gör fel så kommer han att jobba i ett bättre tempo, och |
eller hon gör fel så kommer personen att jobba i ett bättre tempo, och |
| 273 |
göra färre fel. Något som är väldigt viktigt om GUI't |
göra färre fel. Något som är väldigt viktigt om GUI't |
| 274 |
tillåter att man gör fel så måste det varna om det finns |
tillåter att man gör fel så måste det varna om det finns |
| 275 |
aktioner som man kan göra som det inte går att återhämta |
aktioner som man kan göra som det inte går att återhämta |
| 278 |
\subsection{Vikten av att känna igen sig i ett program} |
\subsection{Vikten av att känna igen sig i ett program} |
| 279 |
|
|
| 280 |
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 |
| 281 |
är att detta ger en ''säkerhets känsla`` i programmet, |
är att detta ger en ``säkerhetskänsla'' i programmet, |
| 282 |
användaren känner att han vet (i viss mån) hur han skall |
användaren känner att han eller hon vet (i viss mån) hur man skall |
| 283 |
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 |
| 284 |
program där man kan spara sitt arbete, öppna en fil med |
program där man kan spara sitt arbete, öppna en fil med |
| 285 |
gammalt arbete osv har detta i en meny märk ''Arkiv`` på |
gammalt arbete osv har detta i en meny märk ``Arkiv'' på |
| 286 |
svenska, kommandon som kopiera, klistra in, gör om osv. |
svenska, kommandon som kopiera, klistra in, gör om osv. |
| 287 |
ligger under en meny ''redigera´´. Detta gör att en |
ligger under en meny ``redigera''. Detta gör att en |
| 288 |
användare kan känna igen sig även om han aldrig har |
användare kan känna igen sig även om han eller hon aldrig har |
| 289 |
nyttjat programmet tidigare. |
nyttjat programmet tidigare. |
| 290 |
|
|
| 291 |
\section{Interaktions Design} |
\section{Interaktionsdesign} |
| 292 |
|
|
| 293 |
När man pratar om interaktions design så menar man att |
När man pratar om interaktionsdesign så menar man att |
| 294 |
man sätter användaren och hans behov i fokus, och att man |
man sätter användaren och dess behov i fokus, och att man |
| 295 |
inte så mycket bryr sig om tekniken bakom. |
inte så mycket bryr sig om tekniken bakom. |
| 296 |
|
|
| 297 |
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å |
| 298 |
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 |
| 299 |
interaktions design är väldigt snarlikt till att jobba med |
interaktions design är väldigt snarlikt till att jobba med |
| 300 |
en användarcentrerad lösning. Det går antingen att jobba |
en användarcentrerad lösning. Det går antingen att jobba |
| 301 |
med interaktions design om man har en färdig målgrupp som |
med interaktions design om man har en färdig målgrupp som |
| 303 |
målgrupp, och skapar produkten därefter. |
målgrupp, och skapar produkten därefter. |
| 304 |
|
|
| 305 |
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 |
| 306 |
så är det ''enkelt`` att skapa denna då man hela tiden kan |
så är det ``enkelt'' att skapa denna då man hela tiden kan |
| 307 |
rådfråga målgruppen, skapa mock-uper, prototyper osv, och |
rådfråga målgruppen, skapa mock-uper, prototyper osv, och |
| 308 |
få direkt feedback på det man har gjort. |
få direkt feedback på det man har gjort. Det finns undantag |
| 309 |
|
då man inte kan skapa mock-uper och det är när själva slut |
| 310 |
En annan sak som är viktig, mycket viktig med Interaktions |
produkten är hemligstämplad och det finns andra aktörer på |
| 311 |
design är att den sker iterativt. |
marknaden som jobbar med samma område. Att då låta vanliga |
| 312 |
|
användare komma i kontakt med sin design innebär att hemlig |
| 313 |
|
information kan spridas till konkurrenterna om de nu råkar |
| 314 |
|
få tag på samma testpersoner, och fråga ut dessa. |
| 315 |
|
|
| 316 |
|
En annan sak som är viktig, mycket viktig med Interaktionsdesign |
| 317 |
|
är att den sker iterativt. Detta för att om det |
| 318 |
|
inte sker iterativt så kan man inte dra maximalt värde av |
| 319 |
|
den. Det finns ju en risk att om man gör en ändring |
| 320 |
|
som skall lösa ett problem, introducerar man två nya, och om |
| 321 |
|
processen inte sker iterativt så finns det ingen möjlighet |
| 322 |
|
att finna detta förrän det kanske är försent, och då kan det |
| 323 |
|
kosta väldigt mycket mer att åtgärda. |
| 324 |
|
|
| 325 |
\section{Konceptuella modeller} |
\section{Konceptuella modeller} |
| 326 |
|
|
| 327 |
\emph{Det viktigaste är att designa användarens |
En konceptuell modell är en beskrivning av systemet, i |
| 328 |
|
form av tankar och idéer om hur systemet skall verka och |
| 329 |
|
se ut, och att det kan förstås av användaren. |
| 330 |
|
|
| 331 |
|
\emph{``Det viktigaste är att designa användarens |
| 332 |
konceptuella modell. Allt annat skall ses som |
konceptuella modell. Allt annat skall ses som |
| 333 |
underordnat för att göra modellen klar, tydlig och |
underordnat för att göra modellen klar, tydlig och |
| 334 |
konkret. Detta är nästan tvärt emot hur den mesta |
konkret. Detta är nästan tvärt emot hur den mesta |
| 335 |
mjukvaran utvecklas.}(Liddle, David. 1996)\\ |
mjukvaran utvecklas.''}(Liddle, David. 1996)\\ |
| 336 |
Preece, Rogers and Sharp 2002 definierar en konceptuell |
Preece, Rogers and Sharp 2002 definierar en konceptuell |
| 337 |
modell som \emph{en beskrivning av det föreslagna |
modell som \emph{``en beskrivning av det föreslagna |
| 338 |
systemet i termer av integrerade idéer och koncept om |
systemet i termer av integrerade idéer och koncept om |
| 339 |
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 |
| 340 |
förstås av användaren på rätt sätt}\\ |
förstås av användaren på rätt sätt''} |
| 341 |
|
|
| 342 |
När man skapar en konceptuell modell så är det viktigt |
När man skapar en konceptuell modell så är det viktigt |
| 343 |
att man funderar över hur den slutliga produkten skall |
att man funderar över hur den slutliga produkten skall |
| 347 |
genomföra noggranna och iterativa tester. |
genomföra noggranna och iterativa tester. |
| 348 |
|
|
| 349 |
En viktig del av den konceptuella modellen är att |
En viktig del av den konceptuella modellen är att |
| 350 |
besluta vad användaren skall göra när han använder |
besluta vad användaren skall göra när han/hon använder |
| 351 |
produkten. Detta kan även kallas interaktions sätt |
produkten. Detta kan även kallas interaktionssätt |
| 352 |
dvs hur en användare skall få utföra jobbet. När man |
dvs hur en användare skall få utföra jobbet. När man |
| 353 |
väljer interaktions sätt så får man även tänka över hur |
väljer interaktionssätt så får man även tänka över hur |
| 354 |
man skall interagera med produkten (programvaran), skall |
man skall interagera med produkten (programvaran), skall |
| 355 |
det vara med knappar, menyer, röstkommandon osv. |
det vara med knappar, menyer, röstkommandon osv. |
| 356 |
|
|
| 378 |
\item Instruera |
\item Instruera |
| 379 |
\item Konversera |
\item Konversera |
| 380 |
\item Manipulera och navigera |
\item Manipulera och navigera |
| 381 |
\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? |
| 382 |
\end{itemize} |
\end{itemize} |
| 383 |
När man instruerar så förklarar man vad man vill att |
När man instruerar så förklarar man vad man vill att |
| 384 |
systemet skall göra, man ger order. Detta kan ske t.ex. |
systemet skall göra, man ger order. Detta kan ske t.ex. |
| 385 |
med knappar, menyer osv.\\ |
med knappar, menyer osv. |
| 386 |
|
|
| 387 |
När man konverserar så gör man det som man gör med en |
När man konverserar så gör man det som man gör med en |
| 388 |
människa, antingen talar man till systemet med rösten, |
människa, antingen talar man till systemet med rösten, |
| 389 |
eller så skriver man, men man håller sig till ett |
eller så skriver man, men man håller sig till ett |
| 390 |
normalt språk.\\ |
normalt språk. |
| 391 |
|
|
| 392 |
När man manipulerar och navigerar så har man en |
När man manipulerar och navigerar så har man en |
| 393 |
representation (av något) som man kan manipulera för att |
representation (av något) som man kan manipulera för att |
| 394 |
uppnå önskat resultat. Det är en klar fördel om |
uppnå önskat resultat. Det är en klar fördel om |
| 395 |
representationen delar vissa egenskaper som användaren |
representationen delar vissa egenskaper som användaren |
| 396 |
kan förstå av den fysiska världen.\\ %analoga lät fel, men fysiska låter heller inte riktigt bra... Jag höll på att skriv riktiga, men kom att tänka på vad det skulle innebära |
kan förstå av den fysiska världen. %analoga lät fel, men fysiska låter heller inte riktigt bra... Jag höll på att skriv riktiga, men kom att tänka på vad det skulle innebära |
| 397 |
|
|
| 398 |
När man utforskar och surfar så är systemet utformat på |
När man utforskar och surfar så är systemet utformat på |
| 399 |
ett sådant vis att användaren kan få information utan |
ett sådant vis att användaren kan få information utan |
| 400 |
att behöva formulera frågor. |
att behöva formulera frågor. |
| 404 |
ofta kan man få ett resultat som blir närmare det |
ofta kan man få ett resultat som blir närmare det |
| 405 |
användaren efterfrågar om man väljer att blanda flera |
användaren efterfrågar om man väljer att blanda flera |
| 406 |
aktiviteter. |
aktiviteter. |
|
|
|
| 407 |
\subsubsection{Instruera} |
\subsubsection{Instruera} |
| 408 |
|
|
| 409 |
a |
Detta är en relativt enkel modell att bygga upp, även om |
| 410 |
|
det kan vara krångligt att bygga upp den på ett bra |
| 411 |
|
sätt. Antingen kan man använda knappar, menyer osv för |
| 412 |
|
att ge instruktioner, eller så kan man använda |
| 413 |
|
textsträngar. En klar nackdel med denna modellen är att |
| 414 |
|
om kommandona är långa (eller krångliga) kommer |
| 415 |
|
användaren att glömma bort det, och behöva extra hjälp |
| 416 |
|
när han/hon skall nyttja denna. Detta är ett vanligt |
| 417 |
|
mönster, och återfinns i flera produkter på ett sätt |
| 418 |
|
eller ett annat. |
| 419 |
|
|
| 420 |
\subsubsection{Konversera} |
\subsubsection{Konversera} |
| 421 |
|
|
| 422 |
a |
Denna metoden är vanligast om det handlar om någon form |
| 423 |
|
av expert system, eller sökfunktioner. En klar fördel |
| 424 |
|
med att nyttja detta mönster är att även en människa med |
| 425 |
|
små kunskaper inom både data, och ämnet som experten kan |
| 426 |
|
kan ställa frågor, och få hjälp. En nackdel med detta |
| 427 |
|
mönstret är att om användaren ställer frågor på ett sätt |
| 428 |
|
som man inte har tänkt sig, eller som inte finns med i |
| 429 |
|
informations basen så kan svaren till användaren bli |
| 430 |
|
helt uppåt väggarna om man inte är noga med hur man |
| 431 |
|
behandlar indatan. |
| 432 |
|
|
| 433 |
\subsubsection{Manipulera och navigera} |
\subsubsection{Manipulera och navigera} |
| 434 |
|
|
| 435 |
a |
Visualisering måste innehålla mycket mer än att bara tillåta folk att ``se'' |
| 436 |
|
information. Dom måste också kunna manipulera och fokusera sig på vad som är relevant |
| 437 |
\subsubsection{Utforska och surfa} |
och känna igen det för att skapa ny information. Funktioner som hypertext (t.ex. HTML) |
| 438 |
|
har blivit en dominant metod för att länka samman dokument, vilket tillåter användaren |
| 439 |
a |
att navigera sig genom dokument på ett väldigt dynamiskt och personligt sätt. |
| 440 |
|
|
| 441 |
\subsection{Konceptuella modeller baserat på objekt} |
\subsubsection{Utforska och ögna igenom} |
| 442 |
|
|
| 443 |
a |
Hypertext är |
| 444 |
|
en smidig metod för att söka efter information då man |
| 445 |
\section{Värdet av MDI} |
kan länka vidare till djupare information då en |
| 446 |
|
användare hittar något som intresserar. Nackdelen med |
| 447 |
Det kanske kan verka abstrakt, och som något som bara tar |
denna metod är att det kan bli grötigt, och att det |
| 448 |
tid att hålla på med MDI, och allt man kan göra inom detta |
kan vara svårt att komma igång om man inte riktigt vet |
| 449 |
(mock-ups osv), men faktum är att den tid (och de pengar) |
vad man söker efter. Det ger däremot användaren en möjlighet |
| 450 |
man lägger ner på MDI tjänar man igen ganska så fort. |
att hoppa runt på ett snabbt sätt mellan dokumenten tills |
| 451 |
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
han/hon hittar det som söktes. |
| 452 |
fånga design fel, eller till och med logik fel, och ju |
|
| 453 |
tidigare man kan hitta fel, desto billigare blir dom att |
\subsection{Konceptuella modeller baserat på objekt} |
| 454 |
avhjälpa. |
|
| 455 |
|
När man utgår från ett objekt så tar man ett objekt som |
| 456 |
En annan viktig sak att tänka på med MDI är att man kan på |
användaren kan relatera till, en bok, kaffe bryggare |
| 457 |
ett sätt använda det som en reklam tavla för sitt företag, |
eller dyl. Och sedan så gör man sin modell så att den |
| 458 |
om man gör en extraordinär lösning på något så kommer |
liknar det fysiska objektet. Det bör även gå att |
| 459 |
detta att sprida sig, men det kommer ännu mer att sprida |
manipulera objektet på ett vis som liknar det fysiska |
| 460 |
sig om man gör dåliga MDI lösningar. Ett företag som |
objektet. Men man bör även tänka på vilka funktioner en |
| 461 |
tidigare har köpt en produkt som kanske är bra, bara det |
användare kan tänkas önska utöver dom som finns i det |
| 462 |
att de inte kan nyttja den kommer inte att köpa en produkt |
verkliga objektet. Om man gör en ordebehandlare kan det |
| 463 |
till av samma företag som den förra. |
vara väldigt trevligt om denna klarar av att t.ex. |
| 464 |
|
kompilera texten, rättstavning osv. |
| 465 |
|
|
| 466 |
|
\subsection{Interface-metaforer} |
| 467 |
|
|
| 468 |
|
Denna metod går ut på att man tar och försöker efterlikna |
| 469 |
|
en välkänd metod, eller något som användaren känner igen |
| 470 |
|
för att manipulera systemet. Det handlar oftast om att man |
| 471 |
|
försöker abstrahera bort hur datorn gör, och istället |
| 472 |
|
likna det vid något som man känner igen. Då boken är |
| 473 |
|
väldigt kritisk mot denna metoden att utveckla |
| 474 |
|
produkter, så tänker vi inte gå in på denna så djupt. Däremot så |
| 475 |
|
tror vi att det borde vara en bra metod att iallafall |
| 476 |
|
fundera på, men man måste nog vara försiktig så att man |
| 477 |
|
inte gör ``hål'' i designen då man använder metaforer. |
| 478 |
|
|
| 479 |
|
\section{Värdet av MDI} |
| 480 |
|
|
| 481 |
|
Hela ämnet kanske kan verka abstrakt, och som något som bara tar |
| 482 |
|
upp tid att hålla på med, men faktum är att den tid (och de pengar) |
| 483 |
|
man lägger ner på MDI tjänar man igen ganska så fort. |
| 484 |
|
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
| 485 |
|
fånga designfel, eller till och med logikfel, och ju |
| 486 |
|
tidigare man kan hitta fel, desto billigare blir dom att |
| 487 |
|
avhjälpa. |
| 488 |
|
|
| 489 |
|
En annan viktig sak att tänka på med MDI är att man kan på |
| 490 |
|
ett sätt använda det som en reklamtavla för sitt företag, |
| 491 |
|
om man gör en extraordinär lösning på något så kommer |
| 492 |
|
detta att sprida sig, men det kommer ännu mer att sprida |
| 493 |
|
sig om man gör dåliga MDI-lösningar. Ett företag som |
| 494 |
|
tidigare har köpt en produkt som kanske är bra, bara det |
| 495 |
|
att de inte kan nyttja den kommer inte att köpa en produkt |
| 496 |
|
till av samma företag som den förra. |
| 497 |
|
|
| 498 |
|
Även om själva funtionaliteten i applikationen (eller vad |
| 499 |
|
det nu är som skapats) kanske är helt banbrytande och |
| 500 |
|
ruskigt innovativ så kanske inte produkten kan säljas |
| 501 |
|
ändå, på grund av att användarna helt enkelt inte klarar |
| 502 |
|
av att använda den för att gränssnittet är alldeles för |
| 503 |
|
klumpigt, långsamt och förvirrande. \emph{``Jag fattar inte varför man år 2000 ska behöva |
| 504 |
|
vänta ibland en sekund innan telefonen fattar att man |
| 505 |
|
vill hoppa ett steg till vänster i menyerna.''}(Mats |
| 506 |
|
Ekstrand, 2000-09-20 i en recension av Ericssons R310) |
| 507 |
|
Man brukar säga att utseendet inte spelar någon roll, |
| 508 |
|
men när det gäller MDI så spelar det stor roll. Det första |
| 509 |
|
man möts av när man får/köper en produkt är gränssnittet, |
| 510 |
|
må det så vara en knappsats, touchscreen eller ett flashigt GUI. |
| 511 |
|
|
| 512 |
\end{document} |
\end{document} |