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

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

        \subsection{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.


\end{document}
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	Blekinge Tekniska Högskola\\\vspace{.03in}
15	\texttt{e-mail:}\\
16	\emph{jopd01@student.bth.se}}\\
17	\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	Detta kapitel kommer att ta delar av det vi har gått igenom
26	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	källfilerna ligger i en katalog, de kompilerade
69	programmet i en, och hjälp filerna i en tredje (om
70	programmeringsspråket stödjer detta (t.ex. java API).\\
71
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	i alla fall dom vi har gjort) ''dynamiskt statiska``
123	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	\emph{Ett väl-designat GUI låter användaren göra fel}
160	(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	är att detta ger en ''säkerhets känsla`` i programmet,
177	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	gammalt arbete osv har detta i en meny märk ''Arkiv`` på
181	svenska, kommandon som kopiera, klistra in, gör om osv.
182	ligger under en meny ''redigera´´. Detta gör att en
183	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	måste vi känna målgruppen och dess behov. Att jobba med
194	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	så är det ''enkelt`` att skapa denna då man hela tiden kan
202	rådfråga målgruppen, skapa mock-uper, prototyper osv, och
203	få direkt feedback på det man har gjort.
204
205	En annan sak som är viktig, mycket viktig med Interaktions
206	design är att den sker iterativt.
207
208	\subsection{Konceptuella modeller}
209
210	\emph{Det viktigaste är att designa användarens
211	konceptuella modell. Allt annat skall ses som
212	underordnat för att göra modellen klar, tydlig och
213	konkret. Detta är nästan tvärt emot hur den mesta
214	mjukvaran utvecklas.}(Liddle, David. 1996)\\
215	Preece, Rogers and Sharp 2002 definierar en konceptuell
216	modell som \emph{en beskrivning av det föreslagna
217	systemet i termer av integrerade idéer och koncept om
218	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}\\
220
221	När man skapar en konceptuell modell så är det viktigt
222	att man funderar över hur den slutliga produkten skall
223	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å
225	modellen så som den är tänkt är det viktigt att
226
227	\subsubsection{Konceptuella modeller baserat på
228	aktiviteter}
229
230	\subsubsection{Konceptuella modeller baserat på objekt}
231
232	\section{Värdet av MDI}
233
234	Det kanske kan verka abstrakt, och som något som bara tar
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)
237	man lägger ner på MDI tjänar man igen ganska så fort.
238	Dessutom så är det med hjälp av en mock-up lätt att tidigt
239	fånga design fel, eller till och med logik fel, och ju
240	tidigare man kan hitta fel, desto billigare blir dom att
241	avhjälpa.
242
243	En annan viktig sak att tänka på med MDI är att man kan på
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
246	detta att sprida sig, men det kommer ännu mer att sprida
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
249	att de inte kan nyttja den kommer inte att köpa en produkt
250	till av samma företag som den förra.
251
252
253	\end{document}