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{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-post:}\\
    \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[Script vid mjukvaruproduktion]{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
          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
          programmen i en, och hjälpfilerna i en tredje (om
          programmeringsspråket stödjer detta (t.ex. Java API).


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

          GUI står för Graphical User Interface, eller grafiskt
          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
          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}

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

          Nu vet ju vi att vi bara har använt mock-ups i denna
          kursen, men det vore synd att inte ta tillfället i akt
          och prata lite om prototyper också.

          \subsubsection{Mock-up}

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

          \subsubsection{Lågnivåprototyper}

            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
            väldigt långt från ett färdigt program på datorn, och
            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
            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}

            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 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
              \item Kritiker och testar tenderar att kritisera
              prototypen, och inte funktionaliteten i den.
              \item Utvecklar drar sig för att göra om något dom
              har lagt timmar (eller dagar) på att göra.
              \item En mjukvaru prototyp kan sätta förväntningarna
              för högt.
              \item En enda bugg i prototypen kan sätta stop för
              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
              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
              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
              utvecklingsverktyg, det är ju inget som utvecklar av
              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
              (eller igen) funktionalitet så kan man ju använda
              detta i den färdiga produkten, förutsatt att det
              faller väl ut.


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

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

        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
        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
        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ä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 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 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å
        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åkar
        få tag på samma testpersoner, och fråga ut dessa.

        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)


        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/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
        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 ögna igenom %ä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}

          Detta är en relativt enkel modell att bygga upp, även om
          det kan vara krångligt att bygga upp den på ett bra
          sätt. Antingen kan man använda knappar, menyer osv för
          att ge instruktioner, eller så kan man använda
          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/hon skall nyttja denna. Detta är ett vanligt
          mönster, och återfinns i flera produkter på ett sätt
          eller ett annat.

        \subsubsection{Konversera}

          Denna metoden är vanligast om det handlar om någon form
          av expert system, eller sökfunktioner. En klar fördel
          med att nyttja detta mönster är att även en människa med
          små kunskaper inom både data, och ämnet som experten kan
          kan ställa frågor, och få hjälp. En nackdel med detta
          mönstret är att om användaren ställer frågor på ett sätt
          som man inte har tänkt sig, eller som inte finns med i
          informations basen så kan svaren till användaren bli
          helt uppåt väggarna om man inte är noga med hur man
          behandlar indatan.

        \subsubsection{Manipulera och navigera}

        Visualisering måste innehålla mycket mer än att bara tillåta folk att ``se''
        information. Dom måste också kunna manipulera och fokusera sig på vad som är relevant
        och känna igen det för att skapa ny information. Funktioner som hypertext (t.ex. HTML)
        har blivit en dominant metod för att länka samman dokument, vilket tillåter användaren
        att navigera sig genom dokument på ett väldigt dynamiskt och personligt sätt.

      \subsubsection{Utforska och ögna igenom}

        Hypertext är
        en smidig metod för att söka efter information då man
        kan länka vidare till djupare information då en
        användare hittar något som intresserar. Nackdelen med
        denna metod är att det kan bli grötigt, och att det
        kan vara svårt att komma igång om man inte riktigt vet
        vad man söker efter. Det ger däremot användaren en möjlighet
        att hoppa runt på ett snabbt sätt mellan dokumenten tills
        han/hon hittar det som söktes.

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

    \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 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 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
      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}