Handledare: Projektdeltagare: Uppdragsgivare:

Transkript

1 Mobilapplikation ~Projektrapport~ Handledare: Tobias Ohlsson Projektdeltagare: Claes Tillborg Oscar Lillheden Robert Fransson Tryggve Blom Uppdragsgivare: Pelle Sederkvist Marcus Oldin

2 Sammanfattning Vi har under ett par veckor varit med och skapat en mobilapplikation baserat på ett projekthanteringsverktyg. Tjänsten finns idag som en webbapplikation och ägs av Pelle Sederkvist och Marcus Oldin som tillsammans har företaget Coleo Vision AB. Målet med projektet har varit att utveckla en applikation som tar vara på de möjligheter och begränsningar som medföljer de moderna mobila enheter med touch-skärm, såsom ios- och Android-enheter. Den mobila versionen har till stor del byggt på det gamla verktygets struktur men vi har fått tillåtelse att skala bort funktioner som inte går att översätta till det mobila gränssnittet. Vi har även samarbetat med en grupp studenter från Interaktionsdesignprogrammet årskurs 3 beträffande utseende och interaktion. Målet med kursen Webbprojekt 1 är att eleverna ska genomföra ett projekt i grupp och presentera sitt arbetssätt och resultat skriftligt. Rapporten tar upp de olika tekniker, metoder och strukturer som har använts samt vilka verktyg, program och utvecklingsmiljöer vi stött på. Här berättar vi även hur vi uppnått våra mål, vilka svårigheter vi haft och vilka lösningar vi har tillämpat. Även en och annan lärdom har vi lyckats trycka in. Sist ger vi även förslag på några vidareutvecklingar av den applikation vi skapat. 1

3 Förord Detta projekt är gjort av campusstudenter på webbprogrammerareprogrammet på Linnéuniversitetet inom ramen för kursen Webbprojekt 1, som är en 7,5hp-kurs på halvfart. Kursansvarig handledare har varit Tobias Ohlsson. Projektet har bestått i att utveckla en mobilapplikation för projekthantering åt ett företag i Kalmar. Parallellt med vårt projekt har kunden tagit hjälp av ytterligare två grupper, en annan grupp från webbprogrammerarprogrammet för att utveckla ett API (Application Programming Interface) och en interaktionsdesigngrupp, från Interaktionsdesignsprogrammet årskurs 3, vars uppgift bland annat har varit att ta fram designen på mobilapplikationen. Vi har således fått arbeta med båda dessa grupper under projektets gång. 2

4 Innehållsförteckning Sammanfattning... 1 Förord... 2 Innehållsförteckning... 3 Introduktion... 5 Inledning och bakgrund... 5 Syfte... 5 Mål... 6 Baskrav... 6 Projektorganisation... 7 Genomförande... 8 Metodik... 8 Planeringsvecka... 8 Inceptionfasen... 8 Elaborationfasen... 9 Constructionfasen... 9 Transitionfasen Teknik Resultatbeskrivning/Måluppfyllelse Avvikelser/efterkalkyl Slutsats Förslag på vidareutveckling Privata att-göra -listor Nyhetsflöde Notifikationer Tillgänglig på distributionsplatser Filhantering Övertagande organisation Litteraturförslag/dokumentationshänvisning Förslag till förbättringar inför kommande projekt

5 Bilagor Bas-controller Bas-vymodell Inloggning Planering Projekt info Aktivitetslista Logginlägg Kollegor Kontakt info Väggen TODO-lista Uppdaterings loop

6 Introduktion Webbprojekt 1 är en kurs där man i grupp jobbar med ett projekt under hela kursens gång. Gruppen har regelbundna möten med kurshandledare varje vecka och möjlighet finns till flera möten om så skulle önskas. Projekten i kursen kommer ofta på beställning av externa företag. Betyget i kursen baseras på den färdiga produkt gruppen lyckas skapa och av en projektrapport som beskriver arbetet, det är för övrigt denna projektrapport du läser nu. Vi blev grupp 6 och fick i uppdrag att jobba med utvecklingen av en mobilapplikation för ett projekthanteringsverktyg. Deltagarna i denna grupp har varit Claes Tillborg, Oscar Lillheden, Robert Fransson och Tryggve Blom. Inledning och bakgrund Företaget vi blev tilldelat att jobba för var Coleo Vision AB, ett nystartat företag från Kalmar. Grundaren Pelle Sederkvist har med hjälp av programmeraren Marcus Oldin tagit fram ett webbaserat projektplaneringsverktyg. Mycket håller just nu på att hända med verktyget. Det skall få en ny design och det genomförs även en mer övergripande strukturförändring. För att tilltala fler kunder och tillgodose nuvarande kunders önskemål vill de nu ha en mobil version av sitt verktyg. Ytterligare två grupper fick i uppdrag att arbeta med denna applikation. En annan grupp från vårt program skulle skapa ett API(Application Programming Interface) och en grupp ifrån Interaktionsdesign årskurs 3 skulle vara med i utvecklingen av gränssnittet på applikationen. Vi skulle ha speciellt stort samarbete med ID-gruppen(Interaktionsdesign gruppen). Den ursprungliga webbapplikationen är utvecklad i ASP.NET MVC, ett ASP-dotnet ramverk baserat på Model View Controller strukturen. Coleo använder sig i nuläget av MVC 3 men vill gärna uppgradera sig till ASP.NET MVC 4, en beta-version som har inbyggt stöd för mobilapplikationsutveckling. Vi har även använt oss av ASP.NET 4.5, den senaste versionen av ASP-dotnet som även denna är i en betaversion för tillfället. Som databashanterare använder sig Coleo av RavenDB, en NoSql-databashanterare som använder sig av JSON för att spara undan information om objekt. Vi fick ett utdrag med test-data från deras befintliga databas att arbeta vidare med och fick skapa upp en egen databas-instans på en egen server. Syfte Kunden beställde en mobil-anpassad version av deras egna projekthanteringssystem som idag endast finns för webben. Syftet med projektet är att ta fram en applikation som kommer att användas som grund för deras utveckling av en mobilapplikation. Vårt arbete kan ses som en prototyp-applikation för deras framtida system där källkod likväl som applikationsstruktur är intressanta för kunden. 5

7 Mål Målet med projektet har varit att lära sig jobba mer iterativt och planera både tid och uppgifter tillsammans i gruppen. Vi skulle lära oss att utveckla och jobba tillsammans både som grupp och på individuellt plan. Vi skulle dessutom ha nära samarbete med både kunden och ID-gruppen för att få erfarenheter av större projektarbeten. Möten skulle hållas regelbundet med handledare, kund och i vårt fall även med ID-gruppen. Mobila applikationer skiljer sig från webb-baserade applikationer och därför blev det ett mål för oss att lära sig de tekniker och verktyg som används till detta. Vi fick också tillfälle att jobba med en NoSql-databas, vilket ingen av oss tidigare gjort. Det innebar att vi även fick sätta oss in i hur dessa databashanterare fungerar. Utifrån detta skulle vi uppfylla de baskrav vi och Coleo kommit överens om. Även om dessa efterhand ändrades. Baskrav BK1. Man måste logga in med sitt användarnamn och lösenord. Annars får man ingen tillgång till tjänsten. BK2. Mobilapplikationen skall kunna presentera data om användarens organisationer, avdelningar och aktiviteter. BK3a. Man skall kunna se sina loggposter. BK3b. Man skall ha CRUD på loggposter. BK3c. Man skall kunna klarmarkera loggposter. BK4a. Man skall kunna titta på vilka kollegor man har i organisationen/projektet. BK4b. Man skall erbjudas möjlighet att skicka e-post till en kollega. BK5. Extra funktionalitet är att undersöka hur väggen skulle kunna gå att implementera. BK6. Privata TODO-meddelanden skall vi också kolla på hur man kan implementera. 6

8 Projektorganisation Uppdragsgivaren till detta projekt har varit Coleo Vision AB som består av Pelle Sederkvist och Marcus Oldin. De använde sig även av två andra grupper till detta projekt, en grupp som har utvecklat ett API och en grupp från interaktionsdesignprogrammet som har haft till uppgift att designa mobilapplikationen vi ska utveckla. Vi har haft mycket kontakt med både kunden och de andra parterna för projektet. Kunden har samlat grupperna en gång i veckan för ett avstämningsmöte där alla har kunnat ta del av vad som händer på de olika planen. Vi har även haft kontakt med Marcus via telefon, e-post och chatt under arbetets gång. Vi har även tagit på oss att ta kontakt med de andra grupperna utanför dessa möten, ID-gruppen mer än API-gruppen. Handledare för vår grupp har varit Tobias Ohlson. Varje vecka har vi haft handledarmöte där vi kunnat diskutera hur arbetet framskridit samt fått tips och idéer om hur gruppen kan fortsätta arbetet. Vi har varit en liten projektgrupp där rollerna har växlat under projektets olika faser. Vi har delats in i olika arbetsgrupper beroende på vilka uppgifter som varit aktuella och eftersom vi har haft en tydlig begränsning i antal deltagare så har projektledaren ingått i arbetsgrupperna. Samarbetet med IDgruppen har varit olika beroende på i vilket skede vi varit i under projektet men i stort har de flesta möten med dem varit korta och handlat om design och utformning på olika delar av applikationen. 7

9 Genomförande Metodik Vi har arbetat efter SCRUM-metoden och i enlighet med Unified Process delat in projektet i olika iterationer. Varje vecka innebar en ny iteration och då utsågs även en ny projektledare för att alla skulle få känna på att vara projektledare. Däremot har projektledarrollen varit något lättvindig, projektledaren har mest haft ansvar för dokumentation och veckoplanering. Vi använde oss av burn down charts för att planera och uppskatta vad som skulle göras under veckan och rapportera hur många timmar var och en har arbetat. Handledarmöte är något vi också haft varje vecka. Under dessa har vi redovisat den tidigare iterationens arbetsgång och diskuterat hur vi skall fortsätta arbetet på bästa sätt under den kommande iterationen. Ungefär en gång i veckan har vi haft möte med kunden och de andra grupperna. Vi har då visat våra visioner och resultatet av det vi hittills skapat, lyssnat på feedback och diskuterat olika lösningar. Planeringsvecka Den inledande veckan av projektarbetet var vi inte informerade om några detaljer rörande den produkt vi skulle utveckla, mer än att det var en mobilapplikation av deras nuvarande tjänst. Därför tillägnade vi tiden åt att sätta oss in i verktyget samt till planering och förberedelser. Vi gjorde scheman, mallar för burn down charts, började skriva på risklistan och mycket annat. Dessutom gjorde vi mappar i Dropbox och Google Docs som delades inom gruppen för dokumentation och överföring av filer. De fördelar som kom med Google Docs kontra andra ordbehandlare utnyttjades flitigt. Det är behändigt att skriva i webbläsaren och lagra dokumenten i molnet eftersom man då enkelt får åtkomst till dem från vilken dator man än sitter vid. Vidare är det en väldig vinst med att flera personer i realtid kan arbeta i samma dokument och samtidigt kommunicera via en chatt. Google Docs har därför varit en stor resurs under hela projektets arbetsgång. Inceptionfasen Fasen inleddes med vårt första möte med kunden. Där fick vi en helhetsbild av vad vårt projekt skulle komma att innefatta. Vi kom tillsammans fram till några baskrav som skulle vara grunden i den vision vi började skriva och som sedan godkändes av Coleo. Vi fick dessutom önskemål om utvecklingsspråk och tekniker vilket skulle innebära att vi inte kunde använda våra ordinarie datorkonton i skolan eftersom vi inte kan installera några egna program på dessa. Detta löstes med VMWare Workstation där det skapades en virtuell installation av Windows 7 på vilken det installerades ASP.NET 4.5, MVC 4, RavenDB, SVN och det som behövdes för vår utveckling. Vi behövde ett sätt att skarpt publicera vår applikation för att kunna testa den utanför skolans miljö och i mobila enheter. För detta fick vi av skolan tillgång till en webbserver som vi själva fick administrera och installera bland annat MVC 4 och RavenDB. Mycket tid gick åt till att sätta sig in i de olika ramverk vi skulle jobba med. MVC 4 var ganska likt MVC 3 som vi hade erfarenhet av sen tidigare, men jquery Mobile (JQM) var inget vi var vana vid sedan 8

10 tidigare. JQM innebar många möjligheter men även en del begränsningar som vi efter hand lade märke till och som är bra att känna till på förhand. Elaborationfasen Det har under denna fas förekommit möten med gruppen av Interaktionsdesignstudenter där vi diskuterat hur den visuella utformningen ska bli. Att vara delaktiga i denna process har varit väldigt nyttigt eftersom vi då kunnat påverka och i ett tidigt skede stoppa idéer om vad som är programmatiskt och tidsmässigt omöjlig för oss att utveckla. Interaktionsdesigngruppen skapade sedan en low fidelity-prototyp, som sedan agerade en högst preliminär mall att börja utveckla modellarkitekturen efter. Detta gjorde vi genom att skapa klassdiagram och sekvensdiagram som visade hur vi uppfyllde ett av baskraven. Gruppens medlemmar har på egen hand ägnat mycket tid åt att läsa in sig på de olika resurser vi använder, såsom RavenDB, jquery Mobile och MVC 4, men programmeringsarbetet har även inletts, om än i mindre skala. Implementationen av de första baskraven har påbörjats och en del lösningar för att hålla reda på den aktuella sessionen har vi fått komma på själva. Detta gjordes genom att skapa klassen ActiveModels som innehåller information om den aktiva användaren, organisationen, avdelningen och aktiviteten. Constructionfasen Versionshanteraren, TortoiseSVN, började i den här fasen att skapa problem och vi tvingades lägga ner lite extra tid på lösningar. De flesta felen uppstod när några filer användes och uppdaterades av flera användare samtidigt. Detta går att lösa med TortoiseSVN genom att man slår samman de olika versionerna av filen. Detta kan dock medföra problem ändå, genom till exempel funktioner som jobbar emot varandra, så det är viktigt att dela upp arbetet i gruppen och alltid veta var de olika medlemmarna är och arbetar. Om man vet att någon i gruppen jobbar i filen man ska ändra i, ber man denna medlem göra ändringarna och uppdatera ändringarna. Om man har ändrat i en fil man inte har på sin listan bör man meddela resten av gruppen så att alla kan uppdatera sina versioner för att undvika senare problem. Vi har som sagt haft problem med att handskas med TortoiseSVN men efter ett tag hittade vi ett sätt att jobba på som passade oss mycket bra. Interaktionsdesigngruppen har bidragit med ett gäng High Fidelity-bilder av hur de tycker att applikationen ska se ut och dessa har vi sedan använt som en mall för det grafiska gränssnittet. Applikationens utseende förändrades därmed drastiskt och blev betydligt mer lik den design Coleos webbapplikation använder. De missade dock en del av våra baskrav vilket bidrog till att funktionernas utseende fick diskuteras med dem under implementation. Detta belyser både styrkan och svagheten med samarbetet. Eftersom vi arbetat i två separata grupper med olika tidsplaner och målsättningar har det varit svårt att få ett riktigt bra fungerande arbetsflöde. Samtidigt har vi haft ett så pass flexibelt och nära samarbete att vi kunnat fråga efter direktiv under processens gång. 9

11 Detta är något som kanske inte rekommenderas vid andra projekt men under omständigheterna fick vi göra det bästa av situationen. Att vänta på att interaktionsdesigngruppen skulle göra nya bilder hade fördröjt vårt arbete. I ett bättre scenario hade vi haft med oss en interaktionsdesigner i gruppen som hade följt vårt tidsschema och haft bättre koll på våra krav, alternativt att den externa gruppen arbetat fram en grunddesign innan vi började med vårt projekt. Eftersom JQuery Mobile användes för att skapa det grafiska gränssnittet ville vi även titta lite närmare på Themeroller, det verktyg som JQM erbjuder för att skapa teman. Dessa teman laddar man sedan ner som CSS-filer till sin applikation. Vi bad ID-gruppen i början av projektet att sätta sig in i detta verktyg och då också skapa sitt tema där, något vi trodde skulle spara mycket tid och bidra till ett bättre utseende på applikationen. De lyckades inte lära sig ramverket i tid så själva skapandet av temat fick vi stå för. Egna HTML Helpers användes för att generera många av våra vyers list-element. Helpers var något få av oss hade jobbat med tidigare så det tog därför lite tid att sätta sig in i hur dessa fungerar men när alla väl lärt sig att använda dem på ett korrekt sätt blev det dock mycket smidigt att arbeta med dem. Då större delen av applikationen är väldigt beroende av vilken organisation, avdelning och projekt man befinner sig i skapades det en bas-controller som alla controllers ärver av. Den har ansvaret för att lagra applikationens tillstånd och initiera en sessionsvariabel där denna information sparas (Se bilaga1 för klassdiagram). Samma tankar fördes vidare ut i vyerna där en bas-vymodell använder sig av just denna sessionsvariabel för att vyerna ska veta vart användaren befinner sig i hierarkin. Bas-vymodellen har också olika vymodeller som egenskaper så att den controller som används skapar en egen vymodell och sparar undan information som är intressant för den aktuella vyn (Se bilaga1 för klassdiagram). När vi skulle implementera klarmarkeringen av loggboksinlägg började vi diskutera hur lätt det är att råka trycka fel på en touch-enhet. Vi kom då fram till en lösning som går ut på att man först måste låsa upp listan innan man kan klarmarkera och att man sedan får spara sina ändringar, något som redan finns i deras webbapplikation men som vi ville ta bort först. Vi fick dock problem vid uppdateringen av listan då formulärdatan, vi får från vyn, bara innehåller information om de inlägg som blivit, eller fortfarande är, klarmarkerade. Det blev en lång kväll med många idéer på hur vi skulle lösa detta på bästa sätt. Lösningen vi hittade blev att jämföra den befintliga listan med den vi fick från användaren. Vi fick då jämföra varje värde för sig för att kunna avgöra om det hade förändrats. (Se bilaga3 för exempelkod) Då det är en projekthanteringsapplikation vi har jobbat med har det stundtals funnits väldigt mycket information att arbeta med. Listan på information om ett projekt kan var allt mellan 3-12 punkter vilket har gjort att vi fått brottats mycket med hur allt ska få plats utan att göra vyn för rörig eller texten för liten. Detta var speciellt svårt eftersom vi är vana att jobba med datorers upplösningar och skärmstorlekar. När vi väl hade anpassat oss efter mindre skärmar som till mobiler gjorde vi tester på pekplattor och fick genast nya problem. Att designa resposive har varit något vi fått lära oss den hårda vägen. 10

12 När inloggningen implementerades fick vi hårdkoda in lite användare och lösenord i en egen databas eftersom vi inte hade tillgång till den databas som innehåller de riktiga inloggningsuppgifterna. Detta var nödvändigt för att vi skulle kunna testa inloggning och autentisering. För Coleo att senare implementera deras befintliga inloggningsmodul blir inte svårt. Efter att inloggningen kom på plats började vi tänka mer på hur olika användare har olika rättighetsnivåer och dessa skall begränsa vad man inte får tillgång till samt om man får skrivrättigheter inom projekt eller avdelningar. Efter konsultation med vår kund lyckades vi implementera ett rättighetssystem över hela applikationen enligt deras önskemål. Transitionfasen För att hitta buggar testades alla funktioner frenetiskt. En del småfel upptäcktes, som att fel datum visades på kommentarer till ett vägginlägg. Detta fel berodde på att vi hämtade ut fel datumobjekt i vyn och var därför lätt åtgärdat. Inga större fel som gul-fula sidor påträffades. Applikationens alla funktioner fungerade nu och därför beslutade vi att testa applikationen på olika användare för att se om det var något som var svårt att förstå. Vi skrev ett gäng testfall och tog sedan tiden för hur lång tid testpersonerna tog på sig för att utföra uppgifterna. Av resultatet framkom att en del saker var svåra att förstå, men överlag var testpersonerna nöjda. Därför kodades det in i det sista för att finslipa funktionerna inför slutleveransen i slutet av transitionfasen. Teknik Coleos applikation för webben använder sig i dagsläget av ramverket ASP.NET MVC 3 och RavenDB som är en NoSql-databas. Våra uppdragsgivare hade som önskemål att vi utvecklade i ASP.NET MVC 4 för mobilapplikationen eftersom MVC 4 har bra stöd för jquery Mobile, det touch-optimerade webbramverk som Coleo föreslog att vi skulle använda. Vi skrev således vår backend i C# inom ramen för ASP.NET MVC 4. Frontend-delen av vår applikation är uppbyggd med ramverket jquery Mobile. Ramverket arbetar med jquery, HTML och CSS för att bygga upp sina vyer. jquery är ett ramverk baserat på JavaScript. Innehållet i vyerna som skapas upp dynamiskt på serversidan renderades ut med hjälp av vy-språket Razor som är en del av ASP.NET. Razor kommunicerar med våra modellklasser och renderar ut htmlkod innehållande den information vi eftersöker. Den färdiga html-strukturen skickas sedan över till klienten där JQM tolkar koden och manipulerar strukturen så den får ett mobilanpassat beteende. Vissa delar av ramverkets funktioner fick vi dock överlagra med egen funktionalitet. Vi skrev då egna funktioner i jquery och fick i många fall även skriva över ramverkets css-regler för att få det önskade beteendet och utseendet i vår applikation. Vi fick även skapa en virtuell webbserver som plattform för leveranser av vår applikation under utvecklingsprocessen. Vi lade kontinuerligt upp den senast fungerande versionen av vår produkt så vi och ID-gruppen kunde utföra användartester och vi kunde även testa mjukvaran på olika mobila enheter och skärmupplösningar. Vi driftsatte även en instans av vår test-databas på denna server. Det var smidigt eftersom alla nu kunde utveckla mot samma datakälla och samma testdata. Denna hade även API-gruppen nytta av i 11

13 sitt arbete. Alla inblandade slapp nu ha egna instanser av Raven-databasen igång på sina utvecklingsmaskiner. Till själva programmeringen använde vi oss av Visual Studio Vi har även versionshanterat alla våra filer med Subversion och programmet TortoiseSVN. Resultatbeskrivning/Måluppfyllelse Slutprodukten blev en fullt fungerande mobilapplikation som uppfyller de baskrav vi satte upp i början av projektet. En autentiserad användare får enkelt tillgång till information om de organisationer, avdelningar och projekt han/hon är medlem i och kan även delegera uppgifter till sina kollegor genom loggboksinlägg. Användare kan kommunicera med sina kollegor via gemensamma meddelandeutrymmen på avdelnings- eller projektnivå och det finns även möjlighet att kontakta en kollega via e-post, sms eller röstsamtal. Man kan enkelt se vilka uppgifter man själv har att göra och det går snabbt att klarmarkera dessa från applikationen. (Se bilaga2 för grafiska redogörelser). Avvikelser/efterkalkyl Under projektets fortlöpande dök det upp ett par intressanta förslag på funktionalitet som vi gärna ville implementera. På grund av de begränsningar projektgruppen hade i form av tid och personal fick vi dessvärre utesluta dessa funktioner. En lista av dessa följer här och en längre beskrivning finns att läsa under rubriken Förslag på vidareutveckling. Privata att-göra -listor Ett nyhetsflöde med händelser från applikationen Notifikationer Vi lyckades dock implementera ett av våra bonus -baskrav. Det gemensamma meddelandeutrymmet, väggen, som hör till varje avdelning och även till varje projekt. Väggen är ett vedertaget koncept som redan återfinns i det befintliga verktyget så steget till att implementera det var inte så stort. Vi klarade även av att göra några extra modifikationer på hur den fungerar gentemot deras nuvarande implementation. Att kommentera och gilla inlägg såg vi som relevanta och berikande funktioner som vi valde att implementera. 12

14 Slutsats Det har varit ett väldigt intressant och lärorikt projekt med många tekniska områden som vi har utvecklats inom. Det är klart den största MVC-applikation vi utvecklat vilket har gjort det viktigt att tänka på att få en bra objektorienterad design genom hela applikationen. Att utveckla ett mobilt gränssnitt känns extra roligt eftersom marknaden för mobila applikationer ständigt växer och det gäller att ha en god förståelse för den domänen som utvecklare. De utmaningar som kommer med att arbeta med nya tekniker och ramverk har varit en stor drivkraft för alla gruppmedlemmar och vi har verkligen absorberat mycket kunskap inom dessa områden. De lärdomar vi har fått med oss av att arbeta i grupp har gett oss mycket erfarenhet när det gäller gruppdynamik. Det har även varit spännande att arbeta med de verktyg som finns i SCRUM och att använda dem för att hjälpa det iterativa projektarbetet framåt. Att ha hjälp av en grupp som avlastar arbetet med interaktionsdesign och användartestning innebar också många nyttiga lärdomar även om det samarbetet går att utveckla ytterligare. Önskemål och åsikter på vår implementation har gjort att hela arbetet har blivit mer intressant och levande. Det tillförde en dynamik och känsla av genuinitet till projektet. Det har varit svårt att på förhand uppskatta hur mycket tid de olika uppgifterna skulle ta och det har medfört att vi ofta tog på oss mer uppgifter i varje iteration än vad vi har kunnat klara av. De uppgifter vi inte hunnit med har fått följa med över till nästa iteration. Men om man ser till helheten har vi ändå lyckats uppfylla de flesta uppgifter vi har tagit oss an. Förslag på vidareutveckling Privata att-göra -listor Vi såg ett behov av att kunna samla egna anteckningar och kom-ihåg-listor som inte är bundna till något specifikt projekt eller avdelning. Det finns olika sätt att gå tillväga för att implementera en sådan funktion. De har främst varit två förslag som diskuterats. Det första har inneburit att man har haft en kategori och en tidpunkt kopplad till varje anteckning. Föreslagna kategorier har varit Möte, Deadline, Viktigt, Kom-ihåg. Det andra förslaget har inneburit att listor med minnesanteckningar har varit mer generella och bara gett utrymme för användaren att skriva text. Det har sedan varit upp till användaren att själv bestämma och skapa ett system för hur dessa skall kategoriseras eller användas. Nyhetsflöde På hemskärmen som man kommer till när man loggar in önskades en nyhetsfunktion. Det finns olika sätt att utforma denna på och de representerar olika grundkrav på funktionen i sig. Den skulle kunna lista aktiviteter som har inträffat sedan man var inloggad senast. Alternativt skulle den kunna lista aktiviteter som är aktuella idag, i morgon, tre dagar framåt i olika flöden (Logginlägg som skall vara klara, projekt som tar slut, etc...). Den skulle även kunna ses som en mer generell nyhetslista med de senast skrivna vägginläggen eller kommentarer på vägginlägg, vilka logginlägg som skapats eller klarmarkerats, vilka dokument som har lagts upp eller kollegor som har tillkommit etc. 13

15 Även dessa olika scenarion kan delas in i två olika innehållsrelaterade kategorier. Vad är relevant för mig som person och vad är relevant för de avdelningar och projekt jag är kopplad till? Det är en svår avvägning att hitta rätt abstraktionsnivå och vi tror att detta måste testas under en lång period innan vi hittar rätt. Notifikationer Om man får ett nytt loggboksinlägg tilldelat till sig, eller om någon klarmarkerar ett inlägg som du delegerat kunde det vara intressant att få en lite notifikation om det i systemet. Likaså om någon har svarat på ditt vägg-meddelande eller eventuellt skrivit ett nytt meddelande på en vägg. Det finns olika nivåer av uppmärksamhetspåtvingande hos notifikationer och även olika grader av relevans i de händelser som skulle kunna kasta en notifikation. Även detta är något som måste testas och undersökas för att hitta rätt balans mellan de olika alternativen. Tillgänglig på distributionsplatser Redan från början diskuterades det om att mobilapplikationen skulle kunna säljas på Appstore(Apples plats för köp och nerladdning av applikationer), och Google Play (före detta Android Market, motsvarigheten till Appstore för Android enheter). En applikation som distribueras på dessa platser kallas Native applikation, en applikation som är skriven för en speciell plattform som Android eller IOS. Det fungerar alltså inte med en mobilanpassad webbapplikation som denna är. Därför skulle vi då använda Phonegap, ett JavaScriptbaserat ramverk som hjälper en mobilanpassad webbapplikation att fungera som en så kallad Native applikation. Då projektet blev större än vad vi först hade tänkt fanns det dock ingen tid att tillämpa denna omvandling. Filhantering Coleos nuvarande webbapplikation har stöd för viss typ av filhantering därför diskuterades denna lösning även för mobilapplikationen. Det kan dock vara svårt att säkerställa stöd för olika filformat på de mobila plattformar som används men det kan vara intressant att åtminstone visa vilka filer som finns kopplade till ett projekt. Denna information kan även användas i det planerade nyhetsflödet. Övertagande organisation Coleo Vision AB kommer ta över det samlade resultatet av vårt arbete och förhoppningsvis kommer det stå sig bra som grund för deras fortsatta arbete med att lansera en mobilapplikation. Litteraturförslag/dokumentationshänvisning De dokumentationer vi använt mest är nog de som finns till jquery och jquery Mobile Framework då detta använts flitigt vid skapandet av vårt grafiska gränssnitt. Ett jquery-plugin vid namn datebox användes som datumväljare. När det gäller arbetet med databasen har vi tagit RavenDBs egna dokumentation varit till stor hjälp. Till de problemen vi haft i ASP.NET MVC har olika forum och chatter som finns på Internet används. Vår kund Marcus Oldin har också funnits till hands för att svara på frågor. 14

16 Dokumentationshänvisning: jquery - jquery Mobile Framework - jquery Themeroller - jquery(datebox) - RavenDB - Förslag till förbättringar inför kommande projekt Det var från början tänkt att vår grupp skulle arbeta med testdriven utveckling, men med hänsyn till alla nya domänområden vi skulle sätta oss in i ansåg vi att vi inte skulle få ett tillräckligt bra utbyte av den metoden. Testdriven utveckling tar ett tag att sätta sig in i och det förutsätter även att man vet vad det är man skall utveckla så att man kan skriva tester för det redan från början. Eftersom vi inte riktigt visste från början hur i skulle lösa många av de problem som fanns så var det också svårt att utveckla testdrivet. Till en början fördes dokumentation i form av en slags dagbok flitigt, men det blev sämre och glesare med tiden. Detta berodde mycket på att det blev många sena kvällar och när vi väl var färdiga för dagen hade det hänt så mycket att vi knappt kom ihåg allt vi gjort. Att prioritera vad som skrevs i dagboken kunde också varit bättre. Vissa saker som borde skrivits kom inte in medan mindre viktig information tog plats. Dessutom borde projektrapporten ha påbörjats tidigare och skrivits mer parallellt med projektarbetet. Nu blev det att mycket av rapporten skrevs sista veckan. Våra burn down charts var väldigt inkonsekventa i sin utformning. Något som hade en överskrift en vecka kunde heta något annat en annan vecka även om den beskrev samma arbetsuppgifter. Detta berodde till stor del på en ovana i att skriva burn down charts, men också mycket på att vi skiftade projektledare varje vecka och att det var projektledarens uppgift att skriva veckans burn down chart. Med tiden blev vi duktigare på detta, så man ser en klar förbättring i våra charts vecka efter vecka. Designen ändrades mycket under projektets gång. Detta berodde på att interaktionsdesigngruppen i början av vårt arbete inte var helt insatta i alla funktioner som skulle finnas med i applikationen och mot slutet gav deras projektplanering inte tid för dem att sätta sig in i utformningen. De agerade i princip smakråd snarare än designers. Detta hade kunnat lösas genom att de börjat med designarbetet några veckor tidigare än vi började med vårt projekt, så att vi hade haft en färdig design att arbeta efter redan vid projektets start. En annan sak som hade kunnat underlätta vore om det fanns en interaktionsdesigner med i vår grupp, så att det arbetet på ett smidigare sätt flöt in i vår process och att vi kunde ge varandra feedback på designen direkt utan att behöva göra det genom formella möten. 15

17 Bilagor 1.1 Bas-controller 1.2 Bas-vymodell 16

18 2.1 Inloggning 2.2 Planering 17

19 2.3 Projekt info 2.4 Aktivitetslista 18

20 2.5 Logginlägg 2.6 Kollegor 19

21 2.7 Kontakt info 2.8 Väggen 20

22 2.9 TODO-lista 21

23 3.0 Uppdaterings loop 22