Tetriz - Event & Management

Transkript

1 Tetriz - Event & Management Artistnettside Sluttdokumentasjon Høgskolen i Oslo og Akershus Hovedprosjekt 2014 Gruppe 7 Jasmin Mehrnia, Joakim Kartveit, Frode Mathiesen, Gry Anita Nilsen

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL HOVEDPROSJEKT DATO Tetriz Event & Management Artist Nettside PROSJEKTDELTAKERE ANTALL SIDER / BILAG 189 INTERN VEILEDER Joakim Kartveit Frode Mathiesen Gry Anita Nilsen Jasmin Mehrnia s s s s Geir Skjevling OPPDRAGSGIVER Tetriz Event & Management KONTAKTPERSON Daniel Hamnes SAMMENDRAG Artist Nettside for Daniel Elmrhari, og et CMS verktøy som skal forenkle vedlikehold av artist nettsiden. 3 STIKKORD PHP CMS Databaser

3 Forord Sluttdokumentasjonen inneholder all dokumentasjon i forhold til vårt hovedprosjekt for bachelor i Anvendt Datateknologi, ved Høgskolen i Oslo og Akershus, våren Dokumentet er i all hovedsak beregnet for veileder, oppdragsgiver og sensor. Vi ønsker å takke vår interne veileder Geir Skjevling, for god støtte gjennom hele prosjektperioden. Vi vil også få takke vår oppdragsgiver Tetriz Event & Management for oppgaven, som har muliggjort hele prosjektet. Leserveiledning Sluttdokumentasjonens fem hoveddeler består av: Presentasjon: kort presentasjon av de involverte partene, prosjektet og sluttproduktet. Prosessdokumentasjonen: med innledning beskriver den planleggingen og metoder, utviklingen, kort om kravspesifikasjon og en avsluttende del. Produktdokumentasjonen: redegjør for produktet. Testdokumentasjon: bakgrunn og beskrivelse av testene. Brukerveiledning: en brukerveiledning. I dokumentasjonen vil det bli referert til andre relevante deler i sluttdokumentasjonen, oppgitt med eksempelvis punk 2.3 Nye kunnskaper i Prosessdokumentasjonen. Figurer er merket med nummer, der eksempelvis nummer 1 står for Prosessdokumentasjonen, nummer 2 for Produktdokumentasjonen o.l. For eksempel er figur nr. 1-2, figur nr. 2 i Prosessdokumentasjonen (Nr. 1). Det samme gjelder for henvisning til referanser og vedlegg. Sluttdokumentasjonen vil bli lagt ut på nettsiden Vedlagt dokumentet følger det en CD som inneholder alle filene tilknyttet produktet.

4 Innholdet i denne rapporten Rapporten inneholder følgende dokumenter. Innholdsfortegnelse Presentasjon... 5 Prosessdokumentasjon... 9 Produktdokumentasjon Testdokumentasjon Brukerveiledning Kravspesifikasjon Ordforklaringer

5 Tetriz - Event & Management Artistnettside Presentasjon Høgskolen i Oslo og Akershus Hovedprosjekt 2014 Gruppe 7 Jasmin Mehrnia, Joakim Kartveit, Frode Mathiesen, Gry Anita Nilsen

6 Forord Dette dokumentet er en presentasjon av gruppe 7 sitt hovedprosjekt ved Høgskolen i Oslo og Akershus, våren Dokumentet gir en kort presentasjon av de involverte partene, oppgaven og sluttproduktet. Sluttproduktet vil videre redegjøres i produktdokumentasjonen. Vi anbefaler at dette dokumentet leses i sin helhet, før de andre dokumentene i rapporten. Etter presentasjonen er det fordelaktig å lese prosessdokumentasjonen, der punktene fra presentasjonen blir videre redegjort. Prosessdokumentasjonen refererer videre til produktdokumentasjonen og testdokumentasjonen. Disse to kan leses i sin helhet eller brukes som et oppslagsverk. Etter testdokumentasjonen følger brukerveiledning, som er ment som en hjelp til sluttbrukere av systemet. Til slutt følger den endelige Kravspesifikasjonen og ordforklaringer. Referanseliste og vedlegg vil listes opp i slutten av hvert dokument. Vi ønsker å informere om at CD med alle filer tilknyttet produktet er vedlegg til hele Sluttdokumentasjonen. Presentasjon 6

7 Innholdsfortegnelse Forord... Feil! Bokmerke er ikke definert. 1 Partene i prosjektet... Feil! Bokmerke er ikke definert. 1.1 Gruppen... Feil! Bokmerke er ikke definert. 1.2 Oppdragsgiveren... Feil! Bokmerke er ikke definert. 1.3 Veileder... Feil! Bokmerke er ikke definert. 2 Oppgaven og sluttproduktet... Feil! Bokmerke er ikke definert. 2.1 Bakgrunn for oppgaven... Feil! Bokmerke er ikke definert. 2.2 Sluttproduktet... Feil! Bokmerke er ikke definert. Presentasjon 7

8 1 Partene i prosjektet 1.1 Gruppen Gruppe nr.7 består av Joakim Kartveit, Frode Mathiesen, Jasmin Merhnia og Gry Anita Nilsen. Alle gruppens medlemmer studerer bachelorstudiet Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. Samtlige har jobbet med en eller flere medlemmer tidligere, men dette er vårt første felles prosjekt der alle jobber sammen. Fordelen er at vi kjenner hverandres ambisjoner, mål og kunnskaper. Bakgrunnen for gruppesammensetningen er også at vi har forskjellige styrker innenfor fagene, og har derfor hatt en god mulighet til å lære av hverandre. Vi mener at vi stiller sterkt i forhold til å oppfylle målene ved dette prosjektet. 1.2 Oppdragsgiveren Vår oppdragsgiver er Tetriz Event & Management, et firma som har management drift for flere artister og arrangerer eventer for små og store begivenheter. Kontaktpersonen vår er daglig leder, Daniel Hamnes. 1.3 Veileder Veilederen vår har vært Geir Skjevling, ved Høgskolen i Oslo og Akershus. 2 Oppgaven og sluttproduktet 2.1 Bakgrunn for oppgaven Tetriz Event & Management har ansvar for å promotere sine artister. Bedriften ønsket at vi skulle lage en nettside basert på en av deres artister, da de per dags dato ikke har noen. I tillegg til en artistnettside var det ønskelig med et publiseringsverktøy, som vi videre vil omtale som administrasjonsdel (CMS). 2.2 Sluttproduktet Nettsiden kan brukes som en plattform, og sammen med administrasjonsdelen kan oppdragsgiveren opprette tilsvarende nettsider for de resterende artistene. I tillegg skal administrasjonsdelen benyttes for å foreta endringer på nettsiden, laste opp nyhetsartikler og media. Under administrasjonsdelen kan det også opprettes, endres eller fjernes brukere med tilgang. Presentasjon 8

9 Tetriz - Event & Management Artistnettside Prosessdokumentasjon Høgskolen i Oslo og Akershus Hovedprosjekt 2014 Gruppe 7 Jasmin Mehrnia, Joakim Kartveit, Frode Mathiesen, Gry Anita Nilsen Prosessdokumentasjon 9

10 Forord Dette er prosessdokumentasjonen for gruppe 7 sitt hovedprosjekt, for oppdragsgiveren Tetriz Event & Management. Dokumentet inneholder blant annet utviklingen av systemet, bakgrunnen for utviklingen, bruksområde, arbeidsmetoder og metodikk. I tillegg til dette vil vi fortelle mer om gruppens kommunikasjon seg i mellom, gruppen og veileder, gruppen og oppdragsgiver. I løpet av dokumentet ønsker vi å redegjøre for de ulike fasene, fra forprosjekt til sluttdokumentasjonsfasen. Prosessdokumentasjonen er i all hovedsak skrevet for sensor og veileder (Geir Skjevling), men enkelte deler av dokumentet er også rettet mot oppdragsgiver og eventuelle sluttbrukere av systemet. Det som kan være av interesse for oppdragsgiver og sluttbrukere er sannsynligvis verktøy, teknologier og metoder. Allikevel er dokumentet tilrettelagt slik at alle skal kunne lese det, slik at eksempelvis nye brukere uten forkunnskaper kan benytte seg av dette. Prosessdokumentasjonen er delt opp i fem hoveddeler med underpunkter: 1 Innledning: omhandler de ulike partene i prosjektet. 2 Planlegging og metode: omhandler planlegging, samarbeid/kommunikasjon, kompetansebygging, metodikk, verktøy og teknologier. 3 Utviklingsprosessen: herunder forklarer vi kort prosjektets ulike faser. 4 Kravspesifikasjonen og dens rolle: hvordan gruppen har stilt seg i forhold til kravspesifikasjonen, hvorvidt gruppen har klart å følge denne, oppfylte krav, avvik og eventuelle endringer som oppstod. 5 Avsluttende del: oppsummering og nytteverdi av prosjektet og produktet. Til slutt informerer vi om at vi har lagt over alle filer tilhørende produktet på en CD, som ligger som vedlegg til sluttdokumentasjonen. Prosessdokumentasjon 10

11 Innholdsfortegnelse Forord Innledning Gruppen Oppdragsgiver Oppgaven Bedriftens situasjon Bakgrunn for oppgaven Oppgavens mål Rammebetingelser og begrensninger Planlegging og metode Samarbeid Gruppen Oppdragsgiver Veileder Verktøy og teknologier Verktøy Teknologier Nye Kunnskaper Metodikk Dokumentasjon Utviklingsmetodikk Versjonskontroll og backup Diagrammer Analyser Utviklingsprosessen Prosjektets utviklingsfaser Utredningsfasen Forprosjektfasen Produksjonsfasen Dokumentasjonsfasen Utfordringer Faglige utfordringer Andre utfordringer Prosessdokumentasjon 11

12 4 Kravspesifikasjonen og dens rolle Kravspesifikasjonens rolle Samsvar med kravspesifikasjonen Avsluttende del Prosjektets og produktets nytteverdi Nytteverdi for oppdragsgiver Nytteverdi for sluttbrukere Gruppens læringsutbytte Konklusjon Referanseliste Vedlegg Prosessdokumentasjon 12

13 1 Innledning Under dette punktet ønsker vi å redegjøre for gruppen, oppdragsgiver og informasjon om selve oppgaven. 1.1 Gruppen Gruppe nr.7 består av Joakim Kartveit, Gry Anita Nilsen, Frode Mathiesen og Jasmin Mehrnia. Samtlige av gruppens medlemmer studerer bachelorstudiet Anvendt Datateknologi ved Høgskolen i Oslo og Akershus (HiOA). Alle har jobbet med et eller flere gruppemedlemmer tidligere, vedrørende prosjekter i tidligere fag. Ettersom vi har jobbet med en eller flere før, vet vi en del om hverandres ambisjoner, mål, kunnskaper, styrker og svakheter. Dette har vært en klar fordel for oss som gruppe i løpet av prosjektet. Gruppens store styrke er nok at vi har kjennskap til mye av de samme «fagområdene», ettersom vi stort sett har hatt de samme fagene. Allikevel har vi utmerket oss på forskjellige områder, noe som er en god egenskap for en gruppe. Det er naturlig at medlemmene har ulikt kunnskapsnivå på de forskjellige områdene, og vi har derfor kunnet lære av hverandre. Allerede ved første gruppemøte bestemte vi at samtlige av gruppens medlemmer skulle være delaktig i alle prosjektets ulike områder og faser. Vi fordelte raskt ulike ansvarsområder, og vi stod selv ansvarlig for å oppdatere gruppen underveis. Vi har vektlagt at alle skal ta del og dette betyr derfor at vi skulle komme med innspill og konstruktive tilbakemeldinger til hverandre. Joakim og Frode tok hovedansvaret for administrasjonsdelen, Jasmin og Gry hadde hovedansvaret for nettsiden. 1.2 Oppdragsgiver Oppdragsgiveren vår er Tetriz Event & Management, som er et firma som arrangerer eventer for små og store begivenheter. De har også management drift for en rekke artister. Vår kontaktperson er CEO/daglig leder, Daniel Hamnes. Figur 1-1: Oppdragsgivers Logo Vi kom i kontakt med oppdragsgiveren ved hjelp av et av gruppens medlemmer, da de er tidligere bekjente. Oppdragsgiveren hadde et passende prosjekt for oss, et prosjekt han hadde planlagt å iverksette uansett. Hensikten med arbeidet har vært å gi oppdragsgiveren det som den ønsket, samtidig som vi har vært nødt til å foreta beslutninger som vi mener gagner sluttbrukerne. Etter oppdragsgiverens ønske har vi utviklet en nettside for en artist, samt en administrasjonsdel (Control Management System). Prosessdokumentasjon 13

14 1.3 Oppgaven Under dette punktet vil vi ta for oss bedriftens nåværende situasjon og forklare mer om oppgavens bakgrunn, mål, rammebetingelser og begrensinger Bedriftens situasjon Det skal opprettes en nettside for bedriften, som er bestilt av et firma. Ved prosjektets start var denne under utvikling, men var tilgjengelig for allmenn skue i mars Tetriz har ingen tidligere nettside for sine artister, men promoteres delvis ved hjelp av sosiale medier Bakgrunn for oppgaven Bedriften har ansvar for å promotere sine artister, det var derfor ønskelig at vi skulle lage en nettside basert på en av deres artister. En annen viktig del av prosjektet var at vi skulle lage et publiseringsverktøy, som vi videre omtaler som administrasjonsdel. Publiseringsverktøyet skulle benyttes for å foreta endringer på nettsiden, opplastninger/publiseringer av artikler og media, samt lage nye nettsider Oppgavens mål Hovedmålet var å lage en nettside for en av deres artister som skulle fungere som en «mal» for fremtidige nettsider til andre artister. I tillegg til dette skulle vi som tidligere nevnt, opprette en administrasjonsdel som kunne forenkle vedlikehold av nettsiden. Et ønsket delmål var å forenkle tilgangen til sosiale medier som er knyttet til artisten, herunder gjelder Facebook, Twitter, Instagram, Youtube og Vimeo. Det var viktig for oppdragsgiver at nettsiden skulle vise en oversikt over kommende konserter/opptredener, som ble gjort ved hjelp av oppdragsgiverens ønske om en tredjeparts applikasjon, «BandsInTown». Nettsiden måtte vise linker til artistens verk slik at brukeren får se og/eller høre disse. Bilder og oppdateringer om artisten skal være lett tilgjengelig for tilhørere (fans) og presse. Etter prosjektets oppstart kom oppdragsgiveren med et annet ønskelig krav, muligheten for å melde seg opp til nyhetsbrev på nettsiden. Oppdragsgiveren ønsket videre at dette skulle bli utsendt i PDF format på brukernes e-post som da ville være lagret i en database Rammebetingelser og begrensninger Bedriften hadde før prosjektets oppstart kjøpt domenenavn for sine artister, og skulle leie serverplass når behovet oppstod. Tidsrammen var på 20 uker. Vi har satt rammebetingelser for hvilke programmeringsspråk vi ønsket å benytte oss av, samt valg av databasehåndteringssystemer. Serveren vi har brukt har også vært med på å sette rammebetingelser, for eksempel antall e-poster som kan sendes ut per sekund og per minutt. Vi har satt rammebetingelser i forhold til hvilke plattformer løsningen skal støtte. Prosessdokumentasjon 14

15 Dette prosjektet har vært relativt stort og omfattende, og det er derfor naturlig at det dukker opp noen begrensninger som gjør at vi ikke har fått utført eller implementert enkelte funksjoner. Noen begrensninger har gått på tidsberegning, egen erfaring og generelt for lite kunnskap innenfor det aktuelle området. En begrensning som oppstod var at oppdragsgiver ønsket å kunne sende ut et høyere flertall av e-poster til brukere, dette i henhold til nyhetsbrev funksjonen. Grunnen til at vi ikke fikk oppfylt dette ønskelige kravet er fordi Domeneshop har en egen begrensning. Vi hadde ikke muligheten til å lage egen kode som ventet lenge nok mellom hver e-post. Dette fører til at en ikke kan sende mer enn en e-post i sekundet og 60 i minuttet. Dermed medførte dette en begrensning for oppdragsgiveren i forhold til antall e-poster som kan sendes ut. En annen begrensning som oppstod underveis var at oppdragsgiver ønsket en mulighet for å sende ut SMS til medlemmer. Oppdragsgiveren fortalte ikke dette før vi var godt i gang med prosjektet, og på grunn av mangel på tid og kunnskap måtte vi dermed gi oppdragsgiveren beskjed om at dette sannsynligvis ikke var et ønske/krav vi kunne imøtekomme. For å kunne opprette en slik funksjon, hadde vi også måttet koble inn andre nødvendige tjenester. Vi undersøkte mulighetene for implementering av samtlige funksjoner som blir nevnt under begrensninger, uten at vi klarte å realisere disse. Grunnen til dette var mye på grunn av at vi ikke hadde hverken tilstrekkelig med tid og/eller kunnskap. Oppdragsgiveren ble informert om dette da vi forstod at dette ikke ville imøtekommes, samtidig som vi har prøvd å holde oppdragsgiveren oppdatert i løpet av prosjektet. Prosessdokumentasjon 15

16 2 Planlegging og metode Under dette punktet vil vi redegjøre for samarbeid og kommunikasjon, verktøy og teknologier, planlegging før og underveis i prosjektet. Vi forteller mer om kunnskaper vi måtte tilegne oss, metodikk, diagrammer og analyser. 2.1 Samarbeid Samarbeid er noe som står meget sentralt i prosjektarbeid. Et godt samarbeid kan faktisk være helt avgjørende i alle prosessens ulike deler. I punkt vil vi fortelle mer om samarbeidet i gruppen, punk redegjør vi for samarbeidet med oppdragsgiver og punkt samarbeidet med veileder Gruppen Samarbeidet i gruppen har gått veldig bra, med en åpen og god dialog. Vi har vært dyktige til å holde hverandre oppdatert om arbeidet. Det har heller ikke vært noe problem å fordele arbeidsoppgaver, da alle har vært positive hele veien og interessert i å gjøre sitt beste. Det er en fordel at hele gruppen har vært svært deltagende i prosjektet og prosessen underveis. Vi mener at en av våres styrker er at vi har vært kritiske til hverandres arbeid, noe som har hjulpet i forhold til valg av løsninger. En annen styrke er at vi har vært flinke til å ha møter der «ordet var fritt», altså vi kunne lufte alle tanker og ideer, og fikk konstruktive tilbakemeldinger på dette. Vi tenker at gruppen har en meget god sammensetning da vi alle fire er svært ulike personer, og dette kan være svært gunstig i prosjektarbeid. I løpet av prosjektet forstod samtlige medlemmer at vi jobbet svært godt individuelt og ønsket derfor å jobbe mer hjemmefra. Dette er også litt på grunn av mangelen på grupperom på skolen. Vi startet opprinnelig med faste møtedager på tirsdager, torsdager og fredager, men gikk over til å bestemme neste møtedag på slutten av hvert møte. Enkelte uker hadde vi ikke gruppemøter på skolen, og da ble kommunikasjon ved hjelp av telefon og sosiale medier spesielt nødvendig. Av dette ser vi at det individuelle arbeidet har stått meget sentralt i prosessen, men dette medfører også en god samarbeidsevne. Vi satte opp arbeidsoppgaver og fordelte disse underveis, som ble gjort til satt frist. Det har ikke vært noen begrensning for oss at vi ikke har møttes hver dag, da arbeidet har gitt svært gode resultater Oppdragsgiver Forholdet til oppdragsgiveren har vært noe varierende. Dette er litt med tanke på kommunikasjon, tilgjengelighet og tilstedeværelse. Oppdragsgiveren var i starten flink til å svare på e-post, men det viste seg etter hvert å være vanskelig og få respons. Oppdragsgiveren var særdeles dårlig til å svare raskt og/eller i det hele tatt svare på e- poster, han forklarte dette ved at han var veldig opptatt i forhold til jobben. Da Prosessdokumentasjon 16

17 presiserte vi at vi prøvde å utvikle et produkt som han ønsket, og at vi derfor var nødt til å få svar fortløpende slik at vi kunne gå videre med prosessen. Videre ønsker vi å nevne at oppdragsgiveren først ga noen ønsker/krav, ved neste møte (da etter at vi hadde startet arbeidet) hadde han flere nye ønsker/krav, der noen gikk i strid med de første ønskene/kravene. Da vi nærmet oss slutten på prosjektet, kom han med enda noen ønsker/krav som måtte gjøres annerledes, blant annet ba han oss skifte fonten på slideshowet, som var i strid med typen design han tidligere hadde ønsket. Oppdragsgiveren har tilsynelatende vært flink til å holde seg oppdatert i forhold til hvordan vi utvikler produktet, men det er ikke alltid en kan lese seg opp til kunnskaper om emnene, alt er ikke nødvendigvis like «enkelt» som det står forklart på internett. Vi har holdt et stort fokus på brukervennlighet og universell utforming, så langt dette lot seg gjøre. I skrivende stund ( ) venter vi fortsatt på tilbakemelding fra oppdragsgiver i forhold til produktet, men har ikke fått svar. Vi har gjort flere forsøk på å få tilbakemelding og ved hjelp av forskjellige midler, men dette ser ikke ut til å nytte. Vi er nødt til å godta at vi sannsynligvis aldri får en tilbakemelding på hva han synes om prosjektet. Dette er naturligvis veldig kjedelig for oss i gruppen, da vi har jobbet hardt med dette prosjektet/produktet, men vi får ta det med oss som en erfaring videre Veileder Samarbeidet med veileder har vært bra, han har deltatt på møter når vi har bedt om det og vært etter vår oppfatning positiv til prosjektet. Han har vært flink til å se over ting vi har gjort, noe som har vært viktig for oss. Veileder har vært støttende under fremdriften i alle faser av prosjektet, i ettertid ser vi at vi ønsket flere tilbakemeldinger, tips og kritikk fra veileder. Dette kunne vi som gruppe ha kommunisert bedre til veileder som vi er sikre på ville etterkomme våre ønsker. 2.2 Verktøy og teknologier Underveis i prosjektet har vi benyttet oss av ulike verktøy og teknologier for å nå prosjektets mål. I dette punktet ønsker vi å dele disse inn i punkt Verktøy og Teknologier, der vi forklarer kort hva vi synes om de forskjellige Verktøy Under dette punktet vil vi forklare hva vi mener om de ulike verktøyene som har stått mest sentralt i prosjektet, med tanke på utviklingen av produktet. Alle verktøy vi har benyttet oss av er tilgjengelig på internett og er kostnadsfritt, unntatt Photoshop. Prosessdokumentasjon 17

18 NetBeans Vi har benyttet oss av et IDE-verktøy, NetBeans, ettersom alle av gruppens medlemmer har brukt dette tidligere og det er tilgjengelig i begge operativsystemene som vi har brukt (OSX og Windows). Dette er et godt verktøy som er gunstig å bruke innen programmering da det skaper god oversikt over kodingen og passer utmerket til PHP og JavaScript koding. Figur 1-2 Logo Netbeans Notepad++ Noen medlemmer har valgt å supplere med et programmeringsverktøy kalt Notepad++. Dette er fordi noen av medlemmene kjenner dette enda bedre enn NetBeans, og dette har derfor vært tidsbesparende. Dette er et godt verktøy, spesielt med tanke på HTML og CSS koding XAMPP, Apache og MySQL Figur 1-3 Logo notepad++ Vi har brukt en programpakke for lokal server, XAMPP. Fordelen med XAMPP er at vi kan bruke den lokalt, med andre ord vi må ikke flytte filer til server for å teste endringer og lignende. Figur 1-4 Logo XAMPP Vi har også benyttet oss av en webserver, Apache, dette er programvaren som brukes av netthotellet i dette prosjektet. Figur 1-5 Logo Apache Videre har vi benyttet oss av et Databaseadministrasjonssystem, MySQL. Formålet er å lagre innholdet til nettsiden i en database. Figur 1-6 Logo MySQL Innebygget utviklerverktøy Primært har vi benyttet oss av Google Chrome sin nettlesers innebygde utviklerverktøy. Vi har brukt denne mye opp mot grensesnittet, mest for å finne ut av hvor stor plass de ulike elementene tar, hvordan nettleseren ser koden. Dette har vært et særdeles godt verktøy, der vi ikke har noe negativt å nevne. Med andre ord et sterkt verktøy. Figur 1-7 Logo Google Chrome Prosessdokumentasjon 18

19 Firebug Firebug er et webutvikler verktøy som tillater debugging, endringshåndtering og følger med på nettsides elementer i «sanntid». Det har vært et veldig hjelpsomt verktøy ved utviklingen av JavaScript funksjoner. Ut ifra vår bruk av dette verktøyet, har vi ikke savnet noe funksjonalitet. Figur 1-8 Logo Firebug Git Versjonskontrollsystemet Git er et verktøy som gjør det lettere for utviklere å samarbeide med kode. Verktøyet holder styr på versjoner og endringer som blir utført av utviklere i tillegg til at det tillater utviklerne å flette inn sin egen kode inn i andres kode, kalt «merging». Bitbucket er en webbasert hostingtjeneste for Git. Figur 1-9 Logo Bitbucket Vi brukte dette verktøyet for å kunne programmere deler av produktet individuelt ettersom vi kunne følge med på hvilke endringer de andre utførte i koden. Det er en terskel som en må gå over ettersom man må venne seg til å skrive hva formålet med kode og endringer har før man «pusher» dette til Git. Det kan oppstå problemer dersom man ikke oppdaterer sin lokale «repository» opp mot den eksterne «repositorien», og hvis to eller flere utfører endringer i samme filer. Etter å ha tilvendt oss til å bruke dette verktøyet har det hatt en positiv innvirkning på utviklingen Dropbox Dropbox er en fildelingstjeneste der en kan lagre i «sky», synkronisere filer og klientprogramvare. Brukere kan opprette egne mapper på sin egen datamaskin, som deretter Dropbox vil synkronisere. På denne måten vil mappene være tilgjengelig via Dropbox sin nettside, desktop (dersom en har lastet ned programvaren) og mobil applikasjoner. Det er denne funksjonaliteten vi har benyttet oss, både som verktøy for deling av filer, men også som en backup for gruppen. Det er en ulempe Figur 1-10 Logo Dropbox som er nevneverdig, og det er at kun en bruker kan foreta endringer i dokumentet, Dropbox tillater ikke flere samtidige brukere i «sanntid». Prosessdokumentasjon 19

20 Google Docs Google Docs er en webbasert kontorpakke, som inneholder blant annet tekstbehandling, regneark og presentasjoner. Vi har kun benyttet oss av tekstbehandling i forhold til vår prosjektdagbok, som gjør at vi enkelt kunne dele denne fra gruppens nettside. Dermed ga vi alle Figur 1-11 Logo leserettigheter, men begrenset for skriverettigheter. Fordelen med Google Docs verktøyet er at det tillates flere samtidige brukere i «sanntid». Verktøyet har fungert akkurat slik vi ønsket, og det er ingen funksjonalitet vi savner Adobe Photoshop Photoshop er et grafikkprogram som vi har brukt til å lage skisser og utkast av nettsiden. Dette har gjort at vi enkelt kunne vise disse til oppdragsgiver og få tilbakemelding på eventuelle endringer. Vi har også brukt Photoshop til å redigere bilder, for å tilpasses nettsiden. Dette har fungert bra for å kunne «teste» designet før implementasjon. Det har med andre ord fungert bra og hatt stor nytteverdi for oss Teknologier Figur 1-12 Logo Adobe Photoshop Under dette punktet vil vi forklare hva vi mener om de ulike teknologiene som har stått mest sentralt i prosjektet, med tanke på utviklingen av produktet. Alle teknologiene vi har benyttet oss av er tilgjengelige på nettet og er kostnadsfrie PDO Kort fortalt PDO står for PHP Data Objects, som er en teknologi som brukes for og aksessere databaser i PHP. Denne har vi brukt opp i mot MySQL for å gi tilgang fra PHP til MySQL og Databaser. Se punkt PHP PDO i produktdokumentasjonen for mer detaljer rundt PDO. Denne teknologien har fungert bra, vi har holdt oss til basis funksjonaliteten og savner derfor ikke noe i denne teknologien. Derfor er dette en tilsynelatende sterk teknologi. Figur 1-13 logo PDO Prosessdokumentasjon 20

21 Bootstrap Dette er en teknologi/rammeverk som brukes for å lage nettsider og webapplikasjoner. Det inneholder HTML og CSS design som blant annet omfatter former, knapper, navigering og andre grensesnitt komponenter. Designet til nettsiden er basert på det grunnleggende i Bootstrap. Vi synes dette har fungert veldig bra, og gitt oss et «penere» design, mer moderne og likt som dagens nettsider. Et problem med Bootstrap er at det krever mer kunnskap fordi det er vanskelig å «overstyre». Det hadde vært tidsbesparende om det ikke hadde vært så komplisert å foreta modifiseringer. Det er absolutt en sterk teknologi som gir mye spillerom og økt funksjonalitet for utviklere BandsInTown Dette er et en applikasjon som kan brukes for å varsle om konserter, som brukes blant annet på det sosiale mediet Facebook. Det var et krav fra oppdragsgiveren at vi skulle bruke dette under «Konserter», slik at Figur 1-14 Logo Bootstrap brukere vil være oppdatert hele tiden, og ha oversikt over når og hvor Figur 1-15 Logo artistens kommende konserter er. Denne tillater også at artistene kan BandsInTown administrere sine turne-datoer på et sted og synkronisere dem til deres nettsider og sosiale medier sider. Teknologien fungerer tilsynelatende slik den skal, men er vanskelig ettersom artisten vi har bygget «plattformen» til ikke har noen kommende konserter. Vi har ikke opplevd noen problemer med denne teknologien og mener dette er en sterk teknologi. Prosessdokumentasjon 21

22 2.3 Nye Kunnskaper Det har strengt talt ikke vært like nødvendig med mye fokus på nye kunnskaper, men heller oppfriskning av kunnskaper som vi tidligere har tilegnet oss. Vi har hatt mange relevante fag, som har gitt oss all anledning til å løse dette prosjektet på en god måte. Samtlige av gruppens medlemmer har lest mer om ulike programmeringsspråk, slik at vi er tilnærmet like på området. Programmeringsspråkene som har stått i fokus er PHP, JavaScript, HTML og CSS. Noen gruppemedlemmer har lest seg en del opp om Databaser og databasestruktur, andre har lest seg opp om brukervennlighet, design og universell utforming (tilrettelegging for alle brukere). Når det gjelder nye kunnskaper har det for flere vært nødvendig å lese om bootstrap, som er en form for HTML, CSS og JavaScript rammeverk som kan brukes som hovedgrunnlag når en skal lage nettsider eller applikasjoner på nett. Denne brukte vi for å få et mer gjennomgående og «smooth» design og har sannsynligvis vært meget tidsbesparende på enkelte områder. Fordelen med bootstrap er at den gjør at designet ser bra ut og fungerer som det skal på alle «desktop browsers», og den fungerer på tablets og smarttelefoner. Vi har benyttet oss av JavaScript og Ajax. JavaScript er et dynamisk programmeringsspråk, med dette menes det at denne kan gjøre elementer på nettsider dynamisk. Denne fungerer sammen med HTML-koding, kode blir sendt og utløser en script-kode (JavaScript) som vil kjøre lokalt i nettleseren, automatisk eller som en reaksjon på brukervalg på siden. Ajax (Asynchronous JavaScript And XML) er en kombinasjon av JavaScript og andre skript- og markeringsspråk som brukes til å lage interaktive nettsider. Ved bruk av Ajax er hovedmålet å lage nettsider som skal virke mer responsive for brukeren, samt økte nettsidens interaktivitet, hastighet og generelt øke brukskvaliteten. Istedenfor å laste hele nettsiden på nytt hver gang brukeren gjør en endring/et valg, vil nettsidene utveksle litt og litt data med serveren i bakgrunnen. Ajax er relatert til PHP, JavaScript og jquery. jquery er et supplement til HTML, for å forenkle klientskripting. I all hovedsak er dette et JavaScript-bibliotek. Syntaksen til jquery har som mål å forenkle navigasjonen i et dokument, velge DOM-elementer, opprette animasjoner, behandle hendelser og utvikle Ajax-applikasjoner. PDO (PHP Data Objects) kan brukes opp i mot MySql for å gi tilgang fra PHP til MySql og Databaser. Med andre ord har vi brukt dette som et alternativ til MySql funksjoner i PHP. Vi har måttet lese om Vimeo API: oembed, som er en åpen standard for å implementere deres videoer og/eller bilder på en nettside. Med andre ord kan man si at Vimeo forteller hvordan en tredjepart har lov til å vise/representere deres videoer ifra en URL. API en gjør at nettsiden for lov til å vise «embedded» innhold, bilder og Prosessdokumentasjon 22

23 videoer. Da blir det slik at brukeren kan poste en link til den kilden, uten å måtte analysere kilden direkte. Vi har også måtte lese om Youtube API som fungerer på samme vis som Vimeo API. Vi har tidligere hatt et fag, Universell Utforming, der vi lærte mye, men vi har allikevel vært nødt til å lære oss nye teknikker innenfor universell utforming, for eksempel å bruke fargefilter for å se hvordan en person med fargeblindhet ser nettsiden. I følge referanse nr.1-18 er de to mest vanlige formene for fargeblindhet protanopi (rødblindhet) og deuteranopi (grønnblindhet). Vi henviser til vedlegg nr. 1-1 og 1-2 for å simulere hvordan en med protanopi ser nettsiden. Vi ønsker også å henvise til vedlegg nr. 1-3 og 1-4 for å vise hvordan en med deuteranopi ser nettsiden. Videre er det viktig å vite at det finnes en mindre utbredt form for fargeblindhet som kalles tritanopi (blå/gulblindhet). Vi henviser til vedlegg nr.1-5 og 1-6 for å simulere hvordan en person med tritanopi ser nettsiden. Noe som vi har måttet tilegne oss har vært det å opprettholde et profesjonelt forhold mellom oppdragsgiver og utviklere. Med dette mener vi at det er viktig å kjenne sine «roller», vi skal gi oppdragsgiveren det han vil ha, men må vi virkelig møte han på alle krav? Nei, vi kan ikke møte oppdragsgiveren på alle krav, dersom vi mener dette er en dårlig løsning og det faktisk kan virke mot sin hensikt. Vi skal være «spesialister» innen faget og vi skal kunne gi råd, veilede og hjelpe oppdragsgiveren med å få best mulig resultat. Samtidig er det viktig å skille mellom hva som faktisk er mulig å gjøre, hva vi ikke har kompetansen til eller hva som faktisk ikke er mulig. Under et profesjonelt forhold har vi selvsagt jobbet med kommunikasjonen. Vi har måttet lese oss opp om lovverk, herunder avtaler. Lovverk spesielt med tanke på opphavsretten, designretten, personvernloven, diskriminerings - og tilgjengelighetsloven. Dette er fordi vi vet at dette står meget sentralt i dagens nettutviklingssamfunn og brukerne har rettigheter som vi skal oppfylle. Se punkt 8.2 Lovmessige krav i kravspesifikasjonen for å lese mer om dette. Blant annet har vi også måttet lese om sosiale mediers «branding guidelines», dette i henhold til bruk av logoene på nettsiden, ettersom dette er kopibeskyttet merkevare. Vi har benyttet oss av fem sosiale medier (Facebook, Twitter, Instagram, Youtube og Vimeo) da disse står svært sentralt for artisten. Prosessdokumentasjon 23

24 2.4 Metodikk Under dette punktet ønsker vi å redegjøre for hvilken metodikk og dokumentasjon vi har benyttet oss av i denne prosessen Dokumentasjon I løpet av våre tre år på høgskolen har vi virkelig fått lært hvor viktig dokumentasjon faktisk er og hvilken nytteverdi dette har. Prosjektarbeid bygger på planer i forhold til gjøremål og hva som skal bli sluttproduktet. Ved et prosjekts begynnelse er det viktig med overordnede planer, som kan gi et overblikk over hva som må gjøres for å komme nærmere produksjonsfasen. Ved start av produksjonsfasen er det naturligvis viktig med mer detaljerte planer, da det faktiske produktet skal utvikles. Det finnes forskjellige planer en kan lage og dermed følge, dette går i tråd med utviklingsmodellen som en har valgt. Viktigheten av å dokumentere arbeidet som blir gjort underveis er stor og ikke minst nødvendig i form av hva som ble gjort, når og hvem var ansvarlig for dette. Etter tips fra veileder valgte vi å skrive prosjektboken vår digitalt, som er linket opp fra gruppens nettside, se referanse nr.1-31 for prosjektdagbok Dokumentasjonsstandard Vi har forhold oss til en dokumentasjonsstandard for bachelor-prosjekter som er tilgjengelig fra Høgskolens nettsider, henviser til referanse nr Dokumentasjonsstandarden «Dokumentasjonsstandard for bachelor-prosjekt (hovedprosjekt) for institutt for informasjonsteknologi Høgskolen i Oslo og Akershus», av Ann-Mari Torvatn fra 20.desember Vi har benyttet oss av denne «malen» underveis, men forstod også raskt at dette er ment mer som en veiledning enn en mal. Den har vært til god hjelp, nyttig å få forklart hva som forventes å være med i dokumentasjonen, samt hva som bør og må være med. Denne har stått meget sentralt i sluttdokumentasjonen, riktignok som en inspirasjon og veiledning for at vi skal få god struktur i sluttdokumentasjonen. Ettersom vi har gjort «vår egen vri» enkelte områder av sluttdokumentasjonen, har vi sendt eksemplar av vårt førsteutkast til veilederen vår, og vi har rettet oss etter tilbakemeldingene vi fikk Styringsdokumenter Det er enkelte styringsdokumenter som måtte opprettes ved begynnelsen og underveis i prosjektet. Under utredningsfasen og forprosjektfasen ble det opprettet noen dokumenter, dette for å være til hjelp med selve fremdriften i prosjektet. Et annet viktig mål med disse dokumentene var at de skulle fungere som en rettesnor for oss underveis. Kort oppsummering om styringsprosjektene som ble produsert, i stigende rekkefølge fra prosjektets start og til prosjektets slutt. Statusrapport Herunder skulle det være en kort rapport, som omhandler hvordan vi lå an med å finne Prosessdokumentasjon 24

25 en oppgave/et prosjekt. Når vi skrev statusrapporten hadde vi opprettet kontakt med oppdragsgiver og fått tildelt et prosjekt. Dette er et dokument som hadde innleveringsfrist Se referanse nr.1-33 for Statusrapport i PDF på nettet. Prosjektskisse Dette dokumentet skulle beskrive hvilken retning prosjektet skulle ta. Vi hadde allerede i statusrapport avtalt at «Tetriz Event & Management» skulle være vår oppdragsgiver, og at vi skulle lage en nettside for en av deres artister. Det nye i denne skissen er at vi kartla mer om hva som var ønsket ut av prosjektet og mer om omfanget av selve prosjektet. Innleveringsfristen var Se referanse nr.1-34 for Prosjektskisse i PDF på nettet. Forprosjektrapport Her ønsket vi å få en mer detaljert beskrivelse av prosjektet, og hvilke mål og rammebetingelser vi foreløpig hadde satt oss. Innleveringsfristen var Se referanse nr.1-35 for Forprosjektrapport i PDF på nettet. Kravspesifikasjonen Vi påbegynte arbeidet med denne dokumentasjonen i februar og strakk seg ut til slutten av mars, med rettskriving og eventuelle endringer, se punkt 9. i Kravspesifikasjonen. Innunder avdekket vi flere detaljer og konkrete krav i forhold til design, funksjonalitet og brukervennlighet. Vi refererer med dette til punkt 3. i Prosessdokumentasjonen for dens rolle i prosjektet. Se referanse nr.1-36 for Kravspesifikasjonen i PDF på nettet Prosjektdagbok Som tidligere nevnt har vi skrevet en prosjektdagbok, som er tilgjengelig for alle som måtte ønske å lese denne. Denne er opprettet mest for vår del, veileders del og naturligvis oppdragsgiverens del. I dagboken har vi skrevet et kort referat fra hvert møte, dette er for at veileder og oppdragsgiveren skal kunne se hvordan vi ligger an med prosjektet. For vår del er det et genialt «verktøy» for å kunne se tilbake hva som ble gjort, når det ble gjort, eventuelle problemer eller forsinkelser vi ikke hadde regnet med. Vi kan også se hvem som har gjort hva Prosjektnettside Ved oppstart av prosjektet lagde vi en gruppeside på nettet, refererer til referanse nr.x. På denne nettsiden er det en kort presentasjon av selve prosjektet, oss som gruppe, link til prosjektdagboken og styringsdokumentene i pdf. Prosessdokumentasjon 25

26 2.4.2 Utviklingsmetodikk Samtlige fra gruppen ønsket å jobbe med smidig metodikk, der vi har tatt flere prinsipper fra smidige utviklingsmodeller, men ikke fulgt en eksakt metode. Scrum er den utviklingsmodellen vi har tatt mest inspirasjon og prinsipper fra. Det er vanlig å benytte seg av Scrum ved store og komplekse prosesser, eksempelvis ved utvikling av programvare. Scrum er en metodikk som setter kreativitet og samarbeid i fokus, noe som passer godt for gruppen. Scrum bygger på noe som kalles empirisk tilnærming, som innebærer synlighet, inspeksjon og tilpasning, vi henviser til referanse nr En slik tilnærming bygger på erfaringer og observasjoner som gjøres i løpet av prosjektets gang. Ved synlighet er det viktig at faktorene og funksjonaliteten skal være synlige, at dette faktisk er ferdig, blitt kodet til en standard og testet. Inspeksjon må gjøres ofte, og av en person som besitter kunnskapen for å gjøre dette riktig. Formålet er å fange opp avvik tidlig. Tilpasning gjøres når en finner avvik, disse bør gjøres raskt og ha liten eller ingen konsekvens for produktet. Et annet prinsipp fra Scrum er selvstyrte team, det vi som utviklingsteamet (gruppen) er. I et slikt team er det viktig at alle innehar kompetansen som er nødvendig for å lage produktet. Det er også viktig at alle av teammedlemmene tar likt ansvar i forhold til eierforholdet. Dette medfører ofte at teamet jobber mer optimalt og at dette skaper mest mulig verdi for alle de involverte partene. Fra Scrum finner vi også noe som kalles produktbacklogg, dette kan forklares som en slags «produkt-kø». Denne skal vise en oversikt over de ulike kravene og ønsker som utviklerne (gruppen) og oppdragsgiveren stiller til produktet. Ved en slik liste skal krav og ønsker bli oppramset i en prioritert rekkefølge. I denne listen planla vi også når oppgaven skulle påbegynnes og når den skulle avsluttes, noe som bød på problemer. Det dukket av og til opp hindringer som førte til at vi ikke ble ferdige med oppgaven. Dette løste vi ved at to teammedlemmer fortsatte med oppgaven, og de andre to jobbet videre med andre oppgaver. På et vis kan dette vise til en annen utviklingsmetodikk som kalles Kanban. Dette er det «motsatte» av Scrum, fordi ved Scrum stopper en ikke opp, men ved Kanban jobber man helt til løsningen er ferdig. I Kanban går man ikke videre til neste jobb på «vent» før den første er avsluttet, dette kan sammenlignes med et «kø-system». Dette er den eneste inspirasjonen vi tok fra Kanban. I Scrum er det vanlig å benytte seg av sprinter, men som tidligere nevnt har vi i gruppen brukt dette som inspirasjon og veiledning enn å følge metoden slavisk. Vi har brukt en form for «sprint» der vi lagde en produktbacklogg, som nevnt over, og vi hadde planleggingsmøter der vi bestemte oss for hva som skulle jobbes med i hver «sprint». Dette medførte at vi daglig hadde møter for å informere om hvert enkelt teammedlems status i forhold til oppgaven. Stand-up er noe som brukes i Scrum, men dette består av fysisk oppmøte hver dag, i motsetning til våres møter ved hjelp av sosiale medier. Vi hadde riktignok korte møter hver dag, der vi koordinerte arbeidet. Prosessdokumentasjon 26

27 Møtene varte ikke lenger enn 15 minutter (som er et krav ved stand-up), vi tok opp hva som hadde blitt gjort siden forrige møte, hva som skal gjøres før neste møte og eventuelle hindringer som hemmet teammedlemmets effektivitet i forhold til oppgaven. I tillegg tok vi en jevnlig gjennomgang i forhold til hvordan vi synes arbeidet fungerte og hva som ikke fungerte like bra. Dette medførte at vi kunne legge til rette for at neste «sprint» skulle foregå mer smidig. Vi gjorde et forsøk på å grovestimere tidsbruken på arbeidsoppgaver underveis, og funksjonaliteten som skulle implementeres. Vi estimerte dette ved å se på kompleksiteten av oppgaven, samt hvor omfattende oppgaven var. Grunnen til at vi tok mye inspirasjon fra Scrum er fordi dette er en form for agil utviklingsmetodikk. Innenfor denne metodikken skal personer og samspill verdsettes, fremfor prosesser og verktøy. Programvare verdsettes mer enn dokumentasjon, samarbeid med kunden verdsettes mer enn kontraktsforhandlinger. En skal fokusere mer på å følge endringer enn å følge en plan. Det betyr ikke at prosesser, verktøy, dokumentasjon og kontraktsforhandlinger ikke er viktige, men det legges mer fokus på personer, samspill, programvare og endringer. En agil utviklingsmodell kjennetegnes også ved at de er iterative og inkrementelle. Dette betyr at løsningen blir utviklet, men kan endres underveis i prosjektet. Dette medførte mindre planlegging for oss i forkant av prosjektet, og at det var delvis mindre komplisert å foreta endringer underveis Versjonskontroll og backup Vi har alle fire på gruppen jobbet lokalt med filer på vår egen datamaskin, men vi har også delte mapper i Dropbox, dette for å kunne raskt og enkelt dele filer. Dropbox har fungert godt som en back-up for oss, i tillegg til at vi alle satt med våre egne filer lokalt på datamaskinen. Vi er meget godt fornøyd med tjenesten Dropbox leverer, den eneste ulempen vi kan nevne er at ikke flere kan skrive i «sanntid». Den store fordelen med Dropbox er at en bruker kan logge seg inn fra hvilken som helst pc, riktignok med tilgang til nettverk, da får den tilgang til alle filene som har blitt synkronisert sist brukerne av mappen var tilknyttet et nettverk. Grunnen til at vi valgte Dropbox er fordi samtlige medlemmer har brukt dette mye og da slipper å sette seg inn i nye verktøy. I tillegg til at vi har brukt dropbox, har et av gruppemedlemmene, Frode, hatt ansvaret for å ta backup på ekstern harddisk. Dette for og virkelig kunne sikre at dokumentene ikke skal kunne bli borte. Se punkt i Prosessdokumentasjonen for å lese mer om Dropbox. I forhold til versjonskontroll er det Git som har vært det verktøyet vi har benyttet oss av. Dette er et nytt verktøy for gruppen, positivt i den forstand at vi har måttet tilegne oss nye kunnskaper. Vi synes dette fungerte ypperlig til vårt bruk, og har ikke opplevd noen problemer med dette underveis. Se punkt i Prosessdokumentasjonen for å lese mer om Git. Prosessdokumentasjon 27

28 2.4.4 Diagrammer I omfattende prosjekter er det viktig å foreta gode vurderinger og inneha en god planleggingsevne. Derfor har vi brukt et gantt-diagram for å lage en fremdriftsplan. Vi har vektlagt Use Case Diagram (UCD), med tekstlig beskrivelse av bruksmønster. Til slutt lagde vi et aktivitetsdiagram. Grunnen til at vi valgte UCD og aktivitetsdiagram er fordi vi har brukt disse diagrammene tidligere, og mener selv vi behersker disse diagrammene godt Gantt-diagram En fremdriftsplan kan lages på mange forskjellige måter, i og med at vi tok inspirasjon fra Scrum og ønsket å bruke en smidig metodikk går dette litt i strid med hverandre. Allikevel mente vi at det kunne ha en hensikt å ha en liten oversikt over når vi burde være ferdig med de ulike delene i prosjektet. Det hadde vært veldig trist om vi nå stod ved veis ende og ikke hadde klart å gjennomføre alt det vi satt oss som mål. Vi har benyttet oss av et Gantt-diagram for å fremvise fremdriftsplanen, men ser i ettertid at vi kanskje burde prøvd å bruke dette på en annen måte, med for eksempel tidsfrister i diagrammet istedenfor å fastsette når alle oppgavene skulle være ferdig. Samtidig har vi ikke sagt at vi har fulgt Scrum til punkt og prikke, derfor anser vi dette som «tålelig». Desember Januar Oktober November Februar Mars April Mai Juni Uke Innledende Statusrapport Prosjektsskisse Prosjektdagbok Prosjektside Forprosjekt Forprosjektrapport Fremdriftplan Arbeidsplan Kravspesifikasjon Kraspesifikasjon Analyse kravspesifikasjon Prototype Low-Fi prototype E/R modeller Implementering Database Koding Design Testing Testing Dokumentasjon SWOT-analyse Brukermanual Prosjektrapport Kvailitetssikring Testdokumentasjon Produktdokumentasjon Presentasjon I arbeid Frister Presentasjon Ferdigstilt Figur 1-16 Gantt-diagram Som viser de ulike arbeidsoppgavene med tidsfrister Prosessdokumentasjon 28

29 Use Case Diagrammer Et Use Case Diagram (UCD) representerer en brukers interaksjon med systemet, som kan være veldig oversiktlig og lite komplisert. Vi mener en av de største fordelene med UCD er at vi kan fremstille forskjellige typer brukere ved systemet, og ulike måter de kan samhandle med systemet. Vi ønsker å fremlegge et av våre UCD («Brukere/Users»), se figur 1-17 i Prosessdokumentasjonen. De resterende UCD er lagt med som vedlegg. Det er ikke uvanlig at en benytter seg av et eller flere «oppfølgings-diagrammer», men dette kommer litt an på systemet som blir beskrevet. Vi valgte å lage et aktivitetsdiagram, se punkt Aktivitetsdiagram. Vi minner om at A-bruker er systemadministrator, B-bruker er en innlogget bruker i administrasjonsdelen og C- brukeren er en bruker som ikke er innlogget, som kun ønsker å besøke nettsiden. For mer informasjon om brukere, se punkt 5.3 Beskrivelse til tabell 1 og 2 i Kravspesifikasjonen. Figur 1-17 UCD-Brukere Prosessdokumentasjon 29

30 Tekstlig beskrivelse av bruksmønster Navn: Aktør: Prebetingelser: Postbetingelser: Hovedflyt: Alternativ flyt: Login A-bruker, B-bruker Aktør har navigert til administrasjonssiden Aktør har en brukerkonto Aktør er autentisert og innlogget til administrasjonssidene 1. Aktør fyller inn brukernavn og passord og trykker på logg inn 2. Systemet kontrollerer at brukernavnet finnes 3. systemet sjekker det oppgitte passordet mot det lagrede passordet 4. systemet dirigerer aktør videre til administrasjonssidene 1a. Aktør skriver ikke inn brukernavn eller passord og trykker på logg inn 1a.1. Systemet viser en melding om manglende felt 1a.2. Aktør fyller inn manglende felt. Use case fortsetter til punkt 2. 1b. Aktør avbryter innlogging 1b.1. Systemet dirigerer aktør tilbake til forsiden. 2a. Brukernavnet finnes ikke 2a.1. Systemet går tilbake til punkt 1 med en melding om at det ikke var mulig å logge inn med oppgitte detaljer. 3a. Det oppgitte passordet er ikke likt det lagrede passordet. 3a.1. Systemet går tilbake til punkt 1 med en melding om at det ikke var mulig å logge inn med oppgitte detaljer. Navn: Aktør: Prebetingelser: Postbetingelser: Hovedflyt: Logout A-bruker, B-bruker Aktør er innlogget Aktør er i administrasjonssidene Aktør er logget ut og navigert til innloggingssiden 1. Aktør velger logg ut fra administrasjonssiden 2. Systemet sletter sesjonsvariablene som holder innloggingsstatus 3. systemet dirigerer brukeren til innloggingssiden Prosessdokumentasjon 30

31 Navn: Aktør: Prebetingelser: Postbetingelser: Hovedflyt: Alternativ flyt: List users A-bruker Aktør er innlogget Aktør har valgt brukere kategorien Alle opprettede brukere vises med unntak av innlogget bruker 1. systemet oppretter en liste med alle brukere på systemet og utelater brukerdetaljene for aktøren 2. systemet viser listen med alle brukere til aktør 1a. Det finnes ingen andre brukerkontoer på systemet 1a.1. Systemet viser en tom liste til aktør. Navn: Aktør: Prebetingelser: Postbetingelser: Hovedflyt: Alternativ flyt: Edit userdetails A-bruker, B-bruker Aktør er innlogget Aktør har valgt å vise egen profil Valgte endringer er lagret i databasen 1. systemet viser et skjema med nåværende brukerdetaljer til aktør - e-post adresse - passord 2. Aktør endrer de ønskede feltene og trykker lagre 3. Systemet lagrer endringene til databasen 2a. Ingen endringer blir utført 2a.1. Aktør utfører ingen endringer og trykker lagre 2a.2. Systemet lagrer ingen endringer 2b. Aktør trykker avbryt 2b.1. Systemet dirigerer aktør til kategoriens forside ingen endringer blir lagret Prosessdokumentasjon 31

32 Navn: Aktør: Prebetingelser: Postbetingelser: Hovedflyt: Alternativ flyt: Edit other user A-bruker Aktør er innlogget Aktør har valgt en bruker fra brukerlisten Valgte endringer er lagret i databasen 1. systemet viser et skjema med den valgte brukerens detaljer 2. aktør endrer ønskede felter og trykker lagre 3. systemet lagrer endringene i databasen 2a. Ingen endringer blir utført 2a.1. Aktør utfører ingen endringer og trykker lagre 2a.2. Systemet lagrer ingen endringer 2b. Aktør trykker avbryt 2b.1. Systemet dirigerer aktør til kategoriens forside ingen endringer blir lagret Navn: Aktør: Prebetingelser Postbetingelser: Hovedflyt: Alternativ flyt: Kommentar: Delete user A-bruker Aktør er innlogget A-bruker Aktør har valgt en bruker fra brukerlisten Valgt bruker er slettet fra databasen 1. systemet viser skjemaet for endring av brukerdetaljer 2. aktør trykker på slett bruker knappen 3. systemet sletter brukerkontoen fra databasen 4. systemet dirigerer aktør tilbake til brukerlisten 3a. Systemet er ikke i stand til å slette brukerkontoen 3a.1. systemet viser en melding til aktør om at det ikke var mulig å slette brukeren. Steg 4 blir ikke utført. For å kunne se en annen brukers kontodetaljer må den innloggede brukeren være en A-bruker. Knappen for å slette brukere vil ikke vises på egne kontoer og heller ikke om innlogget bruker er en B-bruker. Prosessdokumentasjon 32

33 Navn: Aktør: Prebetingelser: Postbetingelser: Hovedflyt: Alternativ flyt: Create user A-bruker Aktør er innlogget Aktør har valgt å opprette ny bruker Ny bruker er opprettet 1. Systemet viser et skjema for å opprette ny bruker 2. aktør fyller inn nødvendige opplysninger og trykker på opprett 3. systemet kontrollerer at brukernavn ikke er i bruk 4. systemet kontrollerer at e-post adresse ikke er i bruk 5. systemet forbereder passordet til lagring 6. systemet lagrer detaljene i databasen 7. systemet dirigerer aktør tilbake til brukerlisten 1a. Aktør trykker på avbryt 1a.1. Systemet går rett til steg 7. 3a. Brukernavn er opptatt 3a.1. Systemet går tilbake til skjemaet og gir tilbakemelding om at brukernavn er opptatt. Alle oppgitte opplysninger beholdes utenom brukernavnet og passordet. 3a.2. Aktør bytter ut brukernavnet og trykker opprett 3a.3. Systemet fortsetter på steg 3. 4a. e-post er opptatt 4a.1. Systemet går tilbake til skjemaet og gir tilbakemelding om at e-post er opptatt. Alle oppgitte opplysninger beholdes utenom e-post og passordet. 4a.2. Aktør bytter ut e-post og trykker opprett 4a.3. Systemet fortsetter på steg 2. Prosessdokumentasjon 33

34 Aktivitetsdiagram Figur 18 Aktivitetsdiagram Hendelsesflyten for handlingen "Create User", Opprett bruker Prosessdokumentasjon 34

35 2.4.5 Analyser Under analyser har vi fokusert på å lage en god SWOT analyse og foretatt en risikoanalyse SWOT Analyse En SWOT analyse kan brukes for å gi oversikt over indre og ytre styrker, svakheter, muligheter og trusler i et system. SWOT står for Strengths, Weaknesses, Opportunities og Threats. Dette er et nyttig verktøy som ofte benyttes ved beslutninger, samtidig som det er nyttig for å se hvilke områder som bør/må/kan forbedres. En SWOT analyse skiller mellom det interne (styrker og svakheter) og det eksterne (muligheter og trusler). Sterke sider viser til egenskapene ved systemet som kan gi fordeler, mens derimot svake sider viser til egenskapene ved systemet som kan gi ulemper. Muligheter viser til elementer som systemet kan utnytte til fordel, mens derimot trusler er elementer i miljøet som kan forårsake problemer og/eller svikt i systemet. Se neste side for SWOT-analysen. Prosessdokumentasjon 35

36 Strengths Weaknesses Struktur og oppbygging i henhold til lovverk og standarder Følger estetiske krav CMS vil gi administrative brukere økt kontroll i forhold til andre brukere CMS vil gi administrative brukere økt kontroll på nettsidens innhold og design Mal for flere nettsider Utvidbar Gjennomgående tema Fleksibel i forhold til innhold og tema Vil øke bedriftens profesjonelle status Bedriften vil få mer oversikt og kontroll over artiststall Mer struktur på artisten og konserter Økonomisk, lave kostnader for utvikling av nettsiden Flerspråklig Enkelt å navigere Uavhengig av sted og tid Oppkobling til sosiale medier Måle trafikk på nettsiden Krever innsikt i hvordan CMS fungerer Ikke open source Nettsiden blir hostet eksternt Nettsidens innhold bør oppdateres kontinuerlig av administrative brukere CMS ikke tilstrekkelig fleksibel Tekniske forhold er ikke optimale Kan være tidkrevende å oppdatere/lage nye nettsider for andre/nye artister Utilstrekkelig informasjon/nyheter om artist Bedriften vil kunne bli mer profesjonell utad Artisten vil kunne bli sett på som mer seriøs Reklame for artisten og bedrift Større publikum og flere fans til artisten Flere sponsorer/ samarbeidspartnere til bedriften Nye muligheter for artisten Økt kjennskap til bedriften Økt kjennskap til artisten Publikum får økt interesse for bedriften Tilgang til å booke artist over internett Oversikt over når artisten er booket Oversikt over hvor og når konserter blir avholdt Mer markedsføring Nye markeder Forøkelse av artiststall Økt kontakt mellom bedrift/artist og kunder/fans Økt omsetning Utvikling av nettsiden og bedriften Angrep på servere Konkurrerende nettsider Publikum kan miste interesse for artisten Publikum kan miste interesse for bedriften Problemer med CMS Angrep på CMS Nettsiden appellerer ikke til brukerne/målgruppen Problemer med nettsiden Dårlig profilering Investeringsbehov og utvidelse av nettsiden/servere ved mye trafikk Nedetid, problemer med tekniske forutsetninger Ikke ideelt via smarttelefoner i forhold til skjermstørrelse og struktur Brukerne blir ignorert Angrep på personinformasjon Useriøse henvendelser/spam Nedgang i booking av artist Opportunities Prosessdokumentasjon Threats 36

37 Risikoanalyse Risikoanalyser blir utført for å kunne avdekke eventuelle risikoer knyttet til et system. Analysen skal kunne hjelpe til med å ta beslutninger underveis. En risikoanalyse ligger til grunne for videre å kunne foreta en risikoevaluering. Dette spesielt med tanke når det gjelder om en skal velge å gjøre/ikke gjøre en aktivitet. Dette skal også kunne hjelpe til å iverksette tiltak som gjør at risikoen blir mindre. Risikoanalysen og risikoevaluering utgjør en stor del av risikovurdering. Risikoanalysen bør se på hva som kan gå galt, sannsynligheten for at uønskede hendelser inntreffer og hvilke konsekvenser dette kan medføre. Risikoanalysen er gjengitt i tabellen under. Risiko Sannsynlighet Konsekvens Hvordan unngå dette? Feilberegne Lav Arbeidet blir dårligere Vi må planlegge med gode marginer i tiden gjennomført enn planlagt, en tidsramme, og ikke utsette ting evt. Delvis uferdig eller som kan gjøres. Satse på å bli ferdig i verst ikke levert i tide. god tid, for så å ha god tid til å se over og forbedre mindre detaljer. Sykdom Høy Mer arbeid og mulig dårligere tid på gjenværende medlemmer. Kan bli større vanskeligheter dersom den syke sitter inne med unik kompetanse som de andre ikke innehar (i like stor grad). Miste personer Lav Man kan miste viktig kompetanse, og ikke minst arbeidskraft. Det blir da mer arbeid og mindre tid på de gjenværende. Det kan være hensiktsmessig å prioritere det arbeidet som kun enkeltpersoner i gruppa har kompetanse til, og bli ferdig med dette i god tid. Man bør legge til rette for at den syke kan gjøre arbeid hjemmefra dersom det er mulig. Alt arbeid blir lagt ut i Dropbox og skal derfor være lett tilgjengelig for alle. Hvis alle trives godt på gruppa, er sannsynligheten mindre for at noen dropper ut. Derfor er det viktig med en god tone, og at vi støtter hverandre og behandler hverandre med respekt og forståelse. Vi tror også at siden vi har valgt gruppemedlemmene selv så har vi valgt personer som vi kommer godt overens med og som vi også kan jobbe godt sammen med. Prosessdokumentasjon 37

38 Konflikter i Middels Kan føre til dårlig stemning Skrive en god arbeidsavtale og følge gruppen og dempet motivasjon. Kan denne. Sørge for å snakke godt bli vanskeligere å samarbeide sammen, si hva man mener på en og få ting gjort på en konstruktiv måte og løse vanskelige ordentlig måte. Diskusjoner problemstillinger med stor uenighet er bra, og kan føre til nye ved f.eks. en avstemming, evt. å være gode ideer og synspunkter - åpne for kompromisser. Dersom man men det er viktig å holde seg ikke klarer å løse problemer innad i saklig så det ikke vipper over gruppen, bør man få inn en nøytral i feil retning. megler, f.eks. en veileder. Tap av data Lav Mister mye verdifull tid ved å måtte gjenskape det tapte. Kan være fatalt dersom det er kort tid til levering. Ta backup jevnlig, sørge for å iallefall ha tidligere versjoner tilgjengelig så man slipper å begynne helt på nytt. Del gjerne filer med hverandre hyppig, og ikke slett noe før man er helt sikker på at man har sikret innholdet et eller flere andre steder. Dårlig Middels Kan veldig lett føre til Viktig å møte opp på møtene, og kommunikasjon misforståelser både på det gjøre det klart for hver gang hva den innad i gruppen faglige og personlige plan. enkelte skal gjøre til neste gang, eller Kan også føre til at folk ikke innen en gitt dato. Sørge for at alt er får gjort det de skal fordi de forstått og at alle er enige før møtet ikke vet hva de skal gjøre, avrundes. eller at flere gjør det samme. Dette kan føre til tidstap og forsinkelser. Dårlig Lav Dette kan føre til at vi Vi tror vi har valgt en oppdragsgiver kommunikasjon mangler viktig informasjon som det ikke er så vanskelig å få med som vi trenger fra kontakt med for å unngå at slike ting oppdragsgiver oppdragsgiver. skulle skje, i tillegg har vi en på gruppen som har jobbet i den ene butikken vi har tatt kontakt med så Prosessdokumentasjon 38

39 derfor tror vi ikke dette vil bli et problem. PC-problemer Middels Dersom noen av gruppemedlemmene sine PCer krasjer og ikke vil fungere, vil dette føre til at denne personen ikke kan delta på den samme måten og kan føre til at denne personen ikke får gjort alt arbeidet sitt eller mister arbeid. Dette er noe vi ikke helt kan styre men vi kan jo passe på at vi behandler utstyret på en måte som kanskje kan forebygge dette. Om dette skulle skje kan vi alltids bruke datamaskiner som står på skolen for å få jobbet. Vi deler alle filer på Dropbox fordi da kan alle finne alle filer som de andre har jobbet på, så vi trenger i grunn bare en pc som fungerer. Mangler Middels Dette kan medføre at vi har Vi må det skrive om hvilken ulike kompetanse problemer med å kompetanse gruppen har, og øke kvalitetssikre arbeidet vårt kompetansen til noen gruppe dersom vi ikke har nokk medlemmer, dersom vi mener at dette kompetanse på områder. er nødvendig, dette vil medføre at vi har tilstrekkelig med kompetanse på gruppen. Prosessdokumentasjon 39

40 3 Utviklingsprosessen Under dette punkt vil vi fortelle om prosjektets ulike utviklingsfaser, reflektere over faglige utfordringer, fortelle mer om oppbygging og funksjon i programmet og vårt forhold til oppdragsgiveren. 3.1 Prosjektets utviklingsfaser Dette punktet tar for seg prosjekts forskjellige utviklingsfaser, der vi deler inn i ulike delpunkter for utredningsfasen, forprosjektfasen, produksjonsfasen og dokumentasjonsfasen Utredningsfasen Vi ble en gruppe høsten 2013 og de fleste gruppemedlemmene har jobbet sammen ved tidligere prosjekter. Vi fant fort en oppdragsgiver vi ønsket å jobbe med under hovedprosjektet. Vi produserte en gruppeside for gruppen vår hvor vi underveis i prosjektet kunne legge ut all informasjon som var relevant for veileder å ha tilgang til. I utredningsfasen startet vi med å skrive en statusrapport som skulle legges ut på nettsiden Her skrev vi ned hvor langt vi var kommet i utredningsfasen og litt om oppdragsgiveren vår. Etter at denne var levert inn begynte vi på prosjektskissen. Her skulle prosjektet presiseres, samt definere problemstillingen og relevante krav til prosjektet Forprosjektfasen Etter nyttår bestemte vi oss for å planlegge litt mer, samt sette oss noen mål for prosjektet. I januar begynte vi å skrive en forprosjektrapport hvor vi definerte målene og rammebetingelsene for prosjektet. Etter at denne var ferdigstilt begynte vi så smått å jobbe med kravspesifikasjonen. Vi avtalte et møte med veileder og fikk han til å komme med innspill, samt godkjenne kravspesifikasjonen Produksjonsfasen Etter at vi hadde fått kravspesifikasjonen på plass, begynte vi ganske fort å planlegge hvordan vi ønsket at produktet skulle bli til slutt. Produksjonsfasen startet med at vi begynte å lage flere skisser i form av paper prototyping. Dette for å få en litt bedre oversikt over hva vi ønsket. Etter at vi hadde flere forslag klare, tegnet vi og designet disse i photoshop. Vi fikk oppdragsgiver til å se på dem og gi oss en tilbakemelding på hvilken av disse som var mest likt hans krav og ønsker. Etter hvert begynte vi å programmere, nettsiden begynte å ta form og CMS delen var i gang. Vi møttes ukentlig på skolen for å jobbe sammen slik at vi kunne gi hverandre tilbakemeldinger på det som var blitt utført. Vi avtalte et møte med oppdragsgiver slik at han kunne se fremgangen i prosjektet. Vi ønsket at han skulle komme med noen Prosessdokumentasjon 40

41 tilbakemeldinger slik at vi kunne endre eventuelle feil og mangler så tidlig som mulig i produksjonsfasen Dokumentasjonsfasen Vi dokumenterte underveis i alle de ulike fasene, men starte å dokumentere for fult når produksjonsfasen var over og produktet var utviklet. Vi kom frem til at vi trengte rundt en måned på å bli ferdig med all dokumentasjon i og med at vi hadde dokumentert en del underveis i prosjektet. 3.2 Utfordringer Det er naturlig at det oppstår flere utfordringer i løpet av et omfattende prosjekt, vi redegjør for dette i punkt Faglige utfordringer og punkt Andre utfordringer Faglige utfordringer Alle på gruppen har forskjellige faglige kunnskaper og ferdigheter, derfor tenkte vi å fordele oppgavene slik at man fikk jobbe med det man var sterkest og flinkest i. Men vi synes fortsatt at det var viktig at alle deltok litt på alt og fikk utfordret og lært seg nye ting underveis i prosjektet. Vi så på dette prosjektet som en erfaring og en oppgave hvor alle skulle tilegne seg ny kunnskap, men også ha mulighet til å jobbe med det man presterer best i. To av medlemmene på gruppen var godt kjent med programmering og programmeringsverktøyene som vi tok i bruk, mens de to andre medlemmene var sterkest i dokumentskriving, samt designvalg og universell utforming. Noen av de faglige utfordringene som oppstod var at to av gruppemedlemmene måtte lære seg programmering, spesielt med tanke på HTML og CSS Andre utfordringer Noen av utfordringene vi støtet på underveis var at oppdragsgiver ønsket å implementere noen funksjoner på nettsiden som vi ikke var helt komfortable med. Han ønsket blant annet å implementere nyhetsbrev, slik at brukere kan registrere seg og få e-post når det kommer nye nyheter, men begrensning fra Domeneshop tillater ikke å sende flere enn en e-post per sekund. Derfor var ikke dette en gunstig løsning. Men vi valgte å gi brukerne mulighet til å melde seg på nyhetsbrev likevel. En annen utfordring som dukket opp underveis er at nettsiden må sees i fullskjerm, hvis ikke vil elementer i navigasjonsmenyen vises på en måte som vi ikke ønsket. Dette er en utfordring vi ikke fikk rettet opp i ettersom dette ville kreve en omstrukturering av koden for navigasjonsmenyen som vi ikke hadde tid til når vi oppdaget dette, dette er en visuell utfordring som ikke har noen innvirkning på navigering og bruk av navigasjonsmenyen. Prosessdokumentasjon 41

42 4 Kravspesifikasjonen og dens rolle Under dette punktet vil vi fortelle om kravspesifikasjonens rolle i prosjektet, samsvar med kravspesifikasjonen, til slutt redegjør vi for endringer som ble gjort i kravspesifikasjonen. 4.1 Kravspesifikasjonens rolle Kravspesifikasjon er et dokument som skal fungere som en rettesnor for utviklerne underveis i oppgaven. Dette er en enighet mellom oppdragsgiveren og utviklerne, om hvilke rammer, retningslinjer og mål som skal oppfylles. Andre betingelser er arbeidsprosess, kvalitetssikring, funksjonelle og ikke-funksjonelle krav. Dette medfører at det blir en sikkerhet både for oss som utviklere, men også for oppdragsgiveren. Dette dokumentet fungerer som en avtale mellom gruppen og oppdragsgiver, men det er også krav fra Høgskolen i Oslo og Akershus som må tas hensyn til. Dokumentet må være godkjent av alle parter før det kan anses som gyldig. 4.2 Samsvar med kravspesifikasjonen Herunder vil samsvar med kravspesifikasjonen bli forklart, og om vi har klart å oppfylle de ulike kravene som vi har oppført i kravspesifikasjonen. Vi refererer til kravspesifikasjonen og produktdokumentasjonen. Oppsummert mener vi selv at vi har fulgt kravspesifikasjonen nøye, og gjort kun de mest nødvendige endringene underveis. Vi mener også at kravspesifikasjonen reflekteres i selve produktet, og at dette har gjort at vi faktisk har gitt det produktet vi har «lovet» oppdragsgiveren. Med dette sikter vi til design, funksjonalitet og brukervennlighet på nettsiden og administrasjonsdelen. I forhold til endringer i kravspesifikasjonen, refererer vi til punkt 9. Endringshåndtering i kravspesifikasjonen. Prosessdokumentasjon 42

43 5 Avsluttende del Dette prosjektet har strekt seg over lang tid, naturlig nok vi har hatt våre oppturer og nedturer underveis. Vi har fått spennende utfordringer både med tanke på design, utvikling og implementering. Under dette punktet vil vi derfor oppsummere våre tanker og meninger ved dette prosjektets ende. 5.1 Prosjektets og produktets nytteverdi Hvilken nytteverdi har prosjektet og produktet gitt for de ulike partene (oppdragsgiveren, sluttbrukere), og hvilken nytteverdi vil det kunne gi i fremtiden? Under dette punktet vil vi utgi våre meninger, for deretter i punkt 6.3 å forklare hva vi mener er vår nytteverdi Nytteverdi for oppdragsgiver Dette vil nok ha god nytteverdi for oppdragsgiveren ettersom den har ønsket et slikt produkt og skulle uansett gjøre dette. Oppdragsgiveren har ikke dette fra før av og får muligheten til å opprette flere slike nettsider for sine artister ved hjelp av administrasjonsdelen. På bakgrunn av dette kan vi se at oppdragsgiveren vil kunne ha nytteverdi av produktet i ettertid. Riktignok bør det nevnes at ettersom dette har vært en del av deres ambisjoner, kan en anta at dette til syvende og sist ikke ble slik oppdragsgiveren ønsket og vil derfor kunne være noe negativt, men slik er det i alle former for utviklingsprosesser der en kunde har rammer om hva den ønsker seg av design, funksjonalitet og brukervennlighet. Selve prosjektprosessen vil kunne ha en nytteverdi for oppdragsgiver, som den kan benytte seg av ved en senere anledning. Det er ikke umulig at oppdragsgiveren vil gå i gang med liknende prosjekter i fremtiden, og vil da kunne vite mer om hvordan planleggingsfasen, utviklingsfasen og implementeringsfasen foregår. Samtidig er det tenkelig at oppdragsgiveren vet mer av hva den kan forvente seg av en slik prosess og et slikt produkt. I tillegg til dette er det naturligvis ønskelig fra vår side at denne dokumentasjonen kan bidra til informasjon som kan hjelpe dem videre og ikke minst være til nytte for dem i ettertid. Sannsynligvis vil artistene til oppdragsgiveren få mer oppmerksomhet og tilhengerne vil være mer fornøyd, ettersom de blir holdt oppdatert jevnlig. Prosessdokumentasjon 43

44 5.1.2 Nytteverdi for sluttbrukere Under sluttbrukere gjelder både sluttbrukerne til administrasjonsdelen og nettsiden. Når det gjelder sluttbrukerne til administrasjonsdelen vil vi anta at de vil få en stor nytteverdi ved bruk, ettersom vi har tilrettelagt dette for alle brukere, som tillater en med lite teknisk innsikt til å bruke systemet. Med tanke på sluttbrukere av nettsiden vil vi også anta at disse vil få stort utbytte og nytteverdi av sluttproduktet. Disse sluttbrukerne har også vært en interessent i dette prosjektet, ettersom det er viktig at vi treffer målgruppen med tanke på at det er ønsket mer oppmerksomhet og «blest» rundt artistene. Både sluttbrukerne for administrasjonsdelen og nettsiden er direkte interessenter og ikke minst sentrale i dette prosjektet. Som en oppsummering vil vi si at vi har fulgt kravspesifikasjonen godt og gjort det beste vi kan ut av situasjonen. Med situasjonen mener vi at oppdragsgiveren har blitt mer og mer vanskelig å få kontakt med. Dette har naturligvis ført til at vi har måttet ta egne valg og beslutninger som oppdragsgiveren ikke nødvendigvis synes er de beste, men vi har brukt vår «erfaring» og kunnskap som vi har lært ved Høgskolen i Oslo og Akershus som støtte i disse valgene og beslutningene. Dermed vil vi si at vi absolutt har klart å oppfylle kravene og endt opp med et produkt vi synes er godt, og målene er innfridd. Som en konklusjon på dette vil vi si at sluttbrukerne av produktet vil ha stor nytteverdi, ved bruk til sine formål. 5.2 Gruppens læringsutbytte Vi mener selv vi har fått et stort utbytte av dette prosjektet og produktet. Vi har virkelig fått «smake» på hva det vil si å jobbe med store prosjekter, fra startfasen og helt til sluttfasen. Vi har måttet løse problemer/utfordringer som dukket opp underveis, og som vi ikke kunne ta stilling til før vi kom dit. Det har vært flere interessante aspekter ved prosjektet og produktet. Vi mener selv at vi stiller sterkere enn vi gjorde tidligere, ettersom vi nå har fått litt erfaring på hvor omfattende i forhold til tid og kunnskap slike prosjekter kan være. Vi har lært mye nytt, og måttet benytte tidligere kunnskap i praksis, samt lest oss opp på ting vi har lært tidligere. I forhold til den videre utviklingen ser vi enkelte ting som kanskje bør gjøres noe med, men ikke noen drastiske tiltak som må til. Selv mener vi funksjonaliteten er god og slik oppdragsgiveren ønsket, i det minste som var mulig å realisere på denne tidsrammen. Når det gjelder stabiliteten er dette noe vi er meget fornøyd med, nettsiden og administrasjonsdelen ser ut til å tåle det den skal tåle, og fungerer til sitt bruk. Dersom det skulle oppstå en «eksplosjon» av sluttbrukere, er dette naturligvis noe som eventuelt må forbedres for å få økt stabilitet i forhold til trafikk på administrasjonsdelen og nettsiden. Forprosjektet startet allerede i forrige semester, men det er virkelig i dette semesteret vi har fått «kjørt» oss, og skjønt hva dette faktisk dreier seg om og hva som kreves av Prosessdokumentasjon 44

45 oss som studenter. Samtlige på gruppen mener vi har fått frisket opp «gammel» kunnskap, samtidig som vi har tilegnet oss ny kunnskap og gjort oss nye erfaringer. Dette gjelder ikke nødvendigvis kun et område, men opptil flere. Selve prosessen har vært med på å utvikle oss, og kan absolutt være en viktig brikke i videre karriere innen arbeidslivet. Prosjektet og prosessen har vært svært tidkrevende, og beveget seg over mer tid enn vi tidligere har kjørt prosjekter. I tillegg til dette har vi selv vært ansvarlige for at vi satt fornuftige mål og rammer for prosjektet, naturligvis i samråd med oppdragsgiver og veileder. Planlegging og strukturering har stått meget sentralt i prosjektet, og vi har for så vidt klart å følge tidsrammen godt, men til tider har det skjedd at vi har fått dårligere tid enn hva vi trodde selv. Dette er litt på grunn av at problemer som oppstår kan ta lengre tid å løse enn først antatt. I forhold til å overholde frister og leveranser mener vi selv at ikke vi har hatt noen store problemer, vi har som regel levert før fristene fordi vi har planlagt godt. Allikevel skal det sies at vi kunne startet tidligere med selve sluttdokumentasjonen, samtidig mener vi at å ha full fokus på produktet og prosessen også er viktig. Når det gjelder sluttdokumentasjonen har den selvsagt vært utfordrende, noe vi tenker det er ment at den skal være. Det har vært spennende å ha en oppdragsgiver fra arbeidslivet, det har hele tiden fra oppdragsgivers side vært viktig for han å vise oss hvordan det fungerer i den «virkelige verden». Det har absolutt vært nyttig for oss å få innsikt i dette, samtidig har det vært viktig å bli tatt mer på alvor som studenter (enn vi tidligere har opplevd), alt i alt en meget verdifull erfaring. Vi har naturligvis fått et meget stort læringsutbytte med tanke på erfaringen vi nå har med oss videre innen prosjektarbeid og prosjektstyring. Vi lærte noe nytt ettersom vi måtte benytte oss av verktøy og teknologier som ikke kjente til på forhånd, og nå måtte vi til og med bruke dette i selve produktet. Kort oppsummert må vi si at vi har møtt på både små og store utfordringer, noe vi selv mener vi har klart å løse i fellesskap blant gruppen og i forhold til oppdragsgiveren. Vi ser tilbake på produktet og tenker at det er tydelig hvor stor innsats vi har lagt inn i design, utforming og implementasjon, som igjen kanskje gjenspeiler oss som individuelle og ikke minst gruppe. Vi mener også at vi har fått mer faglig kunnskap og erfaringer, som igjen kanskje har gitt oss mer bredde når vi skal ut i arbeidslivet. 5.3 Konklusjon Konklusjonen etter endt prosjekt er at vi har fått både nye kunnskaper, erfaringer og «smaken» på hvordan det fungerer profesjonelt i arbeidslivet. Vi har lagt et stort press på oss selv, hatt nokså høye ambisjoner og mål, men innenfor rimelighetens grenser. Alt i alt mener vi selv at vi har designet, utviklet og implementert et levedyktig produkt, men vil allikevel presisere at oppdragsgiveren må følge opp dette videre. Mange vil kanskje si at dette er en prosess som har vart over kort tid, men vi ser det Prosessdokumentasjon 45

46 som en tre års lang prosess med læring som har gjort at produktet har blitt til det som det har. Vi har brukt mange metoder og teknikker som vi har lært underveis i studiet, blant annet programmeringsferdigheter, kjennskap til utviklingsmetoder, brukervennlighet og universell utforming. På bakgrunn av det som tidligere har blitt nevnt, ikke minst i konklusjonen, vil vi si at vi er fornøyd og stolt av vårt resultat og derfor har prosjektet vært vellykket i våres øyne. En kan alltids si at noen kunne ha vært gjort annerledes, men det er også en del av læringsprosessen. Til slutt informerer vi om at vi har lagt over alle filer tilhørende produktet på en CD, som ligger som vedlegg til sluttdokumentasjonen. Prosessdokumentasjon 46

47 6 Referanseliste Nr.1-1: Oppdragsgiverens bedrift sin nettside: Nr.1-2: Serverleie: Nr.1-3: Sosiale medier, Facebook: Nr.1-4: Sosiale medier, Skype: Nr.1-5: Sosiale medier, messenger: Nr.1-6: NetBeans: Nr.1-7: Notepad++: Nr.1-8: XAMPP: Nr.1-9: Apache: Nr.1-10: MySQL: Nr.1-11: Innebygget utviklerverktøy: Utviklerverkt%C3%B8y Nr.1-12: Firebug: Nr.1-13: Git: Nr.1-14: Dropbox: Nr.1-15: Google Docs: Nr.1-16: Adobe Photoshop: Nr.1-17: PHP PDO: Nr.1-18: Bootstrap: Nr.1-19: BandsInTown: Nr.1-20: Fargeblindhet: Nr.1-21: Fargeblindhet: Nr.1-22: Fargefilter som simulerer fargeblindhet: Nr.1-23: Protanopi (rødblindhet), fargefilter: Nr.1-24: Deuteranopi (grønnblindhet), fargefilter: Prosessdokumentasjon 47

48 Nr.1-25: Tritanopi (blå/gulblindhet), fargefilter: Nr.1-26: Branding guidelines, Youtube: Nr.1-27: Branding guidelines, Vimeo: Nr.1-28: Branding guidelines, Twitter: Nr.1-29: Branding guidelines, Facebook: Nr.1-30: Branding guidelines, Facebook: Nr.1-31: Prosjektdagbok: Nr.1-32: Dokumentasjonsstandard: Nr.1-33: Statusrapport: Nr.1-34: Prosjektskisse: Nr.1-35: Forprosjektrapport: Nr.1-36: Kravspesifikasjon: Nr.1-37: Scrum, synlighet, inspeksjon og tilpasning: Nr.1-38: Kanban: Prosessdokumentasjon 48

49 7 Vedlegg Nr.1-1: Simulering av rødblindhet, protanopi. Vedlegg nr.1-2: Simulering av rødblindhet, protanopi. Prosessdokumentasjon 49

50 Vedlegg nr.1-3: Simulering av grønnblindhet, deuteranopi. Vedlegg nr.1-4: Simulering av grønnblindhet, deuteranopi. Prosessdokumentasjon 50

51 Vedlegg nr.1-5: Simulering av blå/gulfargeblindhet, tritanopia. Vedlegg nr.1-6: Simulering av blå/gulfargeblindhet, tritanopia. Prosessdokumentasjon 51

52 Vedlegg nr.1-7: UCD «Articles». Vedlegg nr.1-8: Tekstlig beskrivelse av bruksmønsteret til UCD «Articles». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Write article A-bruker, B-bruker Aktør er innlogget Aktør er i kategorien for artikler Ny artikkel er publisert 1. Systemet viser et skjema med tittel felt, språkvalg og en teksteditor 2. Aktør fyller inn tittelen, velger språk og skriver innholdet i teksteditoren 3. systemet validerer tittelen og språkvalget 4. systemet lagrer den nye artikkelen 5. systemet dirigerer aktør til artikkel listen 2a. Aktør fyller ikke inn tittel felt Prosessdokumentasjon 52

53 2a.1. Systemet viser en melding om manglende valg 2a.2. Aktør fyller inn tittel felt og lagrer 2a.3. Systemet fortsetter på steg 3. 2b. Aktør trykker avbryt 2b.1. Systemet lagrer ingenting 2b.2. Systemet dirigerer aktør til artikkel listen. 3a. Tittel validerer ikke 3a.1. Systemet går tilbake til steg 2. og viser en melding om feilen 3a.2. Aktør retter feil og lagrer 3a.3. Systemet fortsetter på steg 3. 3b. Artikkel innhold ikke skrevet 3b.1. Systemet går tilbake til steg 1. ingenting blir lagret. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Edit article A-bruker, B-bruker Aktør er innlogget Aktør har valgt en eksisterende artikkel Endret artikkel er lagret 1. Systemet viser samme skjema som i write article med unntak av språkvalg 2. Aktør utfører ønskede endringer og trykker på lagre 3. systemet lagrer endringene 2a. Aktør tømmer tittel feltet og lagrer 2a.1. Systemet viser en melding om manglende informasjon 2a.2. Aktør retter tittelen og lagrer 2a.3. systemet fortsetter på steg 3. 2b. Aktør trykker avbryt 2b.1. Systemet dirigerer aktør til artikkel listen Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Delete article A-bruker Aktør er innlogget Artikler eksisterer Aktør er i artikkel listen Valgt artikkel er slettet 1. systemet viser artikkel detaljene i en liste 2. aktør markerer ønskede artikler og trykker på slett markerte 3. systemet sletter valgte artikler 2a. Aktør markerer ingen artikler og trykker slett 2a.1. Systemet viser en melding om at ingen artikler er markert. Navn: Aktør: List headers A-bruker, B-bruker, C-bruker Prosessdokumentasjon 53

54 Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: Aktør er navigert til kategorien for artikler Systemet viser en oversikt over alle artikler med nok informasjon til å identifisere en enkelt artikkel 1. systemet samler en liste med informasjon om alle artikler for et gitt språk 2. systemet formaterer informasjonen og viser en liste over tilgjengelige artikler C-brukere får artikkel headere presentert på en annen måte enn A-brukere og B-brukere Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: Read article A-bruker, B-bruker, C-bruker Aktør er i artikkel listen Aktør kan lese hele artikkelens innhold 1. Aktør velger en enkelt artikkel fra artikkel listen 2. Systemet henter fram den valgte artikkelen og presenterer innholdet. C-brukere får lese artikkelen slik den ble formattert ved publisering A-brukere og B-brukere går til use casen edit article Vedlegg nr.1-9: UCD «Artist». Vedlegg nr.1-10: Tekstlig beskrivelse av bruksmønsteret til UCD «Artist». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Edit artistname A-bruker Aktør er innlogget Aktør har valgt kategorien for artistdetaljer Artistnavnet er endret 1. Systemet viser input felt for artistnavnet med det gamle artistnavnet ferdigutfylt. Prosessdokumentasjon 54

55 Alternativ flyt: 2. aktør endrer artistnavnet og trykker lagre 3. systemet validerer artistnavnet 4. systemet lagrer artistnavnet i databasen 2a. Aktør tømmer artistnavn feltet og trykker lagre 2a.1. Systemet viser en melding om manglende input felt 2a.2. Aktør fyller inn artistnavnet 2a.3. Systemet fortsetter på steg 3. 3a. Artistnavnet validerer ikke 3a.1. Systemet går tilbake til steg 1 og viser en melding om feilen Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Kommentar: Edit social media A-bruker, B-bruker Aktør er innlogget Aktør har valgt kategorien for artistdetaljer Lenker til sosiale medier er opprettet, endret eller slettet 1. systemet viser input felter for de forskjellige sosiale mediene, med gamle verdier ferdigutfylt 2. aktør endrer ønskede felt og trykker lagre 3. systemet validerer endringene 4. systemet lagrer endringene til databasen 2a. En eller flere felter inneholder ugyldige URLer 2a.1. Systemet viser en melding om at feltene må inneholde en URL 2b. Aktør trykker avbryt 2b.1. Eventuelle endringer blir ikke lagret og systemet laster siden inn på nytt. Input feltene aksepterer tomme verdier og validerte URLer med protokoll ( etc.) Dersom et felt tømmes og aktør trykker lagre regnes dette som at den oppgitte lenken skulle slettes fra databasen. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Click social media links C-bruker Aktør er på forsiden eller en av undersidene til nettsiden Ny fane / nytt vindu er åpnet og laster inn ønsket sosialt medie 1. Systemet viser ikoner for sosiale medier hvor artisten har konto 2. aktør klikker på ønsket ikon 3. systemet åpner lenken i ny fane / nytt vindu Prosessdokumentasjon 55

56 Vedlegg nr.1-11: UCD «Biography». Vedlegg nr.1-12: Tekstlig beskrivelse av bruksmønsteret til UCD «Biography». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Edit biography A-bruker, B-bruker Aktør er innlogget Aktør er i kategorien for artist biografi Biografi endringer er lagret 1. systemet forhåndsviser biografien for grensesnittets aktive språkvalg 2. aktør velger endre alternativet 3. systemet viser en teksteditor med biografi innholdet forhåndslastet 4. aktør utfører ønskede endringer og trykker lagre 4a. Aktør utfører ingen endringer og trykker lagre 4a.1. Systemet lagrer ingen endringer og gir en melding om dette. 4b. Aktør trykker avbryt 4b.1. Systemet lagrer ingen endringer og dirigerer brukeren tilbake til Prosessdokumentasjon 56

57 Kommentar: forhåndsvisning av biografien Aktøren kan når som helst endre hvilken språkversjon av biografien som skal vises. Dersom det er gjort endringer i biografien og disse ikke er lagret vil endringene bli mistet når en annen språkversjon av biografien er valgt. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: Read biography A-bruker, B-bruker, C-bruker Aktør er navigert til artistens biografi Systemet viser biografien for det aktive språket 1. Systemet laster inn biografien basert på det aktive språket 2. Systemet viser biografien med lagret format. For A-brukere og B-brukere er dette forhåndsvisningen av biogragien, disse aktørene har mulighet til å laste inn andre språkversjoner av biografien uten å bytte aktivt språk. C-brukere kan bare se andre språkversjoner av biografien ved å endre aktivt språk på nettsiden. Vedlegg nr.1-13: UCD «Booking». Prosessdokumentasjon 57

58 Vedlegg nr.1-14: Tekstlig beskrivelse av bruksmønsteret til UCD «Booking». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Create booking request C-bruker Aktør er navigert til kontaktsidene Ny booking forespørsel er sendt og lagret 1. Systemet viser et skjema for booking forespørsler 2. aktør fyller inn nødvendige detaljer og trykker lagre 3. systemet validerer detaljene 4. systemet lagrer detaljene i databasen og sender detaljene på e-post 2a. Aktør fyller ikke inn påkrevd felt 2a.1. Systemet viser en popup melding om manglende felt 2a.2. Aktør fyller inn påkrevd felt og lagrer. Use case fortsetter på steg 3. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: List requests A-bruker, B-bruker Aktør er innlogget Aktør er i kategorien for booking Systemet viser en liste for booking forespørsler 1. Systemet henter en liste fra databasen 2. systemet formaterer dataene og viser disse til aktøren Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Read request A-bruker, B-bruker Aktør er innlogget Aktør er i booking forespørsel listen Systemet viser alle detaljer om en booking forespørsel 1. Aktør velger en oppføring fra booking forespørsel listen 2. systemet henter alle data om forespørselen 3. systemet formaterer detaljene og viser til aktøren Resend request A-bruker, B-bruker Aktør er innlogget Aktør er i read request use casen Booking forespørsel er sendt på nytt til forhåndsdefinert e-post adresse 1. aktør trykker på knappen send på nytt 2. systemet henter alle detaljer og formaterer de for sending 3. systemet sender detaljene på e-post Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Delete request A-bruker Aktør er innlogget Aktør er i read request use casen Booking forespørsel er slettet fra databasen 1. Aktør trykker på slett knappen 2. systemet ber om bekreftelse på at oppføringen skal slettes 3. aktør bekrefter sletting Prosessdokumentasjon 58

59 Alternativ flyt: 4. systemet sletter oppføringen fra databasen 5. systemet dirigerer aktøren til bokking request listen 3a. Aktør avbryter sletting 3a.1. Systemet avbryter slettingen og går tilbake til use casen read request Vedlegg nr.1-15: UCD «Contacts». Vedlegg nr.1-16: Tekstlig beskrivelse av bruksmønsteret til UCD «Articles». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: View contact details A-bruker, B-bruker, C-bruker Aktør er navigert til kategorien for kontakt Systemet viser kontaktdetaljene som de er lagret i databasen 1. systemet henter kontaktdetaljene fra databasen 2. systemet viser kontaktdetaljene med forhåndslagret formatering For A-bruker og B-brukere er dette forhåndsvisningen av kontaktdetaljene disse brukerne vil få mulighet til å endre innholdet og hvordan kontaktdetaljene er formatert. C-brukere vil bare kunne se kontaktdetaljene med den lagrede formateringen. Nettsiden bruker samme kontaktdetaljer på alle språkversjoner av nettsiden Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Edit contact details A-bruker, B-bruker Aktør er innlogget Aktør ser forhåndsvisningen av kontaktdetaljene Kontaktdetaljer er endret 1. Aktør trykker på endre 2. systemet viser en teksteditor for kontaktdetaljene 3. aktør utfører ønskede endringer i kontaktdetaljene (innhold/formattering) og trykker lagre 4. systemet lagrer endringene til databasen Prosessdokumentasjon 59

60 Kommentar: Nettsiden bruker de samme kontaktdetaljene på alle språkversjoner. Dersom aktøren tømmer teksteditoren og lagrer vil alle kontaktdetaljer slettes. Vedlegg nr.1-17: UCD «Discography». Vedlegg nr.1-18: Tekstlig beskrivelse av bruksmønsteret til UCD «Discography». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Add entry A-bruker, B-bruker Aktør er navigert til kategorien for artist diskografi Ny diskografi oppføring er lagret i databasen 1. Aktør trykker på legg til ny 2. systemet viser skjema for diskografi oppføringer 3. aktør fyller ut skjema og trykker lagre 4. systemet lagrer skjema detaljer til databasen 5. systemet dirigerer brukeren til diskografi listen 3a. Aktør fyller ikke ut alle nødvendige felt 3a.1. Systemet viser en melding om manglende felt 3a.2. Aktør fyller inn nødvendige felt og trykker lagre 3a.3. Use case fortsetter på steg 4. 3b. Aktør trykker avbryt 3b.1. use case fortsetter på steg 5. Prosessdokumentasjon 60

61 Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: edit entry A-bruker, B-bruker Aktør er navigert til kategorien for artist diskografi Ny diskografi oppføring er lagret i databasen 1. Aktør velger en oppføring fra listen 2. Systemet viser skjema for diskografi oppføringen med ferdigutfylte input felter. 3. Aktør utfører ønskede endringer og trykker lagre 4. systemet lagrer detaljene til databasen 5. systemet dirigerer brukeren til diskografi listen 3a. Aktør tømmer nødvendige felt 3a.1. Systemet viser en melding om manglende felt 3a.2. Aktør fyller inn nødvendige felt og trykker lagre 3a.3. Use case fortsetter på steg 4. 3b. Aktør trykker avbryt 3b.1. use case fortsetter på steg 5. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: List entries A-bruker, B-bruker, C-bruker Aktør er navigert til kategorien for artist diskografi Systemet lister opp alle oppføringer fra databasen 1. systemet henter detaljer fra databasen 2. systemet formaterer detaljene for visning og viser en liste til aktør A-brukere og B-brukere får en list med klikkbare elementer, ved å klikke på et element vil de gå til use case edit entry. C-brukere vil bare få en tekstliste som de kan lese. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Delete entry A-bruker Aktør er i use case edit entry. Diskografi oppføring er slettet fra databasen 1. aktør trykker på slett oppføring knappen 2. systemet ber om bekreftelse for sletting 3. aktør bekrefter sletting 4. systemet sletter oppføringen 5. systemet dirigerer aktør til diskografi listen 3a. Aktør avbryter sletting 3a.1. Systemet avbryter sletting og går tilbake til use case edit entry Prosessdokumentasjon 61

62 Vedlegg nr.1-19: UCD «Images». Vedlegg nr.1-20: Tekstlig beskrivelse av bruksmønsteret til UCD «Images». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: List images A-bruker, B-bruker, C-bruker Aktør er navigert til kategorien for bilder Aktør ser en oversikt over alle bilder tilgjengelig for aktøren 1. systemet henter detaljer om bildene fra databasen 2. systemet formaterer detaljene om bildene og oppretter lenker til bilder og thumbnails 3. systemet viser bildelisten til aktøren C-brukere vil få en liste bestående av klikkbare thumbnails. Ved å klikke på en thumbnail vil fullversjonen av bildet vises. A-brukere og B-brukere vil få en liste med detaljer om bildet og ved å klikke på bildet vil aktøren gå til use casen edit image details Prosessdokumentasjon 62

63 Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Add image A-bruker, B-bruker Aktør er navigert til kategorien for bilder Nytt bilde er lastet opp og detaljer er lagret i databasen 1. Aktør trykker på legg til ny 2. Systemet viser et skjema med input felt for bildedetaljer og filopplasting 3. Aktør fyller inn nødvendige felter og trykker lagre 4. Systemet validerer bildedetaljer og opplasting 5. systemet flytter bildefilen fra tmp mappe til bilde mappe 6. systemet lagrer bildedetaljer i databasen 7. systemet dirigerer aktør til bilde listen 3a. Aktør fyller ikke inn alle nødvendige felt 3a.1. Systemet gir beskjed om manglende felter 3a.2. Aktør fyller inn nødvendige felter 3a.3. Use case fortsetter på steg 4. 3b. Aktør trykker avbryt 3b.1. Systemet lagrer ingenting, og utfører steg 7 4a. Input verdier er ikke gyldige/fil er ikke gyldig 4a.1. Systemet gir en feilmelding til aktør som beskriver hva som gikk galt Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Edit image details A-bruker, B-bruker Aktør er navigert til kategorien for bilder Bildedetaljer er endret 1. Aktør velger et bilde fra bildelisten 2. systemet viser et skjema med felter for mulige verdier å endre 3. aktør utfører ønskede endringer og trykker lagre 4. systemet validerer endringer 5. systemet lagrer endringene 4a. input felter er tomme / validerer ikke 4a.1. Systemet viser en feilmelding som beskriver hva som gikk galt, Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Kommentar: Delete image A-bruker Aktør er i use case list images eller edit image details Bildefil er slettet fra disk og bildedetaljer er slettet fra databasen 1. Aktør velger bilde som skal slettes og trykker på knappen for å slette 2. systemet ber om bekreftelse på sletting 3. aktør bekrefter sletting 4. systemet sletter bildefilen og bildedetaljer 5. systemet dirigerer aktør til bilde listen 1a. Aktør velger ikke bilder som skal slettes 1a.1. Systemet gir en melding om at ingen bilder er valgt Det er to mulig måter å slette bilder på Prosessdokumentasjon 63

64 1. fra bilde listen markere en eller flere bilder som skal slettes 2. fra endre bildedetaljer skjemaet tilsvarende å merke ett bilde i listen Alternativ flyt er ikke gjeldene for metode 2. Vedlegg nr.1-21: UCD «Lyrics». Prosessdokumentasjon 64

65 Vedlegg nr.1-22: Tekstlig beskrivelse av bruksmønsteret til UCD «Lyrics». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: List lyrics A-bruker, B-bruker, C-bruker Aktør er navigert til kategorien for sangtekster Systemet viser en liste med sangtekster 1. Systemet henter detaljer om opplastede sangtekster fra databasen 2. Systemet formater en liste med detaljene fra sangtekstene og oppretter lenker for nedlasting av filer. 3. Systemet viser listen med sangtekster til aktør C-brukere vil få en nedlastingslenke i listen A-brukere og B-brukere vil få en klikkbar liste som leder til edit lyric details use casen. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Add lyric A-bruker, B-bruker Aktør er innlogget Aktør er navigert til kategorien for sangtekster Ny sangtekst fil er lagret på serveren og detaljer er lagret i databasen 1. Aktør trykker på legg til ny 2. Systemet viser et skjema med fil opplasting og tittelfelt 3. Aktør velger en fil fra filopplasting og fyller inn tittelfelt og trykker lagre 4. systemet validerer tittel og fildetaljer 5. systemet flytter filen fra tmp mappe til sangtekst mappe 6. systemet lagrer detaljene i databasen 7. systemet dirigerer aktør til sangtekst listen 3a. Aktør fyller ikke inn tittel eller velger ikke en fil 3a.1. Systemet viser en melding om manglende felt 3a.2. Aktør fyller inn manglende felt. Use case fortsetter til steg 4. 3b. Aktør trykker avbryt 3b.1. Systemet lagrer ingenting og går til steg 7. 4a. Tittel eller fildetaljer validerer ikke 4a.1. Systemet går tilbake til steg 2 og viser en melding om ugyldige verdier. 4a.2. Aktør utfører nødvendige endringer og trykker lagre. Use case fortsetter på steg 4. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: remove lyric A-bruker Aktør er innlogget Aktør er navigert til kategorien for sangtekster / aktør er i edit lyric details use casen Sangtekst fil er slettet og detaljer om sangteksten er slettet fra databasen 1. aktør trykker på knappen for å slette 2. systemet ber om bekreftelse på sletting Prosessdokumentasjon 65

66 Alternativ flyt: Kommentar: 3. aktør bekrefter sletting 4. systemet sletter filen og database oppføringen 5. systemet dirigerer aktør tilbake til sangtekst listen 1a. Aktør har ikke valgt noen fil for sletting 1a.1. Systemet gir melding om at ingen oppføringer er valgt A-brukere har to muligheter for å slette sangtekster. 1. fra sangtekstlisten hvor det er mulig å velge flere sangtekster 2. fra edit lyric details hvor den valgte sangteksten vil bli slettet Alternativ flyt gjelder ikke for sletting fra edit lyric details Vedlegg nr.1-23: UCD «Newsletter». Vedlegg nr.1-24: Tekstlig beskrivelse av bruksmønsteret til UCD «Newsletter». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Signup C-bruker Aktør er navigert til nettsiden Ny mottaker er lagret i databasen 1. Systemet viser et skjema for påmelding på nyhetsbrev 2. aktør fyller inn nødvendig informasjon og trykker meld på 3. systemet lagrer kontaktdetaljer 4. systemet gir en melding om aktøren er registrert 2a. Aktør fyller ikke inn nødvendig felt 2a.1. Systemet viser en melding om manglende felt 2a.2. Aktør fyller inn nødvendig felt 2a.3. Systemet utfører steg 3. Prosessdokumentasjon 66

67 3a. Mottaker adresse eksisterer allerede 3a.1. Systemet gir en melding om at aktør er påmeldt Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: List signups A-bruker, B-bruker Aktør er navigert til kategorien for nyhetsbrev Systemet viser en liste over mottakere for nyhetsbrev 1. systemet henter detaljer fra databasen 2. systemet formaterer detaljene og viser de i listeform til aktør Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: Download recipients A-bruker, B-bruker Aktør er navigert til kategorien for nyhetsbrev Aktør har lastet ned en fil bestående av alle mottakere. Filen kan åpnes i excel. 1. Aktør trykker på last ned CSV 2. Systemet henter detaljer fra databasen 3. Systemet oppretter en ny fil i output buffer med detaljene fra databasen. 4. Aktør laster ned filen. Når systemet oppretter filen i output buffer vil nettleseren til aktøren be om handling fra bruker. Vanligvis er valgene her å åpne filen, laste ned filen eller avbryte. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Delete selected A-bruker Aktør er i list signups use casen Valgte mottakere er slettet fra databasen 1. Aktør markerer ønskede mottakere og trykker på slett markerte 2. systemet ber om bekreftelse på sletting 3. aktør bekrefter sletting 4. systemet sletter markerte mottakere fra databasen 4a. Aktør markerte ingen mottakere 4a.1. Systemet gir en melding om at ingen mottakere er valgt. Prosessdokumentasjon 67

68 Vedlegg nr.1-25: UCD «Videos». Vedlegg nr.1-26: Tekstlig beskrivelse av bruksmønsteret til UCD «Videos». Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Add video A-bruker, B-bruker Aktør er innlogget Aktør er i kategorien for videoer Ny video er lagt til i databasen 1. Systemet viser et skjema med felter for video tittel og video URL 2. aktør fyller inn feltene og trykker lagre 3. systemet behandler inn dataene 4. systemet lagrer tittel og uthentede video detaljer i databasen 5. systemet navigerer aktør til video listen 2a. Aktør fyller ikke inn et av feltene 2a.1. Systemet viser en melding om manglende felt og går ikke videre 2a.2. Aktør fyller inn manglende felt 2a.3. Systemet fortsetter på Steg 3. 2b. Aktør trykker avbryt 2b.1. Systemet utfører steg 5 ingen data blir lagret 2c. Aktør fyller inn ugyldig URL 2c.1. Systemet viser en melding om at URL ikke er gyldig 2c.2. Aktør retter URL adressen og trykker lagre Prosessdokumentasjon 68

69 2c.3. Systemet fortsetter på steg 3. 3a. Oppgitt URL inneholder ikke video identifikator 3a.1. Systemet viser en melding om at video identifikator ikke kunne finnes i URLen. 3a.2. Aktør retter URLen og trykker lagre 3a.3. Systemet forsøker å utføre steg 3 på nytt. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Edit video details A-bruker, B-bruker Aktør er innlogget Video er valgt i video listen Ny video tittel er lagret 1. Systemet viser detaljer om videoen i et skjema 2. Aktør endrer tittel og trykker lagre 3. Systemet lagrer tittelen 2a. Aktør lar tittel felt stå tomt og trykker lagre 2a.1. Systemet viser en melding om at tittelfeltet må fylles ut 2a.2. Aktør fyller ut tittelfeltet. 2a.3. Systemet utfører steg 3. 2b. Aktør gjør ingen endringer og trykker lagre 2b.1. Systemet viser en melding om at ingen endringer har blitt lagret 2c. Aktør trykker på avbryt knappen 2c.1. Systemet dirigerer aktør tilbake til video listen Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Alternativ flyt: Remove video A-bruker Aktør er innlogget Aktør har valgt en eksisterende video Valgt video er slettet fra databasen 1. Systemet viser detaljer om videoen i et skjema 2. aktør trykker på slett video knappen 3. systemet viser en popup boks for bekreftelse 4. aktør bekrefter 5. systemet sletter videoen 6. systemet dirigerer aktør tilbake til video listen 4a. Aktør avbryter slettingen 4a.1 Systemet sletter ingen detaljer og går tilbake til steg 1. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: List videos A-bruker, B-bruker, C-bruker Aktør har valgt video kategorien Systemet viser en liste over videoer som er lagt til i databasen 1. Systemet oppretter en liste over alle videoer som er lagret i databasen Prosessdokumentasjon 69

70 Kommentar: 2. systemet formaterer listen og viser den til aktør Listen C-brukere får er ikke den samme som A-brukere og B-brukere får. C-brukere får en liste som består av video avspillere mens A-brukere og B-brukere får en liste med tekstlig informasjon om videoer hvor de deretter kan velge en spesifikk video. Navn: Aktør: Prebetingelse: Postbetingelse: Hovedflyt: Kommentar: View video A-bruker, B-brukere Aktør er innloggget Aktør er i video listen Systemet viser all informasjon om valgt video 1. Aktør velger en video fra video listen 2. systemet finner alle lagrede detaljer i databasen om videoen 3. systemet viser et skjema med detaljene om videoen i tillegg til en video avspiller Use casene edit video details og remove video bruker use casen view video Prosessdokumentasjon 70

71 Tetriz - Event & Management Artistnettside Produktdokumentasjon Høgskolen i Oslo og Akershus Hovedprosjekt 2014 Gruppe 7 Jasmin Mehrnia, Joakim Kartveit, Frode Mathiesen, Gry Anita Nilsen

72 Forord Denne dokumentasjonen tar for seg produktet, som vi har utviklet i løpet av prosjektet, fra januar 2014 til mai Ettersom produktet vårt er en nettside med et tilhørende Content Management System (CMS) har vi valgt å referere til de forskjellige delene med følgende terminologi CMS er en forkortelse av Content Management System Nettsiden referere til nettsidene tilgjengelig for besøkende Administrasjonsdelen refererer til nettsidene tilgjengelig for innloggede (CMS) Produktet referer til produktet som helhet CDN Content Delivery Network Produktdokumentasjon 72

73 Innholdsfortegnelse Forord Presentasjon av produktet Innledning Presentasjon nettsiden Formål Beskrivelse Særlige forhold Presentasjon CMS Formål Samkjøring mellom nettsiden og CMS Utvikling Teknologi Apache server MySQL JavaScript JQuery AJAX HTML PHP XAMPP Git PHP PDO Databasen Behov Databasemodell utvikling Databasemodell ferdig versjon Databasetabeller Mappestruktur Mappeinnhold Navngiving Mapper Filer Produktdokumentasjon 73

74 3 Utforming av grensesnitt Designprinsipper Kort forklaring av våre valgte syv designprinsipper Designprinsipper i forhold til CMS og nettsiden Structure Simplicity Visibility Feedback Tolerance og Constraints Consistency og affordance Control Kravspesifikasjon og produkt Kravspesifikasjonen og nettsiden Kravspesifikasjon og CMS Funksjonelle krav Ikke-funksjonelle krav Oppsummering Beskrivelse av produktet Sentrale datastrukturer i produktet Produktets oppbygning Nettsiden CMS Logging Errorhandler log_fatal Try Catch Sikkerhet Passord Registrering Adgangsnivå Forhold til funksjonelt grensesnitt Maskinvare Lagringsplass Produktdokumentasjon 74

75 6.3 Operativsystemer Referanseliste Vedlegg Produktdokumentasjon 75

76 1 Presentasjon av produktet I denne delen beskriver vi produktet vi har utviklet i løpet av prosjekt, presentasjonen er delt i to deler. For presentasjon av nettsiden for besøkende se 1.2 presentasjon nettsiden for presentasjon av administrasjonsdelen for innloggede se 1.3 presentasjon CMS 1.1 Innledning Vi ble enige med bedriften Tetriz - Event & Management å utvikle en nettside for en av deres artister. Et av kravene var at bedriften senere skulle kunne bruke dette produktet som et rammeverk som senere kan tilpasses til behovene. Produktet vårt er utviklet for å støtte de fire mest kjente nettleserne på markedet, her skal produktets funksjonalitet, design og layout være tilnærmet lik på de nyeste versjonene av nettleserne, Google Chrome, Mozilla Firefox, Safari, Opera og Internet Explorer. 1.2 Presentasjon nettsiden Her vil vi presentere nettsiden tilgjengelig for besøkende til nettstedet Formål Formålet med nettsiden er å promotere Daniel Johansen Elmrhari, samt gi brukerne informasjon om artisten. Vi ønsker at brukerne skal kunne lese biografi siste nytt, se bilder, videoer og følge med på når artisten holder konsert. Brukerne har mulighet til å melde seg på nyhetsbrev, laste ned bilder og sangtekster til artisten. Vi har hatt fokus på å lage en forside som gir brukerne et godt førsteinntrykk og som gir brukerne lyst til å navigere seg videre rundt på nettsiden Beskrivelse Nettsiden er basert på en av oppdragsgiverens artister og bygget opp slik at det enkelt skal kunne «gjenbrukes» til andre artister. Vi sier derfor at dette er en slags plattform, som oppdragsgiveren videre kan bruke på andre artister. Nettsiden består av en hovedside «Hjem», med flere undersider; «Nyheter», «Biografi», «Media», «Konserter» og «Kontakt». Under «Media» ligger det igjen tre undersider; «Bilder», «Videoer» og «Sangtekster». Fellesnevneren for hele nettsiden er at toppmenyen (med navigasjonsmuligheter både på nettsiden og sidene til artisten på sosiale medier) og footeren (informasjon om bedriften Tetriz - Event & Management, med tilgang til forenklet navigasjon) er tilgjengelig og plassert likt. Det som også følger hele nettsiden er en «tilbake-til-topp» knapp (illustrert ved en pil som Produktdokumentasjon 76

77 peker oppover), som skal forenkle scrolling til toppen av nettsiden. Denne scroller elegant og rolig opp, i stedet for å «kaste» brukeren opp for en visuelt behageligere opplevelse. Fargevalget og designet er naturligvis et gjennomgående tema. Grunnen til at vi sier dette er naturlig, er fordi vi mener dette gir en god opplevelse for brukeren, samt at brukeren kjenner seg igjen og slipper å forholde seg til mange forskjellige fargevalg og ulike temaer. Under følger en kort gjennomgang av sidenes funksjoner og struktur, ettersom toppmenyen, «tilbake-til-topp» og footeren er konstante, vil ikke disse bli nevnt for de ulike sidene. «Hjem» inneholder et «slideshow» med tre ulike bilder med en liten tekst, samt knapp som henviser til hvor brukeren kan lese mer. Under dette vil brukeren få oppgitt noen «nyhetsartikler» eller det A- og B-brukeren (fra Administrajonsdelen, administratorer for nettsiden) anser som ønskelig å ha plassert der. Dette kan for eksempel være viktige nyheter om artisten eller interessante opplysninger. «Nyheter» inneholder ulike artikler/nyheter, der det blir gitt en liten tittel eller overskrift som forklarer hva artikkelen/nyheten handler om. I «bakgrunnen» av denne vil det ligge et bilde som kan gjøre at brukeren blir mer interessert til å lese artikkelen/nyheten. «Biografi» inneholder en kort tekst om artisten, samt et bilde av artisten i bunn. «Media», «Bilder» inneholder et bildegalleri, der bildene blir vist som «thumbnails» slik at brukeren enkelt kan gå inn på ønsket bilde, eller starte visning fra første bildet. Når brukeren trykker på et valgt bilde, vil dette vises større sentrert midt på skjermen, der brukeren får tre mulige knapper å trykke på. En mulighet er at brukeren kan trykke på «x» i høyre hjørne for å gå tilbake/avslutte visningen. Mulighet nummer to er at brukeren kan trykke på «Forrige»-knappen nederst til venstre, da vil brukeren få vist bildet som ligger før det som nå vises, komme frem. Siste mulighet er at brukeren kan trykke på «Neste»-knappen nederst til høyre, da vil bildet som ligger etter det som nå vises, komme frem. Brukeren har i denne visningsmodusen tilgang til å bruke piltastene på tastarutet på sin pc, som gjør at den kanskje enklere kan bla mellom de ulike bildene. Det er kun venstre og høyre piltast som kan brukes her. Visningsmodusen kan også bli avsluttet ved å trykke på «Esc» knappen på tastaturet. «Media», «Videoer» inneholder en rekke videoer av artisten. Når brukeren trykker på play-knappen til en video vil disse bli vist i samme «miniatyr-størrelse» som er vist på nettsiden. Disse videoene er hentet fra youtube.com ved hjelp av en embed-kode, som er integrert i kodingen. Derfor har brukeren de samme mulighetene i forhold til avspilling som den også har på youtube.com sin nettside. Mange brukere er kjent med youtube, derfor har vi tenkt at dette blir gjenkjennelig for brukeren. Mulighetene den har er: play, pause, regulere lyd, se senere, innstillinger (annoteringer (på/av), hastighet (0.25/0.5/normal/1.5/2), kvalitet (720p/480p/360p/240p/144p/auto)), se på youtube.com, fullskjerm visning, deling via url eller direkte i sosiale medier og informasjon om videoen. Innstillingene vil kunne variere fra video til video. Før Produktdokumentasjon 77

78 avspilling vil en «tittel» bli oppgitt i video-ruten. Etter avspilling vil det komme opp en rekke videoer med lignende innhold, play/pause-knappen er nå omgjort til «spill av igjen». Ved at brukeren høyreklikker i video-ruten vil den kunne kopiere videonettadresse. «Media», «Sangtekster» inneholder per dags dato en liste av artistens cover-låter. Ved at brukeren trykker på ønsket cover-låt vil teksten komme opp på skjermen. «Konserter» inneholder «bandsintown» applikasjon, som gir tilgang til administrator å legge inn artistens navn. Deretter vil denne vise informasjon til brukerne om dato, spillested/arena, sted og billetter for kommende konserter. Brukeren kan også trykke på «Notify me when Daniel Elmrhari comes to my area.», da går den inn via Facebook og gir følgende beskjed Bandsintown will receive the following info: your public profile, friend list, address, current city, likes and music activity. Her får brukeren valgene Cancel og Okey. Brukeren får også oppgitt informasjon om at applikasjonen ikke vil publisere noe på Facebook. Brukeren kan også velge mellom «Upcoming» og «Local dates». Innholdet fra «bandsintown» kan deles via sosiale medier, «Facebook» og «Twitter». «Kontakt» inneholder informasjon om bedriften Tetriz Event & Management, samt en mulighet for brukere å sende inn bookingforespørsler. Når en ny forespørsel skal opprettes er det et krav at brukeren oppgir fornavn, etternavn og kontaktinformasjon i tillegg til ønsket dato. Det er frivillig for brukeren å inkludere beskrivelse og eventuelt budsjett. Detaljene vil deretter sendes på e-post til en forhåndsdefinert adresse og en backup vil lagres i databasen, slik at Tetriz kan behandle forespørselen. Muligheter og funksjoner som er mulig å benytte seg av for brukeren: I en kort oppsummering ser vi at brukeren har en rekke muligheter på nettsiden. Den kan lese nyheter, lese biografi, se bilder, se videoer, lese sangtekster (i dette tilfelle coverlåter), holdes oppdatert om konserter og kontaktinformasjon Særlige forhold Et særlig forhold i forbindelse med utfylling av skjemaer som må opplyses om er dato feltet i skjemaet for å opprette booking forespørsel. Dette input feltet bruker input typen date, dette vil gi den besøkende en kalender som gjør det enklere å velge dato, i skrivende stund er dette bare støttet av nettleserne Google Chrome, Opera og Safari se referanse nr Andre nettlesere som Mozilla Firefox og Internet Explorer vil vise et tekstfelt hvor den besøkende må skrive inn datoen selv. 1.3 Presentasjon CMS Ettersom vi skulle utvikle nettsiden fra bunnen av var det nødvendig å utvikle et tilhørende Content Management System. Dette systemet er utviklet fra bunnen av men er også inspirert av wordpress. Ettersom dette produktet har blitt lansert har vi lagt ut Produktdokumentasjon 78

79 en egen versjon med minimalt med innhold hvor det er mulig å navigere rundt i administrasjonsdelen se referanse nr Formål Formålet med administrasjonsdelen er å forenkle prosessen med å publisere nytt innhold, behandle brukerkontoer, og vedlikeholde nettsidens innhold. Uten at det skal være nødvendig å ha kjennskap til programmering og HTML syntaks. 1.4 Samkjøring mellom nettsiden og CMS For at nettsiden og administrasjonsdelen skal fungere sammen er det nødvendig å lagre dataene som er delt i mellom disse to, dette bruker vi databasen for å oppnå. Ettersom dette er en nettside som er utviklet for ett spesifikt formål, har vi opprettet databasetabeller for de forskjellige kategoriene på nettsiden. Vi spesifiserte også at nettsiden skal ha minimalt behov for å lagre data i denne databasen, og hovedsakelig skal ha funksjonalitet til å hente ut de nødvendige dataene ved behov. Data som kan lagres fra nettsiden er nye elementer i tabellen for mottakere av nyhetsbrev og nye elementer i tabellen for booking forespørsler. Administrasjonsdelen har funksjonalitet til å hente ut, lagre, endre og slette elementer fra databasetabellene, det er noen data som det ikke er mulig å endre, som for eksempel brukernavn. Det er også tilfeller der det ikke er mulig å lagre nye elementer som mottakere av nyhetsbrev og booking forespørsler. Det er i hovedsak ikke mulig å påvirke nettsiden direkte fra administrasjonsdelen og administrasjonsdelen fra nettsiden. Valg som har en direkte innvirkning på begge delene av produktet er valg av visningsspråk som deler mekanismen og variablene for oversettelser. Alle andre data må være lagret i databasen for at det skal være tilgjengelig på nettsiden og i administrasjonsdelen. Produktdokumentasjon 79

80 2 Utvikling Her vil vi forklare hvordan vi endte opp med det ferdige produktet, med brukt teknologi. 2.1 Teknologi Her tar vi for oss teknologien vi har brukt under utviklingen av produktet Apache server For å kunne ta i bruk php er det nødvendig med webserver som kan prosessere denne typen filer. Apache er en slik webserver og er i skrivende stund den mest utbredte webserveren på markedet i følge w3techs, se vedlegg 2-1. Denne webserveren er også den domeneshop bruker på serverne hvor oppdragsgiveren vår har leid serverplass. Det er også denne webserver typen vi er mest kjent med MySQL MySQL er et databaseadministrasjonssystem som er høyt utbredt. Det er dette databasesystemet som brukes av domeneshop, og gruppen har tidligere erfaring med å utvikle løsninger i PHP som tar i bruk MySQL for å lagre og hente data. Vi bruker dette for å lagre innhold som skal vises på nettsiden JavaScript JavaScript er et scriptspråk og er en implementasjon av ECMAScript. JavaScript utføres på klientsiden og vi bruker dette for å legge inn dynamiske elementer på nettsiden JQuery JQuery er et JavaScript bibliotek som er utviklet for å forenkle klientscript. Dette gjør det lettere å kode dynamisk funksjonalitet til nettsiden ettersom de vanligste oppgavene har egne funksjoner. For å kunne bruke JQuery må biblioteket må det inkluderes i html koden, her kunne vi velge å laste ned biblioteket og inkludere biblioteket fra lokal server alternativt kunne vi inkludere biblioteket av en CDN tilbyder, som lar andre nettsider inkludere innhold og elementer fra deres servere. Fordelen ved å inkludere biblioteket fra en lokal server er innlastingstiden for nettsiden, ulempen ved å ha biblioteket lokalt er at administratoren selv må vedlikeholde dette. Vi valgte derfor å bruke JQuery biblioteket som Google tilbyr utviklere, se referanse nr Produktdokumentasjon 80

81 2.1.5 AJAX Asynchronus JavaScript and XML en kombinasjon av Javascript og andre script og markup språk. Gjør det mulig å sende og motta post data til PHP uten å laste siden inn på nytt. Dette brukes på funksjonaliteten som lar brukere av produktet endre det aktive språket, og for påmelding til nyhetsbrev HTML5 Versjon 5 av HTML standarden, HTML er et markup language basert på XML versjon 5 har innebygget støtte for lyd og video elementer. HTML er høyt utbredt og den innebygde støtten for forskjellige medieformater i versjon 5 reduserer behovet for andre teknologier som flash PHP 5 Alle på gruppen har brukt PHP før og har god kjennskap til språket. PHP var ikke opprinnelig objekt orientert, dette ble implementert i språket senere. Språket er heller ikke strongly typed, noe som betyr at variabler kan skifte datatyper uten at det blir varslet XAMPP Git Programpakke for lokal server som støtter Windows, linux og OSX. Vi bruker denne pakken for å kunne utvikle lokalt på egne maskiner for å slippe å flytte filer mellom servere hver gang det blir gjort endringer. Versjonskontrollsystem utviklet for å gjøre det lettere å utvikle og holde kontroll på endringer av kode og versjoner. Vi har brukt Git levert av Bitbucket PHP PDO PDO står for PHP Data Objects, dette er en lett og konsis interface for å aksessere databaser. Vi har valgt å bruke PDO ettersom dette har støtte for flere typer databaser som er støttet av PDO driverne, se vedlegg 2-2 for en liste over tilgjengelige drivere. Poenget med PDO er at man laget et abstrakt lag, slik at man kan bruke den samme funksjonen på alle de forskjellige databasene så lenge de har PDO drivere, dette gjør at man kan bruke de på mange forskjellige databaser. PDO er inkludert i PHP 5.1 og nyere versjoner. Produktdokumentasjon 81

82 PDO bruker ACID, som står for Atomicity, Consistency, Isolation and Durability. Dette er måten de håndter transaksjoner på. Fordelen med dette er at SQL spørringene blir forberedt i forveien og alle endringene som skul utføres blir planlagt i forveien i en cache deretter når endringene skal utføres legges verdiene inn, dette gir en ytelsesforbedring med tanke på spørringer som blir utført ofte siden de allerede er planlagt og bare trenger verdiene. Det gjør også at det ikke er mulig å endre SQL spørringer med de nye verdiene som da omgår risikoen for SQL injection. For mer informasjon om PDO se referanse nr Databasen Fra starten av prosjektet var vi klar over at vi hadde behov for en database for å lagre nettsidens innhold, alternativet var å lagre innholdet i filer noe som er tungvint å vedlikeholde. Derfor startet vi å designe databasemodellen som skulle brukes, denne modellen måtte være fleksibel ettersom vi visste at det ville komme endringer senere, i tillegg måtte databasemodellen det være lettvint å hente ut, endre og lagre data. I løpet av utviklingen vokste databasemodellen og ble endret etter hvert som vi ble bedre kjent med det ønskede produktet, systembegrensninger, egne begrensninger og tidsbegrensninger Behov Vi startet med å identifisere de behovene vi hadde for databasen, ved å gå igjennom kravene vi hadde fått for nettsiden. Her valgte vi å bruke de grunnleggende kategoriene på nettsiden som tabeller, for deretter å sammenligne med andre nettsider for andre artister for å se hva som vanligvis ble lagret under de forskjellige kategoriene. Kategori Artist Biografi Diskografi Nyhetsbrev Behov Lagre artistnavn Lagre lenker til sosiale medier Indikere hvilket språk biografien gjaldt Lagre biografiteksten Angi om oppføringen var album, singel etc. Lagre tittel År utgitt Utgiver Annen informasjon Lagre e-post adresse Lagre mottakers navn Angi når mottaker meldte seg på Produktdokumentasjon 82

83 Artikler Brukere Bilder Fotografer Videoer Sangtekster Booking Kontakt Angi når mottaker meldte seg av En unik identifikator for artikler Angi når artikkelen ble publisert Angi hvilket språk artikkelen gjelder Tittel på artikkel Artikkelens hovedinnhold Brukernavn Passord + salt E-post Angi når bruker ble opprettet Logg innlogginger Mulighet for å tilbakestille passord Filsti detaljer for å finne bildefilen Angi hvilket år bildet ble tatt Angi hvem som tok bildet Fotografens navn Eventuell nettside for fotografen Videoens identifikator ved tjenesten som leverer videoen Angi hvilken tjeneste som leverer videoen for å kunne opprette embed kode Lokal tittel for videoen Når videoen ble lagt til URL/sti for miniatyrbilde for videoen Filnavnet til sangteksten Tittel som vises på nettsiden Angi når sangteksten ble lagt til Navn på person som ønsker å bli kontaktet Kontaktinformasjon Dato for arrangement Ønsket artist Bedrift som holder arrangement Budsjett Beskrivelse av arrangement Kontaktavdeling Kontaktperson Kontaktdetaljer Databasemodell utvikling Basert på behovene vi identifiserte opprettet vi en grunnleggende databasemodell, vist i figur 1, som bare besto av tabellene uten noen definerte koblinger, brukertabellene og Produktdokumentasjon 83

84 bildetabellene var et unntak fra dette ettersom vi her var sikre på at det måtte være koblinger mellom disse tabellene. Disse ble bare brukt til å visualisere hvilke tabeller som måtte være med avhengig av hvordan vi så for oss funksjonaliteten til produktet. Det var stor usikkerhet om hva som skulle lagres for kontaktsiden som gjorde at dette ikke ble inkludert i den figur 2-1. Figur 2-1 Grunnleggende databasemodell Ettersom nettsiden skulle ha støtte for Norsk og Engelsk valgte vi å holde tabellnavn og attributter på Engelsk for å unngå feilsituasjoner med norske spesialtegn som æøå. Den grunnleggende databasemodellen ble deretter brukt til å utvikle modellen som vist i figur 2-2. Produktdokumentasjon 84

85 Figur 2-2 Utkast databasemodell Med disse databasemodellene hadde vi definert at en database kunne holde informasjonen for flere forskjellige nettsider / artister. Vi hadde også definert hvordan kontaktinformasjon skulle lagres. Produktdokumentasjon 85

86 Vi fant fort ut at det var et dårlig valg å la flere nettsider dele en database for artistinformasjon og innhold ettersom dette ville øke risikoen for feil ved lagring og henting fra databasen i tillegg til at produktet ble unødvendig komplekst. Vi ville heller ikke ha tid til å teste ut dette godt nok. Dette førte til at vi omdefinerte hvordan nettsiden skulle forholde seg til databasen, slik at en database bare kunne gjelde for en nettside, og hvordan kontaktinformasjon skulle lagres Databasemodell ferdig versjon Figur 2-3 viser databasemodellen som brukes i det ferdige produktet, denne modellen setter følgende begrensninger. En database gjelder kun en nettside Glemt passord må manuelt endres av en administrator Personer som melder seg av nyhetsbrevet må manuelt fjernes fra databasen Ved å begrense hvor mange nettsider databasen har ansvar for trengte vi ikke å legge inn unødvendig komplisert funksjonalitet for å kontrollere hvilket innhold som hører til hvilken nettside. Begrensningen for glemt passord kom frem under utviklingen når vi definerte at brukerkontoer måtte opprettes av en administrator her hadde vi planlagt å utvikle en metode som opprettet en ny midlertidig lenke som logget brukeren inn og krevde at nytt passord ble satt, denne skulle deretter sendes til brukerens e-post adresse som ble gitt under brukeropprettingen, denne metoden var også tenkt å kunne brukes til tilbakestilling av passord. Vi implementerte ikke en løsning for dette ettersom vi ikke hadde tid til å teste dette grundig nok, og dermed ville risikere å implementere et stort sikkerhetshull. Begrensningen for avmelding av nyhetsbrev kommer av begrensninger satt av domeneshop, som begrenser e-post utsendelse til et begrenset antall pr. minutt, time og dag. Som gjør at nettsiden ikke kan sende ut nyhetsbrev, og dermed kan vi ikke opprette egne lenker for å melde av en mottaker. Dermed må oppdragsgiver selv bruke en tjeneste for utsendelse av nyhetsbrev og fjerne eventuelle mottakere som melder seg av. Lagring for kontaktinformasjon ble også gjort om til en tekstverdi, på denne måten kan brukeren som er ansvarlig for å oppdatere kontaktinformasjonen, selv velge hva slags informasjon skal legges ut på nettsiden i tillegg til å bestemme hvordan informasjonen skal formateres. Dette ble gjort etter flere omganger når det viste seg at vår første metode for å lagre kontaktinformasjon ikke var god nok, og vi ikke hadde fått noen indikasjon på hva slags informasjon skulle lagres her. Produktdokumentasjon 86

87 Figur 2-3 Databasemodell sluttversjon Produktdokumentasjon 87

88 2.2.4 Databasetabeller Den ferdige databasemodellen består av følgende tabeller. articles Field Type Null Key Default Extra articleid int(11) NO PRI NULL auto_increment websiteid int(11) NO MUL 1 lang char(3) NO NULL title varchar(100) NO NULL published datetime NO NULL edited datetime YES NULL maincontent text NO NULL biography Field Type Null Key Default Extra artistname varchar(45) NO PRI NULL lang char(3) NO PRI NULL biography text NO NULL booking Field Type Null Key Default Extra bookingid int(11) NO PRI NULL auto_increment artistname varchar(45) NO MUL NULL fname varchar(45) NO NULL lname varchar(45) NO NULL varchar(200) NO NULL phone varchar(20) NO NULL date date NO NULL company varchar(200) YES NULL budget varchar(15) YES NULL description varchar(2000) YES NULL contact Field Type Null Key Default Extra contactid int(11) NO PRI NULL auto_increment websiteid int(11) NO MUL 1 contactdetails text NO NULL Produktdokumentasjon 88

89 discography Field Type Null Key Default Extra disc_entry int(11) NO PRI NULL auto_increment websiteid int(11) NO MUL 1 type varchar(100) NO NULL title varchar(100) NO NULL year char(4) NO NULL publisher varchar(150) YES NULL images Field Type Null Key Default Extra imageid int(11) NO PRI NULL auto_increment websiteid int(11) NO MUL 1 photogid int(11) NO MUL NULL section int(11) NO NULL title varchar(100) NO NULL year year(4) NO NULL added datetime NO NULL directory varchar(800) NO NULL filename varchar(200) NO NULL lyrics Field Type Null Key Default Extra lyricid int(11) NO PRI NULL auto_increment websiteid int(11) NO MULL 1 filename varchar(150) NO UNI NULL title varchar(100) NO NULL added datetime NO NULL newsletter Field Type Null Key Default Extra websiteid int(11) NO MUL 1 varchar(200) NO PRI NULL phonenumber varchar(20) NO signedup datetime NO NULL photographers Field Type Null Key Default Extra photogid int(11) NO PRI NULL auto_increment fname varchar(45) NO MUL NULL lname varchar(45) NO NULL website varchar(200) YES NULL Produktdokumentasjon 89

90 userlog Field Type Null Key Default Extra loginid int(11) NO PRI NULL auto_increment userid int(11) NO MUL NULL logintime datetime NO NULL users Field Type Null Key Default Extra userid int(11) NO PRI NULL auto_increment websiteid int(11) NO MUL 1 groupcode int(11) NO NULL username varchar(45) NO UNI NULL password char(128) NO NULL salt char(128) NO NULL varchar(200) NO NULL created varchar(45) NO NULL videos Field Type Null Key Default Extra videoid int(11) NO PRI NULL auto_increment websiteid int(11) NO MUL 1 identifier varchar(20) NO NULL host char(2) NO NULL title varchar(200) NO NULL added datetime NO NULL thumbnail varchar(200) NO NULL websitedetails Field Type Null Key Default Extra websiteid int(11) NO PRI NULL auto_increment artistname varchar(45) NO UNI NULL websitetitle varchar(45) NO NULL booking varchar(200) NO NULL facebook varchar(200) YES NULL twitter varchar(200) YES NULL instagram varchar(200) YES NULL youtube varchar(200) YES NULL vimeo varchar(200) YES NULL Produktdokumentasjon 90

91 2.2 Mappestruktur Utvikling av produktet har blitt utført over flere iterasjoner, og har ubevisst fulgt et YAGNI (You aren t gonna need it) prinsipp hvor funksjonalitet og filstruktur har blitt implementert etter hvert som behovet har vist seg. Dermed har filstrukturen blitt endret flere ganger etter hvert som begrensninger og behov blir identifisert. Sluttresultatet kan ses i figur 2-7 og figur 2-8 lenger ned i teksten. Utviklingen startet uten noen spesielle former og regler for filnavn og mapper. Dette viste seg å være problematisk i forhold til å holde styr på hvilke filer som hørte sammen. Fordelen ved å utvikle på denne måten var at all grunnfunksjonalitet ble kodet slik at det var mulig å flytte filer og utføre endringer senere med minimalt med modifikasjoner, dette tok vi i bruk senere når vi planla den grunnleggende filstrukturen til produktet. Når vi hadde den grunnleggende funksjonaliteten og behovet for struktur viste seg satt vi oss ned og planla en grunnleggende filstruktur, denne filstrukturen kan ses i figur 2-4 denne var fokusert på å gi administrasjonsdelen en filstruktur ettersom nettsiden fremdeles var under utforming var vi klare på at filstrukturen senere ville endres. I denne fasen av utviklingen fikk også filnavn regler for hvordan de skulle utformes. Root en admin bootstrap logs core test Figur 2-4 Grunnleggende filhierarki Med den grunnleggende funksjonaliteten og det grunnleggende filhierarkiet utformet ble det lettere å få oversikt over hvilke filer som hørte sammen og utviklingen av administrasjonsdelen kunne begynne. Etter hvert som administrasjonsdelen ble utbrodert bestemte vi oss for å minimalisere størrelsen på rot-mappen endret vi filstrukturen slik at vi endte opp med hovedkategoriene install, admin, css og en. Mappen en var tenkt at skulle inneholde den engelske oversettelsen av nettsiden. Denne filstrukturen kan ses i figur 2-5. Produktdokumentasjon 91

92 Root Install admin CSS En Test Logs Core Bootstrap Config Class Panels Sections Include html Translations Figur 2-5 utvidet filhierarki Vi valgte å utføre denne endringen etter å ha sett på hvordan andre nettsteder hadde bygget opp sitt filhierarki, og ønsket å bruke top-down metoden, ettersom dette er en enkel og ryddig metode å organisere på. Dette gjorde det lettere for oss å bygge opp en mental modell av nettsiden samtidig som det ble enda lettere å holde styr på filer og mapper. Sections mappen plassert i core fikk en planlagt funksjonalitet for hvordan filer skulle bli inkludert og en skisse av denne funksjonaliteten kan ses i figur 2-6. Produktdokumentasjon 92

93 Figur 2-6 funksjonalitets skisse Etter hvert som administrasjonsdelen vokste og nettsiden begynte å bli klar for implementering hadde vi behov for å korrigere filstrukturen på nytt. I figur 2-5 hadde vi ikke tatt høyde for at nettsiden ville ha behov for mappen core og filstrukturen var ikke optimal for størrelsen av filsystemet vi hadde bygd opp. Vi ville også ha en struktur hvor nettsiden ikke skulle ha noe behov for å inkludere filer og mekanismer fra admin mappen, så vi bestemte oss for å oppdatere filstrukturen på nytt. Vi utviklet det ferdige filhierarkiet ved å ta i bruk mobiliteten til koden vi hadde utviklet og bestemte oss for å beholde de delene av den gamle filstrukturen som fungerte. Disse endringene var basert på filstrukturen som hadde gått igjennom en evolusjon. Med det ferdige filhierarkiet fokuserte vi på at administrasjonsdelen og nettsiden skulle være adskilt og at strukturen være ryddig og oversiktelig. Produktdokumentasjon 93

94 Bildene av det ferdige filhierarkiet har blitt delt opp i to deler av hensyn til plassbehov og for å visuelt vise at administrasjonsdelen og nettsiden er bygget opp forskjellig. Det må her opplyses at root mappen er den samme i begge bildene. Figur 2-7 viser hierarkiet brukt av administrasjonsdelen og figur 2-8 viser den grunnleggende strukturen hvor nettsiden er plassert. Figur 2-7 CMS-filhierarki Administrasjonsdelen har en filstruktur hvor en fil er ansvarlig for å inkludere de riktige filene avhengig av meny valg. Den overordnede filen for innloggede brukere er admin.php denne inkluderer panel filene fra mappen panels hvor main.panel.php inkluderer de riktige filene fra kategoriene i undermappen categories. Produktdokumentasjon 94

95 Figur 2-8 Nettside filhierarki Som figur 2-7 og figur 2-8 viser har vi beholdt deler av eldre filstrukturer, hvor noen av delstrukturene har blitt flyttet til andre plasseringer. Nettsiden er utviklet slik at det er mulig å utvikle en ny nettside ved å bare ta i bruk core mappen og opprette de nødvendige database tabellene. Filene som styrer det grafiske grensesnittet er plassert i root mappen og vil bare inkludere filer fra mappene som er vist i filstruktur base, mens administrasjonsdelen kan inkludere filer overalt fra root mappen. Denne filstrukturen gjør det også lettere å inkludere filer og bygge opp lenker. Innholdet til mappene er forklart i mappeinnhold. Produktdokumentasjon 95

96 2.2.1 Mappeinnhold Her tar vi kort for oss de forskjellige mappene som produktet vårt består av og innholdet til disse mappene. Root /includes /logs /js /fonts /decoration Denne mappen inneholder alle undermappene og filene - biography.php viser biografien til besøkende - concerts.php viser kommende konserter til besøkende - contact.php viser kontaktinformasjon for artistens mangaement - images.php viser bilder til besøkende - index.php forsiden til nettsiden - lyrics.php viser tilgjengelige sangtekster til besøkende - news.php viser nyheter til besøkende - videos.php viser innebygde videoer til besøkende - definitions.php inneholder navngitte konstanter som brukes på nettsiden. Inneholder de sidene som viser innhold til C-brukere, disse filene har oftest samme navn som filene plassert i root. Andre filer er head.php som inneholder <head></head> blokken, footer.php som inneholder footeren og newsletter.php som inneholder påmeldingsskjema til nyhetsbrevet. Denne mappen inneholder loggfilene som opprettes av feilhåndterer. Denne mappen inneholder scriptfiler for bootstrap, bildegalleri og egne javascript funksjoner Denne mappen inneholder fontfiler som følger med bootstrap Denne mappen inneholder bildefiler som brukes til dekorasjon på nettsiden, dersom man bytter ut en bildefil med et annet bilde med samme navn vil det nye bildet brukes. Inneholder - background-pattern.png bakgrunnsmønsteret brukt på nettsiden - carousel-image1.jpg bilde nr 1 som blir brukt i karusellen på forsiden - carousel-image2.jpg bilde nr 2 som blir brukt i karusellen på forsiden Produktdokumentasjon 96

97 /css /files /files/lyrics /files/images /core /core/class - carousel-image3.jpg bilde nr 3 som blir brukt i karusellen på forsiden - footer-logo.png logoen som brukes i footeren - logo-facebook.png sosialt medie ikon brukt i navigasjonsmenyen - logo-twitter.png sosialt medie ikon brukt i navigasjonsmenyen - logo-instagram.png sosialt medie ikon brukt i navigasjonsmenyen - logo-vimeo.png sosialt medie ikon brukt i navigasjonsmenyen - logo-youtube.png sosialt medie ikon brukt i navigasjonsmenyen - navbar-logo.jpg nettside logoen brukt i navigasjonsmenyen - tab-logo.png logoikon brukt i nettside fanen Inneholder CSS filer primært brukt av nettsiden for besøkende C-brukere, noen av css filene brukes også av admin sidene. Denne mappen inneholder undermappene lyrics og images. Det er ikke lagret noen filer direkte i files mappen. Sangtekstene som er tilgjengelig på nettsiden lagres i denne mappen. Alle filer som er av PDF format og lagret i denne mappen vil vises på forsiden. I denne mappen ligger standard bildet som brukes dersom bilder ikke har tilsvarende thumbnail. Det opprettes også automatisk undermapper her, navngitt etter året (ex. 2014) som igjen inneholder en undermappe navngitt etter måned (01-12) det er her bilder lagres. Bildemappen er laget slik for å unngå at for mange filer lagres i en mappe, noe som påvirker systemprestasjon. Det opprettes også egne mapper for thumbnails. Inneholder init.php som initialiserer globalt brukte variabler og objekter i tillegg til språk. Inneholder klassefiler, feilbehandler og databasetilkobling Produktdokumentasjon 97

98 /core/config Inneholder konfigurasjonsfiler for, databasetilkobling, database definisjoner, feilrapporterings e-post adresse, filter opsjoner og språk konfigurasjon. /core/translations Inneholder loadlanguage.php som er ansvarlig for å laste inn oversettelsesfilene som er lagret i undermapper. I teorien skal det være mulig å lage oversettelser for andre språk uten å gjøre store endringer i kode. /admin Inneholder CMS delen, med filene - index.php inneholder innloggingsskjema - login.php inneholder funksjonalitet for autentisering og avlogging - download.php funksjonalitet for å laste ned database innhold - admin.php hovedprogrammet for administrasjonsdelen - run.php ansvarlig for å laste inn init.php og ekstra variabler Admin mappen inneholder også mappene plugins, panels og css /admin/plugins /admin/css Her er tredjeparts programvare lagret, disse er tinymce som er en WYSIWYG editor (What You See Is What You Get) og elfinder (fil vindu som bare brukes i tekst editoren) Inneholder CSS stilark for administrasjonsdelen, disse filene brukes ikke andre steder. /admin/panels Inneholder filer for topp panelet, side panelet, brukerpanelet (dropdown meny i topppanelet) og hoved panelet (hvor verktøyene for kategoriene blir inkludert). /admin/panels/categories /install Inneholder kategori filene som blir inkludert i main.panel.php, disse er lagret i undermapper og navngitt etter kategori/underkategori. Denne mappen inneholder filer som oppretter database tabeller med nødvendig innhold. Når installasjonen er fullført skal denne slettes automatisk. Produktdokumentasjon 98

99 2.3 Navngiving Her tar vi for oss hvordan filer, mapper og variabler ble navngitt Mapper Under utviklingen av produktet har vi opprettet en mappestruktur hvor vi har skilt ut funksjonalitet, grensesnitt, filer og annet i forskjellige mapper avhengig av funksjonalitet og hvor de brukes i produktet. Mappenavnene har i stor grad vært avhengig av innholdet til mappene. Her har vi en oversikt over mappenavnene som er brukt, uavhengig av filstruktur og duplikater ikke tatt med. Core class config translations css js fonts decoration files images lyrics includes install logs admin panels categories plugins articles biography details discography artist booking contact media photographers videos newsletter users elfinder tinymce Vi har valgt å kalle mappen som inneholder kjernefunksjonaliteten til nettsiden for core ettersom dette er den Engelske oversettelsen for kjerne. Mappenavnene class, config og translations er også navngitt etter innholdet. Mappen class består av klassefilene, config består av konfigurasjonsfiler og translations består av oversettelser. Mappen translations består igjen av egne undermapper som er navngitt etter språkkode på tre tegn. Mappenavnene css, js og fonts er deler av bootstrap installasjonen som vi har brukt til grensesnittet, vi valgte å beholde disse navnene ettersom det er lett å forstå hva mappene inneholder, vi gjenbrukte mappenavnet css i admin mappen for stil av administrasjonspanelet. I likhet med bootstrap installsjonen har vi valgt å beholde mappenavnene for tredjeparts programvare elfinder og tinymce. Disse to mappenavnene er plassert i plugins mappen som har fått dette navnet ettersom det er tiltankt at eventuell annen tredjeparts programvare skal lagres her. Produktdokumentasjon 99

100 2.3.2 Filer Mappene Decoration og files består av mediefiler som brukes på nettsiden, forskjellen mellom disse mappene er hvor innholdet brukes. Filer plassert i decoration brukes til å dekorere nettsiden derav kommer mappenavnet, filer i denne mappen følger et navnemønster som forklares i Filer. Mappen files skal som navnet tilsier bestå av filer, disse filene er delt opp i to kategorier, bilder og sangtekster disse kategoriene er fordelt på undermappene images og lyrics. I mappen images opprettes nye undermapper etter hvert som bildefiler lastes opp, disse navngis etter året og inneholder igjen undermapper navngitt etter måned. Ved å navngi undermappene på denne måten gjøres det lettere å finne igjen bildefiler dersom man må finne igjen bildefilen på serveren, ettersom det bare er nødvendig å huske hvilket år, måned og filnavn bildet ble lastet opp med. Vi har også mappen includes som består av presentasjonsfiler som skal inkluderes, mappen logs, hvor alle loggfiler lagres, og mappen install som inneholder installasjonsveiviseren. Mappen admin har fått dette navnet ettersom administrasjonsdelen av nettsiden, CMS, er plassert i denne mappen. Mappen inneholder undermappene plugins, css og panels. Mappen panels inneholder filene for panelene og undermappen categories som igjen består av undermapper navngitt etter hvilken kategori de har funksjonalitet for, disse navnene samsvarer med sidemenyen i CMS. Vi opprettet et navnemønster tidlig, før mappestrukturen ble utarbeidet, for å kunne skille mellom filer som inneholdt klasser og filer som inneholdt konfigurasjon, grensesnitt og nødvendige variabler. Filer som er basert på ferdig kode følger navnene som original forfatter brukte. Filer som også er ment å være tilgjengelig gjennom URL har enkle navn basert på hvilken funksjon de har og hva de skal vise. Det tidligste navnemønsteret som ble brukt var filnavn.type.extension eksempelvis images.class.php ved å følge dette mønsteret kunne vi fort se hva filen omhandlet punktumet som skiller filnavnet fra type kunne også byttes ut med bindestrek. Dette ble brukt for å kunne lese eksempelet over som, en php fil innhold klassen Images, hvis det leses bakover. Navnemønsteret filnavn.type.extension fungerte ikke optimalt når det ofte ble gjort endringer i flere filer som hadde lik kode. Dette ble problematisk med CMS verktøyene hvor store deler av de forskjellige verktøyene hadde lik kode. Derfor opprettet vi et nytt mønster for verktøyfilene hvor vi navnga filene med type.funksjon.extension eksempelvis tool.add.php. Ved å følge dette nye navnemønsteret fikk vi en fordel ved at sortering av filene ville gruppere filer som var av samme type alfabetisk, og bruken av generelle navn ga oss også muligheten til å kopiere filene og modifisere koden, hvor vi før måtte modifisere filnavnet. Produktdokumentasjon 100

101 3 Utforming av grensesnitt Under dette punktet redegjør vi for hvordan vi har utformet grensesnittet, dette med tanke på veiledning i forhold til designprinsipper for nettsiden og administrasjonsdelen. Punkt 3.1 vil forklare mer om designprinsipper, punkt 3.2 vil ta for seg våre «valgte» designprinsipper opp mot administrasjonsdelen og nettsiden, før vi tar en kort oppsummering i punkt Designprinsipper Vi bestemte oss tidlig for å fokusere mye på design, da dette var et viktig krav fra oppdragsgiveren. Vi valgte totalt ni designprinsipper som vi mente passet best til vårt produkt. Det finnes flere forskjellige designprinsipper, men vi valgte å fokusere på disse fem: structure, simplicity, visibility, feedback og tolerance. Vi henviser med dette til referanse nr.2-5. I tillegg til dette ønsket vi å supplere med disse fire: consistency, affordance, control og constraints. Vi henviser til referanse nr Vi valgte å slå sammen tolerance og constraints, consistency og affordance da disse prinsippene omtaler mye av det samme. Ved å bruke disse syv designprinsippene som veiledning, var dette med på å skape et godt design og resultat. 3.2 Kort forklaring av våre valgte syv designprinsipper Structure Omhandler strukturen og organisering av innholdet. Simplicity Tar for seg at informasjonen som er tilgjengelig skal være relevant, samt tydelig og enkel å forstå. Visibility Prinsippet forteller noe om hvor synlig funksjonaliteten/mulige handlinger skal være. Feedback Omhandler hvorvidt brukeren får tilbakemeldingene, hva har blitt utført, feilmeldinger og eventuelt mulige handlinger. Tolerance og constraints Forteller noe om at man må ta høyde for hvordan systemet skal tolerere brukerfeil, og ta høyde for konsekvensene dette kan/vil medføre. Prinsippet forteller noe om hvilke handlinger brukeren er tillatt/ikke tillatt til å gjøre. Consistency og affordance Prinsippet tar for seg at designet skal være gjennomgående fra begynnelse til slutt. Tar for seg hvor enkelt det er for brukeren å forstå de ulike funksjonene og hvilke handlinger som kan løses. Produktdokumentasjon 101

102 Control Omhandler at brukeren raskt skal forstå hvem eller hva som har kontroll. 3.3 Designprinsipper i forhold til CMS og nettsiden Under dette punktet vil vi forklare mer om hvordan vi har fulgt designprinsippene. For ordens skyld vil vi kun gi noen eksempler på dette, ettersom det ville blitt svært kaotisk dersom vi skulle ramset opp alt Structure Designet bør organiseres målbevisst, noe som vi har jobbet med fra dag en i samråd med oppdragsgiveren. Vi mener selv vi har funnet en god struktur som presenterer innholdet på en god måte og som gir mening for brukeren. Vi har forsøkt å bruke konsistente modeller som skal være gjenkjennelig for brukerne, både når det gjelder administrasjonsdelen og nettsiden. Ved administrasjonsdelen ytret oppdragsgiver at han synes Wordpress hadde et godt design og gode løsninger, vi har derfor tatt noe inspirasjon derfra for å gi brukerne noe de kjenner til. I forhold til nettsiden har vi brukt et moderne design som ikke er ulikt andre nettsider, nok en gang for å gi brukerne noe de kan delvis gjenkjenne, samt fokusere på at strukturen skal være oversiktlig. Vi har tenkt igjennom plasseringer av de ulike elementene på nettsiden, slik at for eksempel under media finnes en dropdown liste med bilder, videoer og sangtekster, se figur 2-9. I administrasjonsdelen har vi i den venstrestilte menyen prioritert det vi tror er viktigst og som vil bli brukt mest, se figur Dersom en holder musepekeren over et valg i administrasjonsdelen, vil det vise seg de mulige handlingene for akkurat det alternativet, se figur Dette forsterker vår påstand om at vi har prøvd å opprettholde et skille på hva som hører sammen, og hva som ikke hører sammen. Dette gjelder også størrelser på tekst, fontvalg og fargevalg. Figur 2-9 Dropdown meny media Produktdokumentasjon 102

103 Figur 2-11 menyvalg med påfølgende alternativer Figur 2-10 Prioritert menyvalg Når det gjelder selve strukturen har vi vektlagt et lite hierarki, slik at brukeren ikke overstiger «tre-klikks-prinsippet». Dette betyr at brukeren ikke skal bruke mer enn tre klikk for å finne det den søker på nettsiden eller administrasjonsdelen. Vi har prøvd å følge dette prinsippet så langt det lar seg gjøre. Samtidig er det viktig at ikke brukeren blir overveldet av valg, men føler vi ikke det blir overveldende med seks «hovedvalg» på nettsiden, ni hvis vi skal telle med dropdown menyen, og syv valg i administrasjonsdelen. Vi henviser til figur 2-9 (nettsiden) og figur 2-10 (administrasjonsdelen). Vi mener alt i alt at vi har en meget ryddig og god struktur, som ikke vil overvelde brukeren Simplicity Dette prinsippet fokuserer på at de «vanlige» handlingen skal kunne utføres så enkelt som mulig, og være tydelig for brukeren hvilke alternativer den har. Språk og informasjon er viktig her, samt at det er intuitivt for brukeren. Vi har brukt mye tid på å bruke et gjennomgående, enkelt og tydelig språk både på nettsiden og administrasjonsdelen. Oppdragsgiveren ønsket også muligheten til å få språket på engelsk, noe vi har implementert. Vi har unngått å blande norsk og engelsk, selv om kanskje enkelte uttrykk hadde passet bedre på engelsk. Grunnen til at vi valgte dette og et enkelt språk er for at innholdet ikke skal bli tvetydig. Vi mener dette fører til at brukeren raskt vil forstå hvilke handlinger den kan foreta seg. Snarveier er noe vi har benyttet oss av, men vi har prøvd å gjøre disse meningsfulle, slik at dette kanskje vil være et enklere alternativ for brukeren. Et eksempel på dette er logoen til Tetriz Event & Management, som finnes nederst til venstre på nettsiden. Istedenfor at brukeren må skrive inn informasjonen den finner under «Kontakt», kan den velge denne snarveien eller linken i footer en under «KONTAKT OSS». Se figur 2-12 for å se denne snarveien. Et annet eksempel på dette er påmelding til Produktdokumentasjon 103

104 nyhetsbrevet, som brukeren kan gjøre allerede fra hovedsiden, istedenfor å navigere seg til «Kontakt», se figur Det samme ser vi i administrasjonsdelen, se figur 2-14, der det vises en snarvei for å komme til forsiden til administrasjonsdelen og en annen snarvei for å komme til nettsiden. Figur 2-12 snarvei tetriz.no Figur 2-13 snarvei, nyhetsbrev Figur 2-14 snarvei administrasjons forsiden og nettsidens forside (hus) Produktdokumentasjon 104

105 3.3.3 Visibility Det er viktig at både administrasjonsdelen og nettsiden har god synlighet når det gjelder ulike handlinger som kan utføres, og hvilket materiale som er tilgjengelig. Ved god synlighet gir vi brukeren alle forutsetninger om å kunne utføre ønsket handling og/eller inspisere ønsket materiale. Synlighet er viktig, men det må også vises på en god måte. Vi har derfor vektlagt at vi ikke skal synliggjøre unødvendig eller overflødig informasjon, på denne måten kan vi unngå at brukeren blir distrahert og/eller forvirret. Et godt design skal heller ikke overvelde brukeren med mange forskjellige alternativer, da dette kan føre til at brukeren ikke vet hvor den skal begynne. Vi mener selv at vi ikke har for mange alternativer, og refererer med dette til punkt Structure. I form av navigasjonsmuligheter har vi kuttet ut ytterligere to alternativer som skulle være med i toppmenyen på nettsiden. Vi forstod etter hvert at dette var alternativer som kunne slås sammen. Fargevalg er en vesentlig stor del av synlighet, der dette har blitt jobbet med hele veien og vi satt ikke endelige farger før slutten av april. Det har vært mye frem og tilbake med oppdragsgiver i forhold til dette, der vi til slutt kom fram til en form for enighet. Vi har implementer mesteparten av nettsiden i svart/grått og hvitt, fordi dette er svært brukervennlige farger og vil være synlige for alle brukere. Vi refererer til punkt 2.3 Nye kunnskaper i Prosessdokumentasjonen, punkt 8.1 Estetiske krav og Diskrimingerings og tilgjengelighetsloven i Kravspesifikasjonen. I administrasjonsdelen har vi brukt en supplerende farge, blå, for å vise «underkategorier»/«undervalg». På nettsiden har vi supplert med fargen oransje på knapper og når brukeren holder musen over linker. Vi har også bevisst valgt de ulike fontene, de er ikke så veldig «fancy» og moderne, men de er stilrene og lettleste. Se figur 2-15 for et skjermbilde av administrasjonsdelens fargevalg og fontvalg, figur 2-16 for nettsiden. Vi har bevisst bruk mørkere bakgrunn stort sett overalt med hvit tekst, fordi dette skal være enkelt for alle brukere å skille disse to fargene fra hverandre og det skal ikke være distraherende. Produktdokumentasjon 105

106 Figur 2-15 fargevalg og fontvalg administrasjonsdelen Feedback Figur 2-16 fargevalg og fontvalg nettsiden Dette viser viktigheten av tilbakemeldinger til brukeren. Ikke bare må brukeren bli informert over de handlingene den gjør, men også eventuelle feilsituasjoner som oppstår. Tilbakemeldinger skal også gis til brukeren om mulige handlinger den kan foreta seg, for eksempel hvor en link fører. Tilbakemeldingene skal bestå av relevant informasjon til brukeren, med et klart og konsist språk. Nok en gang er det viktig at ikke språket er tvetydig, slik at brukeren misforstår tilbakemeldingen. Vi har prioritert tilbakemeldinger da vi selv vet hvor frustrerende det er når man ikke får det. Et eksempel på feilmelding er dersom brukeren ønsker å melde seg på nyhetsbrev på hovedsiden, da må brukeren fylle ut e-post, dersom dette ikke blir gjort og brukeren trykker «Meld på», vil den få en feilmelding på at den må fylle ut feltet (der det blir pekt til e-post). Dette blir signalisert med et gult utropstegn, som er et klart tegn til brukeren om at noe er «feil». Vi henviser til figur 2-17, der brukeren kun har skrevet inn «eksempel», uten alfakrøll. Brukeren får også oppgitt hva den må gjøre for å kunne melde seg opp til denne tjenesten. Produktdokumentasjon 106

107 Figur 2-17 feilmelding input Et annet eksempel på tilbakemelding er når brukeren holder musepekeren over «Sett inn» når den skal legge til ny artikkel. Da gir administrasjonsverktøyet en respons på at brukeren holder musen over eksempelvis «Sett inn video». Da vil den få en klar tilbakemelding på at dette er et gyldig alternativ og brukeren kan velge å utføre handlingen. Se figur Tolerance og Constraints Figur 2-18 Sett inn video Designet skal være fleksibelt og tolerant, dette er ment for å redusere brukerfeil og misbruk av systemet. Både nettsiden og administrasjonsdelen er fleksible, men innefor de begrensningene vi og oppdragsgiveren har valgt. Vi henviser til punkt Feedback, der vi forklarte eksempelet om nyhetsbrev. Grunnen til at dette har blitt gjort er todelt, en bruker som gjør det bevisst og en som gjør det ubevisst. Den bevisste brukeren kan gjøre dette for å skape «kaos» i databasen ved å lage mange falske brukere, der e-postene ikke vil bli sendt noe sted ettersom den ikke har riktig adresse. Når det gjelder den ubevisste brukeren kan det hende den glemte å sette inn en alfakrøll, vet ikke den har gjort noe feil, og forventer å få nyhetsbrev tilsendt på e- Produktdokumentasjon 107

108 post. Dette ville gitt konsekvenser for brukeren, den ville aldri mottatt noe nyhetsbrev, og sannsynligvis ville dette vært til frustrasjon for brukeren. Dette understreker hvor viktig det er å gi brukeren muligheten til å angre eller forandre noe uten at dette får store konsekvenser. Et tolerant design bør forebygge feil, noe vi mener er mest relevant for administrasjonsdelen da dette kan føre til flere konsekvenser enn på nettsiden. En begrensning vi har satt i administrasjonsdelen er at skjemaene nekter å lagres dersom en ikke fyller ut de nødvendige feltene, se figur Et annet eksempel på en begrensning er dersom en bruker ønsker å slette en artikkel vil det bli bedt om bekreftelse på dette, se figur Dette gjelder alle former for sletting, som vi mener reduserer brukerfeil og konsekvenser av et galt tastetrykk. Figur 2-19 lagre skjema Figur 2-20 bekreftelse slett bruker Produktdokumentasjon 108

109 3.3.6 Consistency og affordance Tema, handlinger, tekst, tilbakemeldinger osv. bør være konsistent og følge både nettsiden og administrasjonsdelen fra begynnelse til slutt. Dette går på at samtlige prinsipper må følges hele veien, slik at alt får en fin «flyt» for brukeren. Når de har lært seg hvordan de foretar en handling, bør de enkelt kunne bruke samme fremgangsmåte for neste handling. Dette er noe vi har husket på ved utviklingen av disse funksjonene. For eksempel legg til nytt bilde i administrasjonsdelen, er så likt som overhodet mulig når det gjelder legg til ny video, se figur 2-21 og Poenget er ikke at det skal være helt likt, men samme metode, oppsett og struktur. Dette vil gjøre det lettere for brukeren å utføre handlinger den ikke har gjort før. Figur 2-21 legg til nytt bilde Figur 2-22 Legg til ny video Produktdokumentasjon 109

110 Språk, layout og design er også deler som skal være konsistent. Som nevnt i punkt Simplicity, er det viktig med et enkelt språk, men dette skal også være likt hele veien. I forhold til design nevnte vi noe om fargevalg i punkt Visibility, og det er viktig at disse fargene og fontene blir et gjennomgående tema på nettsiden og administrasjonsdelen. I tillegg vil vi nevne at oransje fargen er valgt fordi oppdragsgiveren bruker denne fargen på bedriftens nettside, som vil føre til at dette blir konsistent med tanke på artisten er under bedriftens management. Med en nettside som er konsistent vil gi et bedre brukergrensesnitt og gi brukerne en økt forståelse av hvordan ting virker, som igjen vil øke deres effektivitet i oppgavene de ønsker å løse Control Det skal være tydelig og enkelt for brukeren å forstå hvem eller hva som har kontrollen. I forhold til nettsiden er det tydelig hva brukeren får lov til å gjøre, noe som forsterker dette er tilbakemeldingene som blir gitt til brukeren på nettsiden. I administrasjonsdelen er det A-brukeren som har den fulle kontrollen og tillatelsen til å foreta all funksjonalitet som er tilgjengelig, mens B-brukeren har begrenset funksjonalitet. Et eksempel er at A-brukeren kan slette andre brukere, mens B- brukeren ikke har tilgangen til denne funksjonaliteten. Vi mener at kontroll oppnås ettersom det er en klar og tydelig oversikt over de ulike handlingene som kan bli utført, hvilken konsekvens og effekt disse vil medføre. Dette gjelder både for administrasjonsdelen og nettsiden. Spesielt med tanke på administrasjonsdelen er det viktig at brukeren forstår hva disse handlingene vil gjøre med nettsiden, ettersom administrasjonsdelen styrer nettsiden. Produktdokumentasjon 110

111 4 Kravspesifikasjon og produkt Under dette punktet vil vi gjøre rede for samsvar mellom kravspesifikasjonen og produkt, og eventuelle grunner til at vi måtte vike fra kravspesifikasjonen. Punkt 4.1 Kravspesifikasjonen og nettsiden, 2.2 Kravspesifikasjonen og CMS og punkt 2.3 Oppsummering av disse to. 4.1 Kravspesifikasjonen og nettsiden Oppdragsgiverens mest nødvendige krav var at vi skulle laget en nettside (basert på en av deres artister) som kunne brukes som en mal for andre nettsider (andre artister). Et viktig krav var også at oppdragsgiveren og dens ansatte, enkelt skulle kunne foreta forandringer på nettsiden. Med forandringer siktet oppdragsgiveren til innholdet på nettsiden, publikasjoner, opplastning av bilder, video osv. Et annet krav som kom etter prosjektet var i gang, var muligheten for nyhetsbrev. Når vi var over halvveis i prosjektet ytret oppdragsgiveren at den ønsket en slags underside «merchandise», der vi skulle legge inn produkter som kunne selges til fans. Oppdragsgiveren ønsket at vi skulle implementere en slags betalingsfunksjon, vi tok opp dette på et gruppemøte og konkluderte med at vi ikke hadde tilstrekkelig med kunnskaper og tid til å få til dette. Mye av begrunnelsen er tatt på grunn av sikkerhet. Vi har selv stilt ganske store krav når det gjelder brukervennlighet og generelt hvor intuitiv nettsiden og CMS skulle være. Alle valg som er gjort i forhold til designet er en slags sammenslåing av oppdragsgiverens krav og våre krav. Det er selvsagt viktig å gi oppdragsgiveren produktet som er «bestilt» / ønsket, men det er også viktig at vi forholder oss til hva vi har lært, og derfor skal fungere som «spesialister». Noen ting har vi vært nødt til å si nei til, som for eksempel automatisk avspilling av musikk på nettsiden, da vi vet av egne erfaringer og basert på brukerundersøkelser presentert i tidligere fag, at brukere ikke liker dette. Vårt hovedmål var at brukeren skal ønske å besøke nettsiden jevnlig, slik at oppdragsgiveren får et produkt som treffer målgruppen. I forhold til funksjonalitet mener vi at vi har truffet rimelig bra når det gjelder samsvar mellom kravspesifikasjonen og produktet. Produktdokumentasjon 111

112 4.2 Kravspesifikasjon og CMS Vi har i henhold til kravspesifikasjonen, oppretthold kravet om sidestruktur, som oppdragsiver ønsket og oppfylt dette Funksjonelle krav Opprettebrukere Deaktivere/slette brukere Responsiv på enheter Responsiv på nettleser Tilgjengelig på to språk Laste opp/publisere nyhetsartikkel Slette nyhetsartikkel Laste opp media Slette media Snarveier til sosiale medier Tilgang til å spille av video Validering av input Redigere nyhetsartikkel Prioritere nyhetsartikler Legge til/redigere video informasjon Legge til/redigere bilde informasjon Abonnere på nyhetsbrev Meldes av nyhetsbrev Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Nei Ja Ja Ja Nei Det er to krav som vi ikke har oppfylt i forhold til kravspesifikasjonen. Prioritere artikler Dette var en funksjon vi ikke fikk implementert i produktet, vi forsøkte å utvikle denne funksjonaliteten men måtte gi opp dette ettersom det tok for lang tid og vi ikke ville være i stand til å implementere løsningen med tiden vi hadde tilgjengelig. Melde av nyhetsbrev Ettersom vi ikke har noen funksjonalitet til å sende nyhetsbrev er vi heller ikke i stand til å opprette et system som oppdaterer eventuell ekstern tjeneste oppdragsgiver bruker for nyhetsbrev Ikke-funksjonelle krav Krav Nettsiden skal lett eksponeres God brukervennlighet på nettsiden og CMS Oppfylt Ja Ja Produktdokumentasjon 112

113 Intuitiv nettside og CMS Vedlikehold Nettsiden/CMS Håndtere Mange samtidig brukere Responsiv for innlasting Responsiv for spørringer Alle skal kunne bruke nettsiden Alle skal enkelt kunne lære seg CMS Ja Ja Ja Nei Ja Ja Ja Her er det ett krav som ikke har blitt oppfylt. Responsiv innlasting Dette ble ikke oppfylt ettersom produktet inkluderer elementer som er plassert på eksterne CDN servere. Dette gjør innlastingen av nettsiden tregere ettersom hver innlasting av nettsiden vil inkluderer innlasting av elementer fra for eksempel google. 4.3 Oppsummering Vi har tre krav som vi ikke oppfyller, disse er ikke kritiske for at produktet skal fungere. Vi mener at dette er innenfor det som er akseptabelt, ettersom responsiv innlasting var et krav vi satte til oss selv påvirker ikke dette det avtalte produktet i stor grad. For nyhetsbrev utviklet funksjonalitet som lar oppdragsgiver laste ned en fil som inneholder alle mottakere av nyhetsbrev, denne filen er mulig å bruke for å importere i dedikerte tjenester for nyhetsbrev. Angående prioritering av artikler ga vi tidlig beskjed om at dette sannsynligvis ikke ville være mulig for oss å implementere, på et senere tidspunkt vil det være mulig å implementere en løsning som muliggjør både sending av nyhetsbrev og for å prioritere artikler. Produktdokumentasjon 113

114 5 Beskrivelse av produktet 5.1 Sentrale datastrukturer i produktet Sentralt i produktet står databasen og mappen core i tillegg til definisjonsfilen, dersom man har disse elementene er det mulig å utvikle en ny nettside med tilsvarende funksjonalitet. Dette oppnås ved at all grunnleggende funksjonalitet og konfigurasjon for produktet er plassert i core mappen og definisjonsfilen mens innhold er lagret i databasen. 5.2 Produktets oppbygning Nettsiden sitt hovedprogram er CMS, der alt skal kunne bli regulert og styrt. Alle eventuelle endringer blir også styrt gjennom CMS. Noen endringer kan gjøres ved hjelp av «ren» koding, da er det flere tilgjengelige underprogrammer som kan bli brukt, eksempelvis Notepad++ og NetBeans. Vi ønsker å påpeke at dette er tilgjengelige programmer (programmeringsverktøy) som kan lastes ned gratis fra nettet, men dette er ikke noe vi har utviklet. Footeren på nettsiden er noe som må endres ved hjelp av koding, grunnen var og «låse» denne mer, ettersom det er enkelt å gjøre «fatale» endringer. Med «fatale» endringer mener vi at footerens design kan bli svært lite brukervennlig. En visuell fremstilling av nettsidens visuelle hierarki kan ses i vedlegg Nettsiden CMS Nettsiden er bygget opp slik at den primært henter nødvendige data fra databasen, det er også mulighet for å lagre nye data innen noen kategorier på nettsiden. Disse kategoriene er kontakt hvor besøkende kan registrere nye booking forespørsler og på forsiden hvor besøkende har mulighet til å melde seg på nyhetsbrev. Administrasjonsdelen av nettsiden er bygget opp slik at den kan hente nødvendige data, lagre nye data og slette data fra databasen. Her er det ikke mulig å registrere nye mottakere for nyhetsbrev og det er heller ikke mulig å opprette nye booking forespørsler. 5.3 Logging Det skal i denne delen ta for seg hvordan logging skal føres, dette gjelder genererte feil, av flere typer. Alle disse loggene blir loggført i egne filer som har sine respektive navn. De ligger alle i samme mappe kalt logs. Produktdokumentasjon 114

115 5.3.1 Errorhandler Dette er feilbehandleren, vist i figur 2-23, som behandler alle feil som oppstår på nettsiden, den behandler ikke fatale feil ettersom disse blir sendt etter at programutførelsen er stoppet. Oppgaven til errorhandler er å logge informasjon om feilene som oppstår, informasjonen som logges er tidspunkt når feilen oppstod, feilkode, feilmelding, hvilken fil feilen oppstod i og hvilken linje feilen oppstod på. Disse feilene blir lagret i /logs/error.log hvis ikke annet er spesifisert log_fatal Figur 2-23 Kodesnutt errorhandler Denne funksjonen kalles når PHP scriptet stopper, denne sjekker om feilen som har oppstått er en fatal feil, dersom dette er tilfelle så vil funksjonen log_fatal logge feilen og sende en melding til en forhåndsdefinert e-post adresse. Følgende informasjon blir logget og sendt, tidspunkt når feilen oppstod, feilmeldingen, hvilken fil meldingen gjelder og hvilken kodelinje feilen oppstod på. Figur 2-24 viser koden. Figur 2-24 kodesnutt log_fatal Produktdokumentasjon 115

116 5.3.3 Try Catch Alle metoder som utfører oppslag mot databasen har en try catch blokk som forsøker å utføre sin oppgave i try blokken, dersom en exception oppstår vil disse fanges opp i catch blokken hvor errorhandler blir tilkalt. Figur 2-25 viser try catch blokken som er brukt når produktet kobler til databasen. Her sender vi med detaljene som er lagret i exception objektet i tillegg til at vi spesifiserer hvilken fil feilen skal bli logget til, i dette tilfellet database.log. Informasjonen som blir sendt er den samme informasjonen som spesifisert i Errorhandler. 5.4 Sikkerhet Figur 2-25 kodesnutt try-catch Vi har forsøkt å utvikle et produkt som har fokus på sikkerhet, og dette har i tilfeller påvirket hvordan brukere for eksempel opprettes eller hvordan brukere må gå frem for å endre passord i tilfeller de har glemt passordet sitt Passord Behandling av passord er delt opp i flere metoder. Figur 2-26 kodesnutt salt-generator Figur 2-26 viser metoden som genererer en tilfeldig passord salt, denne metoden kalles hver gang et nytt passord opprettes og hver gang et passord endres. På denne måten får alle brukere et nytt passord salt som ikke er lik andre passord salter. Vi brukte openssl_random_pseudo_bytes til å generere tilfeldige bytes med en lengde på 64 bytes. Funksjonen har også en ekstra parameter som vi ikke har brukt, denne Produktdokumentasjon 116

117 parameteren gjør det mulig å teste om de tilfeldig genererte bytene er generert på en kryptografisk sikker måte. Vi bruker deretter bin2hex for å konvertere de binære dataene generert til en 128 tegn lang hex streng som vi lagrer i databasen. Figur 2-27 kodesnutt hash-password Figur 2-27 viser metoden som hasher passordene, denne metoden tar i mot to parametere passordet og det genererte saltet deretter hashes dette med sha512 som returnerer en 128 tegn lang hashet streng som vi lagrer i databasen. Når en bruker logger inn vil hash_password funksjonen kalles mens salt generatoren ikke vil kalles. I stedet vil innloggingsfunksjonen bruke brukernavnet til å hente ut det hashede passordet og salten for brukeren deretter hashes innloggingspassordet med salten og kontrolleres opp mot det hashede passordet som ble hentet fra databasen Registrering Registrering av nye brukere foregår ved at en administrator manuelt oppretter en ny bruker med verktøy tilgjengelig i administrasjonsdelen. Det vil ikke sendes noen detaljer på e-post til den nye brukeren, med andre ord må administratoren personlig gi den nye brukeren brukernavn og passord. Dette er resultatet av at vi ikke hadde tid til å utvikle et system som sender innloggingsdetaljene på en sikker måte, og vi ville heller ikke sende passord i klartekst over e-post Adgangsnivå Administrasjonsdelen har et enkelt adgangsnivå basert på brukernavn, passord og brukergrupper. For å få adgang til administrasjonsdelen må brukeren logge inn med brukernavn og passord. Funksjonalitet som kan fjerne innhold fra nettsiden vil selv kontrollere om den innloggede brukeren har tilstrekkelige rettigheter for å utføre endringer ved å sjekke hvilken brukergruppe brukeren tilhører. Dette skjer da med brukere, slik at menyvalget der man kan opprette og slette brukere ikke vises dersom den innloggede brukeren ikke er i gruppen med administrator rettigheter. Som vist i vedlegg 2-4 og vedlegg 2-5. Produktdokumentasjon 117

118 6 Forhold til funksjonelt grensesnitt I denne delen tar vi for oss det funksjonelle grensesnittet vi har hatt tilgjengelig for utvikling av produktet. 6.1 Maskinvare Maskinene som er brukt eies av domeneshop og blir leid av tetriz, vi har ikke tilgang til en komplett oversikt over oppsett og konfigurasjoner av maskiner som vårt produkt kjører på. 6.2 Lagringsplass Tilgjengelig lagringsplass på serverne for vårt produkt er 1GB, dette blir ikke noe problem i forhold til grunnsystemet som vi utvikler ettersom dette er primært tekstfiler og vi ser for oss at vi vil holde oss under 30MB. I lengden kan dette bli en utfordring for oppdragsgiver ettersom de kommer til å laste opp bilder og andre filer. 6.3 Operativsystemer Pr dags dato, , bruker domeneshop, Linux kernel versjon nr 2.6. Under utviklingen av produktet har dette ikke vært noe problem ettersom vi er kjent med hvordan linux systemer fungerer, og skal i hovedsak forholde oss til den installerte apache serveren og PHP versjonen. Produktdokumentasjon 118

119 5 Referanseliste 2-1. w3schools. (udatert). HTML5 Input types. Hentet 20. Mai 2014 fra Lenke demonstrasjon Google Developers (2014). Make the Web Faster. Hentet 20. Mai 2014 fra PHP. (udatert). PDO Manual. Hentet 20. Mai 2014 fra Wikipedia. (udatert). Principles of user interface design. Hentet 20. Mai 2014 fra Designing Interactive Systems, A Comprehensive Guide to HCI and Interaction design, David Benyon, Second edition, published 2010, s.90. Produktdokumentasjon 119

120 6 Vedlegg 2-1. Markedsstatistikk hentet 20. Mai 2014 fra Tilgjengelige PDO drivere hentet 12. Februar 2014 fra Driver name Supported databases PDO_CUBRID Cubrid PDO_DBLIB FreeTDS / Microsoft SQL Server / Sybase PDO_FIREBIRD Firebird PDO_IBM IBM DB2 Produktdokumentasjon 120

121 PDO_INFORMIX IBM Informix Dynamic Server PDO_MYSQL MySQL 3.x/4.x/5.x PDO_OCI Oracle Call Interface PDO_ODBC ODBC v3 (IBM DB2, unixodbc and win32 ODBC) PDO_PGSQL PostgreSQL PDO_SQLITE SQLite 3 and SQLite 2 PDO_SQLSRV Microsoft SQL Server / SQL Azure PDO_4D 4D Produktdokumentasjon 121

122 2-3. nettside hierarki 2-4. administrator grensesnitt 2-5. publiserer grensesnitt Produktdokumentasjon 122

123 Tetriz - Event & Management Artistnettside Testdokumentasjon Høgskolen i Oslo og Akershus Hovedprosjekt 2014 Gruppe 7 Jasmin Mehrnia, Joakim Kartveit, Frode Mathiesen, Gry Anita Nilsen

124 Forord Dette dokumentet forteller hvordan produktet har blitt testet underveis i utviklingen for å kvalitetssikre koden. Dokumentet tar også for seg brukertesting for å gi en ide om hvordan besøkende reagerer i forhold til nettsiden og med tanke på brukervennlighet. Dette dokumentet er ment for driftsansvarlig for bedre innsikt i hvordan systemet har blitt testet. Og for sensor for innsikt i hvilke tester vi har utført. Testdokumentasjon 124

125 Innhold Forord Formål med testing Testing Test klasser Fremgangsmåte Rapporter Resultater Test grafisk grensesnitt Test mobil enhet Konklusjon Brukerundersøkelse Sammendrag Innledning Metode Respondentene Intervjuguide Resultater Respondent Respondent Respondent Konklusjon Testdokumentasjon 125

126 1 Formål med testing Formålet med å utføre tester er å luke ut feil i programutførelsen så tidlig som mulig slik at det ferdige produktet utfører sine oppgaver som forventet uten feilsituasjoner som sluttbruker ikke er i stand til å rette. Testing gir også oss som utviklere bedre innblikk i hvordan programmet fungerer og gjør oss i stand til å utvikle produktet slik at potensielle feil i programutførelsen ikke blir trusler for produktivitet. 2 Testing 2.1 Test klasser Vi har i stor grad fulgt en testdrevet utvikling hvor aksepterte og ikke aksepterte verdier og datatyper blir brukt som inn parametere for metoder som krever inn parametere. Datatypene vi har brukt er integer, string, array, boolean, null og objekter. Verdier vi har brukt under testing har fulgt ikke godkjent format og godkjent format. På denne måten kunne vi se hvordan forskjellige datatyper og verdier påvirket programutførelsen og utbedre metodene for å unngå feilsituasjoner. Klassene og Klassenes metoder har blitt enhetstestet fortløpende under utvikling og når klassene har blitt ferdigstilt. Ved ferdigstilling har vi også testet hvordan metodene oppfører seg ved å lagre mange elementer i databasen fortløpende, disse testene ble utført ved hjelp av programmerte løkker Fremgangsmåte Måten vi gikk frem på under enhetstesting var at vi opprettet ett nytt PHP script Figur 3-1 viser et enkelt eksempel på hvordan testscriptet ble kodet, testene ble tilpasset etter hva slags funksjonalitet en gitt klasse hadde. Testdokumentasjon 126

127 Figur 3-1 testfil-mal Ved å ta i bruk var_dump for å skrive ut informasjon om retur variabelen fikk vi mulighet til å se hva slags datatype variabelen hadde og verdien som ble returnert vi brukte også kommentarer for å spesifisere hvilke parametere som var godkjent / ikke godkjent. I tillegg til å skrive ut informasjon om variabler la vi også inn meldinger i metodene som skulle skrives ut når programutførelsen kom til punkter, med klassemetoder der det var viktig å få mer informasjon om variabler og verdier som ble brukt internt brukte vi var_dump og i noen tilfeller satte vi inn stopp punkter i klassemetoden som stoppet all videre programkjøring. Testdokumentasjon 127

128 På denne måten fikk vi kontrollert at koden fulgte vår logikk og at resultater av funksjonskall returnerte forventede resultater. I tillegg til feilrapportering og logger ga disse testene oss mulighet til å utbedre kode. Testdokumentasjon 128

129 2.1.2 Rapporter Vi inkluderer bare to rapport-skjemaer av hensyn til dokumentets størrelse. Opprette bruker Parametere Funksjon Formål Metode Interne Funksjonskall Filer Forberedelser Prosedyre Resultater Kommentar Brukernavn Passord E-post gruppekode String String String Integer Opprette ny bruker med oppgitte parameter verdier. Identifisere feilsituasjoner ved oppretting av ny bruker. Users::create_user date( ) Users::generate_salt() Users::hash_password( ) /core/class/users.class.php /users.test.php Opprette users.test.php basert på testfil-mal med nødvendige modifikasjoner. Opprette variabler av forskjellige datatyper og med forskjellige verdier. Deretter opprette en ny bruker med de oppgitte parameterne. Og kontrollere returverdier, meldinger på skjermen, logger og lagrede database verdier. Det ble også automatisert bruker opprettelse for å kontrollere hvordan lagring i database oppførte seg ved oppretting av mange brukere. Disse oppføringene skulle senere brukes til å teste liste funksjonene. Ved bruk av ikke godkjente datatyper på passord parameteren vil Users::hash_password utløse feilmeldinger. Ved booleansk true vil metoden fortsette å opprette passord hash basert på generert salt. Denne testen hjalp oss også å finne en sikkerhetstrussel ved passord hashing under den automatiserte brukeropprettingen. Users::create_user( ) antar at alle inn parametere er validert og av forventet datatype. Den kontrollerer bare at nødvendige parametere ikke er tomme. Dette er gjort med vilje for at det skal være mulig å definere ved oppkall hvilke verdier som er godkjente. Testdokumentasjon 129

130 Filopplasting Parametere Funksjon Formål Metode Interne Funksjonskall Filer Forberedelser Prosedyre Resultater Kommentar Filarray Tittel År Seksjon Fotograf ID Array String String Integer Integer Flytte et opplastet bilde fra tmp katalog med detaljer lagret i filarrayet, opprette thumbnails og opprette ny database oppføring for bildet med de resterende parameterne. Identifisere mulige feilsituasjoner og identifisere mulige begrensninger i forhold til opplastingsskjema. Images::upload() empty( ) isset( ) is_string( ), is_int( ), is_numeric( ), is_array( ) preg_match( ) Images::valid_upload_array( ) Images::image_file_operations( ) Images::add_image_details( ) /core/class/images.class.php /core/class/resizeimage.php images.test.php Opprette images.test.php etter testfil-mal med nødvendige modifikasjoner, opprette et opplastingsskjema for opplasting. De første testene under utvikling gikk ut på å sende med parametre av forskjellige datatyper med forskjellige verdier. Deretter kontrollerte vi returverdier, meldinger på skjerm, logger og lagrede database oppføringer. Ettersom disse testene ble utført under utvikling opplevde vi feil med blant annet flytting av filer og oppretting av thumbnail versjoner i tilfeller der original bildene hadde høy oppløsning eller like størrelser på vidde og høyde. Testen viste også problemer med å behandle filer med UTF-8 filnavn ettersom dette ble utviklet på lokale servere på Windows plattform. Originalt var metoden en metode som validerrte inn parameterne og utførte alle operasjoner selv. Under testingen viste det seg at dette ble problematisk å feilsøke koden. Dette gjorde at vi omdefinerte funksjonaliteten til metoden til å fokusere på å validere inn parametere og skille ut fil- og database operasjoner. Testdokumentasjon 130

131 2.1.3 Resultater Ved å utføre testene kunne vi utbedre koden vi skrev for å ta høyde for situasjoner hvor inn parameterne kunne ha flere forskjellige formater. Figur 3-2 viser hvordan en av Videos klassens metoder så ut før testene hadde blitt utført. Figur 3-2 Denne metoden skulle i prinsippet ta i mot alle youtube støttede URLer og returnere en del av denne URLen som identifiserte videoen. Når vi utførte testene med URLer med varierende format viste det seg at blant annet youtu.be URLer ikke ble behandlet korrekt, dette førte til at vi endret metoden. Testdokumentasjon 131

132 Figur 3-3 Figur 3-3 viser hvordan den oppdaterte metoden ser ut. Den ferdige metoden ble endret til å returnere et array med video identifikatoren og en URL til video thumbnail som er lagret på youtube sine servere. Vi valgte å kode denne metoden slik for å ha tilsvarende funksjonalitet som vimeo alternativet. Et annet eksempel på når testingen hjalp oss å rette opp alvorlige feil er med Users klassen. I denne klassen har vi metoder som behandler passord her hadde vi en feil hvor alle passord ble lagret med den samme hashen denne feilen ble først oppdaget når vi automatiserte en prosess for å opprette en mengde nye brukere. Når vi oppdaget dette leste vi over koden på nytt og prøvde å rette opp i eventuelle feil, vi la også inn meldinger som sa hvilke deler som ble kjørt i tillegg til å skrive ut all informasjon om interne variabler. Ved å kjøre testen på nytt oppdaget vi at alle variabler hadde korrekte verdier det var bare hash-verdien som aldri ble endret dette gjorde at vi så nærmere på hash funksjonen vi brukte og oppdaget at vi hadde en skrivefeil når vi satte sammen to strenger. Hadde vi ikke testet disse metodene er det sannsynlig at vi ville levert et produkt som lot hvem som helst logge inn uten passord. Vi utførte også tester på Images klassen sammen med ResizeImage klassen som vi ikke utviklet selv her oppdaget vi to problemer som oppstod ved opplasting av bilder, disse oppstod når systemet forsøkte å lage en mindre versjon av bilder. Den første feilen vi fant var at bilder som hadde lik høyde og bredde ikke ble behandlet av ResizeImage klassen dette fikset vi ved å legge else if blokken gjengitt i figur 3-4 inn i ResizeImage metoden resizeto vi valgte å lage en helt ny blokk for å holde modifikasjoner separat fra den originale koden. Testdokumentasjon 132

133 Figur 3-4 Den andre feilen vi oppdaget var modifikasjoner på bilder med høy oppløsning ville bruke over 128MB internminne. Dette skapte problemer i forhold til serverhotellet som ikke tillater PHP script å bruke mer en 128MB internminne dette gjorde at vi så på andre alternativ til å kopiere bilder og endre størrelse på disse her var imagemagick et alternativ, vi valgte til slutt å beholde det eksisterende systemet ettersom alternativene også ville ha den samme utfordringen med høyoppløste bilder. Vi endte med å unngå denne feilen ved å regne ut hvor mye internminne som var nødvendig for å utføre de nødvendige operasjonene på et bilde, hvis et bilde ville kreve for mye internminne ville ikke thumbnail opprettes. Figur 3-5 viser koden som kontrollerer dette. 2.2 Test grafisk grensesnitt Figur 3-5 Testing av grensesnitt har blitt testet på desktop versjonene av Google Chrome 34.0, Opera 19 og 20, Internet Explorer 11 og Firefox 28 og Mobil enhet med Google Chrome På desktop versjonene tok vi i bruk de innebygde utviklerverktøyene og i firefox brukte vi i tillegg utvidelsen firebug som ble brukt under utvikling av javascript funksjonalitet. Vi har også testet det grafiske grensesnittet som c-brukerne har tilgang til fortløpende under utvikling, her brukte vi desktop versjonene av nettleserne og simulerte forskjellige oppløsninger ved å endre størrelse på nettleservinduet. Ettersom vi har brukt rammeverket bootstrap 3 til grensesnittet gikk testene våre her ut på å kontrollere at grensesnittet fremdeles så bra ut og at menyer, input skjemaer og lenker fungerte som forventet. Grensesnitt testingen ble utført ved manuelt å navigere rundt på nettsiden og fylle ut skjemaer. Testdokumentasjon 133

134 Under utviklingen av grensesnittet til CMS delen ble testene primært utført på Firefox 28 med firebug. Vi utførte tester med de andre nettleserne periodevis når ny funksjonalitet og endringer i grensesnittet ble implementert. Hovedfokuset med CMS delen var at systemet skulle fungere på de mest utbredte nettleserne for desktop Test mobil enhet Vi utførte test på grafisk grensesnitt med tilgjengelige mobile enheter Testrapport Enheten Tekniske detaljer Samsung Galaxy s4 OS: Android KitKat Skjermstørrelse: 5 tommer Skjermoppløsning: 1920x1080 Tilkobling: trådløs, ping10ms Ned:30Mbps Opp: 25Mbps Nettleser Google Chrome v34.0 Javascript v. v Gjennomføring Resultat Konklusjon Navigerer til nettsiden tilgjengelig for c-brukere Kontrollerer at grafisk grensesnitt oppfører seg som forventet og interagerer med alle navigasjonsknapper, lenker og input skjemaer. Kontrollerer også at nettsidens innhold er lesbart. Navigerer deretter til CMS delen logger inn og forsøker å interagere med de tilgjengelige verktøyene. Under testen av sidene tilgjengelig for c-brukere oppfører grensesnittet seg som forventet. Alle navigasjonsknapper fungerer og det er mulig å bruke input skjemaene. Under testen av CMS grensesnittet fikk vi et uventet resultat, ettersom vi på disse sidene bare har fokusert på støtte for desktop versjoner av nettlesere forventet vi at det ville være vanskelig å interagere med grensesnittet. Resultatet vi fikk her var et grensesnitt som tilpasset seg skjerm størrelsen og fortsatt hadde all funksjonalitet tilgjengelig. Dette resultatet var ikke helt uventet ettersom vi har utviklet dette grensesnittet for forskjellige skjermoppløsninger det som var uventet var at det fremdeles var lett å interagere med grensesnittet på en 5 tommers skjerm. Nettsiden for c-brukere oppfører seg som forventet på denne mobile enheten, og viste fordelene ved å basere grensesnittet på bootstrap 3 som er et mobile first rammeverk. CMS grensesnittet oppfører seg også bedre enn forventet med tanke på at det ikke var utviklet for mobile enheter. Det er også her tatt i bruk elementer fra bootstrap 3 men ikke i like stor grad som på nettsiden. Testdokumentasjon 134

135 3 Konklusjon Resultatene vi oppnådde var i noen tilfeller alvorlige feil som i noen tilfeller truet sikkerhet og i andre tilfeller gjorde noen operasjoner umulig å fullføre. Ettersom testingen vår gjorde oss oppmerksomme på disse feilene hadde vi mulighet til å utbedre koden. Det er fremdeles høy sannsynlighet for at det fremdeles finnes uforutsette feil i koden som først vil oppdages når flere bruker systemet ettersom det ikke er mulig for oss å utføre større tester med flere brukermønstre, men vi mener vi har oppnådd gode resultater med tanke på tiden vi har tilgjengelig og størrelsen på produktet. Testdokumentasjon 135

136 4 Brukerundersøkelse 4.1 Sammendrag Denne rapporten presenterer resultatene fra en brukerundersøkelse foretatt 14. mai Brukerundersøkelsen er tatt på målgruppen av nettsiden som er tilhengere av artisten mellom 8 til 16 år. Undersøkelsen er gjennomført med totalt tre ungdomsskole elever og viser følgende hovedresultater: Alle respondentene mente det var et godt valg å kunne bytte språk til engelsk Nyhetsbrev er en funksjon alle respondentene likte Mulighet til å se artistens neste konsert var veldig populært Det var ønskelig med billettbestilling til konsertene direkte via nettsiden 4.2 Innledning Gruppemedlemmene gjennomførte en brukerundersøkelse for å få frem hvor brukervennlig nettsiden er og for å få innspill fra målgruppen om innhold, design, samt konkrete forslag til forbedringer. I denne rapporten presenteres resultatene fra brukerundersøkelsen. Vi vil gjøre rede for hva nettsiden brukes til, målgruppens syn på innhold, navigasjon og design. 4.3 Metode For innsamling av data ble metoden semistrukturerte intervjuer brukt. Denne typen intervju kan beskrives som en samtale mellom forskeren og respondenten, hvor forskeren styrer samtalen. Det ble laget en intervjuguide for hva vi ønsket at respondenten skulle gi svar på. Vi ønsket å få frem hva intervjupersonene tenker om nettsiden. For å kunne gi respondentene mulighet til å svare litt åpent, har vi også valgt å bruke kvalitative intervjuer. Dette ble gjort bevisst, fordi vi ville få frem flere synspunkter enn kun de som kommer ved bruk av semistrukturerte intervjuer. Vi tok også opptak av intervjuene underveis, slik at vi hadde mulighet til å høre på dem flere ganger. Dette gjør det enklere for oss å bruke i analysen. Respondentene fikk tilbud om å få disse transkribert, men ingen ønsket dette. Testdokumentasjon 136

137 4.4 Respondentene Vi valgte å ta med både gutter og jenter i alderen 13 til 15 år. De fleste respondentene kjente til artisten fra før av og var tilhengere av artisten Daniel Johansen Elmrhari. Respondent 1 Respondent 2 Respondent 3 Kjønn Alder Kjønn Alder Kjønn Alder Kvinne 15 år Kvinne 13 År Mann 15 år 4.5 Intervjuguide Vi ba respondentene om å utføre noen enkle oppgaver etter at de hadde gjort seg kjent med nettsiden. - Naviger til nyheter fra forsiden uten å ta i bruk topp menyen. - Naviger ned til slutten av siden, for deretter å returnere til topp. Vi stilte respondentene følgende spørsmål under brukerundersøkelsen. 1. Hva synes du om designet og fargevalget på nettsiden? 2. Hva synes du om mulighet til å motta nyhetsbrev? 3. Hva synes du om mulighet til å laste ned sangtekster og bilder? 4. Hva synes du om muligheten til å se hvor artisten holder neste konsert? 5. Hva synes du om muligheten til å få nettsiden på Engelsk? 6. Hvordan ser du hvilken side du er på? 7. Er det noe du savner å ha på nettsiden? 8. Er det noe du mener kunne vært bedre? Testdokumentasjon 137

138 4.6 Resultater Respondent 1 Respondent synes designet og fargevalget er kjedelig. Hun mener nettsiden burde vært mer preget av farger. Hun sier at hun liker de sosiale medier knappene øverst til høyre i menyen. Det at det er mulighet for å bytte språk til engelsk på nettsiden, var noe hun mente var et godt valg. Det at brukeren får mulighet til å melde seg på nyhetsbrev var noe respondenten var veldig fornøyd med. Hun mente dette var bra fordi man da får mulighet til å følge med på eventuelle nyheter og motta dette per mail. Respondenten likte at man kunne laste ned bilder og sangtekster. Hun tror det er noe tilhengerne av artisten kommer til å sette pris på, i og med at mange ønsker å bruke bilde av han som bakgrunnsbilde for eksempel. Det at man har mulighet til å se hvor artisten holder neste konsert var noe respondenten var veldig fornøyd med. Hun synes det var fint at man har mulighet til å holde seg oppdatert ved å gå inn på nettsiden til artisten og se hvor og når neste konsert holder til. Når respondenten får beskjed om å finne nyheter andre steder enn på menyen, navigerer hun direkte til nyhetsdelen under karusellen, så trykker hun automatisk på knappen hvor det står flere nyheter. Hun fant også ut at man kan trykke på nyheter knappen på karusellen. Når vi forklarte at man kan trykke på tekstboksen under karusellen ble hun overrasket og syntes det var kult. Dette var noe hun ikke mente var selvforklarende, men etter at vi viste henne muligheten syntes hun det var en god ide. Respondenten får beskjed om å navigere seg helt nederst på nettsiden for deretter å returnere til topp. Respondenten scroller helt ned og når vi ber hun returnere til topp så bruker hun musen til å scrolle. Vi forteller om funksjonen return-to-top og når hun først legger merke til pilen, synes hun det er en god ide. Vi spør respondenten om hvordan man kan se hvilken side man er på, hun forteller raskt at det ser man fordi teksten i menyen er fremhevet med en oransje farge, samt at knappen har en litt mørkere farge enn resten av menyen. Respondenten sier det ikke er noe hun savner på nettsiden. Men en nettbutikk med Merchandise produkter hadde vært kult. Hun sier også at det hadde vært veldig greit om man kunne bestilt konsertbilletter direkte fra nettsiden. Respondenten mener det ikke er behov for endringer på nettsiden. Eneste hun var misfornøyd med er fargevalget. Testdokumentasjon 138

139 4.6.2 Respondent 2 Respondenten kjenner godt til artisten og er stor tilhenger av Daniel Johansen Elmrhari. Respondenten var meget fornøyd med designet på nettsiden og mener den er veldig lik Apple sin forside. Hun likte at vi brukte grått som en kontrast, samt at hun komplimenterte karusellen på hovedsiden. Som tilhenger av artisten synes respondenten at det å motta nyhetsbrev er noe hun absolutt hadde benyttet seg av. Hun mener det er en kjempe god ide å gi fansen mulighet til å motta nyheter per mail. Respondenten er veldig glad for å kunne laste ned bilder og sangtekster. Hun synes det er fint å kunne få de i originale filstørrelser enn å hente bilder fra Google med dårlig kvalitet. Hun mener at det kanskje ikke er like nødvendig å laste ned sangtekster, men at det heller hadde vært bedre om man kunne se sangtekstene direkte på nettsiden. Det at man har mulighet til å se hvor artisten holder neste konsert var noe respondenten satte veldig pris på. Hun mente at dette var noe hun hadde benyttet seg mye av og som en fan av artisten er det moro å kunne se hvor og når han holder konserter. Respondenten sier det er kult at man kan ha nettsiden på engelsk også, men i og med at dette ikke er så relevant for hun så har hun ingen andre kommentarer å komme med. Når respondenten får beskjed om å gå inn på nyheter andre steder enn via menyen, går hun automatisk på nyheter gjennom karusellen. Når vi ber henne trykke andre steder enn på karusellen, trykker hun på tekstboksen under karusellen hvor man også kan lese siste nytt. Respondenten navigerer seg nederst på nettsiden og når hun får beskjed om å navigere seg tilbake til topp, trykker hun automatisk på return-to-top pilen. Respondenten får beskjed om å svare på hvordan man kan se hvilken side man er på og gir samme svar som respondent 1. Hun sier også at man ser det ved at teksten er fremhevet med en oransje tekst og linje, samt at boksen rundt er i en mørkere farge enn resten av menyen. Respondenten savner ingenting på nettsiden og mener at alt ser veldig bra ut. Hun ønsker heller ikke å forbedre noe. Testdokumentasjon 139

140 4.6.3 Respondent 3 Respondenten er en gutt på 15 år. Han har ikke så god kjennskap til artisten fra før av, men vi ønsket også at en som ikke var tilhenger av artisten til å vurdere nettsiden. Som fan blir man kanskje litt blind, derfor ønsker vi også å se hva slags resultater vi fikk ved å brukerteste på en som ikke kjenner til artisten. Respondenten synes designet og fargevalget er moderne. Nettsiden virker ryddig og oversiktlig. At man har mulighet til å motta nyhetsbrev er noe respondenten liker, fordi man har mulighet til å følge med på hva som skjer. Respondenten synes det er bra at man kan laste ned bilder og tekst. Han mener dette er noe tilhengere av artisten sikkert setter pris på. Det at man kan se hvor artisten holder neste konsert er noe respondenten liker veldig godt. Han synes det er gøy at man kan se om artisten holder konsert i nærheten. Respondenten mener at man burde hatt mulighet til å bestille billettene direkte gjennom nettsiden til artisten. Respondenten mener at det er kjempe bra at man kan få nettsiden på engelsk med tanke på tilhengere i andre land. Respondenten får beskjed om å gå inn på nyheter andre steder en gjennom menyen. Han går direkte til tekstboksen under karusellen og trykker på knappen Flere nyheter. Når vi spør om det er andre steder man kan gå inn på nyheter og respondenten trykker på tekstboksen. Respondenten får beskjed om navigere seg helt nederst på nettsiden for så å returnere til topp. Han legger straks merke til return-to-top pilen. Respondenten trykker på den øyeblikkelig. Respondenten blir spurt om hvordan han kan se hvilken side han er på og han svarer raskt at han ser det grunnet den fremhevede teksten og den oransje linjen under. Respondenten sier at han ikke savner noe på nettsiden. Han synes den virker ryddig og oversiktlig, samt at det er enkelt å finne frem til ønskede sider. Testdokumentasjon 140

141 4.6.4 Konklusjon Resultatet av brukerundersøkelsen viser at de fleste respondentene er fornøyd med designet og fargevalget på nettsiden. En av respondentene mente nettsiden var litt kjedelig og kunne tenke seg mer farger. Det kom også frem i brukerundersøkelsen at alle respondentene likte muligheten til å kunne melde seg på nyhetsbrev. Alle respondentene mener at funksjonen bands-in-town, hvor man kan se artistens neste konsert er en meget god ide. Vi ser etter brukerundersøkelsen at de fleste ønsker seg mulighet til å bestille billetter til konsertene direkte på nettsiden. Dette hadde vært en god løsning, men det er ikke noe vi får implementert inn. Når respondentene får spørsmål om hvordan man ser hvilken side man befinner seg på, svarer alle raskt at det ser man ved å se på den fremhevede teksten, samt den oransje linjen under teksten. Respondentene utførte noen enkle oppgaver, slik at vi får en oversikt over brukervennligheten på nettsiden. Alle respondentene fullførte oppgavene og det kom frem at én respondent ikke brukte return-to-top funksjonen for å returnere tilbake til topp. Alle respondentene er fornøyde med nettsiden og sier det ikke er noe de ønsker å forbedre eller forandre. Det virker som nettsiden er brukervennlig og intuitiv etter å ha sett på resultatene av brukerundersøkelsen. Folk er forskjellige og ønsker derfor forskjellige ting, for noen vil designet virke kjedelig, men det virker som de fleste er relativt fornøyde. Vi har tatt til oss noen av tilbakemeldingene og vil videreføre dette til oppdragsgiver, slik at han har mulighet til å ta noen av forslagene opp til vurdering om det skulle være ønskelig i fremtiden. Testdokumentasjon 141

142 Tetriz - Event & Management Artistnettside Brukerveiledning Høgskolen i Oslo og Akershus Hovedprosjekt 2014 Gruppe 7 Jasmin Mehrnia, Joakim Kartveit, Frode Mathiesen, Gry Anita Nilsen

143 Forord Dette dokumentet er ment for driftsansvarlig, publiserer og administratorer som skal bruke produktet. Denne manualen tar for seg Content Management System delen av produktet, heretter referert til som administrasjonsdelen. Manualen dekker ikke all tilgjengelig funksjonalitet i dybden, og vil derfor fokusere på å gi leseren en forståelse av oppbygningen, navigering og bruk av administrasjonsdelen. Manualen tar utgangspunkt i at leseren har grunnleggende datakunnskaper. Brukerveiledning 143

144 Innholdsfortegnelse Forord Innledning Hoveddel Menykategorier Innlogging Administrasjonssiden Brukere Artikler Bildeopplasting Legge til fotografer Legge til sangtekster Legge til video Nyhetsbrev Kontakt Booking Feil og rettingsmuligheter Installering Vedlikehold Utvidelse og modifisering Brukerveiledning 144

145 1 Innledning Administrasjonsdelen av produktet er publiseringsverktøyet tilhørende artistnettsiden. Formålet med verktøyet er å gjøre det enklere å publisere og vedlikeholde innholdet på nettsiden uten å ha god kjennskap til programmering. Noen vanlige oppgaver administrasjonsdelen er utviklet for å oppfylle er: legge ut nyheter legge til media oppdatere biografi og diskografi behandle brukerkontoer Administrasjonsdelen krever at JavaScript er aktivert, for å kontrollere at JavaScript er aktivert og for veiledning om hvordan du kan aktivere JavaScript i nettleseren kan du besøke 2 Hoveddel For å navigere til administrasjonspanelet kan du trykke på "Logg Inn" lenken i footeren. Administrasjonsdelen er delt opp i flere kategorier, disse kategoriene er tilgjengelig gjennom sidemenyen. 2.1 Menykategorier Booking Under er det lagt til en oversikt over kategoriene tilgjengelig i sidemenyen. Kategoriene som har et ekstra innrykk er tilgjengelig i dropdown menyer. Brukere Artikler Artist Artistdetaljer Diskografi Biografi Media Bilder Sangtekster Videoer Nyhetsbrev Kontakt Brukerveiledning 145

146 2.2 Innlogging Ved innlogging vil et panel vises, se figur 4-1, her kan du velge språket som skal brukes i grensesnittet. Støttede språk er Norsk og Engelsk. Brukernavn og Passord feltene må fylles ut med ditt brukernavn og passord. Ved å trykke på "Logg inn" knappen vil systemet kontrollere brukernavnet og passordet samt videresende til administrasjonsdelen. Ved å trykke "Avbryt" vil systemet navigere tilbake til nettsidens forside. Figur 4-1 Dersom en bruker har glemt passord må en administrator manuelt sette nytt passord. 2.3 Administrasjonssiden Etter å ha logget inn på administrasjonssiden vil systemet vise administrasjonshovedsiden, se figur 4-2. Brukere som ikke er administrator vil ikke se "Brukere" valget i sidemenyen. Brukerveiledning 146

147 Figur 4-2 Denne siden vil vise snarveier til handlinger for «Artikler», «Bilder», «Videoer» og «Sangtekster». Administrasjonssiden er delt opp i tre paneler Topp-panelet Sidepanelet Hovedpanelet Topp-panelet Topp-panelet i figur 4-3 er plassert i toppen og vil ikke bli endret under navigering i administrasjonssidene. Figur 4-3 Ved å trykke på dette ikonet vil du bli navigert tilbake til hovedsiden for administrasjonssidene. Ved å trykke på dette ikonet vil brukeren bli navigert til forsiden for nettsiden. Dropdown meny for valg av språk. Dropdown meny for brukerens handlinger. 'admin' vil byttes ut med den innloggede brukerens brukernavn. Brukerveiledning 147

148 2.4 Brukere Kategorien er bare tilgjengelig for administratorer, med unntak av "Din Profil". Handlinger Figur 4-4 Vis alle Legg til ny Din profil Viser alle opprettede brukere med unntak av den innloggede brukeren Viser et skjema for å opprette en ny brukerkonto Viser egne opplysninger med mulighet til å endre detaljer. Også tilgjengelig gjennom topp-panelet. Brukerveiledning 148

149 2.5 Artikler Handlinger Figur 4-5 Vis alle Legg til ny Slett markerte Viser en liste over alle publiserte artikler. Ved å trykke på Vis Engelsk eller Vis Norsk kan listen avgrenses til artikler på valgt språk. Viser verktøy for å skrive nye artikler Vil slette alle artikler som er krysset av i artikkel listen. Bare administratorer har tilgang til dette. Ved å trykke på en artikkel vil den åpnes i det samme verktøyet som ble brukt til å opprette den, beskrevet i Legg til ny Legg til ny Når en ny artikkel skal legges til vises følgende skjema Brukerveiledning 149

150 2.6 Artist Figur 4-6 Her må det velges hvilket språk artikkelen er skrevet på i tillegg til at det må skrives inn en tittel. Systemet bruker TinyMCE som teksteditor for hovedinnholdet av artikkelen, det er her mulig å formattere innholdet og legge til bilder. NB! Bilder må legges til på serveren gjennom Media/Bilder før de er tilgjengelig for editoren. Ved endring i tidligere publisert artikkel vil valget for språk være deaktivert. Artistdetaljer kan endres i kategorien Artist. Brukerveiledning 150

151 Figur 4-7 Artistnavnet kan endres av administratorer. Sosiale media ikoner på navigasjonspanelet vil bare vises dersom det tilhørende feltet ikke er tomt. Sosiale medier feltene aksepterer bare URL-er og disse må starte med "http//" eller " For å slette en lenke er det bare nødvendig å tømme innholdet i det ønskede feltet og trykke "Lagre". Ved å trykke "Avbryt" vil alle endringer som ikke er lagret bli tapt. Artist Biografi Diskografi Forsiden for kategorien artist, inneholder skjemaet som vist over. Verktøy for å oppdatere Artistens biografi, åpner forhåndsvisning av Biografien. Verktøy for å legge til og fjerne oppføringer for diskografien. 2.7 Media Ved navigering til media kategorien hovedpanelet vise snarveiene vist i figur 4-8. Brukerveiledning 151

152 Figur 4-8 Dette er forsiden til media kategorien, og inneholder snarveier til underkategorienes handlinger. Ved å velge en av vis handlingene for bilder og videoer vil mediefilene vises som vist i figur 4-9. velger du vis handlingene for sangtekster eller fotografer vil oppføringene vises som i figur Figur 4-9 Brukerveiledning 152

153 Figur 4-10 Det er mulig å trykke på disse oppføringene i listen, systemet vil da åpne et skjema som viser mer informasjon om oppføringen i tillegg til mulighet for å endre detaljer Bildeopplasting Figur 4-11 Figur 4-11 viser bilde opplastingsskjemaet, her er det mulig å opprette en ny fotograf ved å krysse av "Legg til ny fotograf". Det vil da vises felter som må fylles ut for informasjon om fotografen, se figur Alternativt er det mulig å velge en eksisterende fotograf ved å krysse av velg fotograf. Det vil da vises en liste hvor alle eksisterende fotografer er listet opp. Brukerveiledning 153

154 Det må fylles ut en tittel, og år må velges. I tillegg må bildeplasseringen velges, her er alternativene "Media" og "Diverse", bilder lagt i bildeplasseringen "Media" vil vises til besøkende av nettsiden under kategorien media. Bilder plassert i diverse vil ikke vises på nettsiden for besøkende, men vil være tilgjengelig for bruk i artikler. Til slutt må bildefilen velges, her er det anbefalt å bruke bilder som er mindre enn 4500piksler høye / brede Legge til fotografer Figur 4-12 Figur 4-12 viser skjemaet som vises når ny fotograf skal legges til, her er det bare fornavnet og etternavnet som må fylles ut. "Nettside" feltet er valgfritt, merk at dette feltet bare aksepterer URL-er som starter med " eller " Brukerveiledning 154

155 2.7.3 Legge til sangtekster Figur 4-13 Figur 4-13 viser skjemaet som vises for opplasting av ny sangfil, her må tittelfeltet fylles ut og en fil må velges. Bare PDF filer vil bli akseptert Legge til video Figur 4-14 For å legge til en ny video må tittelfeltet fylles ut og URL-feltet må inneholde en URL fra Youtube eller Vimeo. Brukerveiledning 155

156 2.8 Nyhetsbrev Figur 4-15 Kategorien for nyhetsbrev vil vise en liste over alle som har meldt seg på nyhetsbrevet, disse må slettes manuelt av en administrator. Det er mulig å laste ned en fil som kan åpnes i Excel ved å trykke på "Last ned CSV", denne filen er det også mulig å bruke til å importere nyhetsbrevlister i eksterne leverandører for nyhetsbrevtjenester. 2.9 Kontakt Kategorien for kontakt vil vise en forhåndsvisning av kontaktdetaljene som er lagret for nettsiden, se figur Brukerveiledning 156

157 Figur 4-16 Det er mulig å endre disse detaljene ved å trykke på "Endre" da vil det åpnes en teksteditor, vist i figur 4-17, hvor du kan legge til og formatere kontaktinformasjonen etter eget ønske. Figur 4-17 Brukerveiledning 157

158 2.10 Booking Figur 4-18 Figur 4-18 viser listen booking forespørsler vises i, ved å trykke på en oppføring i listen vil flere detaljer vises om en forespørsel, se figur Her er det mulig å sende forespørselen på nytt til e-post adressen som er satt opp til å motta booking forespørsler og administratorer har mulighet til å slette gamle forespørsler. Figur 4-19 Det er også mulig å endre hvor booking forespørsler blir send ved å trykke på innstillinger, da vil skjemaet vist i figur 4-19 vises. Brukerveiledning 158

159 3 Feil og rettingsmuligheter Figur 4-20 I alle situasjoner hvor et input felt må fylles ut vil det ikke være mulig å lagre ny/endringer. Det vil da vises en melding tilhørende input feltet som indikerer hva som mangler. Når man skal opprette en ny brukerkonto for eksempel og glemmer å skrive inn et felt vil det vises en melding som vist i figur Installering Figur 4-21 Vi har opprettet en installasjonsprosedyre for nettsiden. Brukerveiledning 159