/[cvs]/Kamel/HCI_text.tex

Diff of /Kamel/HCI_text.tex

Parent Directory | Revision Log | View Patch Patch

-revision 1.1 by jontas,
Sun Mar  9 12:35:03 2003 UTC
+revision 1.9 by eax,
Sun Mar  9 17:24:48 2003 UTC
 Line 11
      \large{av}\\
      \LARGE{Jonas Petersson \& Mathias Börjesson}\\\vspace{.4in}
      \large{Institutionen för programvaruteknik och datavetenskap\\
-     Blekinge Tekniska Högskola\\\vspace{.03in}
+     Blekinge Tekniska Högskola\\\vspace{.03in}}
      \texttt{e-mail:}\\
-     \emph{jopd01@student.bth.se}}\\
+     \emph{jopd01@student.bth.se}\\
      \emph{tb00mbo@student.bth.se}\\
    \end{centering}
    \newpage
 Line 205
          En annan sak som är viktig, mycket viktig med Interaktions
          design är att den sker iterativt.
-         \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.
+         \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
+         genomföra noggranna och iterativa tester.
+         En viktig del av den konceptuella modellen är att
+         besluta vad användaren skall göra när han använder
+         produkten. Detta kan även kallas interaktions sätt
+         dvs hur en användare skall få utföra jobbet. När man
+         väljer interaktions sätt så får man även tänka över hur
+         man skall interagera med produkten (programvaran), skall
+         det vara med knappar, menyer, röstkommandon osv.
+         När man har kommit så här långt med sin modell så är det
+         dags att börja fundera över hur GUI't skall se ut, olika
+         mönster, dess fördelar och nackdelar osv. Ju fler man
+         provar med, och funderar över, ju större är chansen att
+         produkten blir bra, och det är viktigt att man jobbar
+         iterativt, och att man använder lite olika metoder, och
+         data (gärna även utvecklare om det går) i dom olika
+         iterationerna för att täcka in så mycket som möjligt.
+         Basen i att konstruera en bra konceptuell modell är
+         användaren, och det användaren skall kunna göra.
+         Det finns ett otal olika konceptuella modeller, men vi
+         kommer bara att ta upp dom två vanligaste.
+         \subsection{Konceptuella modeller baserat på
+         aktiviteter}
+           De fyra vanligaste aktiviteterna användarna kommer att
+           göra (sett ur MDI synpunkt) är:
+           \begin{itemize}
+             \item Instruera
+             \item Konversera
+             \item Manipulera och navigera
+             \item Utforska och surfa %är surfa en bra översättning av browsing?
+           \end{itemize}
+           När man instruerar så förklarar man vad man vill att
+           systemet skall göra, man ger order. Detta kan ske t.ex.
+           med knappar, menyer osv.\\
+           När man konverserar så gör man det som man gör med en
+           människa, antingen talar man till systemet med rösten,
+           eller så skriver man, men man håller sig till ett
+           normalt språk.\\
+           När man manipulerar och navigerar så har man en
+           representation (av något) som man kan manipulera för att
+           uppnå önskat resultat. Det är en klar fördel om
+           representationen delar vissa egenskaper som användaren
+           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
+           När man utforskar och surfar så är systemet utformat på
+           ett sådant vis att användaren kan få information utan
+           att behöva formulera frågor.
+           Det är viktigt att förstå att man måste inte välja en av
+           dessa, utan man kan välja flera om man känner för det,
+           ofta kan man få ett resultat som blir närmare det
+           användaren efterfrågar om man väljer att blanda flera
+           aktiviteter.
+         \subsubsection{Instruera}
+           b
+         \subsubsection{Konversera}
+           a
+         \subsubsection{Manipulera och navigera}
+           a
+         \subsubsection{Utforska och surfa}
+           a
+         \subsection{Konceptuella modeller baserat på objekt}
+           När man utgår från ett objekt så tar man ett objekt som
+           användaren kan relatera till, en bok, kaffe bryggare
+           eller dyl. Och sedan så gör man sin modell så att den
+           liknar det fysiska objektet. Det bör även gå att
+           manipulera objektet på ett vis som liknar det fysiska
+           objektet. Men man bör även tänka på vilka funktioner en
+           användare kan tänkas önska utöver dom som finns i det
+           verkliga objektet. Om man gör en ordebehandlare kan det
+           vara väldigt trevligt om denna klarar av att t.ex.
+           kompilera texten, rättstavning osv.
+       \subsection{Interface metaforer}
+         Denna metod går ut på att man tar och försöker efterlikna
+         en välkänd metod, eller något som användaren känner igen
+         för att manipulera systemet. Det handlar oftast om att man
+         försöker abstrahera bort hur datorn gör, och istället
+         likna det vi något som man känner igen. Dock så är boken
+         vi har väldigt kritisk mot denna metoden att utveckla
+         produkter, så vi tänker inte gå in på denna så djupt. Dock så
+         tror vi att det borde vara en bra metod att iallafall
+         fundera på, men man måste nog vara försiktig så att man
+         inte gör ''hål`` i designen då man använder metaforer.
+     \section{Värdet av MDI}
+       Hela ämnet kanske kan verka abstrakt, och som något som bara tar
+       upp tid att hålla på med, 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.
+       Även om själva funtionaliteten i applikationen (eller vad
+       det nu är som skapats) kanske är helt banbrytande och
+       ruskigt innovativ så kanske inte produkten kan säljas
+       ändå, på grund av att användarna helt enkelt inte klarar
+       av att använda den för att gränssnittet är alldeles för
+       klumpigt, långsamt och förvirrande. \emph{``Jag fattar inte varför man år 2000 ska behöva
+       vänta ibland en sekund innan telefonen fattar att man
+       vill hoppa ett steg till vänster i menyerna.''}(Mats
+       Ekstrand, 2000-09-20 i en recension av Ericssons R310)
+       Man brukar säga att utseendet inte spelar någon roll,
+       men när det gäller MDI så spelar det stor roll. Det första
+       man möts av när man får/köper en produkt är gränssnittet,
+       må det så vara en knappsats, touchscreen eller ett flashigt GUI.
  \end{document}

 Legend:



Removed from v.1.1
 


changed lines


 
Added in v.1.9
 Legend:



Removed from v.1.1
 


changed lines


 
Added in v.1.9
-Removed from v.1.1
+Added in v.1.9

root@recompile.se	ViewVC Help
Powered by ViewVC 1.1.26