/[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.3 by eax, Sun Mar 9 15:19:43 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}
# Line 22  Line 22 
22    \onehalfspacing    \onehalfspacing
23      \section{Kurserfarenheter} %Är detta ett bra namn?      \section{Kurserfarenheter} %Är detta ett bra namn?
24    
25        Detta kapitel kommer vi att ta upp delar av det vi har gått igenom        Detta kapitel kommer att ta delar av det vi har gått igenom
26        i kursen, samt försöka belysa vissa av dem.        i kursen, samt försöka belysa vissa av dem.
27    
28          \subsection{Användandet av en minsta gemensamma          \subsection{Användandet av en minsta gemensamma
# 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, det 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)            \subsubsection{Mock-up}
124            %Uhm, va?  
125            ''dynamiskt statiska``              En mock-up är en form av prototyp. Den görs i ett
126            vilket kan låta som en motsägelse, men vad vi menar med              passande material, och beroende på vilken information
127            det är att den görs dynamisk är att det går att byta              man har om den färdiga produkten så görs den med den
128            detaljer i mock-upen för att symbolisera interaktion. En              detaljnivå som är passande. Denna mock-up används sedan
129            annan fördel med en mock-up framför en fungerade              för att testa om konceptet man har håller, och hur det
130            prototyp är att en mock-up är gjord av ett billigt              skall implementeras. En mock-up behöver inte vara för en
131            material, och går snabbt att göra och göra om då man inser att              programvara, utan kan lika gärna vara för en fysisk
132            lösningen man har inte håller, utan behöver göras om för              produkt, men i kursen har vi inriktat oss på programvara
133            att passa användaren och hans behov.              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 175  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 200  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            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            processen inte sker iterativt så finns det ingen möjlighet
324            att finna detta fören det har gått en lång tid, och det
325            kostar mer att åtgärda.
326    
327        \section{Konceptuella modeller}        \section{Konceptuella modeller}
328    
329          \emph{Det viktigaste är att designa användarens          En konceptuell modell är en beskrivning av systemet, i
330            form av tankar och idéer om hur systemet skall verka och
331            se ut, och att det kan förstås av användaren.
332    
333            \emph{``Det viktigaste är att designa användarens
334          konceptuella modell. Allt annat skall ses som          konceptuella modell. Allt annat skall ses som
335          underordnat för att göra modellen klar, tydlig och          underordnat för att göra modellen klar, tydlig och
336          konkret. Detta är nästan tvärt emot hur den mesta          konkret. Detta är nästan tvärt emot hur den mesta
337          mjukvaran utvecklas.}(Liddle, David. 1996)\\          mjukvaran utvecklas.''}(Liddle, David. 1996)\\
338          Preece, Rogers and Sharp 2002 definierar en konceptuell          Preece, Rogers and Sharp 2002 definierar en konceptuell
339          modell som \emph{en beskrivning av det föreslagna          modell som \emph{``en beskrivning av det föreslagna
340          systemet i termer av integrerade idéer och koncept om          systemet i termer av integrerade idéer och koncept om
341          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
342          förstås av användaren på rätt sätt}\\          förstås av användaren på rätt sätt''}
343    
344          När man skapar en konceptuell modell så är det viktigt          När man skapar en konceptuell modell så är det viktigt
345          att man funderar över hur den slutliga produkten skall          att man funderar över hur den slutliga produkten skall
# Line 229  Line 350 
350    
351          En viktig del av den konceptuella modellen är att          En viktig del av den konceptuella modellen är att
352          besluta vad användaren skall göra när han använder          besluta vad användaren skall göra när han använder
353          produkten. Detta kan även kallas interaktions sätt          produkten. Detta kan även kallas interaktionssätt
354          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
355          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
356          man skall interagera med produkten (programvaran), skall          man skall interagera med produkten (programvaran), skall
357          det vara med knappar, menyer, röstkommandon osv.          det vara med knappar, menyer, röstkommandon osv.
358    
# Line 259  Line 380 
380              \item Instruera              \item Instruera
381              \item Konversera              \item Konversera
382              \item Manipulera och navigera              \item Manipulera och navigera
383              \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?
384            \end{itemize}            \end{itemize}
385            När man instruerar så förklarar man vad man vill att            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.            systemet skall göra, man ger order. Detta kan ske t.ex.
387            med knappar, menyer osv.\\            med knappar, menyer osv.
388    
389            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
390            människa, antingen talar man till systemet med rösten,            människa, antingen talar man till systemet med rösten,
391            eller så skriver man, men man håller sig till ett            eller så skriver man, men man håller sig till ett
392            normalt språk.\\            normalt språk.
393    
394            När man manipulerar och navigerar så har man en            När man manipulerar och navigerar så har man en
395            representation (av något) som man kan manipulera för att            representation (av något) som man kan manipulera för att
396            uppnå önskat resultat. Det är en klar fördel om            uppnå önskat resultat. Det är en klar fördel om
397            representationen delar vissa egenskaper som användaren            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            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å            När man utforskar och surfar så är systemet utformat på
401            ett sådant vis att användaren kan få information utan            ett sådant vis att användaren kan få information utan
402            att behöva formulera frågor.            att behöva formulera frågor.
# Line 282  Line 406 
406            ofta kan man få ett resultat som blir närmare det            ofta kan man få ett resultat som blir närmare det
407            användaren efterfrågar om man väljer att blanda flera            användaren efterfrågar om man väljer att blanda flera
408            aktiviteter.            aktiviteter.
   
409          \subsubsection{Instruera}          \subsubsection{Instruera}
410    
411            a            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}          \subsubsection{Konversera}
423    
424            a            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}          \subsubsection{Manipulera och navigera}
436    
437            a          Visualisering måste innehålla mycket mer än att bara tillåta folk att ``se''
438  >>>>>>> 1.2          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          \subsubsection{Utforska och surfa}          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            a  
443          \subsubsection{Utforska och ögna igenom}
444          \subsection{Konceptuella modeller baserat på objekt}  
445            Hypertext är
446            a          en smidig metod för att söka efter information då man
447            kan länka vidare till djupare information då en
448        \section{Värdet av MDI}          användare hittar något som intresserar. Nackdelen med
449            denna metod är att det kan bli grötigt, och att det
450          Det kanske kan verka abstrakt, och som något som bara tar          kan vara svårt att komma igång om man inte riktigt vet
451          tid att hålla på med MDI, och allt man kan göra inom detta          vad man söker efter. Det ger däremot användaren en möjlighet
452          (mock-ups osv), men faktum är att den tid (och de pengar)          att hoppa runt på ett snabbt sätt mellan dokumenten tills
453          man lägger ner på MDI tjänar man igen ganska så fort.          han/hon hittar det som söktes.
454          Dessutom så är det med hjälp av en mock-up lätt att tidigt  
455          fånga design fel, eller till och med logik fel, och ju        \subsection{Konceptuella modeller baserat på objekt}
456          tidigare man kan hitta fel, desto billigare blir dom att  
457          avhjälpa.          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          En annan viktig sak att tänka på med MDI är att man kan på          eller dyl. Och sedan så gör man sin modell så att den
460          ett sätt använda det som en reklam tavla för sitt företag,          liknar det fysiska objektet. Det bör även gå att
461          om man gör en extraordinär lösning på något så kommer          manipulera objektet på ett vis som liknar det fysiska
462          detta att sprida sig, men det kommer ännu mer att sprida          objektet. Men man bör även tänka på vilka funktioner en
463          sig om man gör dåliga MDI lösningar. Ett företag som          användare kan tänkas önska utöver dom som finns i det
464          tidigare har köpt en produkt som kanske är bra, bara det          verkliga objektet. Om man gör en ordebehandlare kan det
465          att de inte kan nyttja den kommer inte att köpa en produkt          vara väldigt trevligt om denna klarar av att t.ex.
466          till av samma företag som den förra.          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.3  
changed lines
  Added in v.1.16
root@recompile.se
 ViewVC Help
Powered by ViewVC 1.1.26