--- Kamel/HCI_text.tex	2003/03/18 17:50:50	1.15
+++ Kamel/HCI_text.tex	2003/04/10 08:24:19	1.18
@@ -7,12 +7,12 @@
   \begin{centering}
     \huge{HCI Text}\\
     \huge{DVC002: Människa-datorinteraktion (MDI), 5p}\\
-    \huge{2003, period 1}\\\vspace{.3in}
+    \huge{Läsåret 2003-2004, läsperiod 1}\\\vspace{.3in}
     \large{av}\\
     \LARGE{Jonas Petersson \& Mathias Börjesson}\\\vspace{.4in}
     \large{Institutionen för programvaruteknik och datavetenskap\\
     Blekinge Tekniska Högskola\\\vspace{.03in}}
-    \texttt{e-mail:}\\
+    \texttt{e-post:}\\
     \emph{jopd01@student.bth.se}\\
     \emph{tb00mbo@student.bth.se}\\
   \end{centering}
@@ -60,27 +60,29 @@
           Detta kan lätt tyckas att detta inte har med MDI att
           göra, men vi kommer att förklara detta lite senare.
           Tanken med att använda diverse script är främst att
-          abstrahera krångliga kommandon (eller om man vill långa)
+          kristallisera krångliga kommandon (eller om man vill långa)
           från användaren, och istället bara använda ett kort
           kommando. Detta innebär att det blir enklare att hålla
           ordning på det man utvecklar då det i scriptet går
           snabbt att skriva ner de kommandon som ser till att
           källfilerna ligger i en katalog, de kompilerade
-          programmet i en, och hjälp filerna i en tredje (om
+          programmen i en, och hjälpfilerna i en tredje (om
           programmeringsspråket stödjer detta (t.ex. Java API).
 
-          %Eller är det svaret vi skall skjuta in?
+
           Men hur är detta något som är intressant ur en MDI
           synpunkt?\\
           Jo, tanken var ju att ta alla dom krångliga kommandona,
           och helt enkelt byta ut mot ett kort script. Krasst sett
           är detta grunden för MDI. Att ta något krångligt
-          kommando, och byta ut mot ett lättare.
+          kommando, och byta ut mot ett lättare. Eller kanske att på
+          annat sätt underlätta användandet av en produkt vilket är
+          det man bör sikta mot.
 
-        \subsection{GUI design mönster}
+        \subsection{GUI designmönster}
 
           GUI står för Graphical User Interface, eller grafiskt
-          användar gränsnitt på svenska. Ett GUI kan se ut på
+          användargränsnitt på svenska. Ett GUI kan se ut på
           ett (nästan) oändligt antal sätt, men alla dessa följer
           ett eller flera mönster för hur man använder dessa. Då
           dessa mönster upprepas så är det viktigt för oss som
@@ -108,7 +110,7 @@
           Det finns flera olika sätt att demonstrera en idé, men
           den bästa brukar vara att kunna visa upp något. Det kan
           vara bra att kunna berätta om idéen man har, men om man
-          kan ge kunden något han kan se, ta på, och till viss del
+          kan ge kunden något han eller hon kan se, ta på, och till viss del
           kunna interagera med så är det mycket enklare, dels att
           sälja idén, dels att upptäcka fel och brister i den.
 
@@ -130,8 +132,8 @@
             mock-up så tar man denna, och testar på en eller flera
             tilltänkta användare, och lyssnar på deras åsikter om
             den. När man har kommit förbi detta stadiet så kan man
-            bygga en lite mera avancerad prototyp för att vidare
-            utveckla produkten. En mock-up är vanligtvis (eller
+            bygga en lite mera avancerad prototyp för att vidareutveckla
+            produkten. En mock-up är vanligtvis (eller
             i alla fall dom vi har gjort) ``dynamiskt statiska''
             vilket kan låta som en motsägelse, men vad vi menar med
             det är att den görs dynamisk är att det går att byta
@@ -140,14 +142,14 @@
             prototyp är att en mock-up är gjord av ett billigt
             material, och går snabbt att göra och göra om då man inser att
             lösningen man har inte håller, utan behöver göras om för
-            att passa användaren och hans behov.
+            att passa användaren och dess behov.
 
-          \subsubsection{Lågnivå prototyper}
+          \subsubsection{Lågnivåprototyper}
 
-            En lågnivå prototyp är en enkel prototyp, som snarare
-            syftar till att visa den grundläggande idéen. Den kan
-            vara en mock-up, eller något annat. En lågnivå
-            prototyp är något som går relativt snabbt att slänga
+            En lågnivåprototyp är en enkel prototyp, som snarare
+            syftar till att visa upp den grundläggande idéen. Den kan
+            vara en mock-up, eller något annat. En lågnivåprototyp
+            är något som går relativt snabbt att slänga
             ihop, och brukar vanligtvis vara ganska så billig. Den
             kan vara i ett material som är väldigt långt från den
             färdiga produkten (en mock-up på en kartongbit är ju
@@ -155,25 +157,26 @@
             vi är ganska säkra på att man kan komma ännu längre om
             man bara vill).
 
-            Lågnivå prototypen använder man för att demonstrera en
+            Lågnivåprototypen använder man för att demonstrera
             idéer, koncept och dyl. Den kan inte till fullo
             användas för att fånga alla krav, men i samverkan med
             andra metoder (som t.ex. intervjuer, användningsfall
             osv) kan man komma nära nog i många fall.
 
-          \subsubsection{Högnivå prototyper}
+          \subsubsection{Högnivåprototyper}
 
-            En högnivå prototyp är en ''bättre`` prototyp, oftast
-            så ligger den närmare den färdiga produkten än lågnivå
-            prototypen till utseende, och material (där det
-            finns). Det som främst skiljer en högnivå prototyp
+            En högnivåprototyp är en ''bättre`` prototyp, oftast
+            så ligger den närmare den färdiga produkten än
+            lågnivåprototypen till utseende, och material (där det
+            finns). Det som främst skiljer en högnivåprototyp
             från en lågnivå är att högnivån har funktionalitet
             (verklig sådan, inte att man vänder blad).
 
           \subsubsection{Vilken väljer vi?}
 
-            Marc Rettig (1994) anser att det är bättre att använda
-            lågnivå prototyper framför högnivå, detta för att:
+            Marc Rettig (1994) anser att om man är tvungen att
+            välja så är det är bättre att välja
+            lågnivåprototyper framför högnivå, detta för att:
 
             \begin{itemize}
               \item Dom tar lång tid att göra
@@ -187,11 +190,11 @@
               testningen av denna.
             \end{itemize}
 
-              Vi måste säga att vi håller med honom. En lågnivå
-              prototyp kan säga det mesta en högnivå kan, och det
+              Vi måste säga att vi håller med honom. En lågnivåprototyp
+              kan säga det mesta en högnivå kan, och det
               den inte kan säga är det tveksamt om man kan få
-              tillbaka av den tid det tar att göra högnivå
-              prototypen (iallafall i de små projekt vi har jobbat
+              tillbaka av den tid det tar att göra högnivåprototypen
+              (iallafall i de små projekt vi har jobbat
               med hittills), det kan ju ändras om det är ett stort
               projekt, men vi är inte helt säkra på det. En
               prototyp skall endast ses som ett
@@ -199,6 +202,14 @@
               sig självt, på sin höjd kan det ju driva
               utvecklingen framåt.
 
+              Vi anser att de projekt vi har jobbat med har varit
+              så pass små att en högnivåprototyp inte skulle ha
+              hjälp oss komma framåt, utan snarare tvärt om, men
+              om man jobbar med större projekt så skall man nog
+              inte underskatta värdet av en högnivåprototyp, dock
+              så tror vi att det är viktigt att inte överskatta
+              den heller.
+
               Ett undantag bör dock göras. Om man kan utnyttja
               prototypen, eller en ansenlig del av denna senare.
               Om man t.ex. gör en prototyp av ett GUI, med begränsad
@@ -211,41 +222,55 @@
         \subsection{Erfarenhet}
 
           Vi tror att vi kommer att använda någon form av
-          prototyper efter denna kursen då en lågnivå prototyp är ett snabbt
+          prototyper efter denna kursen då en lågnivåprototyp är ett snabbt
           sätt att visa hur man menar att GUI't skall se ut, och
           om man har ett förslag till ett GUI så är det enkelt att
           hitta funktionalitet som man har missat, och det kan
           även vara enklare att förklara vad man vill göra för en
           kund som inte kunskaper inom programvaruutveckling vad
-          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.
           Han kan även ta prototypen och visa för slutanvändarna,
           och dessa kan också komma till tals om hur produkten
           skall se ut, och dess funktionalitet.
 
-      \section{Designmönster}
+          Man kan även se en möjlighet till att kunden kan komma
+          med flera direkta förslag på förändingar/förbättringar,
+          eller till och med göra designen själv (eller delar av
+          den).
+
+          Dessutom så innebär en prototyp av något slag att man
+          underlättar kommunikationen mellan utvecklaren och
+          kunden, och eftersom kund och utvecklare ofta har olika
+          kunskaper/erfarenheter innebär detta att man minskar
+          risken för missförstånd, och kan rätta till eventuella
+          designmissar i ett tidigt stadium. Prototypen kan även till
+          viss del användas för att hitta saknad funktionalitet,
+          dock så kan det vara svårare att hitta felaktig.
 
+      \section {Designmönster}
         När man designar GUI'n så är det nästan omöjligt att
-        inte använda några design mönster. Dom flesta sätt
+        inte använda något/några designmönster. De flesta sätt
         att strukturera upp ett GUI följer de mönster som finns
         definierade. Detta märkte vi av på första laborationen
         när vi skulle identifiera mönster som vi hade använt i
         ett program vi själva hade gjort långt innan vi hade
         hört talas om MDI, och dess betydelse. En anledning till
-        att man använder design mönster är att om flera program
+        att man använder designmönster är att om flera program
         ser ut likadant, och uppför sig likadant så kommer
-        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
         har sett programmet tidigare, eller ens ett program som
         liknar detta (till funktionalitet sett).
 
         \emph{``Ett väl-designat GUI låter användaren göra fel''}
-        (Grand, M. 1999)\\
+        (Grand, M. 1999)
+
         Detta är viktigt därför att om det inte går att göra fel,
         eller viktigare att återhämta sig från ett fel utan en
         förlust, då kommer användaren att ta det lugnt och
         försiktigt, men trots detta kommer användaren att göra
         många fel (eller snarare så är det så det upplevs då alla fel gör
         skada). Men om GUI't låter användaren återhämta sig om han
-        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
         göra färre fel. Något som är väldigt viktigt om GUI't
         tillåter att man gör fel så måste det varna om det finns
         aktioner som man kan göra som det inte går att återhämta
@@ -254,20 +279,20 @@
         \subsection{Vikten av att känna igen sig i ett program}
 
           En viktig sak med att få användaren att känna igen sig
-          är att detta ger en ``säkerhets känsla'' i programmet,
-          användaren känner att han vet (i viss mån) hur han skall
+          är att detta ger en ``säkerhetskänsla'' i programmet,
+          användaren känner att han eller hon vet (i viss mån) hur man skall
           bära sig åt för att göra olika saker. Nästan alla
           program där man kan spara sitt arbete, öppna en fil med
           gammalt arbete osv har detta i en meny märk ``Arkiv'' på
           svenska, kommandon som kopiera, klistra in, gör om osv.
           ligger under en meny ``redigera''. Detta gör att en
-          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
           nyttjat programmet tidigare.
 
-      \section{Interaktions Design}
+      \section{Interaktionsdesign}
 
-        När man pratar om interaktions design så menar man att
-        man sätter användaren och hans behov i fokus, och att man
+        När man pratar om interaktionsdesign så menar man att
+        man sätter användaren och dess behov i fokus, och att man
         inte så mycket bryr sig om tekniken bakom.
 
         Detta innebär dock att för att kunna designa något så
@@ -286,19 +311,31 @@
         produkten är hemligstämplad och det finns andra aktörer på
         marknaden som jobbar med samma område. Att då låta vanliga
         användare komma i kontakt med sin design innebär att hemlig
-        information kan spridas till konkurrenterna om de nu råkas
-        få tag på samma testpersoner.
+        information kan spridas till konkurrenterna om de nu råkar
+        få tag på samma testpersoner, och fråga ut dessa.
 
-        En annan sak som är viktig, mycket viktig med Interaktions
-        design är att den sker iterativt.
+        En annan sak som är viktig, mycket viktig med Interaktionsdesign
+        är att den sker iterativt. Detta för att om det
+        inte sker iterativt så kan man inte dra maximalt värde av
+        den. Det finns ju en risk att om man gör en ändring
+        som skall lösa ett problem, introducerar man två nya, och om
+        processen inte sker iterativt så finns det ingen möjlighet
+        att finna detta förrän det kanske är försent, och då kan det
+        kosta väldigt mycket mer att åtgärda.
 
       \section{Konceptuella modeller}
 
+        En konceptuell modell är en beskrivning av systemet, i
+        form av tankar och idéer om hur systemet skall verka och
+        se ut, och att det kan förstås av användaren.
+
         \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)\\
+        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
@@ -313,10 +350,10 @@
         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
+        besluta vad användaren skall göra när han/hon använder
+        produkten. Detta kan även kallas interaktionssä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
+        väljer interaktionssä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.
 
@@ -348,16 +385,19 @@
           \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.\\
+          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.\\
+          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
+          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.
@@ -376,7 +416,7 @@
           textsträngar. En klar nackdel med denna modellen är att
           om kommandona är långa (eller krångliga) kommer
           användaren att glömma bort det, och behöva extra hjälp
-          när han skall nyttja denna. Detta är ett vanligt
+          när han/hon skall nyttja denna. Detta är ett vanligt
           mönster, och återfinns i flera produkter på ett sätt
           eller ett annat.
 
@@ -426,15 +466,15 @@
         vara väldigt trevligt om denna klarar av att t.ex.
         kompilera texten, rättstavning osv.
 
-      \subsection{Interface metaforer}
+      \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å
+        likna det vid något som man känner igen. Då boken är
+        väldigt kritisk mot denna metoden att utveckla
+        produkter, så tänker vi inte gå in på denna så djupt. Däremot 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.
@@ -445,15 +485,15 @@
       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
+      fånga designfel, eller till och med logikfel, 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,
+      ett sätt använda det som en reklamtavla 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
+      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.
