cvs/Kamel/HCI_text.tex

\documentclass[12pt, a4paper]{article}
\usepackage[latin1]{inputenc}
\usepackage{setspace}

\begin{document}
  \thispagestyle{empty}
  \begin{centering}
    \huge{HCI Text}\\
    \huge{DVC002: Människa-datorinteraktion (MDI), 5p}\\
    \huge{2003, period 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:}\\
    \emph{jopd01@student.bth.se}\\
    \emph{tb00mbo@student.bth.se}\\
  \end{centering}
  \newpage
  \tableofcontents
  \newpage
  \onehalfspacing
    \section{Kurserfarenheter} %Är detta ett bra namn?

      Detta kapitel kommer att ta delar av det vi har gått igenom
      i kursen, samt försöka belysa vissa av dem.

        \subsection{Användandet av en minsta gemensamma
        utvecklingsmiljö}

          Ett syfte med att introducera en minsta gemensamma
          utvecklingsmiljö är att underlätta processen att
          producera programvara, även om man inte sitter vid sin
          egen dator, utan hos någon annan.

          Nyttan med en minsta gemensamma utvecklingsmiljö i en miljö med flera utvecklare är att
          det hämmar användandet av egna utvecklingsverktyg,
          underlättar användandet av en annan dator, underlättar utbildning, samt
          underlättar administrationen av systemet då alla datorer
          har samma programvara installerad.
          Dock så är ju en nackdel med att nyttja en gemensam
          utvecklingsmiljö att då det kommer nya människor som
          inte är vana vid denna miljö så måste de utbildas, men
          genom att tänka sig för då man skapar en gemensam
          utvecklingsmiljö så kan utbildningstiden minskas till
          ett minimum, eller till och med undvikas.

          Det som skall eftersträvas i en gemensam
          utvecklingsmiljö är dels att få den lättförståelig
          (eller självförklarande), men att den för detta inte på
          något sätt skall vara på en nivå för nybörjare, utan ha
          all den styrka som utvecklarna behöver då de utvecklar
          programvara. Kan den gemensamma utvecklingsmiljön
          introduceras som något som kan underlätta arbetet så
          kommer användarna att med glädje byta, även om det kan
          innebära vissa initiala problem.

        \subsection{Användandet av script vid mjukvaruproduktion}

          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)
          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
          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.

        \subsection{GUI design mönster}

          GUI står för Graphical User Interface, eller grafiskt
          användar grä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
          utvecklare att vi känner till de mönster som finns, vad
          de går ut på, samt vad som är viktigt att tänka på. En
          anledning till att detta var viktigt att lära oss är
          genom att vi lär oss detta kan vi spara tid när vi skall
          utveckla en programvara som skall interagera med en
          människa (vilket det stora flertalet program gör), genom
          att vi inte ska behöva uppfinna hjulet igen.

          Vi hade en laboration där vi skulle identifiera design
          mönster i en färdig programvara från SUN Microsystems,
          och efter detta även i en programvara vi själva har
          gjort. Detta innebar att vi var tvungna att lära oss
          känna igen de olika mönster som är vanligt förekommande,
          och på detta sättet så kom vi även att fundera på när de
          olika mönstren är praktiska, och när dom inte är det. Vi
          har genom denna laboration kommit fram till att design
          mönster är något viktigt i utveckling av programvara,
          och är något vi kommer att ta med oss till framtiden.

        \subsection{Prototyper och Mock-ups}

          En mock-up är en form av prototyp. Den görs i ett
          passande material, och beroende på vilken information
          man har om den färdiga produkten så görs den med den
          detaljnivå som är passande. Denna mock-up används sedan
          för att testa om konceptet man har håller, och hur det
          skall implementeras. En mock-up behöver inte vara för en
          programvara, utan kan lika gärna vara för en fysisk
          produkt, men i kursen har vi inriktat oss på programvara
          då detta är det intressanta för oss. Då man skapat en
          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
          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
          detaljer i mock-upen för att symbolisera interaktion. En
          annan fördel med en mock-up framför en fungerade
          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.

          Vi tror att vi kommer att använda någon form av
          mock-uper efter denna kursen då en mock-up ä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.
          Han kan även ta mock-upen 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}

        När man designar GUI'n så är det nästan omöjligt att
        inte använda något/några design mönster. Dom 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
        ser ut likadant, och uppför sig likadant så kommer
        användaren att känna sig hemma i det, även om han 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)\\
        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
        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
        sig ifrån.

        \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
          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
          nyttjat programmet tidigare.

      \section{Interaktions Design}

        När man pratar om interaktions design så menar man att
        man sätter användaren och hans 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å
        måste vi känna till målgruppen och dess behov. Att jobba med
        interaktions design är väldigt snarlikt till att jobba med
        en användarcentrerad lösning. Det går antingen att jobba
        med interaktions design om man har en färdig målgrupp som
        har ett behov av programvaran, eller att man tänker sig en
        målgrupp, och skapar produkten därefter.

        Om man har en färdig målgrupp som har behov av en produkt
        så är det ``enkelt'' att skapa denna då man hela tiden kan
        rådfråga målgruppen, skapa mock-uper, prototyper osv, och
        få direkt feedback på det man har gjort. Det finns undantag
        då man inte kan skapa mock-uper och det är när själva slut
        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.

        En annan sak som är viktig, mycket viktig med Interaktions
        design är att den sker iterativt.

      \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
        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}
1	jontas	1.1	\documentclass[12pt, a4paper]{article}
2			\usepackage[latin1]{inputenc}
3			\usepackage{setspace}
4
5			\begin{document}
6			\thispagestyle{empty}
7			\begin{centering}
8			\huge{HCI Text}\\
9			\huge{DVC002: Människa-datorinteraktion (MDI), 5p}\\
10			\huge{2003, period 1}\\\vspace{.3in}
11			\large{av}\\
12			\LARGE{Jonas Petersson \& Mathias Börjesson}\\\vspace{.4in}
13			\large{Institutionen för programvaruteknik och datavetenskap\\
14	eax	1.6	Blekinge Tekniska Högskola\\\vspace{.03in}}
15	jontas	1.1	\texttt{e-mail:}\\
16	eax	1.6	\emph{jopd01@student.bth.se}\\
17	jontas	1.1	\emph{tb00mbo@student.bth.se}\\
18			\end{centering}
19			\newpage
20			\tableofcontents
21			\newpage
22			\onehalfspacing
23			\section{Kurserfarenheter} %Är detta ett bra namn?
24
25	jontas	1.5	Detta kapitel kommer att ta delar av det vi har gått igenom
26	jontas	1.1	i kursen, samt försöka belysa vissa av dem.
27
28			\subsection{Användandet av en minsta gemensamma
29			utvecklingsmiljö}
30
31			Ett syfte med att introducera en minsta gemensamma
32			utvecklingsmiljö är att underlätta processen att
33			producera programvara, även om man inte sitter vid sin
34			egen dator, utan hos någon annan.
35
36			Nyttan med en minsta gemensamma utvecklingsmiljö i en miljö med flera utvecklare är att
37			det hämmar användandet av egna utvecklingsverktyg,
38			underlättar användandet av en annan dator, underlättar utbildning, samt
39			underlättar administrationen av systemet då alla datorer
40			har samma programvara installerad.
41			Dock så är ju en nackdel med att nyttja en gemensam
42			utvecklingsmiljö att då det kommer nya människor som
43			inte är vana vid denna miljö så måste de utbildas, men
44			genom att tänka sig för då man skapar en gemensam
45			utvecklingsmiljö så kan utbildningstiden minskas till
46			ett minimum, eller till och med undvikas.
47
48			Det som skall eftersträvas i en gemensam
49			utvecklingsmiljö är dels att få den lättförståelig
50			(eller självförklarande), men att den för detta inte på
51			något sätt skall vara på en nivå för nybörjare, utan ha
52			all den styrka som utvecklarna behöver då de utvecklar
53			programvara. Kan den gemensamma utvecklingsmiljön
54			introduceras som något som kan underlätta arbetet så
55			kommer användarna att med glädje byta, även om det kan
56			innebära vissa initiala problem.
57
58			\subsection{Användandet av script vid mjukvaruproduktion}
59
60			Detta kan lätt tyckas att detta inte har med MDI att
61			göra, men vi kommer att förklara detta lite senare.
62			Tanken med att använda diverse script är främst att
63			abstrahera krångliga kommandon (eller om man vill långa)
64			från användaren, och istället bara använda ett kort
65			kommando. Detta innebär att det blir enklare att hålla
66			ordning på det man utvecklar då det i scriptet går
67			snabbt att skriva ner de kommandon som ser till att
68	jontas	1.5	källfilerna ligger i en katalog, de kompilerade
69	jontas	1.1	programmet i en, och hjälp filerna i en tredje (om
70	eax	1.11	programmeringsspråket stödjer detta (t.ex. Java API).\\
71	jontas	1.1
72			%Eller är det svaret vi skall skjuta in?
73			Men hur är detta något som är intressant ur en MDI
74			synpunkt?\\
75			Jo, tanken var ju att ta alla dom krångliga kommandona,
76			och helt enkelt byta ut mot ett kort script. Krasst sett
77			är detta grunden för MDI. Att ta något krångligt
78			kommando, och byta ut mot ett lättare.
79
80			\subsection{GUI design mönster}
81
82			GUI står för Graphical User Interface, eller grafiskt
83			användar gränsnitt på svenska. Ett GUI kan se ut på
84			ett (nästan) oändligt antal sätt, men alla dessa följer
85			ett eller flera mönster för hur man använder dessa. Då
86			dessa mönster upprepas så är det viktigt för oss som
87			utvecklare att vi känner till de mönster som finns, vad
88			de går ut på, samt vad som är viktigt att tänka på. En
89			anledning till att detta var viktigt att lära oss är
90			genom att vi lär oss detta kan vi spara tid när vi skall
91			utveckla en programvara som skall interagera med en
92			människa (vilket det stora flertalet program gör), genom
93			att vi inte ska behöva uppfinna hjulet igen.
94
95			Vi hade en laboration där vi skulle identifiera design
96			mönster i en färdig programvara från SUN Microsystems,
97			och efter detta även i en programvara vi själva har
98			gjort. Detta innebar att vi var tvungna att lära oss
99			känna igen de olika mönster som är vanligt förekommande,
100			och på detta sättet så kom vi även att fundera på när de
101			olika mönstren är praktiska, och när dom inte är det. Vi
102			har genom denna laboration kommit fram till att design
103			mönster är något viktigt i utveckling av programvara,
104			och är något vi kommer att ta med oss till framtiden.
105
106			\subsection{Prototyper och Mock-ups}
107
108			En mock-up är en form av prototyp. Den görs i ett
109			passande material, och beroende på vilken information
110			man har om den färdiga produkten så görs den med den
111			detaljnivå som är passande. Denna mock-up används sedan
112			för att testa om konceptet man har håller, och hur det
113			skall implementeras. En mock-up behöver inte vara för en
114			programvara, utan kan lika gärna vara för en fysisk
115			produkt, men i kursen har vi inriktat oss på programvara
116			då detta är det intressanta för oss. Då man skapat en
117			mock-up så tar man denna, och testar på en eller flera
118			tilltänkta användare, och lyssnar på deras åsikter om
119			den. När man har kommit förbi detta stadiet så kan man
120			bygga en lite mera avancerad prototyp för att vidare
121			utveckla produkten. En mock-up är vanligtvis (eller
122	eax	1.10	i alla fall dom vi har gjort) ``dynamiskt statiska''
123	jontas	1.1	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
125			detaljer i mock-upen för att symbolisera interaktion. En
126			annan fördel med en mock-up framför en fungerade
127			prototyp är att en mock-up är gjord av ett billigt
128			material, och går snabbt att göra och göra om då man inser att
129			lösningen man har inte håller, utan behöver göras om för
130			att passa användaren och hans behov.
131
132			Vi tror att vi kommer att använda någon form av
133			mock-uper efter denna kursen då en mock-up är ett snabbt
134			sätt att visa hur man menar att GUI't skall se ut, och
135			om man har ett förslag till ett GUI så är det enkelt att
136			hitta funktionalitet som man har missat, och det kan
137			även vara enklare att förklara vad man vill göra för en
138			kund som inte kunskaper inom programvaruutveckling vad
139			det är som man skall göra, och vad han får och inte får.
140			Han kan även ta mock-upen och visa för slutanvändarna,
141			och dessa kan också komma till tals om hur produkten
142			skall se ut, och dess funktionalitet.
143
144			\section {Designmönster}
145
146			När man designar GUI'n så är det nästan omöjligt att
147			inte använda något/några design mönster. Dom flesta sätt
148			att strukturera upp ett GUI följer de mönster som finns
149			definierade. Detta märkte vi av på första laborationen
150			när vi skulle identifiera mönster som vi hade använt i
151			ett program vi själva hade gjort långt innan vi hade
152			hört talas om MDI, och dess betydelse. En anledning till
153			att man använder design mönster är att om flera program
154			ser ut likadant, och uppför sig likadant så kommer
155			användaren att känna sig hemma i det, även om han aldrig
156			har sett programmet tidigare, eller ens ett program som
157			liknar detta (till funktionalitet sett).
158
159	eax	1.10	\emph{``Ett väl-designat GUI låter användaren göra fel''}
160	jontas	1.1	(Grand, M. 1999)\\
161			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
163			förlust, då kommer användaren att ta det lugnt och
164			försiktigt, men trots detta kommer användaren att göra
165			många fel (eller snarare så är det så det upplevs då alla fel gör
166			skada). Men om GUI't låter användaren återhämta sig om han
167			gör fel så kommer han att jobba i ett bättre tempo, och
168			göra färre fel. Något som är väldigt viktigt om GUI't
169			tillåter att man gör fel så måste det varna om det finns
170			aktioner som man kan göra som det inte går att återhämta
171			sig ifrån.
172
173			\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
176	eax	1.10	är att detta ger en ``säkerhets känsla'' i programmet,
177	jontas	1.1	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
179			program där man kan spara sitt arbete, öppna en fil med
180	eax	1.10	gammalt arbete osv har detta i en meny märk ``Arkiv'' på
181	jontas	1.1	svenska, kommandon som kopiera, klistra in, gör om osv.
182	eax	1.10	ligger under en meny ``redigera''. Detta gör att en
183	jontas	1.1	användare kan känna igen sig även om han aldrig har
184			nyttjat programmet tidigare.
185
186			\section{Interaktions Design}
187
188			När man pratar om interaktions design så menar man att
189			man sätter användaren och hans behov i fokus, och att man
190			inte så mycket bryr sig om tekniken bakom.
191
192			Detta innebär dock att för att kunna designa något så
193	eax	1.11	måste vi känna till målgruppen och dess behov. Att jobba med
194	jontas	1.1	interaktions design är väldigt snarlikt till att jobba med
195			en användarcentrerad lösning. Det går antingen att jobba
196			med interaktions design om man har en färdig målgrupp som
197			har ett behov av programvaran, eller att man tänker sig en
198			målgrupp, och skapar produkten därefter.
199
200			Om man har en färdig målgrupp som har behov av en produkt
201	eax	1.10	så är det ``enkelt'' att skapa denna då man hela tiden kan
202	jontas	1.1	rådfråga målgruppen, skapa mock-uper, prototyper osv, och
203	eax	1.11	få direkt feedback på det man har gjort. Det finns undantag
204			då man inte kan skapa mock-uper och det är när själva slut
205			produkten är hemligstämplad och det finns andra aktörer på
206			marknaden som jobbar med samma område. Att då låta vanliga
207			användare komma i kontakt med sin design innebär att hemlig
208			information kan spridas till konkurrenterna om de nu råkas
209			få tag på samma testpersoner.
210	jontas	1.1
211			En annan sak som är viktig, mycket viktig med Interaktions
212			design är att den sker iterativt.
213
214	jontas	1.2	\section{Konceptuella modeller}
215	jontas	1.1
216	eax	1.10	\emph{``Det viktigaste är att designa användarens
217	jontas	1.2	konceptuella modell. Allt annat skall ses som
218			underordnat för att göra modellen klar, tydlig och
219			konkret. Detta är nästan tvärt emot hur den mesta
220	eax	1.10	mjukvaran utvecklas.''}(Liddle, David. 1996)\\
221	jontas	1.2	Preece, Rogers and Sharp 2002 definierar en konceptuell
222	eax	1.10	modell som \emph{``en beskrivning av det föreslagna
223	jontas	1.2	systemet i termer av integrerade idéer och koncept om
224			vad det skall göra, bete sig samt se ut som, som skall
225	eax	1.10	förstås av användaren på rätt sätt''}\\
226	jontas	1.1
227	jontas	1.2	När man skapar en konceptuell modell så är det viktigt
228			att man funderar över hur den slutliga produkten skall
229			se ut, baserat på användarnas behov och krav. För att
230			försäkra sig om att användaren kommer att förstå
231			modellen så som den är tänkt är det viktigt att
232			genomföra noggranna och iterativa tester.
233	jontas	1.1
234	jontas	1.2	En viktig del av den konceptuella modellen är att
235			besluta vad användaren skall göra när han använder
236			produkten. Detta kan även kallas interaktions sätt
237			dvs hur en användare skall få utföra jobbet. När man
238			väljer interaktions sätt så får man även tänka över hur
239			man skall interagera med produkten (programvaran), skall
240			det vara med knappar, menyer, röstkommandon osv.
241
242			När man har kommit så här långt med sin modell så är det
243			dags att börja fundera över hur GUI't skall se ut, olika
244			mönster, dess fördelar och nackdelar osv. Ju fler man
245			provar med, och funderar över, ju större är chansen att
246	jontas	1.5	produkten blir bra, och det är viktigt att man jobbar
247			iterativt, och att man använder lite olika metoder, och
248	jontas	1.2	data (gärna även utvecklare om det går) i dom olika
249			iterationerna för att täcka in så mycket som möjligt.
250
251			Basen i att konstruera en bra konceptuell modell är
252			användaren, och det användaren skall kunna göra.
253
254			Det finns ett otal olika konceptuella modeller, men vi
255			kommer bara att ta upp dom två vanligaste.
256
257			\subsection{Konceptuella modeller baserat på
258			aktiviteter}
259
260			De fyra vanligaste aktiviteterna användarna kommer att
261			göra (sett ur MDI synpunkt) är:
262			\begin{itemize}
263			\item Instruera
264			\item Konversera
265			\item Manipulera och navigera
266			\item Utforska och surfa %är surfa en bra översättning av browsing?
267			\end{itemize}
268			När man instruerar så förklarar man vad man vill att
269			systemet skall göra, man ger order. Detta kan ske t.ex.
270			med knappar, menyer osv.\\
271			När man konverserar så gör man det som man gör med en
272			människa, antingen talar man till systemet med rösten,
273			eller så skriver man, men man håller sig till ett
274			normalt språk.\\
275			När man manipulerar och navigerar så har man en
276			representation (av något) som man kan manipulera för att
277			uppnå önskat resultat. Det är en klar fördel om
278			representationen delar vissa egenskaper som användaren
279			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
280			När man utforskar och surfar så är systemet utformat på
281			ett sådant vis att användaren kan få information utan
282			att behöva formulera frågor.
283
284			Det är viktigt att förstå att man måste inte välja en av
285			dessa, utan man kan välja flera om man känner för det,
286			ofta kan man få ett resultat som blir närmare det
287			användaren efterfrågar om man väljer att blanda flera
288			aktiviteter.
289
290			\subsubsection{Instruera}
291
292	jontas	1.7	b
293	jontas	1.2
294			\subsubsection{Konversera}
295
296			a
297
298			\subsubsection{Manipulera och navigera}
299
300			a
301
302			\subsubsection{Utforska och surfa}
303
304			a
305
306			\subsection{Konceptuella modeller baserat på objekt}
307
308	jontas	1.5	När man utgår från ett objekt så tar man ett objekt som
309			användaren kan relatera till, en bok, kaffe bryggare
310			eller dyl. Och sedan så gör man sin modell så att den
311			liknar det fysiska objektet. Det bör även gå att
312			manipulera objektet på ett vis som liknar det fysiska
313			objektet. Men man bör även tänka på vilka funktioner en
314			användare kan tänkas önska utöver dom som finns i det
315			verkliga objektet. Om man gör en ordebehandlare kan det
316			vara väldigt trevligt om denna klarar av att t.ex.
317			kompilera texten, rättstavning osv.
318
319			\subsection{Interface metaforer}
320
321			Denna metod går ut på att man tar och försöker efterlikna
322			en välkänd metod, eller något som användaren känner igen
323			för att manipulera systemet. Det handlar oftast om att man
324			försöker abstrahera bort hur datorn gör, och istället
325			likna det vi något som man känner igen. Dock så är boken
326			vi har väldigt kritisk mot denna metoden att utveckla
327			produkter, så vi tänker inte gå in på denna så djupt. Dock så
328			tror vi att det borde vara en bra metod att iallafall
329			fundera på, men man måste nog vara försiktig så att man
330	eax	1.10	inte gör ``hål'' i designen då man använder metaforer.
331	jontas	1.5
332			\section{Värdet av MDI}
333
334	eax	1.9	Hela ämnet kanske kan verka abstrakt, och som något som bara tar
335			upp tid att hålla på med, men faktum är att den tid (och de pengar)
336	jontas	1.5	man lägger ner på MDI tjänar man igen ganska så fort.
337			Dessutom så är det med hjälp av en mock-up lätt att tidigt
338			fånga design fel, eller till och med logik fel, och ju
339			tidigare man kan hitta fel, desto billigare blir dom att
340			avhjälpa.
341
342			En annan viktig sak att tänka på med MDI är att man kan på
343			ett sätt använda det som en reklam tavla för sitt företag,
344			om man gör en extraordinär lösning på något så kommer
345			detta att sprida sig, men det kommer ännu mer att sprida
346			sig om man gör dåliga MDI lösningar. Ett företag som
347			tidigare har köpt en produkt som kanske är bra, bara det
348			att de inte kan nyttja den kommer inte att köpa en produkt
349			till av samma företag som den förra.
350	jontas	1.1
351	eax	1.8	Även om själva funtionaliteten i applikationen (eller vad
352			det nu är som skapats) kanske är helt banbrytande och
353			ruskigt innovativ så kanske inte produkten kan säljas
354			ändå, på grund av att användarna helt enkelt inte klarar
355			av att använda den för att gränssnittet är alldeles för
356			klumpigt, långsamt och förvirrande. \emph{``Jag fattar inte varför man år 2000 ska behöva
357			vänta ibland en sekund innan telefonen fattar att man
358			vill hoppa ett steg till vänster i menyerna.''}(Mats
359			Ekstrand, 2000-09-20 i en recension av Ericssons R310)
360			Man brukar säga att utseendet inte spelar någon roll,
361			men när det gäller MDI så spelar det stor roll. Det första
362			man möts av när man får/köper en produkt är gränssnittet,
363			må det så vara en knappsats, touchscreen eller ett flashigt GUI.
364	jontas	1.1
365			\end{document}