--- Kamel/HCI_text.tex	2003/04/08 12:43:40	1.16
+++ Kamel/HCI_text.tex	2003/04/09 22:33:03	1.17
@@ -66,7 +66,7 @@
           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).
 
 
@@ -75,8 +75,9 @@
           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. Eller att på
-          annat sätt underlätta användandet av en produkt.
+          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 designmönster}
 
@@ -109,10 +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 eller hon (dock för att underlätta
-          läsningen i fortsättningen använder vi ett könlöst han
-          för att symolisera en person av okänt kön, om inte annat
-          sägs) 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.
 
@@ -144,12 +142,12 @@
             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}
 
             En lågnivåprototyp är en enkel prototyp, som snarare
-            syftar till att visa den grundläggande idéen. Den kan
+            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
@@ -230,36 +228,36 @@
           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.
 
-<<<<<<< HCI_text.tex
           Man kan även se en möjlighet till att kunden kan komma
-          med mera direkta förslag på förändingar/förbättringar,
-          eller till och med själv göra designen (eller del av
+          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 då ofta kund och utvecklare har olika
-          kunnskaper/erfarenheter innebär detta att man minskar
-          risken för missförstånd, och kan rätta till ev design
-          missar i ett tidigt stadium. Prototypen kan även till
+          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 värre att hitta felaktig.
+          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å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).
 
@@ -271,7 +269,7 @@
         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
@@ -281,19 +279,19 @@
 
           En viktig sak med att få användaren att känna igen sig
           är att detta ger en ``säkerhetskänsla'' i programmet,
-          användaren känner att han vet (i viss mån) hur han skall
+          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{Interaktionsdesign}
 
         När man pratar om interaktionsdesign så menar man att
-        man sätter användaren och hans behov i fokus, och att man
+        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å
@@ -313,16 +311,16 @@
         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åkar
-        få tag på dessa testpersoner, och fråga ut dessa.
+        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. Detta för att om det
+        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
-        denna. Det finns ju en risk att om man gör en ändring så
-        som ska lösa ett problem, introducerar man två nya, och om
+        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ören det har gått en lång tid, och det
-        kostar mer att åtgärda.
+        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}
 
@@ -349,7 +347,7 @@
         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
+        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 interaktionssätt så får man även tänka över hur
@@ -415,7 +413,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.
 
@@ -473,7 +471,7 @@
         försöker abstrahera bort hur datorn gör, och istället
         likna det vid något som man känner igen. Då boken är
         väldigt kritisk mot denna metoden att utveckla
-        produkter, så vi tänker inte gå in på denna så djupt. Dock så
+        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.
@@ -492,7 +490,7 @@
       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 MDIlö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.
