/[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.4 by eax, Sun Mar 9 16:40:50 2003 UTC revision 1.18 by jontas, Thu Apr 10 08:24:19 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            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
# Line 105  Line 107 
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)              passande material, och beroende på vilken information
125            %Uhm, va?              man har om den färdiga produkten så görs den med den
126            ''dynamiskt statiska``              detaljnivå som är passande. Denna mock-up används sedan
127            vilket kan låta som en motsägelse, men vad vi menar med              för att testa om konceptet man har håller, och hur det
128            det är att den görs dynamisk är att det går att byta              skall implementeras. En mock-up behöver inte vara för en
129            detaljer i mock-upen för att symbolisera interaktion. En              programvara, utan kan lika gärna vara för en fysisk
130            annan fördel med en mock-up framför en fungerade              produkt, men i kursen har vi inriktat oss på programvara
131            prototyp är att en mock-up är gjord av ett billigt              då detta är det intressanta för oss. Då man skapat en
132            material, och går snabbt att göra och göra om då man inser att              mock-up så tar man denna, och testar på en eller flera
133            lösningen man har inte håller, utan behöver göras om för              tilltänkta användare, och lyssnar på deras åsikter om
134            att passa användaren och hans behov.              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    
267          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,
268          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örlust, då kommer användaren att ta det lugnt och          förlust, då kommer användaren att ta det lugnt och
270          försiktigt, men trots detta kommer användaren att göra          försiktigt, men trots detta kommer användaren att göra
271          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
272          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
273          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
274          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
275          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
276          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
# Line 175  Line 279 
279          \subsection{Vikten av att känna igen sig i ett program}          \subsection{Vikten av att känna igen sig i ett program}
280    
281            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
282            är att detta ger en ``säkerhets känsla'' i programmet,            är att detta ger en ``säkerhetskänsla'' i programmet,
283            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
284            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
285            program där man kan spara sitt arbete, öppna en fil med            program där man kan spara sitt arbete, öppna en fil med
286            gammalt arbete osv har detta i en meny märk ``Arkiv'' på            gammalt arbete osv har detta i en meny märk ``Arkiv'' på
287            svenska, kommandon som kopiera, klistra in, gör om osv.            svenska, kommandon som kopiera, klistra in, gör om osv.
288            ligger under en meny ``redigera''. Detta gör att en            ligger under en meny ``redigera''. Detta gör att en
289            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
290            nyttjat programmet tidigare.            nyttjat programmet tidigare.
291    
292        \section{Interaktions Design}        \section{Interaktionsdesign}
293    
294          När man pratar om interaktions design så menar man att          När man pratar om interaktionsdesign så menar man att
295          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
296          inte så mycket bryr sig om tekniken bakom.          inte så mycket bryr sig om tekniken bakom.
297    
298          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å
# Line 207  Line 311 
311          produkten är hemligstämplad och det finns andra aktörer på          produkten är hemligstämplad och det finns andra aktörer på
312          marknaden som jobbar med samma område. Att då låta vanliga          marknaden som jobbar med samma område. Att då låta vanliga
313          användare komma i kontakt med sin design innebär att hemlig          användare komma i kontakt med sin design innebär att hemlig
314          information kan spridas till konkurrenterna om de nu råkas          information kan spridas till konkurrenterna om de nu råkar
315          få tag på samma testpersoner.          få tag på samma testpersoner, och fråga ut dessa.
316    
317          En annan sak som är viktig, mycket viktig med Interaktions          En annan sak som är viktig, mycket viktig med Interaktionsdesign
318          design är att den sker iterativt.          är att den sker iterativt. Detta för att om det
319            inte sker iterativt så kan man inte dra maximalt värde av
320            den. Det finns ju en risk att om man gör en ändring
321            som skall lösa ett problem, introducerar man två nya, och om
322            processen inte sker iterativt så finns det ingen möjlighet
323            att finna detta förrän det kanske är försent, och då kan det
324            kosta väldigt mycket mer att åtgärda.
325    
326        \section{Konceptuella modeller}        \section{Konceptuella modeller}
327    
328            En konceptuell modell är en beskrivning av systemet, i
329            form av tankar och idéer om hur systemet skall verka och
330            se ut, och att det kan förstås av användaren.
331    
332          \emph{``Det viktigaste är att designa användarens          \emph{``Det viktigaste är att designa användarens
333          konceptuella modell. Allt annat skall ses som          konceptuella modell. Allt annat skall ses som
334          underordnat för att göra modellen klar, tydlig och          underordnat för att göra modellen klar, tydlig och
335          konkret. Detta är nästan tvärt emot hur den mesta          konkret. Detta är nästan tvärt emot hur den mesta
336          mjukvaran utvecklas.''}(Liddle, David. 1996)\\          mjukvaran utvecklas.''}(Liddle, David. 1996)
337    
338    
339          Preece, Rogers and Sharp 2002 definierar en konceptuell          Preece, Rogers and Sharp 2002 definierar en konceptuell
340          modell som \emph{``en beskrivning av det föreslagna          modell som \emph{``en beskrivning av det föreslagna
341          systemet i termer av integrerade idéer och koncept om          systemet i termer av integrerade idéer och koncept om
342          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
343          förstås av användaren på rätt sätt''}\\          förstås av användaren på rätt sätt''}
344    
345          När man skapar en konceptuell modell så är det viktigt          När man skapar en konceptuell modell så är det viktigt
346          att man funderar över hur den slutliga produkten skall          att man funderar över hur den slutliga produkten skall
# Line 234  Line 350 
350          genomföra noggranna och iterativa tester.          genomföra noggranna och iterativa tester.
351    
352          En viktig del av den konceptuella modellen är att          En viktig del av den konceptuella modellen är att
353          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
354          produkten. Detta kan även kallas interaktions sätt          produkten. Detta kan även kallas interaktionssätt
355          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
356          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
357          man skall interagera med produkten (programvaran), skall          man skall interagera med produkten (programvaran), skall
358          det vara med knappar, menyer, röstkommandon osv.          det vara med knappar, menyer, röstkommandon osv.
359    
# Line 245  Line 361 
361          dags att börja fundera över hur GUI't skall se ut, olika          dags att börja fundera över hur GUI't skall se ut, olika
362          mönster, dess fördelar och nackdelar osv. Ju fler man          mönster, dess fördelar och nackdelar osv. Ju fler man
363          provar med, och funderar över, ju större är chansen att          provar med, och funderar över, ju större är chansen att
364          produkten blir bra. Det är viktigt att man jobbar          produkten blir bra, och det är viktigt att man jobbar
365          iterativt, att man använder lite olika metoder och          iterativt, och att man använder lite olika metoder, och
366          data (gärna även utvecklare om det går) i dom olika          data (gärna även utvecklare om det går) i dom olika
367          iterationerna för att täcka in så mycket som möjligt.          iterationerna för att täcka in så mycket som möjligt.
368    
# Line 265  Line 381 
381              \item Instruera              \item Instruera
382              \item Konversera              \item Konversera
383              \item Manipulera och navigera              \item Manipulera och navigera
384              \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?
385            \end{itemize}            \end{itemize}
386            När man instruerar så förklarar man vad man vill att            När man instruerar så förklarar man vad man vill att
387            systemet skall göra, man ger order. Detta kan ske t.ex.            systemet skall göra, man ger order. Detta kan ske t.ex.
388            med knappar, menyer osv.\\            med knappar, menyer osv.
389    
390            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
391            människa, antingen talar man till systemet med rösten,            människa, antingen talar man till systemet med rösten,
392            eller så skriver man, men man håller sig till ett            eller så skriver man, men man håller sig till ett
393            normalt språk.\\            normalt språk.
394    
395            När man manipulerar och navigerar så har man en            När man manipulerar och navigerar så har man en
396            representation (av något) som man kan manipulera för att            representation (av något) som man kan manipulera för att
397            uppnå önskat resultat. Det är en klar fördel om            uppnå önskat resultat. Det är en klar fördel om
398            representationen delar vissa egenskaper som användaren            representationen delar vissa egenskaper som användaren
399            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
400    
401            När man utforskar och surfar så är systemet utformat på            När man utforskar och surfar så är systemet utformat på
402            ett sådant vis att användaren kan få information utan            ett sådant vis att användaren kan få information utan
403            att behöva formulera frågor.            att behöva formulera frågor.
# Line 288  Line 407 
407            ofta kan man få ett resultat som blir närmare det            ofta kan man få ett resultat som blir närmare det
408            användaren efterfrågar om man väljer att blanda flera            användaren efterfrågar om man väljer att blanda flera
409            aktiviteter.            aktiviteter.
   
410          \subsubsection{Instruera}          \subsubsection{Instruera}
411    
412            a            Detta är en relativt enkel modell att bygga upp, även om
413              det kan vara krångligt att bygga upp den på ett bra
414              sätt. Antingen kan man använda knappar, menyer osv för
415              att ge instruktioner, eller så kan man använda
416              textsträngar. En klar nackdel med denna modellen är att
417              om kommandona är långa (eller krångliga) kommer
418              användaren att glömma bort det, och behöva extra hjälp
419              när han/hon skall nyttja denna. Detta är ett vanligt
420              mönster, och återfinns i flera produkter på ett sätt
421              eller ett annat.
422    
423          \subsubsection{Konversera}          \subsubsection{Konversera}
424    
425            a            Denna metoden är vanligast om det handlar om någon form
426              av expert system, eller sökfunktioner. En klar fördel
427              med att nyttja detta mönster är att även en människa med
428              små kunskaper inom både data, och ämnet som experten kan
429              kan ställa frågor, och få hjälp. En nackdel med detta
430              mönstret är att om användaren ställer frågor på ett sätt
431              som man inte har tänkt sig, eller som inte finns med i
432              informations basen så kan svaren till användaren bli
433              helt uppåt väggarna om man inte är noga med hur man
434              behandlar indatan.
435    
436          \subsubsection{Manipulera och navigera}          \subsubsection{Manipulera och navigera}
437    
438            a          Visualisering måste innehålla mycket mer än att bara tillåta folk att ``se''
439            information. Dom måste också kunna manipulera och fokusera sig på vad som är relevant
440          \subsubsection{Utforska och surfa}          och känna igen det för att skapa ny information. Funktioner som hypertext (t.ex. HTML)
441            har blivit en dominant metod för att länka samman dokument, vilket tillåter användaren
442            a          att navigera sig genom dokument på ett väldigt dynamiskt och personligt sätt.
443    
444          \subsection{Konceptuella modeller baserat på objekt}        \subsubsection{Utforska och ögna igenom}
445    
446            a          Hypertext är
447            en smidig metod för att söka efter information då man
448        \section{Värdet av MDI}          kan länka vidare till djupare information då en
449            användare hittar något som intresserar. Nackdelen med
450          Hela ämnet kanske kan verka abstrakt, och som något som bara tar          denna metod är att det kan bli grötigt, och att det
451          upp tid att hålla på med, men faktum är att den tid (och de pengar)          kan vara svårt att komma igång om man inte riktigt vet
452          man lägger ner på MDI tjänar man igen ganska så fort.          vad man söker efter. Det ger däremot användaren en möjlighet
453          Dessutom så är det med hjälp av en mock-up lätt att tidigt          att hoppa runt på ett snabbt sätt mellan dokumenten tills
454          fånga design fel, eller till och med logik fel, och ju          han/hon hittar det som söktes.
455          tidigare man kan hitta fel, desto billigare blir dom att  
456          avhjälpa.        \subsection{Konceptuella modeller baserat på objekt}
457    
458          En annan viktig sak att tänka på med MDI är att man kan på          När man utgår från ett objekt så tar man ett objekt som
459          ett sätt använda det som en reklam tavla för sitt företag,          användaren kan relatera till, en bok, kaffe bryggare
460          om man gör en extraordinär lösning på något så kommer          eller dyl. Och sedan så gör man sin modell så att den
461          detta att sprida sig, men det kommer ännu mer att sprida          liknar det fysiska objektet. Det bör även gå att
462          sig om man gör dåliga MDI lösningar. Ett företag som          manipulera objektet på ett vis som liknar det fysiska
463          tidigare har köpt en produkt som kanske är bra, bara det          objektet. Men man bör även tänka på vilka funktioner en
464          att de inte kan nyttja den kommer inte att köpa en produkt          användare kan tänkas önska utöver dom som finns i det
465          till av samma företag som den förra.          verkliga objektet. Om man gör en ordebehandlare kan det
466            vara väldigt trevligt om denna klarar av att t.ex.
467          Även om själva funtionaliteten i applikationen (eller vad          kompilera texten, rättstavning osv.
468          det nu är som skapats) kanske är helt banbrytande och  
469          ruskigt innovativ så kanske inte produkten kan säljas        \subsection{Interface-metaforer}
470          ändå, på grund av att användarna helt enkelt inte klarar  
471          av att använda den för att gränssnittet är alldeles för          Denna metod går ut på att man tar och försöker efterlikna
472          klumpigt, långsamt och förvirrande. \emph{``Jag fattar inte varför man år 2000 ska behöva          en välkänd metod, eller något som användaren känner igen
473          vänta ibland en sekund innan telefonen fattar att man          för att manipulera systemet. Det handlar oftast om att man
474          vill hoppa ett steg till vänster i menyerna.''}(Mats          försöker abstrahera bort hur datorn gör, och istället
475          Ekstrand, 2000-09-20 i en recension av Ericssons R310)          likna det vid något som man känner igen. Då boken är
476          Man brukar säga att utseendet inte spelar någon roll,          väldigt kritisk mot denna metoden att utveckla
477          men när det gäller MDI så spelar det stor roll. Det första          produkter, så tänker vi inte gå in på denna så djupt. Däremot så
478          man möts av när man får/köper en produkt är gränssnittet,          tror vi att det borde vara en bra metod att iallafall
479          må det så vara en knappsats, touchscreen eller ett flashigt GUI.          fundera på, men man måste nog vara försiktig så att man
480            inte gör ``hål'' i designen då man använder metaforer.
481    
482        \section{Värdet av MDI}
483    
484          Hela ämnet kanske kan verka abstrakt, och som något som bara tar
485          upp tid att hålla på med, men faktum är att den tid (och de pengar)
486          man lägger ner på MDI tjänar man igen ganska så fort.
487          Dessutom så är det med hjälp av en mock-up lätt att tidigt
488          fånga designfel, eller till och med logikfel, och ju
489          tidigare man kan hitta fel, desto billigare blir dom att
490          avhjälpa.
491    
492          En annan viktig sak att tänka på med MDI är att man kan på
493          ett sätt använda det som en reklamtavla för sitt företag,
494          om man gör en extraordinär lösning på något så kommer
495          detta att sprida sig, men det kommer ännu mer att sprida
496          sig om man gör dåliga MDI-lösningar. Ett företag som
497          tidigare har köpt en produkt som kanske är bra, bara det
498          att de inte kan nyttja den kommer inte att köpa en produkt
499          till av samma företag som den förra.
500    
501          Även om själva funtionaliteten i applikationen (eller vad
502          det nu är som skapats) kanske är helt banbrytande och
503          ruskigt innovativ så kanske inte produkten kan säljas
504          ändå, på grund av att användarna helt enkelt inte klarar
505          av att använda den för att gränssnittet är alldeles för
506          klumpigt, långsamt och förvirrande. \emph{``Jag fattar inte varför man år 2000 ska behöva
507          vänta ibland en sekund innan telefonen fattar att man
508          vill hoppa ett steg till vänster i menyerna.''}(Mats
509          Ekstrand, 2000-09-20 i en recension av Ericssons R310)
510          Man brukar säga att utseendet inte spelar någon roll,
511          men när det gäller MDI så spelar det stor roll. Det första
512          man möts av när man får/köper en produkt är gränssnittet,
513          må det så vara en knappsats, touchscreen eller ett flashigt GUI.
514    
515  \end{document}  \end{document}
Legend:
Removed from v.1.4  
changed lines
  Added in v.1.18
root@recompile.se
 ViewVC Help
Powered by ViewVC 1.1.26