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

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.10

root@recompile.se
ViewVC Help
Powered by ViewVC 1.1.26