/[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.6 by eax, Sun Mar 9 17:03:44 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 205  Line 205 
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}
209    
210            \emph{Det viktigaste är att designa användarens          \emph{Det viktigaste är att designa användarens
211            konceptuella modell. Allt annat skall ses som          konceptuella modell. Allt annat skall ses som
212            underordnat för att göra modellen klar, tydlig och          underordnat för att göra modellen klar, tydlig och
213            konkret. Detta är nästan tvärt emot hur den mesta          konkret. Detta är nästan tvärt emot hur den mesta
214            mjukvaran utvecklas.}(Liddle, David. 1996)\\          mjukvaran utvecklas.}(Liddle, David. 1996)\\
215            Preece, Rogers and Sharp 2002 definierar en konceptuell          Preece, Rogers and Sharp 2002 definierar en konceptuell
216            modell som \emph{en beskrivning av det föreslagna          modell som \emph{en beskrivning av det föreslagna
217            systemet i termer av integrerade idéer och koncept om          systemet i termer av integrerade idéer och koncept om
218            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
219            förstås av användaren på rätt sätt}\\          förstås av användaren på rätt sätt}\\
220    
221            När man skapar en konceptuell modell så är det viktigt          När man skapar en konceptuell modell så är det viktigt
222            att man funderar över hur den slutliga produkten skall          att man funderar över hur den slutliga produkten skall
223            se ut, baserat på användarnas behov och krav. För att          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å          försäkra sig om att användaren kommer att förstå
225            modellen så som den är tänkt är det viktigt att          modellen så som den är tänkt är det viktigt att
226            genomföra noggranna och iterativa tester.
227            \subsubsection{Konceptuella modeller baserat på  
228            aktiviteter}          En viktig del av den konceptuella modellen är att
229            besluta vad användaren skall göra när han använder
230            \subsubsection{Konceptuella modeller baserat på objekt}          produkten. Detta kan även kallas interaktions sätt
231            dvs hur en användare skall få utföra jobbet. När man
232        \section{Värdet av MDI}          väljer interaktions sätt så får man även tänka över hur
233            man skall interagera med produkten (programvaran), skall
234          Det kanske kan verka abstrakt, och som något som bara tar          det vara med knappar, menyer, röstkommandon osv.
235          tid att hålla på med MDI, och allt man kan göra inom detta  
236          (mock-ups osv), men faktum är att den tid (och de pengar)          När man har kommit så här långt med sin modell så är det
237          man lägger ner på MDI tjänar man igen ganska så fort.          dags att börja fundera över hur GUI't skall se ut, olika
238          Dessutom så är det med hjälp av en mock-up lätt att tidigt          mönster, dess fördelar och nackdelar osv. Ju fler man
239          fånga design fel, eller till och med logik fel, och ju          provar med, och funderar över, ju större är chansen att
240          tidigare man kan hitta fel, desto billigare blir dom att          produkten blir bra, och det är viktigt att man jobbar
241          avhjälpa.          iterativt, och att man använder lite olika metoder, och
242            data (gärna även utvecklare om det går) i dom olika
243          En annan viktig sak att tänka på med MDI är att man kan på          iterationerna för att täcka in så mycket som möjligt.
244          ett sätt använda det som en reklam tavla för sitt företag,  
245          om man gör en extraordinär lösning på något så kommer          Basen i att konstruera en bra konceptuell modell är
246          detta att sprida sig, men det kommer ännu mer att sprida          användaren, och det användaren skall kunna göra.
247          sig om man gör dåliga MDI lösningar. Ett företag som  
248          tidigare har köpt en produkt som kanske är bra, bara det          Det finns ett otal olika konceptuella modeller, men vi
249          att de inte kan nyttja den kommer inte att köpa en produkt          kommer bara att ta upp dom två vanligaste.
250          till av samma företag som den förra.  
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              a
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          Det kanske kan verka abstrakt, och som något som bara tar
329          tid att hålla på med MDI, och allt man kan göra inom detta
330          (mock-ups osv), men faktum är att den tid (och de pengar)
331          man lägger ner på MDI tjänar man igen ganska så fort.
332          Dessutom så är det med hjälp av en mock-up lätt att tidigt
333          fånga design fel, eller till och med logik fel, och ju
334          tidigare man kan hitta fel, desto billigare blir dom att
335          avhjälpa.
336    
337          En annan viktig sak att tänka på med MDI är att man kan på
338          ett sätt använda det som en reklam tavla för sitt företag,
339          om man gör en extraordinär lösning på något så kommer
340          detta att sprida sig, men det kommer ännu mer att sprida
341          sig om man gör dåliga MDI lösningar. Ett företag som
342          tidigare har köpt en produkt som kanske är bra, bara det
343          att de inte kan nyttja den kommer inte att köpa en produkt
344          till av samma företag som den förra.
345    
346    
347  \end{document}  \end{document}

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

root@recompile.se
ViewVC Help
Powered by ViewVC 1.1.26