Rickard Magnusson (Alla individuella uppgifter hittar ni här)
fm22ba - Fredrik Müntzing
Tobias Fröberg - tf22cg
sn22gn - Simon nilsson

Hela arbetet ligger i denna pdfen!


Arbetet är nu uppdaterat och komplettrat!

Bakgrund

Vi har fått i uppdrag att granska Ladok på webb. Hitta eventuella problem och förslag på ändringar, detta skall vi ta reda på igenom att intervjua de personer som använder tjänsten och administrerar den. Under denna 30 minuter långa intervjun kommer vi kunna ställa frågor om hur tjänsten fungerar idag och eventuella problem. De som vi skall intervjua är följande personer,
Birgitta Svensson, administratör,
Sven-Åke Johansson, lärare,
Martin Kling, programansvarig NS,
Morgan Rydbrink, programansvarig ID.

De frågor vi har förberett och vill ha svar på är följande,
Hur går ni tillväga när ni rapporterar betyg idag?
Vad fungerar inte med betygsrapporteringen idag?
Hur skulle ni vilja att det fungerade?
Rapporterar ni elev för elev eller alla elever samtidigt?
Hur arbetar ni när ni tar emot en betygsrapport?
Har ni någon önskan kring hur systemet skall se ut?

Vi valde dessa frågor för att få reda på rutinerna och få en inblick i deras problem och önskemål. Under intervjun så antecknade vi vad som sades. Efter intervjun så renskrev vi våra anteckningar och tog ut de viktigaste punkterna som vi sedan sammanställde.

Sammanställning av frågorna

Under intervjun fick vi reda på hur tjänsten fungerar. Ladok på webb och Ladok är två skiljda system, Ladok på webb används av lärare och elever där lärare kan hämta ut uppgifter om elever, och där elever kan registrera sig till kurser och se slutbetyg på kurserna. Informationen på Ladok på webb hämtas från Ladok. Ladok används av administratören Birgitta Svensson som då rapporterar in betygen efter hon har fått betygsrapporten av lärarna. När betygen är inrapporterade måste respektive lärare skriva under på slutgiltiga betygsrapporteringen. Ett av problem med tjänsten är att rutinerna för att lägga till betyg är omständiga och ostrukturerade. Betygsrapporteringen skiljer sig mycket från lärare till lärare, vissa lämnar in Excel dokument andra Word dokument. Hur lärarna strukturerar betygsrapporteringen är också upp till varje enskild lärare, vilket försvårar för administratörerna då det inte finns några riktlinjer för hur det ska se ut. Det har tidigare funnits en mall för betygsrapportering men den används inte längre på grund av att kurserna förändras och lärare har olika sätt att lägga upp betygssättningen för kursen. Önskemål som kom fram under intervjuerna var att en lista på alla elever skulle finnas tillängligt på webben där man kan sätta betyg och gradera laborationer, där även elever ska kunna se hur de ligger till i kursen och delmomenten. Vilket även underlättar för administratören då all betygsrapportering är strukturerad på samma sätt. Ett annat problem med Ladok är att det inte är så användarvänlig och svår för ovana användare att använda, så om administratören inte är tillänglig så kan ingen annan hantera betygsrapporteringen.


PERSONA LÄRARE


Namn: Elias Häger
Ålder: 45
Yrke: Lärare på Linnéuniversitetet
wpc01_tech.bmp
Elias är en medelåldersman som arbetar som lärare på Linnéuniversitetet och har en årsinkomst på 250,000 kr. Elias har ett stort teknikintresse där han på fritiden leker med sin smartphone som han även använder för att kolla sin mail. Han är en van datoranvändare som använder MSN, Skype, Adobe Connect, Outlook och har bra kunskaper i Office-paketet. Elias föreläser en gång i veckan och använder ofta datorn för att handleda studenterna delvis genom forum, Skype och MSN. Jobbet är mycket viktigt för Elias och jobbar ofta övertid för att hjälpa studenter som alltid kommer först i hans ögon. Det är mycket viktigt för Elias att rapportera in betyg i god tid och på ett korrekt sätt. För att få en överblick och rapportera in betygen använder han Ladok på Webb minst tre gånger i veckan samt använder och uppdaterar kurshemsidan dagligen.
Elias bor tillsammans med sin sambo och två barn i ett radhus i utkanten av Kalmar. Där han på fritiden gillar att umgås med vänner och bekanta. En gång i veckan tränar han på det lokala gymmet. Han umgås även mycket med sin familj och tar gärna barnen till badhus eller andra aktiviteter.


PERSONA ADMINISTRATÖR



Namn: Ingrid Lindquist
Ålder: 55 år
Yrke: Administratör på Linnéuniversitetet
wpc01_admin.bmp
Ingrid är en medelinkomsttagare som bor i utkanten av Kalmar tillsammans med sin man och två barn. När hon ska ta sig in till jobbet åker hon tillsammans med sin man. Det första hon gör när hon kommer till jobbet på morgonen är att starta upp Outlook för att kontrollera om det finns någon inkommen e-post att svara på.
Under hela dagen sitter Ingrid väldigt mycket i ett system som heter Ladok, där arbetar hon med att fylla i uppgifter om elever och rapportera in de betyg som kommit via lärarna på skolan. Varje dag blir Ingrid avbruten 2-3 gånger för att svara på frågor eller hjälpa någon student. Ingrids ledord är att studenterna alltid ska komma först, därför försöker hon fylla in information så snabbt som möjligt samt hjälpa de elever som behöver hjälp dagligen.

Intresset för teknik är inte stort, däremot har Ingrid goda kunskaper i hur man använder en dator och de ”vanliga” program, såsom Officepaketet och Internet Explorer. Ingrid anser att de system hon jobbar med ska hjälpa henne till att få sina uppgifter gjorda i tid så att hon slipper lägga tid och tankar på jobbet när hon är hemma.
Ingrid brukar inte kommunicera så mycket privat på Internet, hon är inte medlem i några communities utan använder andra ”klassiska” kontaktformer när hon vill komma i kontakt med sin släkt och vänner.


BEHOV

Vi har sammanställ data från intervjuerna och kommit fram till några behov som lärarna administratörerna har.
Lärarnas behov
  • Att på ett lätt sätt kunna rapportera in betyg.
  • Betygsrapporteringsmallen ska vara lätt att anpassa för varje kurs.
  • På ett enkelt sätt kunna få ut kurslistor.
  • Det ska vara lätt att navigera.
Administratörens behov
  • Lätt att hantera systemet.
  • Enkelt att rapportera in betygen.
  • Lärarna använder sig av en mall för att rapportera betygen så det är lätt att se vilket betyg som är satt.
  • Få in betygen i god tid från lärarna.
  • Att inte få in ströuppgifter, utan att få in de klassvis.


ANVÄNDERFALL 1 - Elias Häger


Uppgift: Rapportera betyg
Beskrivning: Läraren ska rapportera in betyg för samtliga i klassen
Aktör: Läraren, systemet
  1. Läraren går till Ladok på Webb.
  2. Läraren loggar in på sitt konto.
  3. Läraren klickar på betygrapportering i menyn.
  4. Läraren väljer kursen som är avslutad.
  5. Läraren klickar på klassen han vill rapportera (WP09C, WP09D, ID09C etc.)
  6. Läraren får då fram hela klasslistan och kan sätta betygen via en dropdown meny (U, 3, 4, 5, Komplettering).
  7. När alla betyg är satta klickar läraren på Slutför och får se en bekräftelse där han kan dubbelkolla om han gjort rätt.
Alternativ 1 – Missade att skriva in betyg på någon elev.
Vid steg 7 så visas ett felmeddelande om läraren glömmer att sätta betyg på en student.
  1. a, Läraren får en indikation på vilken student han har missat och kan sätta betyget på studenten.
  2. b, Läraren klickar på Slutför igen och om alla betyg är satta visas bekräftelse.

ANVÄNDERFALL 2 - Elias Häger


Uppgift: Hämta kurslistor
Beskrivning: Läraren ska hämta en kurslista
Aktör: Läraren, systemet
  1. Läraren går till Ladok på Webb.
  2. Läraren loggar in på sitt konto.
  3. Läraren klickar på hämta kurslistor.
  4. Lärare väljer den aktiva kursen som han vill ha kurslista på.
  5. Läraren ser då hela kurslistan.
  6. Läraren kan genom att klicka på skriv ut och får ut kurslistan.



Scenario – Ingrid Lindquist


Ingrid vaknar alltid klockan kvart i sju på vardagarna, hon tar på sig sina tofflor och morgonrock för att gå till köket och äta en stadig frukost. Den består oftast av fil tillsammans med svartvinbärssylt, en ost och skinkmacka slinker också gärna ned. Ingrid läser alltid tidningen på morgonen.
När Ingrid kommer till jobbet blir hon avsläppt av sin sambo, hon går snabbt in för att sätta på första koppen kaffe. Det första Ingrid gör när hon kommer till datorn är att starta Outlook för att kolla sin kalender efter eventuella möten som inte får missas. Därefter börjar Ingrid läsa samt svara på eventuella nyinkomna mail. Det är inte ovanligt att den första halvtimmen går åt till just detta.
Efter att svarat på de mail som inkommit går hon direkt in på systemet Ladok På Webb, när hon loggat in ser hon ett meddelande om att det finns nya aktiviteter att behandla. Två stycken kursansvariga har rapporterat in sina studenters betyg och dessa måste hanteras. Hon klickar på en länk i meddelandet som går direkt till de aktiviteter hon behöver utföra för att godkänna en inskickad betygsrapport.
När hon godkänt en av rapporterna går hon snabbt vidare på den andra betygsrapporten, där misstänker hon att någonting inte riktigt står rätt till, hon ringer därför upp Elias (kursansvarige) för att kontrollera att uppgifterna stämmer. Elias bekräftar Ingrids misstanke, detta var ett litet fel så Ingrid kunde ändra det manuellt och därefter godkänna betygsrapporteringen.


KRAVSPECIFIKATION ADMIN/LÄRARE


Vilka huvudfunktioner skall finnas?
  • Hämta kurslistor
  • Sätta betyg
  • Rapportera betyg på ett enkelt sätt
Varje huvudfunktion bör också beskrivas utifrån följande:
Vilka funktionella krav har dessa?

Vilka icke-funktionella krav finns?
  • Fungera i alla webbläsare
  • Lättanvändligt

Vilka kontextbaserade krav finns?
  • Dator
  • Internetuppkoppling

Vilka databaserade krav finns?
  • Betygsskalor, U, 3, 4 , 5 och Komplettering.
  • Betygslistor i Excel-format och Word-format
  • En standard mall skickas till admin.

Vilka användarbaserade krav finns?
  • Lätt att förstå gränssnittet.
  • Lätt att navigera och använda systemet.

Vilka användarhetskrav finns?
  • Lätt att hitta det man söker
  • Förstå var man är och hur man navigerar sig fram.
  • Fokus på rätt saker
  • Bra kontraster och struktur

Prototyping

Vi började med att ta fram en low fidelity prototyp igenom att skapa ram och linjer samt text i photoshop som vi sedan skrev ut och för att illustrera interaktivitet så som dropdown menyer och popups så använde vi pappersbitar med alternativen på.

Våra test av low fidelity prototypen visade en hel del funktionella brister. Bland annat blev testpersonerna över när man skulle välja kurs och klass, vilket resulterade i att vi la till en kort beskrivning över dropdown menyerna samt en Visa knapp för att förenkla momentet. Sen framkom de att vissa menyalternativ krockade på grund utav likheter i namn. Ett annat problem som framkom var att det var oklart hur arkiv knappen skulle fungera samt vad den gjorde. Detta löste vi genom att lägga till en beskrivning av knappens funktion. En av testpersonerna påpekade att det var svårt att veta om betygen hade skickats in, genom att ha en popup box efter att man har bekräftat. Annars så fick vi väldigt bra feedback på vår funktionalitet.

När vi tog fram vår high fidelity prototyp så implementerade vi den feedback vi fått från vår low fidelity prototyp. Som grund för vår design använde vi den nuvarande Ladok på Webb som vi sedan modifierade genom att ta bort de menyerna som var överflödiga. Samt lade till lite menyval så som logga in, betygsrapportering, hämta kurslista och Nya händelser. För att förtydliga våra listor bytte vi färg på varannan rad för att förenkla betygssättandet.

Low fidelity





High fidelity




------------------------------------------------------ Comment 1 ----------------------------------------------------
Morgans kommentar: Generellt tycker jag att ni valt frågor som ligger på en bra nivå då ni fokuserar på frågor kring hur våra rutiner ser ut idag. Det är ju just dessa som ni skall stödja i den tjänst som ni skall ta fram. I detta skede är detta av största vikt. Man hade även kunnat tänka sig att ni gått igenom frågor som vilka system som finns idag för att utforska dessa ytterligare. Som jag ser det har ni i stort främst målorienterade och systemorienterade frågor, vilket är bra. Ni har också främst öppna frågor vilket i just detta medium passar riktigt bra då ni är i den utforskande fasen. Längre fram i processen är det mer naturligt med mer slutna frågor då man mer behöver stämma av enskilda frågor.

Jag hade gärna också sett att ni i detta dokument (på wiki-sidan) motiverar varför ni valt de frågor som ni gjort, hur ni planerat att lägga upp intervjun samt att ni också visat att ni tänkt igenom hur själva sammanställningen och vidare dataanalys skall genomföras. Detta hade gett mig en större inblick i vilken förståelse ni som grupp och enskilda personer har samt tror jag även lyft även er diskussion kring det ni kommit fram till ytterligare. I stort tycker jag att ni gjort ett fullt godtagbart arbete, men vidare förklaring kring hur ni tänkt hade lyft detta ytterligare.

------------------------------------------------------ Comment 2 ----------------------------------------------------
Morgans kommentar: Det ser ut som att ni redan nu kommit en bra bit på vägen vilket är trevligt. Grunden på era personas är bra; ni har valt bra bilder som känns väl valda samt bra evokativa namn som är lätta att komma ihåg. Lite synd att ni inte även gjort ett moodboard då detta skulle gjort ert persona mer levande. Och just mer levande är något som jag tycker att ni kan arbeta vidare med, detta främst genom att beskriva mer ingående vem denna person är. Målet med ett persona är ju att få en levande bild av vår användare, någon som vi kan relatera till. Ni är redan nu en god bit på vägen, men var inte rädda för att förklara mer målande. Om vi inte gör detta bra så riskerar vi att få en kort sammanställning av data, och det är ju för en viss användare vi utvecklar något, inte för en rad data.

Behoven som ni tagit fram är intressanta, men vart får ni dessa från? Det optimala hade varit om ni hade gjort tydligare scenarier. Ni har ju gjort ett fåtal ovan, men ni bör tänka på att dessa skall spegla hur en tjänst hjälper användaren i sin vardag genom att visa vad användaren gör med tjänsten i en viss kontext. Gör vi detta bra så kan vi från våra scenarier få ut de behov som ligger och även grunden till de huvudfunktioner som tjänsten skall göra. Således skulle ni behöva fler scenarier som täcker in samtliga handlingar som vår användare gör med er tjänst. Ett scenario skall visa på vad tjänsten gör, inte vilka problem som finns idag. Visserligen KAN det användas på detta sätt, men det hjälper då inte lika mycket vad gäller att ta fram en kraftfull kravanalys.

Om ni får till era scenarier bra så kan ni använda dessa för att ta fram behov och huvudfunktioner. Då faller det naturligt att använda sig av användarfall, vilket ni gjort. Dessa är ju betydligt mer detaljerade och visar mer exakt vad som görs i tjänsten. Tänk över om ni verkligen tänkt och fått med samtliga funktioner som skall göras i tjänsten i era användarfall. Det ser ganska tunt ut. Skall man inte till exempel kunna lägga till delmoment? Hämta klasslistor? Hämta nya kurser? Vad gör systemet automatiskt för användaren och vad kan jag göra själv? Utifrån den data som ni har bör det finnas några fler funktioner än den ni har specificerat. Var också noga med att i era användarfall noga visa på vart systemet interagerar och vart användaren interagerar så att man får en klar bild över den arbetsbörda som användaren får lägga ner.

Utifrån ovanstående så får man rejält med underlag för att göra en kravspecifikation. Ni har redan en ovan, vilket är okej, men kan bli betydligt bättre. Jag skulle säga att ni får en bättre kravspecifikation genom att börja med att gå igenom era scenarier och ta ut samtliga huvudfunktioner, därefter går ni igenom era användarfall och plockar ut varje underfunktion och lägga dessa under huvudfunktionerna och till sist specificerar ni under varje funktion vilken data som behövs för varje funktion. Detta gör att ni får det otroligt mycket enklare i prototyp-arbetet då ni här kan fokusera på interaktionen och placering av element och kan då lägga mindre tid på att diskutera data och krav.

------------------------------------------------------ Comment 3 ----------------------------------------------------
Kommentar Morgan: I stort tycker jag att ni har en ganska tydligt sammanfattning av er utvärdering. Det är dock oklart hur ni använt er av DECIDE. Förtydliga gärna så att det klart framgår hur ni använt er av detta. Det känns snarare som att ni här presenterar ert tidigare arbete än hur ni tänkt att lägga upp arbetet med er utvärdering. Det gick vill att ni kompletterar med är att tydligt visa hur ni använt er av decide, hur ni genomfört själva utvärderingen samt koppla ert resultat till era användarfall. Ni visar ju redan nu hur ni kopplat konkreta problem till vissa designprinciper, för men att göra det ännu tydligare bör ni först upprepa de användarfall ni utgår från, därefter visa på de problem som finns i varje användarfall och till slut presentera lösningar för varje. Det är alltså främst en bättre struktur jag efterfrågor för att jag skall kunna följa ert arbete på ett enkelt sätt. Vad gäller designprinciperna tar ni här upp 3 stycken, men ni nämner inte alls affordance, överenstämmelse eller mappning. Även dessa bör förstås finnas med både i genomförande och i ert resultat. Ni utgår från ett helt set med designprinciper i en utvärdering för att täcka upp så mycket problem som möjligt. Vill dock poängtera att det sätt ni presenterar de problem som ni hittat och de lösningar ni lagt fram är bra och känns relevant.