| 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 |
| 119 |
den. När man har kommit förbi detta stadiet så kan man |
den. När man har kommit förbi detta stadiet så kan man |
| 120 |
bygga en lite mera avancerad prototyp för att vidare |
bygga en lite mera avancerad prototyp för att vidare |
| 121 |
utveckla produkten. En mock-up är vanligtvis (eller |
utveckla produkten. En mock-up är vanligtvis (eller |
| 122 |
i alla fall dom vi har gjort) ''dynamiskt statiska`` |
i alla fall dom vi har gjort) ``dynamiskt statiska'' |
| 123 |
vilket kan låta som en motsägelse, men vad vi menar med |
vilket kan låta som en motsägelse, men vad vi menar med |
| 124 |
det är att den görs dynamisk är att det går att byta |
det är att den görs dynamisk är att det går att byta |
| 125 |
detaljer i mock-upen för att symbolisera interaktion. En |
detaljer i mock-upen för att symbolisera interaktion. En |
| 156 |
har sett programmet tidigare, eller ens ett program som |
har sett programmet tidigare, eller ens ett program som |
| 157 |
liknar detta (till funktionalitet sett). |
liknar detta (till funktionalitet sett). |
| 158 |
|
|
| 159 |
\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''} |
| 160 |
(Grand, M. 1999)\\ |
(Grand, M. 1999)\\ |
| 161 |
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, |
| 162 |
eller viktigare att återhämta sig från ett fel utan en |
eller viktigare att återhämta sig från ett fel utan en |
| 173 |
\subsection{Vikten av att känna igen sig i ett program} |
\subsection{Vikten av att känna igen sig i ett program} |
| 174 |
|
|
| 175 |
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 |
| 176 |
är att detta ger en ''säkerhets känsla`` i programmet, |
är att detta ger en ``säkerhets känsla'' i programmet, |
| 177 |
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 |
| 178 |
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 |
| 179 |
program där man kan spara sitt arbete, öppna en fil med |
program där man kan spara sitt arbete, öppna en fil med |
| 180 |
gammalt arbete osv har detta i en meny märk ''Arkiv`` på |
gammalt arbete osv har detta i en meny märk ``Arkiv'' på |
| 181 |
svenska, kommandon som kopiera, klistra in, gör om osv. |
svenska, kommandon som kopiera, klistra in, gör om osv. |
| 182 |
ligger under en meny ''redigera´´. Detta gör att en |
ligger under en meny ``redigera''. Detta gör att en |
| 183 |
användare kan känna igen sig även om han aldrig har |
användare kan känna igen sig även om han aldrig har |
| 184 |
nyttjat programmet tidigare. |
nyttjat programmet tidigare. |
| 185 |
|
|
| 198 |
målgrupp, och skapar produkten därefter. |
målgrupp, och skapar produkten därefter. |
| 199 |
|
|
| 200 |
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 |
| 201 |
så är det ''enkelt`` att skapa denna då man hela tiden kan |
så är det ``enkelt'' att skapa denna då man hela tiden kan |
| 202 |
rådfråga målgruppen, skapa mock-uper, prototyper osv, och |
rådfråga målgruppen, skapa mock-uper, prototyper osv, och |
| 203 |
få direkt feedback på det man har gjort. |
få direkt feedback på det man har gjort. |
| 204 |
|
|
| 205 |
En annan sak som är viktig, mycket viktig med Interaktions |
En annan sak som är viktig, mycket viktig med Interaktions |
| 206 |
design är att den sker iterativt. |
design är att den sker iterativt. |
| 207 |
|
|
| 208 |
\subsection{Konceptuella modeller} |
\section{Konceptuella modeller} |
|
|
|
|
\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)\\ |
|
|
Preece, Rogers and Sharp 2002 definierar en konceptuell |
|
|
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}\\ |
|
|
|
|
|
När man skapar en konceptuell modell så är det viktigt |
|
|
att man funderar över hur den slutliga produkten skall |
|
|
se ut, baserat på användarnas behov och krav. För att |
|
|
försäkra sig om att användaren kommer att förstå |
|
|
modellen så som den är tänkt är det viktigt att |
|
|
|
|
|
\subsubsection{Konceptuella modeller baserat på |
|
|
aktiviteter} |
|
|
|
|
|
\subsubsection{Konceptuella modeller baserat på objekt} |
|
|
|
|
|
\section{Värdet av MDI} |
|
|
|
|
|
Det kanske kan verka abstrakt, och som något som bara tar |
|
|
tid att hålla på med MDI, och allt man kan göra inom detta |
|
|
(mock-ups osv), men faktum är att den tid (och de pengar) |
|
|
man lägger ner på MDI tjänar man igen ganska så fort. |
|
|
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
|
|
fånga design fel, eller till och med logik fel, och ju |
|
|
tidigare man kan hitta fel, desto billigare blir dom att |
|
|
avhjälpa. |
|
|
|
|
|
En annan viktig sak att tänka på med MDI är att man kan på |
|
|
ett sätt använda det som en reklam tavla för sitt företag, |
|
|
om man gör en extraordinär lösning på något så kommer |
|
|
detta att sprida sig, men det kommer ännu mer att sprida |
|
|
sig om man gör dåliga MDI lösningar. Ett företag som |
|
|
tidigare har köpt en produkt som kanske är bra, bara det |
|
|
att de inte kan nyttja den kommer inte att köpa en produkt |
|
|
till av samma företag som den förra. |
|
| 209 |
|
|
| 210 |
|
\emph{``Det viktigaste är att designa användarens |
| 211 |
|
konceptuella modell. Allt annat skall ses som |
| 212 |
|
underordnat för att göra modellen klar, tydlig och |
| 213 |
|
konkret. Detta är nästan tvärt emot hur den mesta |
| 214 |
|
mjukvaran utvecklas.''}(Liddle, David. 1996)\\ |
| 215 |
|
Preece, Rogers and Sharp 2002 definierar en konceptuell |
| 216 |
|
modell som \emph{``en beskrivning av det föreslagna |
| 217 |
|
systemet i termer av integrerade idéer och koncept om |
| 218 |
|
vad det skall göra, bete sig samt se ut som, som skall |
| 219 |
|
förstås av användaren på rätt sätt''}\\ |
| 220 |
|
|
| 221 |
|
När man skapar en konceptuell modell så är det viktigt |
| 222 |
|
att man funderar över hur den slutliga produkten skall |
| 223 |
|
se ut, baserat på användarnas behov och krav. För att |
| 224 |
|
försäkra sig om att användaren kommer att förstå |
| 225 |
|
modellen så som den är tänkt är det viktigt att |
| 226 |
|
genomföra noggranna och iterativa tester. |
| 227 |
|
|
| 228 |
|
En viktig del av den konceptuella modellen är att |
| 229 |
|
besluta vad användaren skall göra när han använder |
| 230 |
|
produkten. Detta kan även kallas interaktions sätt |
| 231 |
|
dvs hur en användare skall få utföra jobbet. När man |
| 232 |
|
väljer interaktions sätt så får man även tänka över hur |
| 233 |
|
man skall interagera med produkten (programvaran), skall |
| 234 |
|
det vara med knappar, menyer, röstkommandon osv. |
| 235 |
|
|
| 236 |
|
När man har kommit så här långt med sin modell så är det |
| 237 |
|
dags att börja fundera över hur GUI't skall se ut, olika |
| 238 |
|
mönster, dess fördelar och nackdelar osv. Ju fler man |
| 239 |
|
provar med, och funderar över, ju större är chansen att |
| 240 |
|
produkten blir bra, och det är viktigt att man jobbar |
| 241 |
|
iterativt, och att man använder lite olika metoder, och |
| 242 |
|
data (gärna även utvecklare om det går) i dom olika |
| 243 |
|
iterationerna för att täcka in så mycket som möjligt. |
| 244 |
|
|
| 245 |
|
Basen i att konstruera en bra konceptuell modell är |
| 246 |
|
användaren, och det användaren skall kunna göra. |
| 247 |
|
|
| 248 |
|
Det finns ett otal olika konceptuella modeller, men vi |
| 249 |
|
kommer bara att ta upp dom två vanligaste. |
| 250 |
|
|
| 251 |
|
\subsection{Konceptuella modeller baserat på |
| 252 |
|
aktiviteter} |
| 253 |
|
|
| 254 |
|
De fyra vanligaste aktiviteterna användarna kommer att |
| 255 |
|
göra (sett ur MDI synpunkt) är: |
| 256 |
|
\begin{itemize} |
| 257 |
|
\item Instruera |
| 258 |
|
\item Konversera |
| 259 |
|
\item Manipulera och navigera |
| 260 |
|
\item Utforska och surfa %är surfa en bra översättning av browsing? |
| 261 |
|
\end{itemize} |
| 262 |
|
När man instruerar så förklarar man vad man vill att |
| 263 |
|
systemet skall göra, man ger order. Detta kan ske t.ex. |
| 264 |
|
med knappar, menyer osv.\\ |
| 265 |
|
När man konverserar så gör man det som man gör med en |
| 266 |
|
människa, antingen talar man till systemet med rösten, |
| 267 |
|
eller så skriver man, men man håller sig till ett |
| 268 |
|
normalt språk.\\ |
| 269 |
|
När man manipulerar och navigerar så har man en |
| 270 |
|
representation (av något) som man kan manipulera för att |
| 271 |
|
uppnå önskat resultat. Det är en klar fördel om |
| 272 |
|
representationen delar vissa egenskaper som användaren |
| 273 |
|
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 |
| 274 |
|
När man utforskar och surfar så är systemet utformat på |
| 275 |
|
ett sådant vis att användaren kan få information utan |
| 276 |
|
att behöva formulera frågor. |
| 277 |
|
|
| 278 |
|
Det är viktigt att förstå att man måste inte välja en av |
| 279 |
|
dessa, utan man kan välja flera om man känner för det, |
| 280 |
|
ofta kan man få ett resultat som blir närmare det |
| 281 |
|
användaren efterfrågar om man väljer att blanda flera |
| 282 |
|
aktiviteter. |
| 283 |
|
|
| 284 |
|
\subsubsection{Instruera} |
| 285 |
|
|
| 286 |
|
b |
| 287 |
|
|
| 288 |
|
\subsubsection{Konversera} |
| 289 |
|
|
| 290 |
|
a |
| 291 |
|
|
| 292 |
|
\subsubsection{Manipulera och navigera} |
| 293 |
|
|
| 294 |
|
a |
| 295 |
|
|
| 296 |
|
\subsubsection{Utforska och surfa} |
| 297 |
|
|
| 298 |
|
a |
| 299 |
|
|
| 300 |
|
\subsection{Konceptuella modeller baserat på objekt} |
| 301 |
|
|
| 302 |
|
När man utgår från ett objekt så tar man ett objekt som |
| 303 |
|
användaren kan relatera till, en bok, kaffe bryggare |
| 304 |
|
eller dyl. Och sedan så gör man sin modell så att den |
| 305 |
|
liknar det fysiska objektet. Det bör även gå att |
| 306 |
|
manipulera objektet på ett vis som liknar det fysiska |
| 307 |
|
objektet. Men man bör även tänka på vilka funktioner en |
| 308 |
|
användare kan tänkas önska utöver dom som finns i det |
| 309 |
|
verkliga objektet. Om man gör en ordebehandlare kan det |
| 310 |
|
vara väldigt trevligt om denna klarar av att t.ex. |
| 311 |
|
kompilera texten, rättstavning osv. |
| 312 |
|
|
| 313 |
|
\subsection{Interface metaforer} |
| 314 |
|
|
| 315 |
|
Denna metod går ut på att man tar och försöker efterlikna |
| 316 |
|
en välkänd metod, eller något som användaren känner igen |
| 317 |
|
för att manipulera systemet. Det handlar oftast om att man |
| 318 |
|
försöker abstrahera bort hur datorn gör, och istället |
| 319 |
|
likna det vi något som man känner igen. Dock så är boken |
| 320 |
|
vi har väldigt kritisk mot denna metoden att utveckla |
| 321 |
|
produkter, så vi tänker inte gå in på denna så djupt. Dock så |
| 322 |
|
tror vi att det borde vara en bra metod att iallafall |
| 323 |
|
fundera på, men man måste nog vara försiktig så att man |
| 324 |
|
inte gör ``hål'' i designen då man använder metaforer. |
| 325 |
|
|
| 326 |
|
\section{Värdet av MDI} |
| 327 |
|
|
| 328 |
|
Hela ämnet kanske kan verka abstrakt, och som något som bara tar |
| 329 |
|
upp tid att hålla på med, men faktum är att den tid (och de pengar) |
| 330 |
|
man lägger ner på MDI tjänar man igen ganska så fort. |
| 331 |
|
Dessutom så är det med hjälp av en mock-up lätt att tidigt |
| 332 |
|
fånga design fel, eller till och med logik fel, och ju |
| 333 |
|
tidigare man kan hitta fel, desto billigare blir dom att |
| 334 |
|
avhjälpa. |
| 335 |
|
|
| 336 |
|
En annan viktig sak att tänka på med MDI är att man kan på |
| 337 |
|
ett sätt använda det som en reklam tavla för sitt företag, |
| 338 |
|
om man gör en extraordinär lösning på något så kommer |
| 339 |
|
detta att sprida sig, men det kommer ännu mer att sprida |
| 340 |
|
sig om man gör dåliga MDI lösningar. Ett företag som |
| 341 |
|
tidigare har köpt en produkt som kanske är bra, bara det |
| 342 |
|
att de inte kan nyttja den kommer inte att köpa en produkt |
| 343 |
|
till av samma företag som den förra. |
| 344 |
|
|
| 345 |
|
Även om själva funtionaliteten i applikationen (eller vad |
| 346 |
|
det nu är som skapats) kanske är helt banbrytande och |
| 347 |
|
ruskigt innovativ så kanske inte produkten kan säljas |
| 348 |
|
ändå, på grund av att användarna helt enkelt inte klarar |
| 349 |
|
av att använda den för att gränssnittet är alldeles för |
| 350 |
|
klumpigt, långsamt och förvirrande. \emph{``Jag fattar inte varför man år 2000 ska behöva |
| 351 |
|
vänta ibland en sekund innan telefonen fattar att man |
| 352 |
|
vill hoppa ett steg till vänster i menyerna.''}(Mats |
| 353 |
|
Ekstrand, 2000-09-20 i en recension av Ericssons R310) |
| 354 |
|
Man brukar säga att utseendet inte spelar någon roll, |
| 355 |
|
men när det gäller MDI så spelar det stor roll. Det första |
| 356 |
|
man möts av när man får/köper en produkt är gränssnittet, |
| 357 |
|
må det så vara en knappsats, touchscreen eller ett flashigt GUI. |
| 358 |
|
|
| 359 |
\end{document} |
\end{document} |