Slutrapport - VisitOland

Transkript

1 Slutrapport - VisitOland 1DV411, Webbprojekt I, LNU Johan Johansson Sjölin jj222cr@student.lnu.se, Madeleine Landerhjelm ml22ny@student.lnu.se, Gunnar Annerstedt ga22bb@student.lnu.se, March 30, 2012

2 Sammanfattning Visitoland.com ska bli den ledande webbplatsen för att främja turism på Öland. Meningen är att Visitoland.com är det första steget av många som senare kommer leda till ett företag som kommer att utveckla liknande webbsidor för andra områden i landet, samt för andra öländska företag, även arbete med behandling av lm och fotogra. Visitoland.com ska täcka i stort sett allt som kretsar kring Öland och ska vara till stor nytta om man som besökare benner sig på plats, bor permanent på Öland, eller vill resa dit. Webbplatsens innehåll ska presenteras på era språk där varje språk översätts av kompetenta personer inom området för att komma bort i från googles översättningsapplikation. Idag nns Svenska, Engelska och Tyska framtaget och med tiden ska det tillkomma er språk som polska och italienska. Då visitoland.com är en helt ny webbsida och kund ville få upp den snabbt valde vi att göra den i wordpress då det ska vara enkelt för kund att uppdatera och lägga till innehåll på sidan. Själva webbsidan ska vara användarvänlig och lätt att hitta på. Längre fram är tanken att man ska gå ifrån wordpress och bygga en helt egen applikation för att kunna skräddarsy den helt efter ens egna önskemål samt återanvända strukturen på andra webbsidor. 1

3 0.1 Förord Projektet har legat under en tio veckors period på halvfart i kursen 1DV411 Webbprojekt I. Projektet är gjort i en grupp på tre personer. Uppdraget var att göra en enkel första struktur för webbsidan visitoland.com som ger kund en bra grund för vidareutveckling av webbsidan samt möjligheten att enkelt publicera material under olika kategorier. För att försäkra sig om ett bra resultat har projektmetoden SCRUM använts. Det innebär att hela projektet har drivits itterativt och varje vecka har utvärderats individuellt Varje vecka har vi bytt projektledare i syfte av att alla ska få vara projektledare, detta har skett i ett rullande schema och vi har haft tydliga uppgifter menade åt projektledaren. Vi har valt att använda oss av WordPress och skapat ett skräddarsytt tema efter vår kunds krav och mål samt önskad funktionalitet. 2

4 Innehållsförteckning 0.1 Förord Introduktion Inledning/badgrund Syfte och mål Projektorganisation Genomförande Metodik Teknik Resultat Resultatbeskrivning Måluppfyllelse Avvikelser/efterkalkyl Slutsats - varför blev det såhär? Förslag på vidareutveckling Litteraturförslag/dokumentationshänvisning Förslag till förbättringar inför kommande projekt Bilagor Frågeställning

5 0.2 Introduktion Inledning/badgrund Visitoland.com är en helt ny webbsida som utvecklas då det inte nns någon liknande på Öland. Kund började undersöka hur turistnäringen var på Öland och det visade sig snabbt att den inte fungerade som önskat. De redan förekommande sidorna var i sämre genomförande när det gäller information för personer som ska till Öland, de som varit där eller när man benner sig på ön. Detta gäller både som turist eller fast befolkning. De webbsidor som nns nu har i snitt ca besökare per år där unika besökare är ca och 65 % är från Sverige. Personerna bakom Visitoland.com vill ändra på detta och arbeta mer internationellt samt utöka den svenska marknaden för att främja Öland. Målet är att bli den ledande webbsidan över Öland där man lätt ska kunna gå in och få den informationen man behöver för sin vistelse. Innehållet kommer vara kontinuerligt uppdaterat och aktuellt. Detta ska resultera i minimum på 1,5 miljoner besökare per år inom tre år. Visitoland.com ska fungera både nationellt och internationellt. Språken man kommer att börja översätta till är engelska, tyska och italienska. Innehållet kommer att översättas av personer med god kunskap inom respektive språk. När vi ck detta projekt tilldelat till oss hade kunden redan skaat sig ett antal domännamn. Sedan detta initiativ har kund även slagit i hop sig med en annan grupp med liknande motivation för att sträva mot samma mål istället för att konkurera med varandra Syfte och mål Syftet med vårt projekt är att lägga grunden för utvecklingen av en digital portal till Öland som skall fungera som ett nätverk för besökare, tidigare, återkommande samt nya. Prolen skall vara internationell och nationell och täcka i princip allt om Öland och ska därför vara redo för erspråkighet. Den skall inrikta sig mot olika åldersgrupper och kategorier som exempelvis barnfamiljer, ungdomar, bröllopspar, äldre och funktionshindrade. Materialet som publiceras ska kunna vara text, bilder och video. Bilder ska nnas i både bildspel och inlägg på sidan. På grund av den snäva tidsramen har vi tillsammans med kund bestämt att målet under våra tio veckor begränsas till en fungerande startsida som representerar konceptet samt funktionalitet trots att diverse undersidor ej kommer vara klara. Fokus ska med andra ord ligga på att skapa en välstrukturerad ram man kan bygga vidare på efter projektets slut och hjälpa kund att visualisera sina idéer. Det är även viktigt att det i ett tidigt stadie implementeras en god sökmotorsoptimering så att sidan snabbt klättrar och 4

6 konkurerar med de webbsidor som idag nns kring Öland som resmål Projektorganisation Uppdragsgivaren har varit Lars Nilsson-Lund samt fem av hans partners. Figure 1: Projektorganisation Lars har kommit med idéer om hur sidan ska se ut och vad som ska nnas på den. Annika som är fotograf och konstnär har gett oss bilder till sidan. Ronny gav oss den korrekta färgpaletten. Projektgruppen, bestående av Madeleine Landerhjelm, Johan Sjölin och Gunnar Annerstedt. Projektledare har vi haft ett rullande schema på. var tredje vecka. Där vi har haft rollen Projektgruppens handledare under projektets gång har varit Tobias Ohlsson. Webbhotellet vi har arbetat med är Binero. 5

7 0.3 Genomförande Metodik Vi har haft ett rullande schema på projektledare och bytts av veckovis där projektledaren har fått skriva och planera kommande vecka med tillhörande sprint backlog. Sprint backlog har använts för att dokumentera varje medlems timmar och gruppens sammanlagda arbetstid veckovis samt ge en bra översikt över vad man ska jobba med under veckan. Varje vecka har inletts med ett möte inom gruppen där man diskuterar föregående samt kommande vecka och därefter ett möte med vår handledare för att diskutera hur arbetet går. Varje vecka har avslutats med ett kundmöte för att visa upp vad som har gjorts och hur projektet ska gå vidare. Genom att arbeta iterativt har vi under projektets gång haft möjligheten att styra resultatet mot ett gemensamt mål. Det som kändes aktuellt och viktigt i början av projektet har sedan fallit av och det har fokuserats på andra områden. Detta har gjort att vi i projektgruppen tillsammans med kunden känner oss nöjda över det resultat vi ck fram. Varje vecka har vi haft något att visa vår kund, det medför att man snabbt kan få feedback på resultatet för veckan och man kan sträva vidare i samma riktning mot nya mål. Tidsrapportering och veckoplaneringar har vi gjort i form av en sprint backlog och en burndown chart, vilket är ett diagram som visar hur man, i antal timmar, ligger till tidsmässigt jämfört med den tid man uppskattar i sin sprint backlog. Med dessa två vektyg kan man tidigt i varje vecka hitta arbetsuppgifter samt fördela dem inom gruppen. Varje fredag efter kundmöte har nästa veckas projektledare skapat en ny sprint backlog där man för in punkter som har kommit upp under veckan och på mötet med kunden. Man uppskattar hur lång tid varje punkt kommer ta och då får man en sammanlagt tid, den sammanlagda tiden har vi siktat på att ligga omkring sextio timmar per vecka. I slutet av varje vecka när alla tider har rapporterats kan man utvärdera sin burndown chart, och reektera över vad man kan förbättra. Det tar ett tag innan man kommer in i konceptet och tänket kring hur man uppskattar tid och listar ut vilka punkter som ska ingå. När man väl gör det är det en ovärderlig tillgång, både innan, under och efter varje vecka Teknik Vi har använt oss av CMS-verktyget WordPress. CMS står för Content Management System och är ett färdigt innehållshanteringssystem som man sedan kan anpassa efter sina egna önskemål. WordPress ses av många som 6

8 en blogtjänst, denna syn på WordPress håller däremot på att arbetas bort och ses istället som ett brett CMS-verktyg där man som utvecklare kan ta fram applikationer med många olika ändamål. Under projektets gång har det tagits upp av kund att vi borde byta till ett annat CMS-verktyg, som Drupal eller Joomla. Vi har dock undanböjt alla dessa förslag på grund av tidsbrist samt att vi ansåg att det inte fanns några fördelar i de CMS som togs upp gentemot WordPress som motiverade en sådan ändring. Vi har utfört en ytlig undersökning av era CMS-verktyg. Den slutsats vi kom fram till är att de esta verktyg ger ungefär samma möjligheter, men WordPress är enklast för en ovan programmerare att uppdatera då det är väldokumenterat och välanvänt vilket leder till att man enkelt kan vända sig mot olika källor för att hitta lösningar på eventuella problem. De första veckorna av projektet delade vi kod med hjälp av verktyget Tortoise SVN och arbetade i en lokal utvecklingmiljö. Men ju längre in i projekttiden vi kom desto mer insåg vi vikten av att låta det ligga skarp men lösenordsskyddat på ett webbhotell. Tillsammans med vår kund bestämde vi oss för denna lösning eftersom alla i gruppen såg vikten i att använda sig utav något visuellt och som alla kunde ta del av från sina respektive arbetsplatser. Detta gjorde att vi snabbt kunde göra ändringar och snabbt utvärdera dem. Om någon ck en idé över vad som behövdes göras som inte var specicerat i vår sprint backlog, ck vi förklara att det inte var aktuellt den vecka vi befann sig i utan ck skjutas upp till veckan efter då vi hade möjlighet att konstruera en ny sprint backlog. Att använda Tortoise SVN som versionshanteringsverktyg när man jobbar med wordpress var en utmaning. Wordpress fungerar genom att man har en databas där alla kongurationer är förklarade. Därför måste man om man delar projekt även dela versionen av databas. Detta görs genom att inkludera en exporterad SQL-databas i varje version. Detta gjorde att varje person som utvecklar mot projektet måste ha samma absolut sökväg till ler och länkar. Detta skapade många problem och det smidigaste hade varit om man tidigt hade laddat upp en databas på webbhotellet som alla kunde använda, även när man utvecklade lokalt. Men för att komma åt databasen på webbservern lokalt behövde vi tunnla en anslutning via en SSH-tunnel, dock tillät det SSH-program som webbhotellet tillhandahöll endast två samtidiga anslutningar. I och med detta bestämde vi att vi skulle ladda upp hela projektet skarp och utveckla mot det. Vi har haft begränsad testning under projektets gång. Som vi nämner i testspecikationen så beror det på att vi använder ett CMS som redan är utförligt testat samt att vi ej har gjort några ändringar i källkoden. Vi tittade på Selenium som är ett plugin till Firefox som utför automatiska tester i WordPress. Vi tog även fram ett antal testfall som vi använde för att 7

9 bekräfta att grundfunktionalitet fungerande och som lärande moment. Testfallen upprepades även när vi yttade från lokal till skarp utvecklingsmiljö och när vi bytte plugin som skötte erspråkighet. 8

10 0.4 Resultat Resultatbeskrivning Under projektperioden började vi att lägga upp en enkel sida på visitoland.com för att förbättra SEO tills den riktiga sidan ska upp. Där skulle enligt kunds önskemål nns bildspel, facebook gilla och översättning på era språk. Vi uppnådde visionen där vi bland annat skulle bygga upp en struktur för inlägg. Vi gjorde sex stycken olika strukturer för att lägga in inlägg. Två av dessa strukturtyper syns på en bild som nns längst ner i detta dokument, som följs av en bild som visar koden som åstadkommer detta. Under projektperioden har vi uppnått de esta av punkterna i visionen. Vi har skapat en struktur för startsida och undersidor och hur man lägger till nytt material för att denna struktur ska bibehållas. Kund har fått dokumentation som i steg för steg förklarar hur nytt material läggs till och bestämmelser som nns för exempelvis bild storlekar Vi har inte integrerat Booking.com vilket var tänkt från början då vi med tiden tillsammans med kund bestämde oss för att jobba mer konceptuellt istället för att sträva för att få fram en färdig sida. Kund har dessutom inte börjat knyta boenden till sig som skulle kopplas till bokningssystemet och därför bestämde vi tillsammans att förbise detta mål Måluppfyllelse Det är viktigt att man i början av projektet hittar ett gemensamt mål, och en gemensam vision av vad som ska komma ur de veckorna man har avsatt till uppgiften. Vi lade väldigt mycket kraft på att vi skulle få en genomtänkt vision som man skulle ha som grund för att driva projektet i rätt riktning. På det första mötet med vår kund tog vi upp detta och förklarade vikten och poängen med att skapa en vision. Under de första veckorna började den ta form under tillsyn av kund, detta för att snabbt kunna korrigera om vi i gruppen hade misstolkat kundens vision. När man bygger ett projekt med en gemensam vision som grund är det mycket enkelt och troligt att man når samma mål. Om vi inte använt en vision hade det varit mer troligt att antingen kunden eller projektgruppen inte hade varit nöjd med resultatet. Vissa punkter på visionen faller bort allt eftersom man arbetar med det man prioriterar, det medför att man slipper utveckla funktioner som man kanske aldrig behövt. Vår mening är att visionen ska vara exibel och det ska ändras i den om man stöter på saker som har blivit nerprioriterade till den nivån att man inte längre vinner något på att utveckla dem. I och med att detta projekt är en del av vår utbildning ska man även ha i åtanke att 9

11 varje punkt helst ska innehålla ett lärande moment i utbildningssyfte. Ett stort mål vi haft är att vi ska ha god kunskap om WordPress när vi är färdiga med projektet. Detta har vi lyckats med eftersom vi skrivit ett tema med WordPress som grund. Denna punkt är ett exempel som både stämmer överens med det som kund vill nå samt blir ett lärande moment. Eftersom wordpress är ett expanderande och eftertraktat koncept på webben kände vi att det var viktigt att skaa denna erfarenhet. 10

12 0.5 Avvikelser/efterkalkyl Vissa veckor har det varit svårt att hålla sig inom ramarna av sprint backloggen på grund av funktioner eller designförslag som kommit upp under veckan. Sådant som kommer upp under veckan ska egentligen skrivas ner och tas upp när man skriver nästkommande veckas sprint backlog, men detta är inte alltid lätt eftersom det kan komma upp bra idéer eller väldigt omfattande ändringar under veckan. I vårt fall hade vi även till en början svårt att stå emot vår kunds entusiasm. Eftersom vår kund var väldigt driven och impulsiv var det svårt till en början att avböja de förbättringsförslag han kom med under veckorna vilket ledde till att vi gick ifrån vår planering. Efter en tid ck vi dock bra kontroll och förklarade att vi inte kunde ändra på vår veckorplanering eftersom hela konceptet av SCRUM bygger på att man arbetar med små moduler varje vecka och sedan utvärderar de i slutet av veckan när man gör en ny veckoplanering. Vi klagar absolut inte på att vår kund var väldigt involverad i vårt arbete, vi är inte heller avundsjuka på projekt som har en kund som är involverad väldigt lite eller inget alls. Vi tror och tycker att det är viktigt att kunden har bra översyn av vad gruppen gör under veckorna, då kan man i ännu större utsträckning styra sitt resultat till det att både kunden och gruppen är nöjda. Det man hade kunnat förbättra var att utbilda kunden inom den projektteknik man använder så att dem får full förståelse för hur man jobbar vecka till vecka och detta skulle ha gjorts första veckan. Det är också svårt att hålla sig till sin vision i och med att synen på slutresultatet ofta ändras under projektets gång. I och med att projektet är så pass levande är det viktigt att man utvärderar alla förslag på förändring. Därefter bestämmer man sig för om man ska gå implementera dessa förändringar eller om man skall hålla sig till det man från första början planerat. Exempelvis ck vi som förslag efter ungefär halva projekttiden att byta CMS-verktyg då kund var osäker att WordPress kunde hantera allt kund vill ha med. Vi var väldigt tveksamma till förslaget och pekade istället på fördelarna med WordPress och undersökte de delar som kund inte trodde att WordPress klarade av. Efter ungefär en veckas överläggning, där vi i projektgruppen även visade att WordPress klarade av de orosmoment som kund hade, bestämde vi tillsammans med kund att inte gå igenom med förslaget utan fortsätta på det man planerat från början. Hade vi genomfört denna ändring hade allt vårt tidigare arbete varit förgäves. I efterhand ångrar vi inte att detta förslag blev nerröstat, det hade inneburit en stor förändring i vision, baskrav och projektet i helhet. Det fungerade även som en bekräftelse på att vårt val av WordPress var rätt från början. Från början var visionen att vi skulle överlämna ett skal till en webbsida som skulle vara lätt uppdaterad och framförallt skalbar som kund sedan 11

13 skulle vidareutveckla. Ju längre vi kom in i projektet desto mer säker var kunden på att han skulle starta en webbyrå på Öland, med VisitOland.com som huvudsaklig syssla. Detta gjorde att vissa krav ändrade sig. Projektet tog en oväntad svängning och det vi utvecklade inom wordpress skulle istället fungera som en prototyp för den verkliga sidan. En prototyp där man snabbt skulle kunna göra ändringar och utvärdera dem, utan att behöva gå igenom allt för stort jobb. För vår del var förändringen relativt liten eftersom vi fortfarande skulle utveckla en sida som såg bra ut och en som var enkel att uppdatera, dock behövdes det inte lägga lika stor satsning på att det skulle bli en färdig sida som skulle driftsättas vid projekttidens slut. Det är däremot tänkt att den framöver ska ligga tillgänglig för allmänheten medan man utvecklar det andra konceptet paralellt. Vi i gruppen är glada över att projektet har styrt mot ungefär samma mål hela tiden, och det gäller att stå på sig när ändringarna kommer som förslag. Vi har lärt oss mycket om hur en god kommunikation med kunden är viktig och en stor inuens på hur projektet tillslut blir. Vissa gånger blir det för lite gjort och andra gånger får man inte allt gjort, vi känner att vi har hållit det på en hållbar nivå genom hela projektet och har inte varit överväldigade med uppgifter. Detta har gjort att vi kunnat göra varje del utförligt och noga. 12

14 0.6 Slutsats - varför blev det såhär? Eftersom vi har utvecklat efter projektmetoden SCRUM har vi kunnat hålla oss på rätt spår och ha möjligheten att granska varje veckas framgångar väldigt överskådligt Stundvis var det svårt att hålla sig till planeringen på grund av att projektet ofta bytte riktning, trots detta så nådde vi i slutändan de mål vi specicerade. För att dela dokument med varandra har vi använt oss utav Google Docs, där nns ett gemensamt utrymme att lagra dokument, då blir det överskådligt vad man har för dokument och vilka ändringar som gjort i dom. Det har hjälpt oss väldigt mycket. Gruppen har fungerat bra ihop och vi har haft väldigt tydliga uppgifter inom gruppen. Det har gett en bra gruppdynamik och vi kan snabbt beta av saker utan att hamna i diskussioner som troligtvis hade påverkat arbetet negativt. 13

15 0.7 Förslag på vidareutveckling Eftersom vi inte är ansvariga för webbsidan, och att den benner sig i ett tidigt utvecklingsstadie är det svårt för oss att se förslag på vidareutveckling, detta kommer bero på hur projektet drivs vidare av vår kund. Men vår kund hade många visioner och tankar på vad som kan implementeras på sidan. Dessutom kommer det skal vi gjort åt vår kund fungera som en visuell prototyp, därför kommer det vara svårt att hitta nya funktioner som ska nnas med. Skulle det nnas förslag från vår kund att vidareutveckla idéer som uppkom under eller efter vår projekttid kan vi rekommendera att utföra dessa, eftersom vi trivdes bra med Lars som kund och han är väldigt driven. 14

16 0.8 Litteraturförslag/dokumentationshänvisning Titel: Smashing WordPress Undertitel: Beyond the Blog Författare: Thord Daniel Hedengren ISBN :

17 0.9 Förslag till förbättringar inför kommande projekt Att skriva ett acceptanstest som kund får skriva under första veckan för att undvika att man inte håller sig till iterationen. Med ett acceptanstest vet både kund och utvecklare vad som ska göras under pågående period till projektet är klart. Vara mer tydlig mot kund genom att ge kund dokument regelbundet som projektplan, vision, agenda och sammanställning av möte. Även stå emot kunds önskningar så att man inte arbetar med annat än det som är planerat i iterationen och så att projektets storlek inte växer för mycket eller i en riktning som inte är givande. 16

18 0.10 Bilagor Testspecikation Kravspecikation Projektplan Vision Sammanställning av möten Agenda inför möten Tidsrapportering (sprint) Manual (till kund) Ordlista Risklista Mjukvaruarkitektur Iterationsplan Riktlinjer 17

19 0.11 Frågeställning Vad gjorde vi bra respektive vad gjorde vi mindre bra? Till en början hade vi svårt att hålla tillbaka vår kund och deras starka entusiasm som ofta styrde projektet i era olika riktningar. Vi ville även hinna med många av kundens nya idéer men insåg efter ett tag att det inte skulle hålla i längden då det tog en massa mertid från vår sida. Det gjorde även att vi hade svårt att hålla oss till vår sprint backlog. Varje vecka hade vi en projektledare som vi hade rullande schema på vems vecka det var. Projektledaren förberedde inför näst kommande vecka. Detta tillsammans med en god dialog inom arbetsgruppen och regelbundna arbetstider gjorde att vi hade ett mycket bra arbetsklimat och kunde komma förbi problem snabbt. Utvärdering av tidsplanen - höll den? Vad beror det på? Vi arbetade efter SCRUM och gjorde en sprint backlog varje vecka för att dela upp momenten i mindre delar. Detta gjorde att vi ck en bra överblick och kunde se hur timmarna skulle fördelas. Ofta kom kund med nya önskemål samt sa att vi skulle sluta jobba med tidigare idéer vilket gjorde det svårt att följa vår egen tidsplanering. Trots detta så avslutade vi varje vecka mer eller mindre med målen avklarade inom den tänkte tidsfördelningen, även om det inte skildras lika bra i sprint backloggen på grund av att kunds ändrade inriktning. Blev användarhandledningen tillräckligt bra? Kunde vi gjort annorlunda? Det bästa med handledningen enligt vår mening är att snabbt kunna få feedback och korrigera eventuella missförstånd eller fel man gjort när man jobbar med SCRUM. Dessutom har det fungerat som en ventil, där man kan prata av sig om man har eventuella problem inom gruppen, med kund, system och så vidare. Vissa handledarmöten var för vår del överödiga, men vi har inte sett det som negativt, då det mer berodde på att vi inte hade några problem eller frågor att ta upp. Hur fungerade informationsödet mellan projektgrupp och kund? Vad kunde vi ha gjort annorlunda? Kund har varit bra på att hålla oss uppdaterade och komma med information. Däremot skulle vi ha delat med oss av er dokument till kund tidigare för att undvika missförstånd samt förklarat hur SCRUM fungerar och varför man jobbar efter det. Efter varje möte borde även sammanställningen skickas till kund, vilket den tyvärr inte gjorde under de första perioderna av 18

20 projektet, så att dem kunde sett vad som vi kom fram till. Nu i efterhand skulle man kanske även staplat upp punkterna i sprint och skickat till kund för att visa vad som kommer att arbetas på i veckan. Hade alla dessa delar fungerat optimalt skulle det troligtvis resultera i att kund skulle ha bättre förståelse vad som ska göras och vilken tid som beräknas till varje del. Hur fungerade samarbetet inom och utom projektet? Samarbetet har fungerat mycket bra i gruppen. Vi har fördelat uppgifterna för att lättare veta vem som ska göra vad. Inom gruppen har vi kunnat föra en öppen och ärlig dialog och även haft väldigt roligt tillsammans. Var projektmöten, styrgruppsmöten med era lagom långa? Tillräckligt eektiva? Hölls mötena tillräckligt ofta? Kunde vi gjort på annat sätt? Vi hade inga speciella dagar eller tider för projektmöten inom gruppen. Eftersom vi arbetade på att ha en öppen dialog under hela projektet så ck vi kontinuerlig uppdatering av varandra hur det gick. De relativt fasta och regelbundna arbetstiderna har fungerat mycket bra för oss då vi har kunnat ta upp problem direkt istället för att vänta till ett speciellt möte. Hur var riktlinjerna vi ck? Var de tydliga nog? Riktlinjerna vi ck var breda och svåra att få grepp om till en början. Men då vi tillsammans med kund tog fram en gemensam vision tidigt blev det en annan helhet. Koncentrationen låg på att göra det lätt för kund att uppdatera eller lägga till på sidan. Sidan skulle få en fungerande struktur som är användarvänlig. Vi kändes oss till en början även ringrostiga när det kom till de olika delarna av den obligatoriska dokumentationen, men successivt så lossnade även förståelsen kring dem. Motsvarade vi kundens krav? Vi har motsvarat de kraven som kund kom med första veckan och andra. Kund ville då ha SEO, hantera inlägg på sidan, bilder och lmer. Ett administrationsgränsnitt som man lätt kan lära sig var en annan del som kund önskade. Däremot så trodd ekund att utvecklingen skulle gå mycket snabbare framåt och det tog några veckor innan vi ck kund att inse att dessa 10 veckor inte skulle resultera i ett helt färdigt projekt med tanke på deras stora visioner och allt dem ville ha implementerat. Men med tiden så insåg även kund värdet av att ta det lite lugnare och mer utveckla konceptuellt och testa olika idéer så att dem sedan kan ta detta när dem vidareutvecklar sidan. I slutet av projekttiden ville kund till största del jobba med CSS och olika förslag på layout av inläggsstrukturen. I slutändan så har dem fått en 19

21 användarvänlig sida efter deras önskemål som även är lätt att förstå när man är administratör och ska ändra på sidan samt stämmer överens med deras visuella önskemål. Gav vi realistiska förslag på lösningar? Kunde vi gjort annorlunda? De förslag som vi gav kund anser vi vara realistiska. Vi tänkte inledningsvis bygga ett eget CMS innan vi bestämde oss för WordPress. Vi förklarade för kund fördelarna med att använda WordPress då tiden var mycket begränsad och att det skulle medföra att man snabbt skulle kunna få upp projektet med ett fungerande administrationsgränsnsitt så att vi kunde fokusera på annan funktionalitet som också var viktig. Vi tog även snabbt upp med kund när vi insåg att saker som vi testade inte fungerade som vi hade tänkt och tog istället fram andra lösningar. Har vi haft ett system för tidiga varningar om planerna inte följs? Hur har det fungerat? Vi hade regelbundna möten med kund, fredag varje vecka, samt ett bra arbetsklimat inom gruppen vilket gjorde att vi hade en god översikt över hur vi låg till vilket även gjorde att vi hade en god översikt hur vårt arbete gick i förhållande till planeringen. Vad blev resultatet på kort och lång sikt? Resultatet blev som förväntat. Vi hade gärna hunnit med några er funktioner men insåg att det tar längre tid än man trott samt att de delarna även blev nerprioriterade av kund som hellre såg att vi jobbade med olika koncept gällande design och layout. 20

22 Figure 2: Temporär Startsida 21

23 Figure 3: Levande struktur Figure 4: Koden som gör det möjligt för levande struktur 22

24 Figure 5: Bildspelet längst upp på sidan VisitOland.com Figure 6: Ett youtube klipp inlaggt istället för en bild i ett inlägg 23

25 Figure 7: Cloud meny kod Figure 8: Slut giltigt utseende för cloud meny Figure 9: Social hub / språk val 24

26 Figure 10: Breadcrumbs för SEO skäl 25