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