Prosessdokumentasjon for Sir Jerky Leap

Transkript

1 Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1

2 Innholdsfortegnelse 1. Forord Innledning Gruppen Om bedriften Bakgrunn for oppgaven Mål Sir Jerky Leap! Fasene i prosjekt Planlegging Innledende arbeid Første tanker Fremdriftsplan og arbeidsplan Metode Kravspesifikasjon Utviklingsprosessen Kompetansetilegning Design Bakgrunn for designet Utvikling Utfordringer Optimalisering av GUI Personlig-visning Innhold i TOC (Table Of Content) Tab-funksjon Ikoner «Mus-over-funksjonen» Mappestruktur Implementasjon Databasestruktur Prototype og Scriptacolous Sorterbare trekkspill-lister Bakgrunn Forarbeide Utvikling Utfordringer Interaktivitet Brukerdifferansiering Kondisjonell lasting av innhold Oppdatering av listen Løsninger Interaktivitet Brukerdifferansiering Kondisjonell lasting av innhold Oppdatering av listen Testing Samarbeid Samarbeid med oppdragsgiver og sluttbrukerne Veiledning fra Høgskolen i Oslo

3 6. Konklusjon Forord Med denne rapporten vil vi fortelle hva vi har gjort og hvordan vi har jobbet for å komme frem til det endelige produktet. Vi vil utdype og redegjøre for hvilke teknikker og metoder som er brukt for å komme frem til de ulike løsningene. Rapporten er beregnet for sensor, veileder og arbeidsgiver, samt andre som har interesse av å sette seg inn i arbeidsmetodikken vi har brukt. Vi forutsetter at leser er datakyndig. Prosessdokumentasjonen er delt opp i slik: Innledning, produkt, fasene i prosjektet, samarbeid og konklusjon. Vi anbefales at dokumentene leses i denne rekkefølgen. Vi henviser til produktdokumentasjonen som gir en dypere teknisk beskrivelse av produktet og systemets oppbygning. Vi har lagt ved en ordbok hvor leseren kan slå opp ord og uttrykk som er nevnt i denne rapporten. I teksten er disse markert i kursiv. Vedlagt ligger også styringsdokumentene og andre dokumenter som kan være nyttige for å forstå programmet og prosessen vi har vært igjennom. 3

4 2. Innledning Denne delen av dokumentet inneholder bakgrunnsinformasjon for prosjektet. Vi begynner med å presentere hvem som har utført prosjektet, etterfulgt av en mer detaljert beskrivelse av bedriften og bakgrunn for oppgaven. Dette kapittelet avsluttes med målene vi satt for Sir Jerky Leap Gruppen Gruppen bak produktet Sir Jerky Leap består av Tor Anders Gustavsen, Fredrik Hoem Grelland, Jasmine En-Ning Garry og Line Sørensen. Gruppemedlemmene har flere ganger jobbet sammen på prosjekter, og har derfor et godt og innøvd samarbeid. Vi valgte å arbeide sammen også på dette prosjektet nettopp på grunn av godt samarbeid, at vi utfyller hverandre, har samme ambisjonsnivå og ønsket samme type oppgave. Gruppens første utfordring var å finne et passende prosjekt. Vi satt oss ned i fellesskap og gikk igjennom de prosjektforslagene som forelå på hjemmesiden til dataavdelingen ved Høgskolen i Oslo. Utviklingsfirmaet Aptoma AS hadde kontaktet skolen og lagt frem to hovedprosjektoppgaver. Vi fant prosjektoppgaven Sir Jerky Leap interessant, ikke minst på grunn av utfordringene knyttet til denne oppgaven Om bedriften Aptoma AS utvikler dynamiske webapplikasjoner, rettet mot større avisselskaper og mediale bedrifter i Norge og utlandet. Produktspekteret omfatter blant annet løsninger innen web-tv, visuell produksjonsplattform for nettmedier, og konsulent-tjenester til større mediehus. Aptoma betjener flere store kunder, blant annet VG-nett, hvor de har VG-TV og Listefeber. I tillegg har bedriften utviket et verktøy for oppsett av forsider, Dr. Front., som blir brukt på blant annet VGnetts «Rampelys» og den franske nyhetsnettsiden « Bedriften samarbeider også med Scanpix/NTB. 4

5 2.3. Bakgrunn for oppgaven Oppdragsgiver benytter i dag flere ulike verktøy til å administrere prosjekter og oppgaver, føre timer og registrere ferier. Å jobbe på tvers av mange ulike programmer, er tidkrevende og lite effektivt. Oppdragsgiver hadde ønske om å gjøre arbeidet smartere, og vi ble bedt om å utvikle et oppgavestyringsverktøy med vekt på effektivitet Mål Målet med oppgaven var å lage et solid og innovativt, webbasert grensesnitt for oppgavestyring. Systemet skal forenkle jobben med planlegging og styring av prosjekter. Sir Jerky Leap, som vi har utviklet, er i utgangspunktet laget internt for bedriften, men har muligheter for utvidelse slik at det kan tilpasses andre firmaer med ulike behov. At systemet er generisk og modulært, er derfor helt essensielt. Det ble stilt store krav til brukergrensesnittet. Vi ønsket å unngå en applikasjon med for mye informasjon og funksjonalitet på en gang. Forskjellene mellom en brukervennlig applikasjon og en tung applikasjon blir tydeliggjort i figuren over. 5

6 3. Sir Jerky Leap! Sir Jerky Leap er en webbasert applikasjon i skjæringspunktet mellom en oppgaveliste og et fullverdig oppgavestyringsverktøy. Programmet egner seg for organisasjoner og privatpersoner med behov for å administrere oppgaver på en smart og effektiv måte. Med sitt enkle og intuitive design, gjør Sir Jerky Leap oppgavestyring enkelt, uten påtrengende elementer. Ajax-teknologi gir applikasjonen et interaktivt brukergrensesnitt. Applikasjonen er responsiv og dynamisk, og bærer i så måte preg av en vindusapplikasjon. Sir Jerky Leap er utviklet med fokus på enkelthet. Brukeren gis tilgang til de verktøy som til enhver tid kreves, men ikke mer. Programmets funksjonalitet og valgmuligheter blir presentert for brukeren basert på kontekst og roller. Man unngår eventuelle forvirrelser, og reduserer grensesnittets kompleksitet. Prosjekter og underprosjekter, med tilhørende oppgaver blir strukturert hierarkisk. Strukturen gjør det enkelt å navigere seg frem og tilbake mellom ulike prosjekter og oppgaver. Oppgaver gis innhold etter eget ønske. Dette er foreløpig begrenset til tekst og bilde, men kan i prinsippet være alle typer data. Oppgaver tilknyttet innhold får sin egen innholdsfortegnelse, heretter kalt TOC (table of contents). Innholdsfortegnelsen i ekspandert form, gir en formattert visning av oppgavens innhold, og egner seg ypperlig som dokumentasjon til den enkelte oppgave. Prosjekter og oppgaver, samt innhold i TOC, kan enkelt sorteres og flyttes på med dra-og-slipp-metoden. 6

7 Som første produkt innen genren, legger Sir Jerky Leap opp til fanebasert arbeidsflyt. Alle prosjekter og oppgaver, uansett hierarkisk plassering, kan åpnes i faner. Man holder lettere oversikt, og bevarer simplisiteten i brukergrensesnittet. Sir Jerky Leap gjør det enkelt å delegere arbeidsoppgaver. Brukere med administrative rettigheter kan ved få museklikk tildele andre brukere oppgaver. Make everything as simple as possible, but not simpler. - Albert Einstein 7

8 4. Fasene i prosjekt Denne delen av dokumentet omhandler de forskjellige fasene vi har vært gjennom for å komme frem til det endelige produktet. Kapittelet er delt opp i fire deler: planlegging, utvikling, utfordringer og dokumentasjon Planlegging Vi vil her forsøke å gi et innblikk i hvordan vi valgte oppgaven, hvordan planleggingsfasen har vært, og hvilke beslutninger som ble tatt og hvorfor Innledende arbeid Tidlig i november 2007 tok vi kontakt med Geir Berset ved Aptoma AS, angående prosjektet Sir Jerky Leap. Firmaet hadde ennå ikke engasjert noen gruppe til oppgaven og vi ble innkallt til et møte. Vi syntes oppgaven hørtes spennende ut og bekreftet kort tid etter at vi gjerne ville ha prosjektoppgaven. Det ble opprettet en Aptoma-mailadresse og en egen konto på Aptoma AS sitt intranett for hver av oss. Dette gjorde at vi fikk tilgang til dokumenter og lignende som kunne være aktuelle for prosjektet. Vi var i gang med planleggingen i januar, og vi ble raskt enige om at vi skulle ha en kjernetid alle ukedager mellom 10:00 og 15:00, med mindre man hadde gyldig fravær. Eventuelle fravær skulle på forhånd legges inn i Google Kalender og godkjennes av de øvrige gruppemedlemmene. Da vi er en morgentrøtt gjeng fant vi ut at vi måtte bli enige om en måte å få alle på skolen tidsnok. Vi ble da enige om å «bøtelegge» hver person med 50 kr per halvtime han/hun var forsinket. Pengene i denne potten skulle gå til sosiale sammenkomster for alle gruppemedlemmene. Gruppen startet på første fasen av prosjektet, forprosjektet, rett etter nyttår. Vi avtalte et møte med veileder, Eva Hadler Vihovde, og ble enige om ukentlige møter inntil vi var godt igang med implementasjonen. Oppdragsgiver hadde lagt ut en kravspesifikasjon på intranettet og denne gjorde at vi kom raskt i gang med vår forprosjektrapport. Underveis i arbeidet med denne rapporten fant vi en god del ting i oppdragsgivers kravspesifikasjon som vi ville endre. Vi kontaktet da oppdragsgiver og la frem våre ideer. Oppdragsgiver var som oftest enig i våre forslag. Hvis ikke, ble det inngått et kompromiss. 8

9 Første tanker Allerede ved første titt på oppgaven Sir Jerky Leap visste vi at det kom til å bli et utfordrende og spennende prosjekt. Vi hadde mange meninger om prosjektet og om hvordan vi kunne løse det. Vi så med en gang store muligheter for Sir Jerky Leap og lagde oss tanker rundt hvordan vi skulle utvikle et webbasert oppgavestyringsverktøy med de kravene oppdragsgiver hadde satt. Oppdragsgiver var veldig klar på at vi skulle bruke mye tid på å tenke, resonnere, diskutere, forske, og planlegge. Vi måtte vurdere allerede eksisterende oppgavestyringsverktøy, evaluere de og finne bedre løsninger på den samme funksjonaliteten. Det var ikke meningen at Sir Jerky Leap skulle utvikles å framstå som et ferdig produkt innen 23. mai, men derimot leveres med en solid «oppbygging», som lett skal kunne videreutvikles. Vi visste at det ville oppstå problemer underveis, da det var mye nytt å sette seg inn i. Vi var forberedt på å håndtere alle de utfordringer som måtte komme Fremdriftsplan og arbeidsplan Fremdriftsplanen ble satt opp tidlig i prosjektet, men den var noe ufullstendig. Det ble utviklet en overfladisk fremdriftsplan, med hovedpunkter om når hver enkelt prosjektdel burde være ferdig. Sammen med fremdriftsplanen lagde vi en overordnet arbeidsplan. Vi var litt usikre på hva som lønte seg å starte med. Etterhvert som vi kom i gang med prosjektet, var det lettere å se hva som skulle gjøres og i hvilken rekkerfølge, og fremdriftsplanen og arbeidsplanen ble utvidet og ferdigskrevet. Begge disse dokumentene har blitt brukt aktivt gjennom hele prosjektgjennomføringen. 9

10 Metode Aptoma AS har utvilket en egen utviklingsprosess som de har kalt ADP Aptoma Development Process. Oppdragsgiver så helst at vi fulgte denne prosessmetoden. Denne metoden går i korthet ut på at all planlegging skal skje først. Deretter skal brukegrensesnittet designes før noe kode på bakende implementeres. Testing skal skje kontinuerlig gjennom hele prosjekttiden. Under vises en figur av Aptoma Development Process: For nærmere beskrivelse av Aptoma Development Process, se vedlegg nr Kravspesifikasjon Kravspesifikasjonen har vært et viktig dokument gjennom prosjektfasen og har blitt utarbeidet etter oppdragsgivers ønsker. Det fantes et utkast til kravspesifikasjonen som vi fikk da vi påbegynte prosjektet. Da denne var noe ufullstendig og vi hadde noen innvendinger, avtalte vi et møte med oppdragsgiver. Dette var en viktig prosess for å få frem hva deres ønsker for systemet, Sir Jerky Leap, var. Sammen med oppdragsgiver ble funksjonene fastsatt. Systemets rammebetingelser var i hovedsak predefinert av oppdragsgiver. Vi stod imidlertid fritt når det gjaldt valg av blant annet IDE og modelleringsverktøy, og det var opp til gruppen å finne gode løsninger på dette. Det var først når vi fikk et overblikk over systemet og kunne begynne å se for oss hvordan det skulle fungere, at vi kunne ta funksjonalitetsavgjørelser. Produktet samsvarer med kravspesifikasjonen, slik som den er per i dag. Kravspesifikasjonen finnes i sin helhet senere i 10

11 sluttdokumentasjonen Utviklingsprosessen Dette kapittelet omhandler de ulike utviklingsfasene vi har vært igjennom. Det blir beskrevet utfordringer og valg vi stod overfor, hvilke løsninger vi vurderte og hvilke løsninger vi valgte Kompetansetilegning Denne delen tar for seg hvilke verktøy og teknologier vi har tatt i bruk, samt hvilke teknologier som var ukjente for oss og hvilke vi måtte fordype oss i. På forhånd ble det gitt en del konkrete krav til funksjonalitet, samt visse krav til tekniske løsninger. Det ble blant annet satt føringer for hvilke språk og rammeverk vi skulle bruke. I bunnen av applikasjonen ligger en database av typen MySQL. Back-end er utviklet med objektorientert PHP og arbeidsgivers eget PHP-rammeverk, AFW. Brukergrensesnittet er utviklet ved hjelp av HTML, CSS og JavaScript. Vi har også benyttet Prototype og Scriptaculous, to JavaScript-rammeverk spesialdesignet for å gjøre websider dynamiske. Applikasjonen er optimalisert for Mozilla Firefox, da denne webleseren har implementert de fleste webstandarder. Her følger en detaljert oversikt over de ulike verktøyene og språkene vi har tatt i bruk: Programvare / Teknologi Apache HTTP Server PHP MySQL Memcached Prototype 1.6 Scriptaculous Zend Studio 6.0 BETA DBDesigner 4.0 Navicat 8 for MySQL Mozilla Firefox x Firebug 1.x Beskrivelse Webserver Programmeringsspråk (server-side) DBMS (database management system) System for caching av databasekall på webserver Rammeverk som gir objektdreven tilnærming til JavaScript JavaScript-rammeverk basert på Prototype. Integrert utviklingsmiljø for PHP, basert på Eclipse. Databasemodelleringsverktøy for MySQL Databaseadministreringsverktøy for Windows Webleser Utviklingsverktøy for Mozilla Firefox 11

12 Tortoise SVN 1.4.x Versjonskontroll Merk: Utfyllende informasjon om de ulike teknologiene finnes i ordboken, vedlegg nr. 9. Skolen hadde allerede kurset oss med innføringer i de fleste av disse teknologiene. Det var likevel et stort gap mellom hva vi hadde lært på forhånd, og hva som trengtes av kunnskaper for å ta fatt på oppgaven. Basiskunnskapene har trolig gjort læringskurven noe slakere enn den ellers ville ha vært, men vi har likevel måttet fordype oss ytterligere, ikke minst innen PHP og JavaScript. Tidligere har vi benyttet PHP til å lage enkle kodesnutter for å gi websider dynamisk innhold. Vi har aldri tatt i bruk objektorientert PHP, noe som er strengt nødvendig på et prosjekt av dette omfanget. PHP er et høynivåspråk hvis syntaks minner mye om Java og C++. Våre tidligere erfaringer med objektorientert utvikling i blant annet Java, gjorde overgangen til PHP relativt enkel. Rammeverket AFW, produserer objekter basert på tabeller i databasen, og legger i så måte opp til objektorientert programmering. I forkant var våre kunnskaper om JavaScript begrenset til det mest basale, og i forhold til denne oppgaven svært mangelfulle. Et av hovedmålene var å gi applikasjonen et sofistikert brukergrensesnitt. Vi ville viske ut forskjellene mellom en typisk webapplikasjon og en vindusapplikasjon, og tilby brukeren det dynamiske og responsive brukergrensesnittet som ofte preger sistnevnte. Dette kan ikke gjøres uten en kontinuerlig og massiv manipulering av DOM [23], og det er her JavaScript kommer til sin rett. Rammeverket Prototype er utviklet med tanke på dette formålet, og har vært uvurderlig i utviklingen av applikasjonen. Rammeverket Scriptaculous er igjen basert på Prototype, og har hovedsakelig blitt brukt til visuelle effekter. Alle teknologiene vi har benyttet oss av ligger åpne for allment bruk, og er stort sett grundig dokumentert. Det har derfor ikke vært nødvendig å bruke andre oppslagsverk. 12

13 Design Her blir designfasen beskrevet. Den tar for seg noen av de viktigste avgjørelsene vi har har tatt, hvilke løsninger vi har valgt samt hvorfor vi valgte disse Bakgrunn for designet Hovedkravet til oppdragsgiver var at Sir Jerky Leap skulle være et brukervennlig program. Firmaet ville at alle skulle kunne bruke programmet og at det ikke kun var forbeholdt datakyndige. Ellers hadde de ingen krav til hvordan brukergrensesnittet skulle være. Vi stod derfor fritt til å designe dette. Ansatte ved Aptoma AS har til nå benyttet seg av oppgavestyringsverktøyet Streber, men de finner brukergrensesnittet til dette programmet lite brukervennlig. Det de var mest misfornøyde med, var at all funksjonaliteten var tilgjengelig til enhver tid. De fant dette meget forstyrrende og ønsket derfor å utvikle et nytt oppgavestyringsverktøy, Sir Jerky Leap. Vi hentet inspirasjon fra applikasjoner som har liknende formål. Vi testet disse og fant ut hvilke funksjonaliteter vi fant nyttige og hvilke vi ikke likte Utvikling Sir Jerky Leap har vært igjennom en spennende designutvikling. Det har vært en lang vei fra å bare eksistere på papir til å bli et webbasert, brukervennlig produkt. Oppdragsgiver ga oss to bilder til inspirasjon, AccordionEditList og en skisse på hvordan «Edit mode» kunne se ut. Disse bildene vises her: 13

14 AccordionEditList 14

15 «Edit mode» Utifra disse bildene og de andre prosjektstyringsverktøyene vi testet, laget vi flere papirprototyper av hvordan Sir Jerky Leap kunne se ut. En av de første papirprototypene vi utviklet så slik ut: 15

16 I det første utkastet var all funksjonaliteten synlig til enhver tid. Dette virket forstyrrende og det ble for mye funksjonalitet å forholde seg til for bruker. Etterhvert så vi at det måtte settes noen begrensninger i programmet. Alle brukere kunne ikke ha tilgang til alle funksjoner, da dette kunne misbrukes. Andre brukere kunne for eksempel slette oppgaver uten å ønske det. Vi bestemte oss derfor for å ha tre bruker-nivåer; administrator bruker som er tilegnet en oppgave bruker Det er nå begrensninger på hva brukerne kan se og gjøre. Dette gjorde at Sir Jerky Leap ble mer oversiktlig. De første papirprtotypene inneholdt en «rullegardin-meny» med funksjoner som «Add», «Edit» og lignende. Brukermessig fant vi denne funksjonaliteten tungvinn, og endte i stedet opp med å bruke en administratorlinje. Dette førte til at brukeren lett kan se hvilke funksjonaliteter som er tilgjengelig. Her er et skjermbilde på hvordan Sir Jerky Leap nå er blitt; 16

17 Utfordringer Å designe et brukervennlig brukergrensesnitt har vært den største utfordringen gjennom hele prosjekttiden. Listen under viser noen av utfordringene vi har stått ovenfor i prosjektet Optimalisering av GUI Dette har uten tvil vært den største utfordringen vi har hatt. Vi har gjennom hele prosjektgjennomføringen hatt i tankene at brukerkvaliteten er avgjørende for sluttproduktet og suksessen til produktet. Aptoma AS har til nå benyttet fem forskjellige programmer for oppgavestyring, og ønsket et program som var lett å bruke, men allikevel hadde mye funksjonalitet. Det å hele tiden ha fokus på brukervennligheten har derfor vært en utfordring ved utvikling av ny funksjonalitet og implementering av dette. Vi tok en avgjørelse på å holde designet minimalistisk og enkelt. Fargene og stilen er gjennomgående for hele systemet, noe som gjør at bruker «kjenner seg igjen» når han beveger seg rundt i programmet. For å få best mulige brukerkvaliteter er grundig testing utført. 17

18 Personlig-visning I «Personal» vises de prosjektene og oppgavene brukeren er blitt tilegnet. En stor utfordring var å finne en måte å presentere disse på, uten å presentere for mye informasjon på en gang. En bruker kunne ikke være tilegnet oppgaver som var over bunnivå, det vil si at det måtte være en oppgave med TOC. Vi valgte å presentere disse i tre lister, en «My assigned tasks», «My assigned tasks with administrative privileges» og «My tasks with administrative privileges». Vi fant dette nyttig da en bruker nødvendigvis ikke jobber på en oppgave som han er administrator for. «Brødsmulene» forteller bruker hvilket prosjekt oppgaven ligger under. Oppgavene ligger som linker i listen og da bruker trykker på disse, åpner oppgavene seg i en ny tab. Personligvisning vises her: 18

19 Innhold i TOC (Table Of Content) Denne visningen var ment å erstatte dagens bruk av Wiki, det vil si et dokument som var lett å jobbe med. Utformingen av denne visningen viste seg å bli mer utfordrende enn vi hadde forventet oss. I de første papirprototypene ble disse tegnet som en «oppslagstavle» med innholdsbokser som kunne flyttes. Oppslagstavlen blir vist i skissen: Ved nærmere ettertanke fant gruppen og oppdragsgiver dette oppsettet uoversiktig. Vi ble istedet enige om å presentere oppgavens innhold ved hjelp av en TOC (Table Of Content). Denne ble vi enige om at skulle vise tittelen på innholdsobjektene i oppgavene, med et symbol for type innholdsobjekt (tekst/bilde) som vist i skissen under: 19

20 Vi videreutviklet denne løsningen, og under vises slik den ser ut i programmet: Tab-funksjon En annen stor utfordring var å presentere prosjekter og oppgaver uten å overlesse brukeren med informasjon. Vi valgte en løsning hvor brukeren hadde mulighet til å åpne en liste over prosjekter gjennom «Projects -knappen», og umiddelbart kunne navigere seg nedover i trekkspillisten med prosjekter og oppgaver. Alle oppgaver, prosjekter, og tilhørende funksjonalitet er tilgjengelig i denne modusen. Dette tar mye skjermplass, og ved store prosjekter kan brukeren miste oversikten. Med tab-funksjonaliteten tilgjengelig, kan man velge å åpne oppgaver i en ny tab og på denne måten ha bedre kontroll på hva man jobber med. I tab'en står tittelen på oppgaven som er åpnet og tittel på overordnet oppgave følger med som brødsmuler. Ved åpning av oppgave i tab eller oppdatering av innhold i tab, blir brukeren gjort oppmerksom på dette gjennom en 20

21 oppdateringsindikator Ikoner Vi har valgt å bruke bildeikoner ved de forskjellige funksjonene. Målet med disse var at brukeren skulle forstå hva funksjonen gjorde uten å nødvendigvis lese teksten, og ikonvalg var derfor viktig. Valgte ikoner vises i tabellen under: Add administrator Administrator på oppgave Assign bruker Assignet til oppgave Aministrator og assignet til oppgave Prosjekt (mappe med innhold) Edit tittel på prosjekt Add/edit detaljer Move to tab Add oppgave Oppgave Oppgave med underoppgaver Åpen oppgave Add tekst Tekst i TOC Add bilde Bilde i TOC Open/close TOC Slette Lukke tab Accept/OK Cancel Brødsmuleindikator 21

22 «Mus-over-funksjonen» Da det er mye funksjonalitet i applikasjonen måtte vi finne en løsning som skjulte noe av dette, slik at det ikke ble uoversiktelig. Vi valgte «mus-over-funksjon». Nå brukeren navigerer seg igjennom applikasjonen blir ikoner, og dermed også funksjonalitet, tydeligere når musepekeren treffer disse Mappestruktur Dette var en funksjon vi valgte fordi det er noe de fleste brukere kan relatere seg til. Alle som har brukt Windows er vant med å navigere seg igjennom en slik struktur. 22

23 Implementasjon Denne delen av dokumentet beskriver de største utfordingene vi møtte på, valgene vi stod ovenfor, hvilke løsninger vi vurderte samt hvilke løsninger vi valgte Databasestruktur Fra starten var det enighet i gruppen om at Sir Jerky Leap kom til å bli en klar databasedrevet applikasjon, og dermed satt vi relativt tidlig i gang med å utforske hvilken databasestruktur vi trengte for å løse utfordringen vi sto ovenfor. Det viste seg snart at systemet trengte en sortert hierarkisk trestruktur, og dette skulle vise seg å bli vår første store utfordring. De fleste vanlige databasesystemer har per i dag ikke integrert støtte for foreldre-barn strukturer, og tilbyr kun en flat datastruktur basert på tabeller. For å kunne jobbe opp mot en database med en slik struktur må en dermed implementere sin egen logikk i datalageret, og deretter bearbeide disse dataene programatisk i etterkant. Vi så på flere mulige løsninger, fortrinnsvis disse; 1. Forelderpeker i barnet (Stakk). 2. Preordens-traversering med nodenummerering. 3. Brødsmule-indikator. Nummer to på listen er den mest elegante løsningen, da vi kunne benytte rekusjon for å traverse treet. Ettersom vi leste videre om denne løsningen viste det seg at denne varianten er rask på å hente data, men vinningen går opp i spinningen ved at metoden benytter mye prosesseringskraft på å sette inn, sortere eller slette data ved store datamengder. Dette grunnet at en må endre nummerering på potensielt n-1 av n oppføringer. Nummer tre på listen «brødsmuleindikator» er benyttet av flere forumvarianter, som også er hierarkisk strukturert av natur, og baserer seg på at barn arver sin forelders brødsmuleliste, og legger deretter til forelderen i denne listen. Slik vil en ha oversikt over hvor i hierarkiet en postering er relativt til sin forelder. Vi valgte ikke denne varianten da vi har behov for sortering av foreldre og barn, og et ønske om å vite hvilket nivå en oppgave er lokalisert på. Vi valgte en variant av nummer en på listen, som har foreldrepeker, sorteringindikator, og nivåindikator. Dette gjør at vi kan sortere en foreldergren av datalageret uten å endre flere posteringer enn nødvendig. Videre er det, ved å inspisere en forelders datafelter, effektivt å legge til 23

24 nye barn. AFW tilbyr et relativt godt abstraksjonslag mellom datalager og rammeverket, hvor en hver tabelloppføring eksponeres i form av et refleksivt objekt av samme klasse som databasetabellnavnet. Et hvert objekt opprettet av AFW-rammerverket får også sin egen unike identifikator, en såkalt AFWId, og kan hentes ut hvor som helst i applikasjonen basert på dette nummeret. I lys av dette valgte vi å basere interaksjonen mellom webgrensesnittet og bakenden av applikasjonen på utveksling av AFWId'er. Komplikasjonene med en slik tilnærming viste seg snart, da AFW ikke har noen form for å hente ut hierarkiske data slik vi trengte. Vi lagde dermed en egen uthentingsrutine for å hente ut oppgavetreet, men denne viste seg å være nokså tidkrevende. Vi måtte videre påse at AFWId'en i webgrensesnittet alltid var en referanse til et faktisk objekt i bakenden, og antok i utgangspunktet at AFW tildelte samme AFWId til en oppføring i datalageret hver gang denne ble hentet. Dette viste seg fort å være gale forutsetninger, og vi vurderte å gå bort fra AFW som enhet for objektidentifikasjon. Etter konsultasjon med hovedutvikler på Aptoma AS ble vi gjort oppmerksomme på MemCached, en applikasjon som kan fungere som et persisterende lag mellom webgrensesnittet og applikasjonen. MemCached lagrer data i minnet på serveren, og er per i dag stort sett kun i bruk i miljøer hvor samme, prosessorkrevende operasjon, gjøres meget hyppig. Et typisk eksempel på en slik operasjon er å vise forsiden på en større nettavis. I vår applikasjon har vi en slik prosessorkrevende operasjon ved hver eneste sidevisning, og dermed valgte vi å minske denne lasten ved å legge oppgavetreet i minnet på serveren, og manipulere dette parallelt med databaselaget. Dette viste seg å kreve betydelig mindre av serveren, og førte også til at vi kunne sikre at samtidige brukere jobber på samme datasett. 24

25 Prototype og Scriptacolous. Prototype er et rammeverk for Javascript som tilbyr objektdreven tilnærming til Javascript, og utvider DOM med et vell av nyttige metoder for hurtig og oversiktelig manipulasjon av klienten i en dynamisk webapplikasjon. Videre tilbyr Prototype kraftige Ajax-verktøy for oppdatering og uthenting av informasjon dynamisk. Scriptaculous er basert på Prototype og leverer ferdigutviklede komponenter som ved hjelp av Javascript, CSS og Ajax-kall tilbyr funksjonalitet som; dra-og-slipp, autooppdaterende nedtrekksmenyer, med mange flere. Sir Jerky Leap er tungt basert på Scriptaculous og Prototype. All oppdatering av siden baserer seg på Ajax-kall, og sortering av oppgave- og innholdslister er realisert med Scriptaculous Sortable kombinert med egendefinerte metoder for å hente ut relevante data. Den største utfordringen med å jobbe med Prototype og Scriptaculous har vært å debugge egenskrevet kode. Tiltenkt bruk og parametere er godt dokumentert, men selve metodikken bak koden er som oftest ikke dokumentert. Med bruk av predefinerte metoder på utradisjonelt vis, kode som i stor grad hadde avhengigheter og mangel på gode debugingsverktøy, gikk mye av tiden med til å inspisere DOM og saumfare kryptisk kode for å finne årsaken til eventuelle problemer. Den største utfordringen vi møtte på var å påse at Scriptaculous sortable fungerte i hierarki, og at oppdatering og utbytting av én sortable ikke forstyrret, og skapte problemer med de andre. Etter mye prøving og feiling viste det seg at ved utbytting av en sortable måtte alle parametre og id'er være identiske. Dette er nødvendig for å få slettet den foreldede listen fra DOM. Det ville vise seg at denne oppførselen inntraff ved uønskede og ulogiske tilfeller, og førte til at vi måtte utvide Sortable for å unngå at sortable-lister forstyrret hverandre ved oppdatering av lister som befant seg innenfor samme nodetre i DOM. Vår noe uvanlige tilnærming til navigasjon i applikasjonen gjennom bruk av både statiske funksjoner og faner som representerer innhold, skapte en utfordring i å beholde tilstand i applikasjonen på tross av at vi arbeider med en tilstandsløs protokoll. Ved hjelp av utstrakt bruk av Prototype for å inspisere DOM og identifisere elementer i en bestemt tilstand (eks. Åpen, aktiv, i endring, sortering, med flere) kunne vi sende tilstandsinformasjon av berørte elementer ved oppdatering av innhold. 25

26 Uten Prototype og Scriptaculous ville vi ikke vært i stand til å levere en dynamisk webapplikasjon på den tiden vi hadde til rådighet Sorterbare trekkspill-lister Sir Jerky Leap benytter trekkspill-lister, heretter kalt en Accordion, for å representere oppgavelister Bakgrunn Store deler av utfordringen vi fikk fra Aptoma AS gikk ut på å produsere et grensesnitt som var så lite påtrengende som mulig, og lot brukeren følge sin egen arbeidsflyt. «Programmet skal tilpasse seg brukeren.» Tilsvarende produkter, på nettet eller i skrivebordsmiljø, krever i høy grad at du bokstavlig talt fyller ut et skjema for å opprette, endre, eller administrere oppgaver. Denne metodikken gir brukeren liten grad av frihet til å jobbe iterativt på en oppgave, og kan føre til mange sidevisninger og repetative oppgaver Forarbeide Fra oppdragsgivers side var det et ønske om bruk av Accordion for å sortere oppgaver. Inspirasjonen for denne tilnærmingen var en Accordion basert på Scriptaculous,[ laget av Stickmanlabs. Aptoma AS hadde laget en egen, sorterbar, variant av denne accordionen, AccordionEdit. For å minske utviklingsbyrden var våre intensjoner å benytte denne i Sir Jerky Leap Utvikling AccordionEdit er en hendig tag for å produsere en sorterbar liste som har en tittellinje og innhold. Innholdet kommer til først til syne ved å klikke på tittellinjen og lukker seg ved å åpne en annen. AccordionEdit har mange nyttige funksjoner, slik som; automatisk oppdatering ved endringer, innlasting av innhold ved behov, søkefunksjonalitet og navigasjon med hurtigtaster. Det viste seg snart at vi ikke kunne benytte disse ekstrafunksjonene, og at utvidelse av selve 26

27 grunnfunksjonaliteten var nødvendig for å møte de kravene vi hadde til listen Utfordringer Interaktivitet Vi trengte en interaktiv liste, med ekstrafelter og knapper, noe man ved utviklingen av AccordionEdit ikke hadde tatt høyde for. Mulighet for sortering av listen skulle også kunne skrues av og på, og selve «dra-og-slipp»-funksjonaliteten skulle tilegnes et eget felt Brukerdifferansiering Brukere med forskjellig tilgangsnivå skulle kun ha tilgang til, og vise de funksjoner som er tilgjengelige for brukeren Kondisjonell lasting av innhold Innhold i elementer skal lastes inn på bakgrunn av hva slags type element det er. For at dette skulle fungere, måtte listen kunne skille mellom en liste med oppgaver, heretter kalt listeelement, og en enkeltstående «bunnoppgave». En «bunnoppgave» har et annet utseendet og funksjonalitet enn et listeelement, men skal kunne gjøres om til et listeelement hvis ønskelig. Bunnelementer skal også kun lastes inn i sin helhet ved behov Oppdatering av listen Det skulle være mulig å oppdatere deler av listen med nytt eller endret innhold. 27

28 Løsninger Interaktivitet For å gjøre AccordionEdit interaktiv ble vi tvunget til å utvide selve Javascriptkoden og legge inn våre egne funksjoner. Når man klikket på et accordionelement ville listelementet åpne eller lukke seg, avhengig av kontekst. Dette skjedde også om vi trykket på ekstraelementene vi hadde lagt inn i listeelementet. Dette skjedde på grunn hendelsesbobling i Javascript, og måtte avbrytes i hendelseslytteren. I hendelseslytteren sjekket vi hvilket ekstraelement som var trykket på, utførte tilhørende operasjoner, og avbrøt hendelsen Brukerdifferansiering Ved å endre templatene, HTML-koden som produseres av Accordion, brukt til å vise listene til å motta brukerinformasjon kunne vi utelate de elementer som ga brukeren mulighet til å endre på en liste Kondisjonell lasting av innhold AccordionEdit hadde en metode for å laste innhold i et listeelement ved åpning av listeelementet, men var ikke laget med tanke på hierarkiske lister og ga lite frihet med tanke på hva som oppdateres ved innlasting. Vi valgte derfor en tilnærming hvor innlasting av lister og listeelementer med lister alltid lastes inn, mens «bunnelementer» lastes inn ved behov. Dette løste vi ved å utvide AccordionEdit til å kjøre et Ajax-kall som lastet innhold og andre elementer etter behov Oppdatering av listen Ved endringer, eksempelvis ved sortering, tillegging og sletting av et listeelement, i en liste var det nødvendig å oppdatere denne. Grunnet at AccordionEdit ikke var tilrettelagt hierarkiske lister lå mye av utfordringen på å beholde sorteringsfunksjonaliteten ved oppdatering. AccordionEdit var utviklet slik at elementer først lastes synlige inn i nettleseren for så i andre rekke å manipuleres i DOM for å lukke elementene som ikke skal være synlige for brukeren. Dette skapte en flimmereffekt på skjermen som trakk fokus fra brukeren, og skapte et inntrykk av at noe var galt. Det viste seg å være en stor oppgave å endre denne oppførselen direkte i AccordionEdit, og vi valgte dermed en tilnærming hvor alt innhold som lastes inn dynamisk, skjules og erstattes med en 28

29 innlastingsindikator Testing Testrapporten ligger vedlagt i sin helhet senere i sluttdokumentasjonen. Testfasen er en viktig fase, da det å levere et produkt uten store kodefeil er vesentlig for hvordan det oppleves for sluttbrukeren. Det er nær umulig å levere et helt feilfritt produkt, derfor er det viktig å dokumentere hva vi testet og hvordan. Dette gjør det lettere å vedlikeholde produktet og lettere å finne eventuelle feil som oppstår senere. Vi testet først brukergrensesnittet, da brukervennlighet var en viktig del av prosjektet. Vi begynte med papirprototyper som senere utviklet seg til en HTML-prototype. Funksjonaliteten til designet har blitt testet og godkjent av oppdragsgiver. Da vi var ferdig med programmet ble Sir Jerky Leap testet av oppdragsgiver og sluttbrukerne for å få en bekreftelse på brukervennligheten. Vi har testet for feil i kode kontinuerlig gjennom hele implementasjonsfasen. Etterhvert som funksjoner ble ferdigstilt, testet vi ut disse. Dette viste seg å være til stor hjelp, da vi oppdaget ganske fatale feil under denne testingen. Dette ble rettet opp før vi fortsatte arbeidet med andre funksjoner. I denne fasen ble FireBug brukt aktivt. Denne viste om og hvor eventuelt feilen(e) oppstod. 29

30 5. Samarbeid Her beskrives samarbeidet mellom gruppen og veileder samt gruppens samarbeid med oppdragsgiver Samarbeid med oppdragsgiver og sluttbrukerne Vi har hatt et veldig positivt samarbeid med vår oppdragsgiver, Aptoma AS. Vi fikk tilbud om å bruke deres lokaler, men da det stadig dukket opp ting vi måtte diskutere, og firmaet har et åpent kontorlandskap bestemte vi oss for å reservere et grupperom på skolen. Dette rommet har vi benyttet oss av så og si hver dag. Vi hadde regelmessige møter med oppdragsgiveren der vi la frem forslag og løsninger til Sir Jerky Leap. Vi fikk skryt og konstruktiv kritikk på ting vi hadde gjort bra eller mindre bra. Utenom møtene hadde vi alltid mulighet til å kontakte både oppdragsgiver og de ansatte ved Aptoma AS for å få tips og råd. Dette kunne skje over Skype, telefon eller mail. Dette viste seg å være veldig nyttig for oss da vi skulle ta i bruk rammeverk og programmer som de har utviklet, og integrere vårt produkt med disse Veiledning fra Høgskolen i Oslo Vi ble tidlig enige med vår veileder, Eva Hadler Vihovde, at vi skulle ha ukentlige møter. På disse møtene fikk vi veiledning om hvordan vi burde gå frem, hva som burde prioriteres, hvor lang tid vi burde bruke på hver fase av prosjektet osv. I tillegg har vi sett på veiledningen til utvikling av prosjektdokumentasjonen som meget nyttig. Vi hadde aldri vært borti et så stort og viktig prosjekt, og vi har av den grunn ikke skrevet prosjektdokumentasjon på denne måten før. Vi har hatt god kommunikasjon med vår veileder, og har fått god hjelp til å løse de utfordringene vi har stått ovenfor. Veilederen vår har allerede begynt å snakke med oss om veiledning til fremføringen, og vi har tro på at det gode samarbeidet mellom oss og veileder vil fortsette helt til prosjektets slutt. 30

31 6. Konklusjon Sluttproduktet, Sir Jerky Leap, har gruppen planlagt og utviklet på egenhånd, med unntak av enkelte krav til funksjonalitet og brukergrensesnitt som oppdragsgiver hadde på forhånd. De ansatte på Aptoma AS kan nå opprette prosjekt og oppgaver med tilhørende underoppgaver eller TOC. Hva en bruker kan gjøre er avhengig av hvilke rettigheter han/hun har. At prosjektet har vært utfordrende er det ingen tvil om. Det å sette oss inn i nye rammeverk og prinsipper har vært en større jobb enn vi trodde. Måten vi taklet utfordringene på har vist seg å være en viktig del av læringsprosessen. Vi har lært mye av et så omfattende prosjekt som Sir Jerky Leap, og vi vet vi at vi kommer til å få bruk for dette i fremtiden. Det ble bestemt, i samråd med oppdragsgiver, at det ikke var nødvendig med en brukerveiledning da programmet vi har laget er intuitivt. Vi har derimot laget noe som heter «clean slate», som er et forklarende bilde og vil fungere som en slags brukerveiledning. Denne skal være tilgjengelig for bruker i oppstarten av Sir Jerky Leap. Dette clean slate er det første brukeren ser når han logger inn på applikasjonen. I et slikt prosjekt stilles det store krav til oss som utviklere og forventningene har vært høye. Vi føler at vi har levd opp til disse og er veldig fornøyde med det vi har produsert i løpet av prosjektperioden. 31

32 Under utvikling av Sir Jerky Leap har det blitt tilrettelagt for vidreutvikling av applikasjonen, gjennom å legge til tabeller i databasen som foreløpig ikke er i bruk, og mulighet for å produsere objekter og strukturer av disse. Det er klargjort for implementasjon, og delvis utviklet funksjonalitet utover det systemet tilbyr i dag. For en oversikt over disse funksjonene se vedlegg nr