Metoder för värdering

Värderingen, eller användbarhetstestningen, är naturligtvis ett viktigt steg i designprocessen. Då kan man erhålla ett kvitto som visar hur användbar produkten upplevs. Enligt Löwgren och Stolterman [7] är användbarhets- testning ett mer eller mindre formellt experiment, där de blivande använ- darna försöker använda systemet eller en prototyp för att genomföra ett antal kortare testuppgifter. Under experimentet noteras användarnas in- teraktion med systemet med fokus på prestation, till exempel hur många fel som görs och hur lång tid olika operationer tar att utföra.

Nielsens heuristiska utvärderingsmetod

Ett exempel på en välanvänd användbarhetsmetod för webbgränssnitt är Nielsens heuristiska utvärderingsmetod [8]. Metoden utgår från ett tiotal punkter som Nielsen anser viktiga för användbarheten. Utvärderingen be- står av att cirka fem användare använder systemet och tillsammans med testledaren bedömer hur väl Nielsens punkter överensstämmer med pro- dukten.

Denna metod har kritiserats av användbarhetsexperten Tajakka [9] för att vara alltför godtycklig och diffus. Dessutom kritiseras metoden för att

vara onödigt resurskrävande då den kräver minst fem testanvändare för att ge bra resultat [8]. Istället föreslår Tajakka sin egenutvecklade metod, Design-Interaktion-Navigation-metoden (DIN-metoden) [10], som han på-

står löser dessa problem.

DIN-metoden

DIN-metoden utgår från vad som kännetecknar bra egenskaper i ett an-

vändargrässnitt, är konkret och innehåller handfasta rekommendationer på ett flertal punkter. Den är inte vetenskapligt utvecklad och tycks till stor del bestå av Tajakkas egna åsikter. Metoden utgår från en webbplats tre grundläggande kännetecken: design, interaktion och navigation. För varje kännetecken värderas ett antal egenskaper. Metoden innehåller även ett antal mycket konkreta råd i stil med att man alltid ska ha vänsterställ- da formulär. Det mesta i metoden kan vi själva utvärdera och testa men upplevelsen av navigationen och möjligheten till överblick av webbplat- sen kräver externa testanvändare.

Design Designen ska präglas av enkelhet och struktur. Enkelhet finns om det går fort och lätt att få en överblick över webbplatsens innehåll och de funktioner som erbjuds. Designstrukturen handlar om hur informatio- nen är strukturerad i form av till exempel rubrik- och länkhantering, bröd- text och bilder samt formulär. Det är viktigt att informationen grupperas så att viktig information framträder tydligt, att informationen även syns i mindre skärmupplösningar utan att bläddring i sidled krävs och så att balansen mellan information och tom yta är god.

Navigation Navigationen ska vara enkel i den meningen att användaren ska förstå var han eller hon befinner sig, har varit och kan navigera sig. Om det finns flera menyer är det nödvändigt att kopplingen mellan dem är tydlig. En meny får inte ta för stor plats på webbplatsen, maximalt en femtedel, och det ska gå att navigera utan hjälp av datormus. Vidare är det viktigt att namnen på menyelementen är väl överensstämmande med vad de innehåller samt att man kan ta sig tillbaka till startsidan.

Interaktion Interaktionen är uppdelad i tre delar: felhantering, instruk- tioner/information och användarkontroll. Felhanteringen ska uppmärk- samma, informera och ge förslag på hur användaren kan åtgärda felet. Instruktionerna och informationen ska underlätta för användaren att an- vända webbplatsen och i möjligaste mån förhindra fel. Användaren ska ha

2.2. Designmetod 13

kontroll över vad som sker i interaktionen och bör kunna ångra val samt avbryta och stanna upp processer.

2.2.4 Vår användbarhetsmetod

Vision

Vi utgick från Lorensbergs Communications vision för hur enkätunder- sökningar ska hanteras och formulerade en vision som är specifik för den del av enkätmodulen som examensarbetet innefattar.

Operativ bild

Eftersom visionen till stor del var given fokuserade vi inte på scenarion eller storyboards. Istället fokuserade vi på gränssnittsskisser och en dyna- misk pappersprototyp som vi även utvärderade. Därefter använde vi de riktiga programmen för utvärdering.

Värdering

Vi har tidigare i ett flertal projekt använt oss av Nielsens heuristiska ut- värderingsmetod och finner visst fog för Tajakkas kritik, se stycke 2.2.3. Nielsens metod är mer generell än Tajakkas som är strikt webbanpassad och konkret.

Eftersom vi användeXPoch påbörjade programmering och gränssnitt-

design i ett tidigt skede hade vi ett fungerande användargränssnitt till vå- ra applikationer som gick att testa. Vi använde oss av MVC-arkitekturen

vilket innebär att gränssnittslagret är åtskiljt från de övriga delarna och därför med lätthet kan modifieras. Detta gjorde att en datorprototyp inte var nödvändig.

Inledningsvis testade vi gränssnitten på en pappersprototyp för att an- vändaren skulle känna sig fri att komma med åsikter och kritik. Pappers- prototypen gick snabbt att utveckla och vi trodde att testanvändarna var mer benägna att kritisera och reflektera kring designen om den inte kän- des färdig och opåverkbar. Som utvecklare är det ofta lättare att ändra designen i en pappersprototyp jämfört med i produkten.

Vid utvärderingen skulle vi även säkerställa att de användbarhetskrav som vi ställde på vår produkt i kravspecifikationen var uppfyllda genom att först användaDIN-metoden och sedan intervjua och observera testan-

vändare. När vi använde DIN-metoden gick vi igenom punkterna i den

Till vår hjälp i värderingen hade vi definitionen av användbarhet, se stycke 5.1, för att se om vår produkt var användbar. Det är dock våra krav i kravspecifikationen som var viktigast att uppfylla.

2.3 Metodkritik

Vi har förstås inte haft möjlighet att ta del av all litteratur inom området men har försökt att välja vår litteratur med omsorg. Eftersom XPförordar

att man börjar programmera direkt vid projektuppstarten trodde vi att det fanns det en risk att vi skulle börja bygga systemet med bristfälliga kun- skaper och inte vidareutveckla det på bästa sätt. Så blev det dock inte utan vi byggde om systemet i takt med att vi tillägnade oss nya kunskaper.

Vad gäller användbarhetsmetoder finns en uppsjö designparadigmer att välja bland och vi hade svårt att på förhand veta om vi valde den som är bäst lämpad för detta projekt. Detta är något som vi fortfarande inte med säkerhet kan avgöra men det tycks som om metoden har fungerat bra.

Kapitel 3

Uppgift

Inledningsvis följer en beskrivning av uppgiften i form av en kravspecifi- kation, som grundar sig på den övergripande kravspecifikation som vi fick av Lorensbergs Communication, se bilaga B. Därefter beskriver vi krav- specifikationen kortfattat.

Enkätmodulen kommer att vara en fristående del av Asynja, både på grund av prestanda- och säkerhetskäl. I enkätmodulen ska det finnas möj- lighet att publicera och svara på enkäter samt ta emot och lagra svaren.

Utvecklingen av den fristående modulen ska ta hänsyn till att delar av modulen i framtiden kan komma att integreras i det befintliga Asynjasy- stemet. Det är dock inte troligt att den del där de svarande lämnar sina enkätsvar kommer att integreras i Asynja på grund av säkerhetsskäl.

Användbarhetskraven, krav fem till elva bland de icke-funktionella kraven, är formulerade med inspiration från Jakob Nielsens användbar- hetsheuristiker [8].

3.1 Funktionella krav

1. Inloggningsmöjlighet för administratörerna som ska skapa enkät- undersökningarna ska finnas men behöver inte valideras mot någon extern källa.

2. Administratörer som är inloggade i designapplikationen ska kunna publicera enkäter genom att överföra dem till svarsapplikationen. 3. En enkätundersökning består minst av en frågesamling samt inlogg-

ningsinformation för de som ska besvara enkäten. Denna informa- tion ska finnas i svarsapplikationen.

4. Frågesamlingarna, målgruppernas inloggningsinformation samt en- kätsvaren ska lagras i ett format som gör att informationsutbyte med andra applikationer kan ske på ett enkelt sätt.

5. Varje person i målgruppen ska ha användarnamn och lösenord för att kunna logga in och svara på en publicerad enkät.

6. En inbjudan ska skickas till alla i målgruppen med lämplig informa- tion om enkätundersökningen.

7. Enkätsvaren ska lagras krypterat i svarsapplikationen.

3.2 Icke-funktionella krav

1. De webbapplikationer som skapas ska fungera oberoende av val bland de vanligt förekommande webbläsarna1_.

2. Applikationerna ska vara skrivna i Java och köras under Tomcat på en webbserver.

3. Webbservern som kör applikationerna ska inte ha några beroenden till Asynjas databas eller andra databashanterare.

4. Applikationerna ska vara plattformsoberoende.

5. Användargränssnittet ska vara lätt att förstå och använda för perso- ner med grundläggande datorvana.

6. Systemets användare ska tydligt informeras om vad som har hänt och vad som pågår i systemet.

7. Val av begrepp, koncept och metaforer ska upplevas konsekvent med användarnas verklighet.

8. Användaren ska ha möjlighet att återställa misstag.

9. Applikationerna ska förhindra fel från användarens sida i möjligaste mån genom att tydliggöra när händelser aktiveras.

10. Användaren ska inte behöva ha onödigt mycket information i hu- vudet, utan all nödvändig information ska finnas lätt tillgänglig i systemet.

3.3. Beskrivning av kravspecifikationen 17

11. Antalet interaktioner mellan användare och system för att utföra en uppgift ska minimeras, men inte på bekostnad av något annat användbarhetskrav.

3.3 Beskrivning av kravspecifikationen

3.3.1 Krav på designapplikationen

Inloggning

Användarna ska kunna logga in för att administrera enkätundersökning- arna. Användaren är i detta fall till exempel en skolsköterska eller kurator. Dessa personers inloggningsuppgifter finns redan i Asynjas databas men autentiseringen görs istället lokalt i vår applikation. Detta eftersom det i dagsläget är oklart hur pass integrerad i Asynja som denna modul kom- mer att bli.

Publicera enkäter

När Asynjas administratörer ska publicera en enkätundersökning elektro- niskt måste de välja vilken frågesamling som ska användas i enkätunder- sökningen, och vilka som ska inbjudas till att svara på enkäten.

Datat som beskriver frågesamlingarna och målgrupperna ska sparas i ett format som möjliggör att de kan tillgodogöras från andra system, ex- empelvis Asynja.

De som ska svara på enkäten behöver ett användarnamn och ett lö- senord som de kan använda vid inloggningen till enkäten.

I samband med publiceringen skickas en inbjudan med inloggnings- uppgifter, enkätensURL samt eventuellt meddelande från den som publi-

cerat enkäten, ut via e-post till de som ska svara.

Vid publicering överförs enkäten och information om målgruppen till svarsapplikationen där respondenterna loggar in för att besvara enkäten.

3.3.2 Krav på svarsapplikationen

Inloggning för att svara på enkäter

Inloggningsuppgifterna ska finnas i svarsapplikationen eftersom inget be- roende till direkt kommunikation med designapplikationen får finnas för att kunna svara på enkäter.

Ta emot och lagra enkätsvar i svarsapplikationen

Enkätsvaren ska mellanlagras i svarsapplikationen för att vid annan tid- punkt överföras till designapplikationen. Vid lagring måste känsliga da- ta krypteras eller på annat sätt göras oåtkomliga för obehöriga. Vi måste även specificera hur detta görs för att underlätta framtida importering av enkätsvar till andra system.

Kapitel 4

Översikt av befintliga

enkätsystem

Vi har studerat några befintliga enkätsystem för att hämta inspiration. Med dem som underlag är det lättare för oss att bedöma vad som är rele- vant att ha med i vår enkätmodul. Vi har inget krav på att man ska kunna skapa själva enkäten i vårt program, men vi presenterar skapade enkäter och måste därför specificera vilka element som kan ingå i en enkät.

Det finns ett mycket stort antal befintliga enkätsystem och vi har en- dast valt ut en handfull. Vi börjar med att kort beskriva Asynjas befintliga enkätsystem.