Lektionsbank på Musiklärarportalen.se Grupp 4 Mars 2013 Webbprojekt I / IDV411 / 7,5p 1
Organisation: Linnéuniversitetet Institutionen för datavetenskap, fysik och matematik Gruppdeltagare: Henrik Petersson Christoffer Rydberg Simon Ebeling Dokumenttyp: Rapport Utgivningsår: 2013 2
Förord Vi har i kursen IDV411 Webbprojekt I för första gången fått jobbat direkt mot en riktig kund under vår utbildning Webbprogrammerare på Linnéuniversitetet. Uppdraget gick ut på att utveckla en lektionsbank till sajten Musiklärarportalen, samt att förbättra designen. Denna rapport beskriver uppdraget och dess mål, hur vi vi gått tillväga för att uppnå dem, och avslutas med en analys av hur arbetet har gått. 3
Innehållsförteckning 1.Inledning...5 1.1Bakgrund...5 1.2Problemsomskalösas...5 1.3Syfte...6 1.4Mål...6 1.4.1Lektionsbanken...6 1.4.2Designochanvändbarhet...6 2.Metod...7 2.1Projektmetodik...7 2.2Verktyg...8 2.2.1Trello...8 2.2.2GitHub...8 2.3Versionshantering...8 2.4Ramverk...9 2.5Testning...9 2.6Mötenochkommunikation...9 3.Analys...10 3.1Resultatochmåluppfyllelse...10 3.1.1Lektionsbanken...10 3.1.2Designochanvändbarhet...11 3.2Avvikelserochförslagpåvidareutveckling...13 3.2.1Avvikelser...13 3.2.2Förslagpåvidareutveckling...13 4.Bilagor...15 4.1Bilaga1...15 4.2Bilaga2...16 5.Referenser...18 4
1 Inledning Projektet genomfördes under kursen Webbprojekt I, som lästes under den sista terminen av utbildningen Webbprogrammerare på Linnéuniversitetet. Eleverna blev uppdelade i olika grupper, och varje grupp blev tilldelad varsin verklig kund. Kunden till detta projekt var Linnéuniversitetet, som driver tjänsten Musiklärarportalen för vilket uppdraget gällde. Uppdraget innefattade dels utveckling av en ny plugin men även förbättring av den befintliga designen. 1.1 Bakgrund Musiklärarportalen siktar på att vara den självklara och naturliga samlingsplatsen för Sveriges musiklärare. Musiklärarportalen är en plattform där Sveriges musiklärare kan dela med sig av och diskutera sina tankar och idéer kring musikundervisning med andra musiklärare och forskare. Det finns en önskan om att musiklärare använder portalen till att kommunicera med andra lärare och utvecklar en kollegial samsyn gällande allt som har med musikundervisning att göra. På sikt finns förhoppningar om att plattformen ska leda till att kvaliteten på den svenska musikundervisningen ökar. 1.2 Problem som ska lösas Många av Musiklärarportalens befintliga användare har efterfrågat en funktion för att göra det möjligt att dela med sig av lektionsupplägg till andra användare, inkluderande möjligheten att diskutera dessa. Trots en stadig ökning av användare sedan uppstarten 2012 är det fortfarande låg aktivitet på sajtens diskussionforum. Förhoppningen är att denna ska öka då kommunikationen mellan användarna är en nyckelfaktor till att Musiklärarportalen ska bli en lyckad satsning. 5
Musikläraryrket är ofta ett relativt ensamt yrke då det skiljer sig markant från de vanliga basämnena, och musiklärare har därför sällan någon att bolla tankar och idéer med. Trots det uppenbara behovet finns råder det alltså låg aktivitet på Musiklärarportalens diskussionsforum, och anledningen till detta behöver därför utredas. Mycket sannolikt är att det finns brister i användarvänligheten som måste tas itu med för att få bukt med problemet. Parallellt med detta kommer även designen överlag ses över, och förhoppningen är att förbättringspunkter identifieras som sedan kan ågärdas. 1.3 Syfte Syftet med projektet är primärt att tillgodose befintliga användares behov. Vidare önskar uppdragsgivaren att aktiviteten på Musiklärarportalens diskussionsforum ökar. För att säkerställa ursprunget till den låga aktiviteten kommer initialt en undersökning att göras bland Musiklärarportalens användare där förhoppningar finns på svar som kan leda till att orsaker till problematiken med låg aktivitet uppdagas.. Idag har cirka 20% av landets musiklärare anslutit sig till Musiklärarportalen, och förhoppningen är att implementationen av lektionsbanken samt förbättringarna av desginen kommer att leda till att ännu fler av Sveriges musiklärare ansluter sig till Musiklärarportalen. 1.4 Mål 1.4.1 Lektionsbanken Målet är att skapa en lektionsbank som uppfyller användarnas behov, och skapar ett mervärde för användarna. På sikt är målet att lektionsbanken bidrar till en ökning av kvaliteten på svensk musikundervisning. 1.4.2 Design och användbarhet 6
Målet är att en klar förbättring sker av användarbarheten och designen, vilket skapar nöjdare användare och dessutom genererar en ökad aktivitet på Musiklärarportalens diskussionsforum. På sikt är målet att användarna agerar ambassadörer som sprider ryktet om Musiklärarportalens existens så att fler av landets musiklärare ansluter sig till Musiklärarportalen. 2. Metod I det här kapitlet följer en beskrivning av val av ramverk, versionshanteringssystem och verktyg. Vidare beskrivs hur testning har gått till, samt hur möten och kommunikation genomförts. 2.1 Projektmetodik Under utbildningens gång har stort fokus legat på agil utveckling, och vikten av en bra och balanserad dokumentation. Mycket av projektstrukturen var förbestämd för detta projekt, och den utvecklingsmetod som fick användas var Unified Process (UP) 1. UP är en agil metod som består av fyra faser där var och en av dessa karaktäriseras av ett speciellt fokus (t ex fokus på förberedelse genom skrivande av funktionella krav eller fokus på tester). Utvecklingen skedde i så kallade sprintar (en vecka per sprint). Inför varje ny sprint hade gruppen ett möte där det bland annat diskuterades vad den kommande sprinten skulle innehålla och tasks (uppgifter) som ansågs passa med den övergripande projektplanen lades in i sprinten. En gång i veckan genomfördes möten med handledare, då den gångna sprinten, samt planerna för den kommande sprinten diskuterades. De sista veckorna av projektet valdes dock handledarmötet bort på grund av att arbetet var under kontroll och så mycket tid som möjligt behövdes läggas på implementation och tester. 7
Inom gruppen för projektet genomfördes dagligen ett kort för att hålla koll på hur arbetet fortgått under föregående dag, samt planera den aktuella dagens arbete. Rollen som projektledare delades initialt upp på samtliga projektmedlemmar vilket innebar att man fick vara projektledare en vecka åt gången. Dock valdes en bit in i projektet att en och samma person fick vara projektledare resten av projektet, då detta ansågs vara mer effektivt. 2.2 Verktyg 2.2.1 Trello Som verkyg till sprintarna användes Trello 2. Trello är en gratis webb baserad projekthanterings applikation skapad av Fog Creek Software. I Trello skapar man så kallade brädor, en för varje sprint, där man lägger in de tasks som ska utvecklas i sprintarna. Vad en bräda innehåller är upp till användarna, och i detta projekt användes standardmallen, (se bilaga 4.1), för en SCRUM sprint 3. Vidare finns i Trello möjlighet att tilldela en användare en task, vilket gör det lätt att veta vem som arbetar på en specifik uppgift. Detta var särskilt användbart då på grund av arbetet som skedde på distans. Att använda Trello gick väldigt bra då det var lagom mycket funktionalitet, stabilt och då det fanns möjlighet att skräddarsy sprintarna på ett lämpligt sätt. 2.2.1 GitHub Som bas för projektet användes GitHub 4. GitHub är ett webbhotell för mjuvaru projekt utvecklat med öppen källod. GitHub innefattar bland annat versionshantering (med Git), dokumentation (via en inbyggd wiki) samt ett bugg tracking system. GitHub användes till många viktiga delar av projektet, bland annat för versionshantering (vilket tas upp senare), projektdokumentation (funktionella krav, testfall mm) och för så kallad bugg tracking. Som exempel skapades i början av projektet en kalender som fick utgöra tidsplanen, där projektets milstolpar lades in tillsammans med andra viktiga delar, som till exempelvis planerade möten. Tyvärr uppstod problem med wikin under en tid i projektet på grund av en bugg som gjorde att vissa saker inte blev sparade, men denna fixades relativt snart av GitHubs 8
support. I övrigt fungerade GitHub för det mesta bra. 2.3 Versionshantering Då projektet är ett grupp projekt och inte individuellt måste behövde det finnas ett bra sätt att dela programkoden mellan de olika projektmedlemmarna, och till detta valdes GitHub som versionshanteringsverktyg. Varför Github valdes är för att det har många hjälpmedel utöver just versionshantering, däribland ett inbyggt system för bugg tracking och en wiki som användes som verktyg till projektets dokumentation. 2.4 Ramverk Att välja rätt ramverk för projektet var inte några problem då uppdraget handlade om vidareutveckling av en sedan tidigare existerande plattform byggd på Wordpress 5 tillsammans med BuddyPress 6. Det arbete som utfördes handlade därmed primärt om påbyggnad till den befintliga plattformen, såväl som vidareutveckling av sedan tidigare existerande funktionalitet och design. Planer fanns initialt på att bygga någonting helt nytt i ett helt annat ramverk som Laravel 7 eller Ruby on Rails 8, men på grund av bristande tid valdes dock att arbeta vidare med den befintliga installationen. 2.5 Testning För att fastställa att den nya funktionaliten som byggdes ut var fri från buggar lades mycket tid ner på testning. Projektets testfall skapades manuellt utifrån den funktionalitet som ämnades för implemention, och testades av en annan person inom projektet för att fastställa att testfallen var bra skrivna. Efter genomförandet av testfallen upptäcktes buggar som sedan lades in i GitHubs bugg tracking system och vilka sedan åtgärdades i senare iterationer. Allt eftersom förändringar skedde i funktionalitet och design (på begäran från kund) uppdaterades testfallen så att de hela tiden vara aktuella. 2.6 Möten och kommunikation 9
Under projektets gång hölls regelbunden kontakt med kunden, dels via ett möte en gång per vecka via Connect och dels via e post. Inom projektet användes främst Skype som verktyg till möten. 3 Analys Detta kapitel är en analys av hur projektet har gått. Här tar vi upp de svårigheter vi stött på och hur vi löst dem, huruvida vi anser att vi uppnått målen, de avvikelser vi gjort från ursprungsplanen samt förslag på vidareutveckling av Musiklärarportalen. 3.1 Resultat och måluppfyllelse Om vi lyckats uppnå de långsiktiga målen går av förklarliga skäl inte svara på ännu. Med tanke på det som användarna efterfrågade vad beträffar av förändringar och förbättringar av Musiklärarportalen i den enkät vi skickade ut känns det dock som att chansen är stor att de långsiktiga målen kommer att uppnås. En röd tråd i enkät svaren var att man anser att det varit svårt att hitta på sajten och att informationen varit svår att urskilja på vissa sidor på grund av det ofta saknats en distinkt avgränsning mellan ens sidas sektioner. Detta anser vi att vi har åtgärdat. Det kortsiktiga målet för lektionsbanken tror och hoppas vi att vi uppnått genom vårt arbete, på grund av att de flesta av användarnas önskemål gällande funktionalitet tillgodosetts. Vad gäller användbarheten och designen hoppas och tror vi att dess mål har uppnåtts då vi åtgärdade många av de identifierade problemen som uppdagades i och med enkäten, samt att uppdragsgivaren är nöjd med resultatet. Dock har vi på grund av tidsbrist inte kunnat lägga ner något arbete explicit på förbättring av sajtens diskussionsforum, men vi tror och hoppas att den generella förbättringen av designen kommer att leda till ökat aktivitet på sikt. 10
3.1.1 Lektionsbanken Skapandet av lektionsbanken var det huvudsakliga uppdraget, och hade sedan tidigare haft högst prioritet vad gäller implementation med tanke på den stora efterfrågan från användarna. I enkäten visade sig denna efterfrågan vara tydlig då det var flertalet användare som uttryckte en önskan av en sådan funktionalitet. Vi ville undvika att göra lektionsbanken för avancerad och valde istället att satsa på att göra den så pass avskalad som möjligt vad gäller funktionalitet, med stort fokus på användbarheten. Tittar man på liknande tjänster på nätet (t ex lektion.se) är de ofta krångliga och ologiska. Vidare ligger fokus på dessa tjänster ofta på att man ska ladda upp sedan tidigare skapat lektionsmaterial i dokumentform, vilket gör det hela krångligt då standardisering saknas vad gäller filformat. Vad vi har gjort är att man som användare (genom designen) primärt uppmanas att skapa lektionen direkt på Muskilärarportalen via en mall som är uppdelad i de väsentliga delarna för en lektion. Vidare måste man välja Mål & Syfte samt målgrupp(er). Då uppdelningen av dokumenten är standardiserad blir det enkelt att förstå upplägget på de olika lektionerna, och kategoriseringen underlättar dessutom för användarna när de vill hitta lektioner av intresse. Önskar man att bifoga filer finns denna möjlighet, och de filformat vi tillåter är de vanligaste bild, video, ljud och dokumentformaten. Har man sedan tidigare en skapad lektion på sin dator finns alltså möjligheten att ladda upp denna, men man måste ändå fylla i de obligatoriska sektionerna för lektionen, vilket ger användarna en överblick av vad lektionen handlar om. För att öka interaktionen samt få användare att interagera mer med varandra har vi lagt till möjligheten att kommentara lektionerna. Vidare implementerade vi även en gilla funktionalitet likt den som Facebook har, så att användaren kan visa att uppskattning av lektionen. För att göra det enkelt för användarna att hitta lektioner av intresse har vi som tidigare tagits upp valt att kategorisera lektionerna i 11
olika kategorier, och till detta finns även möjligheten att söka på ett specifikt ord (fritext sökning). Som ytterligare komplement till detta finns möjligheter till sortering via till exempel senast uppladdat, mest kommenterade och mest gillade. 3.1.2 Design och användbarhet I ett inledande skede av projeket gick vi igenom den befintliga designen och försökte hitta en röd tråd vad gäller förbättringspunkter. Det vi identifierade som problematiskt var bland annat att det var alldeles för mycket text på alldeles för stora ytor på förstasidan. Det saknades en tydlig avgränsning mellan artiklarna och nyheterna på och det var svårt att urskilja var en artikel slutade och var nästa började. I linje med detta saknade den grafiska designen kontraster, och det var alldeles för få och bleka färger. I mångt och mycket hade man gått efter Buddypress standardtema, vilket vi anser har flertalet brister främst vad gäller användarvänligheten på diskussionsforumet (de så kallade grupperna ). I detta saknas en tydlig avgränsning mellan grupperna och man har valt att lyfta fram delar som är mindre intressanta, istället för de som verkligen är av intresse för en användare. Många av de svar vi fick i enkäten visade också på dessa brister i designen överlag och detta gav oss därmed ett bra utgångsläge, trots en något sparsmakad kravspecifikation från uppdragsgivaren. För att råda bot på avsaknad av kontrast och dynamik i den grafiska designen valde vi att lägga fokus på att bland annat minska ytan med text på förstasidan, och istället dela in artiklar och nyheter i enskilda element med tillräckligt avstånd från varandra för att man enkelt ska kunna skilja dem åt. Vidare ändrade vi bakgrundsbilden i sidhuvudet till en med mer färger, samt använde oss av dessa färger till ruriker, länkar och annat på resterande delar av sajten. Dessutom ändrade vi typsnitt både på logotypen, rubriker och brödtext och gjorde sidan smalare. Tyvärr visade det sig att designen inte föll vårt uppdragsgivare i smaken då de var ute efter en mer stilren och minimalistisk design. Önskemål fanns istället om att använda sig av Linnéuniversitetets grafiska profil, eftersom Musiklärarportalen är en del av Linnéuniversitetet. Tyvärr fick vi reda på detta när mer än halva projekttiden gått, vilket gjorde att mycket arbete lades ner i onödan och annat planerat 12
arbete fick lida då vi var tvungna att ändra om designen igen. Slutresultatet uppskattades dock av vår kund, och flera av de åtgärder vi gjorde för att öka kontrasten mellan element valde vi att ha kvar. Vi anser därmed att användbarheten (vars brister bland annat bestod av att det var svårt att hitta information) har fått sig ett ordentlig ansiktslyft, och vi hoppas att det kommer att uppskattas av användarna. 3.2 Avvikelser och förslag på vidareutveckling 3.2.1 Avvikelser Det mesta av de funktionella kraven implementerades, även om viss funktionaliteten förändrades under projektets gång. Det enda funktionella krav vi valde att inte implementera var FK 2.3 Användare ska kunna hitta de lektioner som en specifik användare skapat. Tanken var här att vi skulle lägga in en ny flik på användarprofilen för lektioner, och därmed kunna se de olika lektioner som en användare skapat. Anledningen att vi inte implementerade detta var tidsbrist. Den i övrigt enda stora avvikelsen var som tidigare nämnts att vi inte lade ner något arbete på att förbättra användbarheten på Musiklärarportalens diskussionsforum. Dock gjorde vi som tidigare beskrivits en förbättring av designen överlag, vilket vi som sagt tror indirekt kan bidra till en bättre användbarhet även gällande diskussionsforumet. En avvikelse från den ursprungliga planen var att vi valde att jobba med den responsiva designen. Anledningen till detta var att det uppdagades att webbsidan ej var anpassad till fullo för mobila enheter, vilket vi passade på att fixa. De största förändringarna var att vi ändrade menyn (som tidigare inte ens fungerade i en mobiltelefon), samt att vi anpassade artiklarna så att de visas på ett bättre sätt än tidigare. 3.2.2 Förslag på vidareutveckling Något som i ett sent skede efterfrågades från uppdragsgivaren var möjlighet för en än mer detaljerad kategorisering av huvudområde (samt eventuellt ytterligare en kategori), så att man kan specificera vad 13
lektionen handlar om i ytterligare steg. Kategorierna vi implementerat följer läroplanen för musikundervisning, och dessa underkategorier som även de finns specificerade i läroplanen skulle bidra till att komma än närmare den aktuella läroplanens utformning. Detta bör vara lämpligt att börja med om man har för avsikt att vidareutveckla lektionsbanken. En annan sak som efterfrågades av uppdragsgivaren var möjligheten att exportera lektionen som en pdf fil, vilket skulle underlätta för utskrift. I övrigt är ett förslag från vår sida att man särskiljer presentationen gällande de olika filtyperna som kan bifogas, så att det tydligt kan presenteras för användaren att en lektion innehåller till exempel musikfiler (skulle kunna göras tydligt med olika ikoner). När det gäller diskussionsforumet (de så kallade grupperna) används som tidigare nämnts en standardlösning tillhandahållen via pluginet Buddypress. Denna lösning innehåller enligt oss en hel del brister i användarvänlighets synpunkt som skulle behöva ses över. Presentationssidan över de olika grupperna bör vara mer hierarkiskt uppbyggd istället för att visa grupperna och dess händelser knutna till dem på samma sida, vilket kan vara förvirrande för användaren. Möjlighet att visa en användares lektioner, som tidigare nämndes var ett funktionellt krav vi valde att inte implementera är också något man bör fundera på att implementera, då vi tror att detta kan ge ett mervärde för användarna. 14
4. Bilagor Här följer bilagor till projektdokumentet, som visuellt visar på intressanta delar av projektet så som t ex verktyg vi använt, vår dokumentation etc. 4.1 Bilaga 1 Ett exempel på hur en sprint kunnat se ut i Trello: 15
4.2 Bilaga 2 Exempel på hur vår dokumentation ser ut med hjälp av GitHub Wiki. 16
17
5. Referenser Här finns referenser till olika webbapplikationer och sajter. [1] Unified Process http://en.wikipedia.org/wiki/unified_process [2] Trello https://www.trello.com [3] SCRUM http://sv.wikipedia.org/wiki/scrum [4] GitHub https://www.github.com [5] Wordpress http://www.wordpress.org [6] Buddypress http://www.buddypress.org [7] Laravel http://www.laravel.com/ [8] Ruby on Rails http://www.rubyonrails.org/ 18