/[cvs]/Kamel/HCI_text.tex
ViewVC logotype

Diff of /Kamel/HCI_text.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

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