HOVEDPROSJEKT. Windows Phone 7 TV-Guide. TV-Guide. Windows Phone 7. App

Transkript

1

2

3 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Lukket Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Windows Phone 7 TV-Guide DATO ANTALL SIDER / BILAG 139/1 PROSJEKTDELTAKERE Alexander Backløf Barve Hans Petter Naumanm Vegard Nyeng Kristofer Selbekk s s s s INTERN VEILEDER Thomas Sødring OPPDRAGSGIVER BEKK Consulting AS KONTAKTPERSON Dan Robert Ekrem SAMMENDRAG Applikasjonen er en TV-guide - et hjelpemiddel som skal bidra til å forenkle planlegging av tv-kvelden for sluttbrukeren og andre tvtittere, i tillegg til å øke kundens salg av filmleietjenester. Applikasjonen er utviklet for Get AS i samarbeid med konsulentselskapet BEKK Consulting AS. 3 STIKKORD TV-Guide Windows Phone 7 App

4

5 Forord Denne rapporten er satt sammen av all dokumentasjon gjort i forbindelse med hovedprosjekt i informasjonteknologi ved Høgskolen i Oslo, våren Prosjektet er utført for Bekk Consulting AS, som også stilte med ulike veiledere. Valget falt på dette prosjektet da vi alle var interresert i å lære om teknologiene rundt mobilapplikasjon-utvikling. Rapporten er delt inn i selvstendige deler: prosessrapport, produktrapport, kravspesifikasjon og testrapport. Brukermanual følger ikke med da oppdragsgiver eksplisitt har bedt om å ikke få en brukermanual, og produktet har blitt utviklet slik at brukere ikke skal behøve en. Til slutt har vi lagt med ett vedlegg, en markedsundersøkelse vi gjorde i oppstarten av konseptutviklingsfasen. Hver del kan leses uavhengig av de andre, og har egen innholdsfortegnelse og sidenummerering. Prosessrapport gir innsikt i hvordan vi arbeidet, hvilke valg vi tok og hvorfor. Produktrapport inneholder teknisk informasjon om applikasjonens oppbygging og virkemåte, samt hvordan det kan videreutvikles. Kravspesifikasjon presenterer kravene satt til prosjektet av oppdragsgiver og oppdragsgivers kunde. Testrapport tar for seg testingingen vi har utført på applikasjonen og resultatene av testingen.

6

7 Prosessrapport

8 Prosessrapport 1 Forord Prosessrapporten beskriver måten gruppen har jobbet på, hvilke metoder som har blitt brukt under utvikling av produktet, samt hvilke verktøy og teknikker vi har benyttet oss av. Rapporten er først og fremst beregnet på sensor og veileder for oppgaven, men også for entusiaster eller interesserte innenfor applikasjonsutvikling for mobile plattformer. Det stilles ikke noe krav til at man har noen innsikt i programutvikling for å ha noe glede av å lese denne rapporten, men det kan likevel være en fordel. Rapporten er videre delt opp i flere underkapitler. Disse underkapitlene kan i hovedsak deles inn i planlegging og metode, utviklingsprosessen samt kravspesifikasjonen og dens rolle. Delen om utviklingsprosessen er beskrevet kronologisk, for å gjøre det lett å forstå hvilken rekkefølge ting er gjort. 1.1 En takk til bidragsyterne Denne rapporten og prosessen den beskriver, ville aldri vært mulig uten bidragsyterne, testpersonene, samarbeidspartnerne og andre frivillige. Denne seksjonen er dedikert til dere. Takk til Dan Robert Ekrem, Hans Magnus Inderberg og resten av veilederne våre hos Bekk. Uten dem ville vi ikke hatt mulighet til å lage en såpass brukervennlig og profesjonell mobilapplikasjon. Takk til Marius Haugen hos Get, som lot oss produsere applikasjon til sitt fulle potensiale ved å raskt ta tilbakemelding til etteretning. Takk til Petri Wilhelmsen som satte av tid til å gi oss teknisk veiledning, samt resten av gutta hos Microsoft for tilbakemelding på det ferdige produktet. Takk til vår veileder på HiOA, Thomas Sødring, som hjalp oss med å lage denne rapporten så god som mulig. Til slutt vil vi takke alle de som hjalp oss med å holde motet oppe gjennom denne prosessen. Takk til venner, familie, kodemiljøet på StackOverflow og alle andre som har fått oss tilbake på sporet når vi var usikre på neste steg. Uten dere ville ikke dette prosjektet vært halvparten av hva det er i dag. 2

9 Prosessrapport Innholdsfortegnelse 1 Forord En takk til bidragsyterne Innledning Gruppen Om oppdragsgiver Get AS BEKK AS Bakgrunn for oppgaven Dagens løsning Oppgavens mål Beskrivelse av applikasjonen Konsept Generell beskrivelse Om applikasjonsutvikling for mobile plattformer Native utvikling Hybrid utvikling Planlegging og metode Forløp til prosjektstart Prosjektstyringsdokumenter Arbeidsplan Fremdriftsplan Arbeidslogg Arbeidsteknikker og utviklingsmetoder Scrum Gruppearbeid Kommunikasjon med veiledere Arbeidsforhold Verktøy Versjonskontroll Dokumentasjon Utvikling Utvidelser og rammeverk Samsung Omnia 7 og LG med WP Zune Windows Phone Application Deployment Tool

10 Prosessrapport Skype Advanced REST Client Maven og Jetty Utviklingsprosessen Konseptutvikling Forarbeid Datainnsamling Introduksjon Brainstorming Målgruppe og behov Markedsundersøkelse Møter Presentasjon av konsept for oppdragsgiver Hybridutvikling Valg av tekniske løsninger Utforming av webinnhold Native navigasjonsrammeverk Problemer med hybridutvikling Nativeutvikling GitHub og Team Foundation Server Utviklingsprosess Implementasjon av MVVM-strukturen Implementering av funksjonalitet Utforming av views Kravspesifikasjonen og dens rolle Bakgrunn for kravspesifikasjonen Rammekrav Fortløpende endringer Vår erfaring med kravspesifikasjonen Kravspesifikasjonen og det endelige produktet Oppfyllelse av krav Tilbakemelding fra oppdragsgiver og kunde Konklusjon Avsluttende del Ord fra veiledere Ord fra Kunden

11 Prosessrapport 8.3 Ord fra Microsoft Samarbeid i gruppen Veiledning fra HiOA Det ferdige produktet Hva kunne vært gjort annerledes Konklusjon

12 Prosessrapport 2 Innledning Denne innledningen inneholder bakgrunnsinformasjon for oppgaven, og finnes både i prosess- og produktrapporten. Innledningsvis vil vi beskrive hvem som har vært involvert i prosjektet, bakgrunnen for oppgaven og hva som har vært oppgavens mål. 2.1 Gruppen Gruppen bestod av tre dataingeniørstudenter og én informasjonsteknologistudent: Hans Petter Naumann, Kristofer Selbekk, Alexander Barve og Vegard Nyeng. Gruppemedlemmene har tidligere arbeidet sammen på skoleprosjekter, og kjenner hverandres faglige styrker meget godt. Vi valgte å danne denne gruppen da vi tidligere har hatt god kommunikasjon, sterke faglige kvaliteter og samme, høye ambisjonsnivå. Figur 2.1: Organisasjonskart over alle aktører 6

13 Prosessrapport 2.2 Om oppdragsgiver I dette prosjektet har vi hatt to ulike bedrifter å forholde oss til, hvor vi skiller mellom kunde og oppdragsgiver. Kunden, Get AS, har hyrt inn BEKK, vår oppdragsgiver, til å utføre dette prosjektet. Ved prosjektslutt vil Get overta ansvaret for vedlikehold og videreutvikling av applikasjonen Get AS Get AS er en av Norges største leverandører av bredbånd og digital-tv. Med over 500 ansatte og over 1 million kunder, har Get alltid vært grensesprengende innen teknologi. Som første leverandør av bredbånd (1997) og første leverandør av digital-tv i verden med vifteløs HD PVR-dekoder (2007), har Get alltid arbeidet Figur 2.2: Get-logo for å bringe den nyeste underholdningsteknologien til hjem og arbeidsplasser over hele Norge. Get AS vil bli referert til som kunden i fremover BEKK AS Bekk er et konsulentselskap med omkring 300 ansatte, som utvikler IT-systemer for offentlige og private virksomheter. Bedriften, som er eid av Evry, har kontorer både i Oslo og Trondheim. Figur 2.3: Bekk-logo Til prosjektet vårt stilte Bekk med to veiledere: Dan Robert Ekrem og Hans Magnus Inderberg. Dan Robert har sin ekspertise innen interaksjonsdesign, og har bidratt mye innen konseptutvikling og interaksjonsdesign. Hans Magnus er programmerer, og var behjelpelig med innen implementeringsfasen. I tillegg ble vi bistått av grafisk designer Morten Kjøs Utengen, som assisterte oss innen designspørsmål. BEKK AS vil bli referert til som oppdragsgiver i fremover. 2.3 Bakgrunn for oppgaven Kunden har allerede utviklet TV-guide-applikasjoner for ios og Android-baserte telefoner, men ønsket å utvide sin portefølje med en applikasjon for Windows Phone 7, da mange eksperter har foreslått at dette også blir en viktig mobil-plattform i fremtiden. Det fantes ikke noe umiddelbart behov for støtte på denne plattformen, men kunden ville utforske de tekniske mulighetene og være ute på markedet før sine konkurrenter. Deres eksisterende TVguide-applikasjoner innholder en komplett tv-guide, mulighet til å sortere ut kanaler, igangsette opptak på kundens PVR-boks over nettverket, varsling på mobil før tvprogrammer begynner og oversikt over filmene tilgjengelige i kundens filmleie-tjeneste. 7

14 Prosessrapport 2.4 Dagens løsning I dag har kunden applikasjoner for ios- og Android-baserte telefoner, i tillegg til webapplikasjoner tilpasset vanlige og mobile nettlesere. ios-versjonen av dagens applikasjon er portet med PhoneGap til Android, og er relativt like hverandre. Begge disse versjonene inkluderer funksjonalitet for å se tv-programmet for den kommende uken, filmer i filmleiedatabasen og søkefunksjonalitet, samt opptaksfunksjonalitet for innloggede brukere. Applikasjonene har fått gode, om enn varierende skussmål på sine respektive salgskanaler, og gjennom å analysere disse tilbakemeldingene fikk vi innsikt i hva vår versjon av applikasjonen burde inkludere. 2.5 Oppgavens mål Målet med prosjektet er å konseptualisere, planlegge og produsere en TV-guide-applikasjon for smarttelefoner basert på Windows Phone 7-plattformen. Applikasjonen som skal utvikles skal inkludere all funksjonalitet som finnes i dagens applikasjoner for ios og Android, og, om tiden tillater, noen nye funksjoner. Applikasjonen skal tilby: TV-guide Muligheten til å velge TV-kanaler som vises Søk i TV-programmet og filmleiedatabasen Fjernstyring av programopptak Muligheten til å lage varsling før et TV-program starter Applikasjonen bør tilby (om tiden tillater): Planleggingsfunksjonalitet Trailerstreaming ved filmleie I tillegg hadde vi følgende overliggende visjoner å strekke oss etter: Lage den beste TV-guiden i Norge Lage den beste WP7-appen i Norge I utgangspunktet skulle vi lage en hybridapplikasjon, som gjør det lettere å forvalte og oppdatere applikasjonen. Det ble det etter hvert tatt en helomvending på, siden det viste seg å være lite hensiktsmessig for plattformen. Vi endte da opp med å implementere applikasjonen i native-kode, C#. Begrunnelsen for dette følger senere i rapporten. Videre ble det ytret et ønske om at applikasjonen designes med hensyn på styrkene og designprinsippene til Windows Phone 7, og at nåværende informasjons-api er blir brukt til sitt fulle potensiale. 8

15 Prosessrapport 3 Beskrivelse av applikasjonen Vi vil i denne seksjonen gjøre rede for den overordnede strukturen og funksjonaliteten som tilbys i TV-guide-applikasjonen slik at leseren får større utbytte av senere kapitler. Her vil vi gi en innføring til applikasjonens konsept, en generell beskrivelse av hva applikasjonen er og gjør, samt navigasjonsstruktur. 3.1 Konsept Før kodingen av applikasjonen ble påbegynt, gikk gruppen gjennom en grundig konseptutviklingsfase. Vi ønsket å utvikle en applikasjon som tok de beste elementene fra dagens mobile tv-guider, samt nye ideer vi og våre veiledere kom opp med, og sette dem sammen til et enkelt, brukervennlig og strømlinjeformet konsept. Flyten i applikasjonen skulle være intuitiv og effektiv, og det grafiske uttrykket skulle bidra til merkevarebygging for kunden. 3.2 Generell beskrivelse Applikasjonen er en TV-guide - et hjelpemiddel som skal bidra til å forenkle planlegging av tv-kvelden for sluttbrukeren og andre tv-tittere, i tillegg til å øke kundens salg av filmleietjenester. Brukeren blir presentert med en komplett oversikt over dagens tv-program, med søke-, planleggings- og opptaksfunksjonalitet, oversikt over kundens filmleieutvalg (inkludert filmtrailervisning), programvarsling og annen mindre, men smart, funksjonalitet. Nedenfor følger screenshots av et utvalg av sidene som er å finne i den ferdige applikasjonen. 9

16 Prosessrapport Figur 3.1: Førstesiden Figur 3.2: Kanalvisning Figur 3.3: Filmleie 10

17 Prosessrapport 4 Om applikasjonsutvikling for mobile plattformer Å utvikle applikasjoner for mobile plattformer bringer med seg både andre utfordringer og nye muligheter i forhold til andre applikasjoner og programmer. Skjermområdet er typisk mindre, ytelsen er lavere, og interaksjon og bruksområde er annerledes. Samtidig har man verktøy som lokasjonstjenester, vibrasjoner, bevegelsessensorer og mye annet til rådighet. Med andre ord, det er mange forskjeller å huske på. Et av de viktigste momentene som skiller mobil og stasjonær applikasjonsutvikling er bruksmønster. Navigasjonsflyten skal være så enkel at en brukerveiledning blir overflødig, og applikasjonen må gi et såpass bra førsteinntrykk at brukere vil se dens potensiale selv ved første bruk. Før utviklingsstarten til prosjektet var det en rekke holdepunkter det var viktig for oss å sette oss inn i. Ingen av oss hadde erfaring med utvikling for mobile plattformer, så vi bestemte oss tidlig for å gjøre research om plattformen vi skulle utvilkle, WP7, og mobilutvikling generelt. Dette ga oss et bedre bilde av hva vi begav oss ut på, og gjorde det lettere for oss å sette mål og bestemme rammer for prosjektet. For utvikling på mobile plattformer har vi fått lære og erfare hvor viktig brukeropplevelsen er for en applikasjon. Vi har gjennom fag som HCI - Human-Computer-Interaction fått innsikt i viktigheten av å utvikle et produkt fra en sluttbrukers perspektiv. Dette er også ytterst relevant i mobilverdenen, og små detaljer ved en brukeropplevelse kan utgjøre forskjellen på om en applikasjon vil brukes eller ikke. Statistikk viser også at 26% av applikasjoner som lastes ned kun prøves én gang. Med andre ord så betyr førsteinntrykket mye. Inneholder applikasjonen en bug som kun utgjør en liten del av applikasjonen, kan dette være forskjellen som gjør at man ikke vil bruke den igjen. Brukertesting er en av de viktigste faktorene for å kunne utforme en brukervennlig applikasjon. Det vil avdekke svakheter og feil ved et program som fra en utviklers perspektiv blir vanskelig å oppdage. En utvikler ser seg fort blind på sitt eget produkt, og kjenner til funksjonalitet og brukergrensesnitt for godt. Ved å la brukere teste grensesnitt og funksjonalitet både under og etter utviklingsstadiet, får man hjelp til å avdekke svakheter ved brukervennligheten av en applikasjon. Vi har i testrapporten dokumentert hvordan brukertestingen er utført under utviklingsprosessen. Et annet aspekt som gjør applikasjonsmarkedet for smarttelefoner spesielt er rangerringssystemet, som i vårt tilfelle for WP7-telefoner er på Microsofts Marketplace. Her gis det størst spalteplass til de applikasjonene som har fått de beste rangeringene, eller hvis man er ekstra heldig - om den blir anbefalt og håndplukket av Microsoft selv. Dette sier også noe om hvor viktig det er å ha et gjennomført produkt før det skal vurderes om applikasjonen skal lanseres på Marketplace. Vi ble fortalt av kunden at majoriteten av brukerene for webapplikasjonene deres bestod av unge menn. Selv om dette ble nevnt, bestemte vi oss for at applikasjonen skulle være intuitivt utformet slik at alle alder- og brukergrupper skulle kunne ha glede av den. Innen mobile plattformer finnes det ulike retninger man kan gå i utviklingen, nativeutvikling og hybrid-utvikling er i dag to av de mest brukte. Under følger en innføring i disse to, da vi har vært gjennom utvikling i begge løsninger. 11

18 Prosessrapport 4.1 Native utvikling En native applikasjon er kodet i plattformens eget programmeringsspråk. Native applikasjoner er utformet med tanke på å kun fungere på plattformen de utvikles for, og vil som regel yte bedre og se bedre ut enn hybride løsninger, da operativsystemet man kjører på først og fremst er utviklet for å håndtere native kode. Windows Phone 7-plattformen bygger på Silverlight systemet, som definerer koblingen mellom brukergrensesnittet (i XAML) og koden (C#). 4.2 Hybrid utvikling En hybrid applikasjon er kodet i både JavaScript og native kode. Som regel vil utviklerne forsøke å gjøre så mye som mulig i JavaScript og HTML5 fordi denne koden er gjenbrukbar på andre plattformer, men det vil variere fra prosjekt til prosjekt. Selv om det som regel er JavaScript og HTML5 som kommer til å stå for det meste av presentasjonen og interaksjonen, så er utviklerne nødt til å forholde seg til native kode for å utvikle skallet applikasjonen kjøres fra og webinnholdet vises i. En viktig årsak til at mange bedrifter vil utvikle i hybride løsninger er fordi det gir dem mulighet til å umiddelbart legge ut oppdateringer for alle plattformene de har applikasjoner på, uten å måtte vente på godkjenning fra markedet. Hvis en bug viser seg i applikasjonen, kan det ta opptil en uke før oppdateringen blir godkjent. 12

19 Prosessrapport 5 Planlegging og metode Denne delen vil beskrive planleggingsprosessen, hvilke verktøy vi har brukt for planlegging og utvikling, og hvordan vi har jobbet. 5.1 Forløp til prosjektstart Planleggingen av prosjektet startet fra første møtet med oppdragsgiver den 15. desember hvor vi ble orientert om omfanget av oppgaven vi skulle bli tildelt. Vi ble fortalt hva vi skulle utvikle, men ble likevel bedt av interaksjonsdesigner Dan Robert om å ikke sette oss altfor mye inn i det tekniske for utvikling av Windows Phone 7. Tanken ved dette var at første fasen av prosjektet bestod av konseptutvikling, og at det ikke var ønskelig å starte på den prosessen med noen som helst form for tekniske begrensninger i bakhodet. Vi ble informert om at dersom vi var uerfarne med Javascript, kunne vi med fordel bruke tid på å lese og prøve å lære oss programmeringsspråket innen prosjektstarten, noe vi også gjorde. Fram til offisiell prosjektoppstart 12. januar leste vi alle boken Javascript - the Good Parts, som vi ble anbefalt. Denne tok for seg de beste aspektene ved Javascript, og tar utgangspunkt i at man har erfaring med programmering fra før. Utover det ble det bestemt at vi ikke skulle bruke tid på noe annet i tiden før prosjektoppstart. 5.2 Prosjektstyringsdokumenter Arbeidsplan Det ble tidlig skrevet en arbeidsplan med delmål og milepæler for prosjektet. Denne ble ikke arbeidet videre med, etter vi begynte å jobbe i Scrum, en arbeidsmetode beskrevet senere i dette dokumentet. Som en del av Scrum-utviklingen ble arbeidsoppgavene definert uke for uke gjennom detaljerte iterasjoner, og dette ble brukt som vår arbeidsplan. Scrumutvikling og iterasjoner er beskrevet senere i rapporten. 13

20 Prosessrapport Fremdriftsplan Fremdriftsplanen ga oss en oversikt over hvor vi burde være på hvilket tidspunkt. En visuell fremstilling av prosjektets høyeste nivå - faser og iterasjoner - viste seg som det beste alternativet. Fremdriftsplanen ble kontinuerlig justert for endringer, og var et nyttig verktøy i både planleggingen og utføringen av prosjektet. Figur 5.1: Siste oppdatering av fremdriftsplan (17. april) Arbeidslogg Arbeidsloggen fungerte som et dokument hvor vi fortløpende dokumenterte hvilket arbeid som ble lagt ned fra dag til dag, uke til uke. Vi hadde riktignok iterasjonene på Github å forholde oss til, men arbeidsloggen ble et fint ekstradokument for å se hva som var gjort til nøyaktig tidspunkt, og av hvem. 5.3 Arbeidsteknikker og utviklingsmetoder Scrum Scrum er et smidig utviklingsrammeverk, som ofte brukes i relativt komplekse og tverrfaglige informasjonsteknologiprosjekter. Det baserer seg på korte tidsintervaller (iterasjoner) hvor spesifikke deler av en applikasjon (kalt en delleveranse) blir ferdigstilt for hvert intervall. Når man arbeider under Scrum er man delt opp i en rekke enheter. En produkteier (i vårt tilfelle vår tekniske rådgiver hos oppdragsgiver) produserer en produktkø, som består av et sett med funksjoner og krav. Scrum-teamet, en tverrfaglig samling av fagfolk, har som mål å implementere så mange av disse kravene som mulig innenfor den gitte tidsfristen. Ved starten av hver iterasjon, holdes det et møte der en sprintkø blir opprettet. En sprintkø består av alle krav og funksjoner som skal fullføres innen slutten av inneværende iterasjon. Scrum-teamet står ansvarlig for å fullføre disse innen gitt tidsfrist. Et Scrum-møte avholdes i starten av hver arbeidsdag, hvor dagens mål og arbeidsfordeling blir avklart mellom gruppemedlemmene. På slutten av dagen holdes det et kort evalueringsmøte, hvor avtalte mål, utfordringer og avvik gjennomgås og avklares. 14

21 Prosessrapport Gruppen valgte å utvikle applikasjonen gjennom denne utviklingsmetodikken. Dette innebar at vi fortløpende leverte delleveranser av produktet, så det hele tiden var utviklet ferdig funksjonalitet til applikasjonen som kunden kunne teste, vurdere og eventuelt godkjenne Hvorfor utvikle i Scrum Valget av Scrum som utviklingsmetodikk ble basert på flere forskjellige grunnlag. For det første var prosjektet spesifisert til å vare innen en gitt periode. Siden oppdraget ikke spesifiserte at vi skulle ha et 100 % ferdigstilt produkt ved leveransedato, var en iterativ utviklingsmodell vårt beste alternativ. Slik kunne vi garantere at alt vi leverte var fullstendig utviklet, testet og godkjent av produkteier. For det andre var det knyttet stor usikkerhet til hastigheten på utviklingen. Siden utvikling av mobile applikasjoner var nytt for alle gruppemedlemmer, regnet vi med at mengden funksjoner og krav oppnådd per iterasjon ville øke lineært med forløpt tid. Dette gjorde det enkelt å tilpasse hver iterasjon til antatt effektivitet, og økte gruppens gjennomsnittlige effektivitet. Et tredje argument var inspirasjon og motivasjon innad i gruppen. Ved å se ferdigstilt funksjonalitet, kunne vi se at prosjektet sakte men sikkert ble mer og mer ferdig - og fremtidige elementer ble oppfattet som ekstrafunksjonalitet. Dette hjalp gruppen til å være motivert gjennom hele prosjektperioden Hvordan vi utviklet i Scrum For hver uke fikk vi et gitt antall iterasjoner tildelt med beskrivelse av oppgaver som skulle utføres for iterasjonen. Hver iterasjon ble definert som en user story hvor hensikten var å definere en funksjonalitet fra brukerens perspektiv. En user story sier hvem som utfører noe, hva som utføres, og begrunnelse for hvorfor det gjøres. Ved å definere iterasjoner på denne måten ville vi som programmerere enkelt bli fortalt hva som skulle implementeres og grunnen bak. Eksempel på en user story: Som en bruker skal jeg kunne se hva som går på tv i dag slik at jeg kan planlegge tv-kvelden min På møtet ble iterasjonene gjennomgått og diskutert. Ble issuen fullført ble den lukket i Github. Om noe manglet ble den overført sammen med neste ukes iterasjoner som også ble opprettet. Iterasjoner er i utgangspustet tidsbegrenset, men kan forlenges om de ikke er helt fullført. Dette førte til at alle iterasjoner ble grundig gjennomført Vår erfaring med Scrum-utvikling Å jobbe med en smidig utviklingsmetodikk var en ny og lærerik prosess for oss i gruppen. Ved tidligere prosjekter har vi hatt langsiktige mål, og underveis ikke jobbet med små, konkrete deloppgaver. Her fikk vi derimot erfare hvordan det var å jobbe med konkrete delmål underveis, og i tillegg gå grundig igjennom disse arbeidsoppgavene hver uke med en teamleder som styrte prosessen. Å utvikle i Scrum ga oss også muligheten til å starte på kodingen umiddelbart etter konseptutviklingsfasen. 15

22 Prosessrapport Iterasjonene har hatt passe stor arbeidsmengde, og vi erfarte at jo flere iterasjoner vi fullførte, jo lettere gikk det å fullføre nye tildelte oppgaver fra produktkøen. Derfor hadde vi en stigende formkurve og erfarte underveis i utviklingen at jo mer vi lærte underveis, jo mer effektive ble vi. Funksjonalitet som det tidlig i fasen virket lite sannsynlig å få implementert ble også implementert Gruppearbeid Det å jobbe i gruppe i seg selv var ikke ukjent for oss som har tidligere erfaring med å jobbe sammen. Gruppen har derimot denne gangen sørget for å møtes hyppigere på skolen, for å ha mest mulige effektive arbeidsøkter. Siden HiOA har begrenset med plass, og da spesielt få tilgjengelige grupperom så vi oss nødt til å reserevere rom fortløpende under hele prosjektperioden Kommunikasjon med veiledere Vi har hatt fortløpende kontakt med alle veiledere involvert i prosjektet både via e-post og gjennom ukentlige møter. Alle design- og interaksjonsrelaterte spørsmål ble dirigert til interaksjonsveilederen vår Dan Robert Ekrem, mens alle datatekniske spørsmål ble tatt opp med vår tekniske rådgiver Hans Magnus Inderberg. Hyppige møter med begge veiledere sikret oss rask og konstruktiv tilbakemelding på vår fremgang. Videre ble spørsmål og henvendelser via e-post raskt besvart av alle parter. HiOAs veileder har hatt en mindre rolle i dette prosjektet, da vi følte oss relativt selvgående med hensyn til dokumentasjonen. Ved eventuelle spørsmål, var veileder derimot rask til å svare og korrigere eventuelle feil vi hadde gjort. Vi sitter igjen med et meget positivt inntrykk av arbeidsprosessen med vår veiledere. Kontinuerlig kommunikasjon og tilbakemelding bidro til å gjøre prosjektet så komplett og ferdig som overhodet mulig i den tildelte prosjektperioden. 5.4 Arbeidsforhold Arbeidsteknikkene vi har benyttet oss av har basert seg mye på hvilken fase av prosjektet vi har vært i. I den første fasen bestod arbeidet av konseptutvikling, hvor vi var avhengige av lage skisser og sitte i en gruppe og idémyldre. Da hadde vi regelmessige gruppemøter på skolen eller hjemme hos én av gruppemedlemmene. I tillegg til arbeidet som ble gjort rundt konseptutviklingen, gjorde vi selvstendig arbeid der vi blant annet lærte oss Javascript og leste annen faglitteratur. Dette ble som oftest gjort hjemmefra, og bestod blant annet av å lese boken Javascript: The Good Parts, samt å gjøre oppgaver og tutorials på diverse nettsider. I programmeringsfasen hvor vi har sittet med selve implementeringen har vi i hovedsak benyttet oss av grupperom på skolen. En typisk arbeidsdag for denne fasen i utviklingsprosessen kunne se slik ut: 1. Jobbe fra :00 på skolen, så jobbe et par timer på kvelden 2. Jobbe på skolen fra 12:00-16:00 (hvor resten av tidsbruken er brukt til skolearbeid eller andre aktiviteter urelatert til hovedprosjekt). 3. Jobbe hjemmefra (vanskelig å anslå nøyaktig tidsbruk, men 8-10 timer var typisk) 16

23 Prosessrapport Arbeidstype 1 var den hyppigste arbeidsformen. Vi foretrakk å jobbe på skolen, siden vi hadde direkte kontakt med hverandre. Dette gjorde at vi sparte oss for unødvendig arbeid med å vise hverandres problemer på dataskjermen. 5.5 Verktøy Versjonskontroll Et versjonskontrollsystem er programvare laget for å dele filer i prosjekter, og sørger for at endringer blir sammensmeltet. Versjonskontrollsystemer er essensielle for prosjekter med flere utviklere Team Foundation Server Team Foundation Server er Microsofts egne versjonskontrollsystem, innebygget i Visual Studio. Programmet gir oss muligheten til å lage et prosjekt på en.net-server, og jobbe med prosjektet samtidig. Man kan laste ned siste versjonen og laste opp endringene man har gjort på filer. Hvis flere personer har gjort endringer i filen samtidig må man merge filen og gå gjennom dokumentet for å velge hvilke endringer man skal godta. Dette har gjort det mulig for oss å jobbe tett for å fullføre funksjonalitet hurtig, men også jobbe med ulik funksjonalitet i samme del av prosjektet uten å få komplikasjoner Git med GitHub Git er et versjonskontrollsystem som ble introdusert for oss av arbeidsgiver. Git har egne kommandoer, bl. a. pull og push, for synkronisering med andre repositorier. Dette muliggjør alle-til-alle-synkronisering (ikke bare alle-til-én, som i CVS og SVN). Dessuten, uten implisitt synkronisering trenger man for eksempel ikke å være koblet til nettverk hele tiden for å kunne jobbe. Alt innhold i et Git-repositorium er indeksert etter sha1-sum. I tilfelle bitfeil i lagring eller overføring, kan man være rimelig sikker på at det vil oppdages. Fordi sjekksummen regnes for å være kryptografisk sikker, kan man stole på at ikke uvedkomne kan ha endret innholdet uten at dette også vil oppdages. Git er både raskt og god til sammenfletting (merging) av kode. Ved hjelp av Github, som er et web-basert hostingsystem for Git-prosjekter, har vi oversikt over hvem som har tilgang til hvem som jobber med prosjektet og hvilke endringer de gjør, samt oppgaver som må gjøres. Ved commit av endringer skrives en beskrivelse av endringen inn, som igjen kan sees av alle medlemmer på GitHub. Slik er det enkelt å se siste endringer gjort av andre Dokumentasjon Google Docs Google Docs er Googles online kontorpakke, lik Microsoft Office. Her kan man lage tekstdokumenter, regneark, presentasjoner og tegne. Google Docs er en tjeneste som tilbys over nett for brukere med Gmail epost eller Google konto. Vi har benyttet oss av Google Docs for å skrive dokumentasjon fordi tjenesten leveres over nett, uten behov for innstallasjon av programvare, samt tillater en gruppe å dele dokumenter og skrive på samme dokument samtidig. Vi har også delt gruppas dokumenter med veiledere for tilbakemelding. 17

24 Prosessrapport Microsoft Word 2007 Microsoft Word er et populært skriveprogram som mange anser som standarden for tekstbehandling og -formattering. Vi har benyttet oss av Microsoft Word for å formattere sluttrapporten før leveranse p.g.a. Google Docs sin manglende støtte for tilpassing. Med Microsoft Word hadde vi mulighet til å tilføre bl.a. sidetall i innholdsfortegnelsen og kapittelnumre Lucidchart Lucid chart er en webapplikasjon for å lage diagrammer, use cases og all slags typer grafiske modeller. Tjenesten tilbyr muligheten for å jobbe flere på samme fil ala Google Docs. Lucid Charts har et enkelt brukergrensesnitt med click and drag -funksjonalitet og tilbyr muligheten for å skrive ut og lagre i tilgjengelige formater som.png og.pdf Utvikling Her er en beskrivelse av de ulike verktøyene vi har brukt for å skrive kode og programmere i Sublime Text 2 Sublime Text er en teksteditor med støtte for en syntax-highlighting out of the box for en rekke programmeringspråk, blant annet JavaScript og HTML. Dette passet oss utmerket i begynnelsen av prosjektet, da vi skulle utvikle applikasjonen i hybrid. Etter beslutningen om å lage hele applikasjonen i native-kode fikk vi mindre bruk for Sublime Text, men brukte det fortsatt for å se på den eksisterende kodebasen til arbeidsgiver, som vi trengte for å vite hvordan vi kunne hente ut data. Sublime Text ble et enkelt valg av teksteditor for alle på gruppen da det er kjapt, enkelt, pent og tilgjengelig både på Mac OS X og Windows Visual Studio 2010 Visual Studio var for oss kjent fra før, da vi har jobbet med det i faget webapplikasjoner på HiOA. Det vil primært være vårt utviklingsverktøy for å lage native-koden (C#). Med i VS følger også en emulator som simulerer en Windows Phone, slik at det er enkelt å teste applikasjonen underveis Utvidelser og rammeverk Nuget Package Manager Nuget Package Manager er en utvidelse for Visual Studio 2010 for å laste ned og opprettholde pakker i solutions. Vi brukte denne utvidelsen for å laste ned og legge inn nye pakker i prosjektet vårt. Disse pakkene var typisk rammeverk som for eksempel for Jsonserialisering og tilpassede messageboxer. Utvidelsen mangler dessverre støtte for Team Foundation Server-utvikling i skrivende stund, slik at vi var nødt til å utveksle pakkene oss imellom, men utvidelsen legger til pakken og lager referansen Silverlight Toolkit for Windows Phone 7 Denne tilleggspakken gir utviklere mulighet til å implementere en del av de mest utbredte og innovative funksjonene Windows Phone 7 tilbyr. Viktige Windows Phone 7-komponenter som application bar, context menu, live tiles og progress bar følger med i denne pakken for applikasjoner som trenger denne funksjonaliteten og vil være plattformstro. I pakken følger også en rekke animasjonsoverganger tilpasset Windows Phone 7. 18

25 Prosessrapport Windows Phone Theme Manager Windows Phone Theme Manager er en prosjektpakke som hjelper applikasjoner å styre unna Windows Phone 7 sin temahåndtering. Vanligvis blir alle applikasjonsressurser satt avhengig av temaet brukeren har valgt på sin mobil. Hvis brukeren har valgt hvitt tema vil dette endre på utseende i alle innebygde controls. Det er mulig å endre på hvilket tema brukeren har i koden, men det blir ikke tillatt i Microsofts Marketplace. Man har muligheten til å legge til nye applikasjonsressurser som tilbakestiller fargene til sort tema, men det er en del jobb å finne alle controls som må implementeres. Dette rammeverket er oppdatert med siste versjon og gjør jobben for deg programatisk Windows Phone Assets Windows Phone Assets er et prosjekt for Windows Phone 7, med fri lisens, som inneholder en rekke praktiske verktøy for utviklere. Prosjektet inneholder blant annet en funksjon, NotificationTool, som immiterer Windows Phone 7 sin MessageBox. MessageBox er en systemfunksjon, og lar seg derfor ikke endres av stil-tilpasninger i applikasjonen. Dette gjorde dermed at MessageBoxene ikke passet med applikasjonen når vi gjorde applikasjonen tema-uavhengig. NotificationTool kan man enkelt endre utseendet på, ved at utvikleren har gjort et eget stilark enkelt tilgjengelig. Med NotificationTool har man også muligheten til å definere andre knapper enn i MessageBox, som bare har OK og Cancel. Figur 5.2: MessageBox med Windows Phone Assets 19

26 Prosessrapport Samsung Omnia 7 og LG med WP7 Disse telefonene ble brukt som testtelefoner for prosjektet. Samsung Omnia 7-telefonen ble mest brukt Zune For å kunne ta i bruk og teste applikasjonen på en mobil enhet måtte musikktjenesten Zune være innstallert og kjøre før telefonen ble koblet til. Zune ble ellers brukt til å oppdatere telefonen(e) slik at de alltid hadde siste versjon av firmwaren Windows Phone Application Deployment Tool For å legge over.xap-filen på mobiltelefonen, så applikasjonen kunne bli testet på en mobil enhet Skype Skype er vår hovedportal for kommunikasjon i nåtid når vi ikke jobber samlet. Her kan vi holde konferansesamtaler, sende filer/lenker og chatte for å sørge for god arbeidsflyt. 20

27 Prosessrapport Advanced REST Client Figur 5.3 Advanced REST Client gir utvikleren mulighet til å utforske REST-kall, og responsen gitt i grensetilfeller Applikasjonen benytter seg av JSON-formattert data levert fra en ekstern web-tjeneste. Ved problemer i deserialiseringen av denne dataen, kan det være nyttig å se hva et kall til tjeneren returnerer. Nettleseren Google Chrome støtter den gratis og fritt tilgjengelig utvidelsen Advanced REST Client, som lar utvikleren sende egenskrevne kall til REST-tjenere, og dissekere de returnerte verdiene. Kundens REST-tjener bruker JSON-serialisereren Jackson, som returnerer til tider ukonsekvent parset kode. Advanced REST Client er et meget nyttig verktøy for å oppdage slike irregulære kodemønstre i generelle og spesielle tilfeller, og anbefales på det sterkeste å bli brukt i en eventuell feilsøkingssituasjon som involverer overføring av data Maven og Jetty Maven er et bygningsautomatiseringsverktøy brukt typisk for java-applikasjoner. Jetty er en Maven-plugin som fungerer som en HTTP-server. Med Maven og Jetty kunne vi kjøre JsTestDriver for å debugge (feilsøke) JavaScript-koden vår, men vi brukte det også lokalt for å teste vår webkode i applikasjonen. Etter beslutningen om å gå native fikk vi ikke lenger bruk for Maven, Jetty og JsTestDriver. 21

28 Prosessrapport 6 Utviklingsprosessen Prosjektet vårt hadde noen klare, ulike delprosesser som kan deles inn i tre faser. Disse fasene kan beskrives fra start til slutt som: konseptutviklingsfasen, hybridutviklingsfasen og nativeutviklingsfasen. Hva fasene innebærte er beskrevet her. 6.1 Konseptutvikling Helt siden vårt første møte med oppdragsgiver og kunden har de vært klare på at konseptutviklingen er en viktig del av vårt hovedprosjekt. Det gikk tidlig opp for oss at kunden ikke hadde absolutte krav om å få en ferdig utviklet applikasjon. Selv om de setter stor pris på å kunne delta på Windows Phone 7-markedet tidligst mulig, har de også lyst til å ha tre applikasjoner som er nytenkende, bidrar til en bedre brukeropplevelse og tiltrekker seg nye kunder. Det er derfor oppdragsgiver og kunden valgte å ha våre første møter etter de to introduksjonsmøtene om konseptutvikling, i form av brainstorming-økter. Tanken til kunden var også at om vi ikke skulle få til å lage en god applikasjon, så ville de i det minste stå igjen med et brukbart konsept Forarbeid Vår aller første reelle jobbeøkt var en liten tjuvstart før vårt første offisielle møte med oppdragsgiver. Her startet vi med idémyldringer for ideer til applikasjonen. Dette gjorde vi ved å ha hjemmejobbing hos et av gruppemedlemmene i tre dager, før det første offisielle møtet den 12. januar Her møtte vi alle ansvarlige personer for prosjektet, inkludert Marius - hovedsjef for utvikling hos kunden. I oppstarten var det klart for en fase med konseptutvikling, derfor stod veileder innen interaksjonsdesign Dan Robert for regien ved møtene. Her lærte vi nye idémyldringsteknikker, og bearbeidet ideer som allerede var lagt frem Datainnsamling I konseptutviklingsfasen ble vi fra dag en fortalt av veileder innen interaksjonsdesign, Dan Robert, at vi ikke skulle begrense oss med å sette oss inn i det tekniske ved utvikling for Windows Phone 7. Dette fordi det kunne være en ulempe for konseptutviklingen sin del å sette tekniske begrensninger for oss selv Introduksjon I løpet julen, før offisiell prosjektstart, sendte vår tekniske veileder Hans Magnus oss flere eposter med relevant informasjon til vårt hovedprosjekt. En av epostene inneholdt en plan for å konseptutvikle en Windows Phone 7 app med Metro Design. Gruppen valgte derfor å møtes for å brainstorme ideer til applikasjonen vi skulle utvikle. Vi så først en presentasjon på Metro Design i Windows Phone 7. Deretter satte hele gruppen seg ned og drøftet ideer. Vi stilte oss spørsmålet hva ville vært i din drømmetv-guide? Vi lot også andre gruppemedlemmer ha muligheten til å utdype hverandres ideer videre. Ideer ble deretter skrevet ned Brainstorming 17. januar 2012 møtte vi opp ved kundens hovedlokaler for vårt andre møte der. Dan Robert og Marius Sonvoll Haugen (som er leder i web- og utvikling hos kunden) ledet møtet. Vi fikk beskjed om at dagens møte skulle være brainstorming til konseptutviklingen. Vi fant da ut at 22

29 Prosessrapport vi hadde tyvstartet på konseptutviklingsdelen. Dan Robert hadde en liten presentasjon til å begynne med. Det er viktig å ha informasjon om hva man vil oppnå med applikasjonen før man drøfter funksjonalitet. Presentasjonen omhandlet derfor applikasjonens målgruppe, mål og hvilke behov brukerne av applikasjonen har. Den var lagt opp slik at det var rom for drøfting av punktene underveis. Vi diskuterte også hvilke konkurrenter kunden har, hvilke målsetninger kunden har for utviklingen og hvilke muligheter kunden ser for applikasjonen Målgruppe og behov Kunden har tidligere hatt spørreundersøkelser på sin nettside. I disse spørreundersøkelsene kom de blant annet frem til at det er ytterst få eldre enn 37 som benytter seg av webtjenestene deres, og ca 70% av disse er menn. Det var derfor ingen gode grunner for at vi skal anta at det er en annen demografi som benytter seg av applikasjonene, selv om de ikke har undersøkt dette hittil. Vi fikk også høre at det var mulighet for at de norske bankene ville satse på at deres ansatte benyttet Windows Phone 7 i nærmeste fremtid, da disse mobilene har tilgang til Office-pakken og finnes i billigere versjoner enn Apple sin iphone. Dette kan gjøre at denne applikasjonen får en litt eldre demografi, men vi kom til enighet at det har liten påvirkning på utformingen av applikasjonen. Den vi skal lage skal være intuitiv å bruke, uansett aldersgruppe. Under presentasjon kom vi inn på temaet om hvilke behov brukeren har. I hvilke situasjoner kommer folk til å starte applikasjonen? Først og fremst kom vi frem til at applikasjonen kommer til å brukes av folk som er i farten. Den kommer til å brukes av folk som er på trikken, bussen eller t-banen og har noen minutter å slå ihjel. De prøver å finne ut hva de skal se på TV når de kommer hjem fra jobb. Ut ifra dette kunne vi tolke at det er viktig at applikasjonen er lett å navigere med en hånd, det er viktig å ikke bruke for mye datatrafikk, at den føles rask og responsiv, at den er lett å tolke og at den gir deg mulighet til å ta steg tilbake. Det kan for eksempel være en fordel om applikasjonen har mulighet til å skreddersy tilbudet den fremviser for brukeren. En annen bruker vi har lyst til å nå, er brukeren som allerede sitter hjemme og ser på TV. Hvis applikasjonen kan tilby informasjon enklere og raskere enn brukerens dekoder og andre tilbud, vil det åpne muligheter for å promotere andre tjenester fra kunden samt tiltrekke nye kunder, som er et mål de har med applikasjonene i fremtiden. Derfor er kunden interessert i å inneha nytenkende, nyttig funksjonalitet folk har bruk for, som konkurrentene ikke tilbyr Markedsundersøkelse På eget initiativ gjorde vi en markedsundersøkelse på hva som finnes av tv-guideapplikasjoner for mobile enheter fra før. I tillegg til å se nøye på hvordan tv-guider for WP7 var designet, så vi på andre plattformer, og hva applikasjonene generelt hadde å tilby av funksjonalitet. Noe av ulempen ved markedsundersøkelsen for WP7-applikasjonene var at vi ikke hadde noen telefon å teste på. Derfor var det vanskelig å få gode inntrykk av hvilke løsninger som var smarte og intuitivt utformet. Vi fikk allikevel mange gode ideer til design og layout gjennom å se skjermbilder for applikasjoner som var lagt ut på Microsofts Marketplace. Marketplace er Microsofts portal hvor alle applikasjoner utviklet av både Microsoft og uavhengige utviklere ligger. Hele markedsundersøkelsen finnes som et vedlegg til rapporten. 23

30 Prosessrapport Møter De følgene avsnittene vil inneholde fyldige beskrivelser og skildringer som beskriver prosessen med å utforme et konsept for TV-guiden vi skulle utvikle. 24. januar 2012 var vi samlet hos kunden for enda mer idémyldring, omtalt som assosiasjonslek (med et snev av tvungen tilkobling ). Vi skulle komme med alle slags mulige assosiasjoner til ordet trikken. Her skrev vi ned alt vi forbandt rundt det å ta trikk, både negative og positive ting. Da ideene var skrevet ned, fikk vi beskjed om å stryke ordet trikk og erstatte det med TV-Guide. Det viste seg at hensikten med dette var at på trikken er en typisk situasjon hvor man benytter seg av mobilen for å slå ihjel tid. Deretter utdypet vi alle ordene vi hadde skrevet ned, og kom på funksjonalitet i sammenheng med enkeltordene. Gjennom denne variasjonen av idémyldring fikk vi satt fokus på hvilke kvaliteter som var ønsket, men også uønsket. På denne måten fikk vi forkastet dårlige ideer ved et tidlig stadie, og beholdt de gode. Senere brukte vi tid på å bearbeide ideene, tegnet skisser og utarbeide ferdige konsepter som ble diskutert. I løpet av denne prosessen fikk vi også tilbakemelding av veileder innen interaksjonsdesign, som også fikk oss til å tenke annerledes og få en ny innfallsvinkel på konseptene våres. Dette resulterte i mange nye skisser og utbedrede konsepter, som senere ble presentert hos kunden Presentasjon av konsept for oppdragsgiver Den 31. januar hadde vi et møte hos kunden hvor gruppen presenterte fire ulike konsept, hvor vi i etterkant kom fram til et felles konsept ved help fra Dan Robert og innspill fra Marius om hvilke ideer han likte best. Det ble kommet til enighet om et overordnet konsept, som inneholdt fire funksjoner: 1. Et startvindu i panoramastil, med en oversikt over hva som skal komme av programmer basert på visning av egne favoritter og anbefalinger. Viser kun oversikt over dagens programmer, det vil si de programmene som kommer, og ikke for andre dager. Opptak/varsling direkte herifra var en mulighet som skulle diskuteres nærmere. 2. En programoversikt over hva som går nå og hva som kommer av programmer. Denne oversikten har mulighet for å filtrere etter dag, tidspunkt og sjanger/kategori. Favoritter som mulig kategori, for å kunne se brukerens favorittsendinger en gitt dag? 3. Min kalender/min tv-kveld: Liste over programmer lagt til i planleggeren, sortert etter tid. Markerer eventuelle konflikter mellom programmer. Listevisning for vertikalt view, timeline for horisontalt view. Deling med venner, trekning osv? Mulig integrering med kalender på telefonen. 4. Filmguide. Vi bestemte oss for å kalle det filmguide fremfor filmleie. Alt skulle skisseres nærmere før en endelig beslutning ble tatt. 24

31 Prosessrapport Figur 6.1: En av skissene som ble presentert for kunden Alt skulle skisseres nærmere før en endelig beslutning ble tatt. 6.2 Hybridutvikling Da det endelig var duket for oppstart av programmeringsfasen var det mange ukjente aspekter å ta for seg. Vi fikk en liten innføring av teknisk veileder blant annet i API en og JavaScript-kodebasen, og ble instruert om å ta et online kurs i JavaScript som oppdragsgiver hadde utviklet og bruker på kurs og seminarer. For å starte utviklingen var vi alle nødt til å registrere GitHub-kontoer og ha en lokal versjon av et repository kunden skulle dele med oss, samt innstallere og kjøre Jetty med Maven slik at appen får tilgang til websidene med JavaScript-koden vi utvikler (og den felles kodebasen). Første iterasjon inkluderte å sette opp Git lokalt, klone kodebasen, laste ned og installere programvaren som trengtes, samt å sette opp en WP7-applikasjon med et WebBrowserobjekt. Videre skulle vi finne ut hvordan native kode kunne kommunisere med Javascriptkoden, og sette opp en eksempelnavigasjon. I løpet av 4 dager var vi ferdige med kurset på nett, som skulle vise seg å være svært utfordrende og omfattende, men også lærerikt. Alle i gruppen hadde installert Git og begynt å gjøre klar for kjøring av utviklermiljøet med Maven og Jetty. Til å begynne med hadde vi problemer med å kjøre Jetty på Windows-maskiner, men etter en oppdatering av Javas SDK løste disse problemene seg Valg av tekniske løsninger I utgangspunktet ble vi bedt om å utvikle applikasjonen gjennom en hybrid-løsning. Dette innebar at den skulle være en kombinasjon mellom native -kode og HTML5/CSS/Javascript. På denne måten ville det være enklere å oppdatere appen uten at man trenger godkjenning gjennom Windows Phone sitt marketplace, samt gjøre det lettere å 25

32 Prosessrapport få oppdatert applikasjonen i seg selv ved at den bruker felles javascriptkode for alle plattformene (WP7, Android og ios) som allerede eksisterte hos kunden Utforming av webinnhold Utformingen av webinnholdet ble strukturert på en objektorientert MVC-måte, for å sikre enkel lesbarhet i ettertid. Views, kontrollere og modeller ble alle lagret som egne filer, og ble inkludert på de sider som trengtes. Javascript kan brukes som et objektorientert språk hvis visse retningslinjer blir fulgt. Alle klasser, funksjoner og variable ble innkapslet i pakker - namespaces - for å både strukturere koden, og lage objekter som både kunne opprettes, endres, presenteres og slettes. Figur 6.2: En typisk enkel klasse, innkapslet for å lagre objektet i DOM-treet Kodebasen ga oss mange av klassene som trengtes for å porte denne applikasjonen til en Windows Phone 7-applikasjon, og ble derfor inkludert direkte. Andre klasser måtte bli implementert direkte av oss, og var spesifikke til den informasjonen vi ville vise og den strukturen vi ville ha for å presentere det. Applikasjonens WebBrowser-objekter bruker den integrerte nettleseren Internet Explorer 9 (heretter kalt IE9). Denne nettleseren tar høyde for mange av W3Cs nyeste standarder, og er derfor relativt lett å jobbe med. Siden vi ikke trengte å ta høyde for andre nettlesere, ble moderniseringsrammeverk som Modernizr (Javascript) ikke nødvendige. Selve webinnholdet ble skrevet, strukturert og kodet til HTML5-standarden. Denne standarden gir tilgang til en rekke strukturelle elementer som både gjør applikasjonen mer tilgjengelig, men høyner også kompatibilitet for fremtidige nettlesere. All stilsetting ble gjort gjennom et sentralt CSS3-basert stilark, og ble gjennomgående sjekket for kompatibilitet med IE9. For å minimere filstørrelsene ble det lagt fokus på å lage gjenbrukbare stiler - stiler som ble brukt flere ganger gjennom applikasjonen. 26

33 Prosessrapport Native navigasjonsrammeverk Under oppstartsfasen i prosjektet hadde vi fått som oppgave å gjøre oss kjent med native Windows Phone 7 utvikling. Det ble foreslått at hver av oss kunne lage vår egen lille applikasjon. Slik ble vi bedre kjent med XAML og Windows Phone 7-kode. I tillegg har vi tidligere hatt et prosjekt i ASP.NET og en mindre oppgave i Silverlight, så vi var godt kjent med C#. Det tok oss dermed kort tid å få satt igang et navigasjonsrammeverk. Vi hadde allerede bestemt at navigasjonen skulle utføres i native slik at vi kunne ta nytte av Windows Phone 7-funksjonalitet som panorama- og pivotvisning. I Windows Phone 7 blir navigasjon utført ved at man benytter et metodekall med klassen NavigationService, som tar imot en absolutt eller relativ URL til XAML-filen (view) du vil navigere til. Senere gikk vi til verks for å implementere webvisere i native-koden. Her benytter man seg av kontrollen WebBrowser. WebBrowser implementeres i XAML-markup og kan blant annet ta imot en URL-adresse. Etter å ha implementert WebBrowsere i noen views satte vi i gang å utforske mulighetene for kommunikasjon mellom native kode og JavaScript. Her fant vi ut at støtten for dette er god i Windows. For å kommunisere fra native til JavaScript trenger man kun å kalle på en metode WebBrowser-objektet har, med to parameter (navnet på JavaScript funksjon som skal kalles og eventuelle parametere). Under er en liten test som viser hvordan man kan få webinnholdet til å passe til hvitt og sort tema. Figur 6.3: Kommunikasjon fra Native til JavaScript - temautveksling For å kommunisere fra JavaScript til native er man nødt til å opprette en event handler for WebBrowser. Event handleren blir kjørt når JavaScript bruker funksjonen window.external.notify(). Under ser man et eksempel på hvordan man kan sende beskjeder til native og hvordan man i native kan tolke ulike beskjeder etter innhold. 27

34 Prosessrapport Figur 6.4: Kommunikasjon fra JavaScript til Native - swipevarsling Problemer med hybridutvikling Etter litt testing av webvisning på Windows Phone 7 var det åpenbart at det var andre problemer med løsningen. WebBrowser gir ikke direkte mulighet til å deaktivere scrolling eller zooming (pinch), kun å deaktivere all interaksjon. En slik løsning vil ikke fungere da vi er nødt til å ha klikk-interaksjon med mye av innholdet. Dermed vil en bruker være nødt til å swipe over webinnholdet for å gå til neste side. Dette brøt med plattformen og gjorde applikasjonen vanskeligere å bruke. Vi var derfor nødt til å finne en løsning på dette. Etter en lang periode med research på nett, fant vi fremdeles ingen enkel implementering for å deaktivere bare interaksjon som ikke scroller eller zoomer inn, men beholde klikkinteraksjon for linker. Vårt første forsøk på å løse problemet var å løse dette i HTML-markup. Ved å implementere Figur 6.5: Forsøk på å blokke skalering via metainformasjon i HTML-metaen håpet vi å løse problemet da dette forteller browseren at siden skal ha samme bredde som browservinduet, og ikke tillate brukeren å zoome i websiden. Dette var dessverre ikke implementert i Windows Phone 7 sin WebBrowser, noe vi også fant bekreftelse av på nett fra flere andre brukere. Vårt andre forsøk på å løse problemet var ved å implementere jquery Mobile, som er et JavaScript-rammeverk med hjelpefunksjonalitet for utvikling av hybride applikasjoner på alle plattformer, og bygger på jquery. Vi forsøkte å danne lyttere for swipe events som kunne varsle Native når brukeren utførte en swipe-interaksjon. Vi fikk bekreftet at disse lytterne fungerte i våre nettlesere med notifikasjoner, men interaksjonene ble ikke fanget opp i WebBrowser controlleren. 28

35 Prosessrapport Til slutt fant vi en løsning på nett som har blitt dokumentert at fungerer. Istedenfor å bruke den vanlige WebBrowser controllen, bruker man en egen klasse med en privat WebBrowser attributt. Ved bruk av en API som heter LINQ to Visual Tree kan man query e barna en WebBrowser control består av. Slik kunne vi lytte på interaksjon utført på et av barnene til WebBrowser, der interaksjon mottas, og ved hjelp av koordinater blokkere swipe-interaksjon og pinch (zoom). Da var det mulig å swipe til neste pivot eller panorama selv over WebBrowser-flaten. Etter tre uker med hybrid utvikling fant vi ut at hver WebBrowser-instans i WP7 bruker omtrent 80MB RAM. Windows Phone Marketplace godkjenner bare applikasjoner som bruker mindre enn 100MB. Man kan derfor kun ha 1 WebBrowser instans. Vi fant dessverre ikke ut av dette tidligere da det er få utviklere av hybride applikasjoner som benytter seg av panorama og pivot på grunn av problematikken vi har drøftet rundt dette. Vi diskuterte dette med teknisk veileder og det viste seg at noen av hans medarbeidere tidligere hadde støtt på det samme problemet. Det er mulig å sende en WebBrowser instans fra view til view under navigasjon, slik at man bare benytter én instans. Det hadde gått opp for oss i løpet av den siste uken hvor mye bruk av hybrid løsning går utover brukeropplevelsen i Windows Phone 7, og nå som vi bare kunne ta i bruk én WebBrowser-instans ville det ødelegge brukeropplevelsen enda mer. I både pivot- og panorama-visninger vil lasting fremstå som tregt, da man ikke kan begynne å laste og rendre før swiping til neste side er igangsatt. I panoramaviews vil det heller ikke være mulig å vise innholdet på neste side., slik panoramaviews er ment å være. Windows Phone 7 pryder seg selv i rask respons og raske animasjoner, blant annet ved at innhold allerede er lastet og klart for fremstilling før man swiper til neste side. Dermed ville en hybrid løsning fremstå som treg og lite plattformtro, to av målene kunden hadde satt. Arbeidet for å utvikle native rammeverket ville også bli en av de mest tidskrevende delene i prosjektet og langt mer avansert enn kunden opprinnelig ønsket med hybrid utvikling, slik at forvaltningen ikke ville fått noen fordel av å være i hybrid. Allikevel var det fremdeles ønsket at applikasjonen skulle benytte seg av pivot- og panoramafunksjonalitet, da dette gir mening for fremstilling av tv-guideinformasjonen. Under møte den 28. februar 2012 diskuterte vi dette med teknisk veileder og kunden. Kunden var enig i at det ikke ga like mye hensikt å utvikle i hybrid lenger for Windows Phone 7 og vi tok dermed sammen en rask beslutning om at all utvikling skulle gå over til ren native, noe som ville gjøre applikasjonen mer responsiv og plattformstro. 6.3 Nativeutvikling Denne seksjonen beskriver vår utviklingsprosess i native kode. Her vil vi diskutere overgangen fra GitHub til TFS, hvordan vi implementerte viktig funksjonalitet og utviklingsprosessen rundt viewene, samt koblingen mellom viewene og logikk GitHub og Team Foundation Server Tidligere hadde vi brukt Git med GitHub for versjonskontroll og det gikk greit i hybridfasen siden det som regel bare var en person som jobbet i native. Da vi begynte å jobbe tettere i native oppstod det hyppig konflikter ved opplastning og nedlasting av endringer. Til å begynne med forsøkte vi å lage en gitignore fil i prosjektet slik at filene det ikke gir hensikt å dele (systemfiler med lokale adresser og ressurser) ikke skaper konflikter ved hver 29

36 Prosessrapport opplasting. Dette hjalp, men det oppstod fremdeles konflikter når nye filer ble lagt til i prosjektet eller fjernet, på grunn av en fil som holder oversikt over alle filer i prosjektet. Dette ville være problematisk ved hurtig utvikling. Vi har tidligere brukt Team Foundation Server i ASP.NET-prosjekter og visste at dette versjonskontrollsystemet håndterer slike endringer og gjør innsjekking enklere, da det er en del av Visual Studio. Team Foundation Server trenger også bare pålogging ved oppstart mens GitHub trenger passord ved hver eneste innhenting og opplasting, noe som gjorde at vi kunne jobbe tettere og sjekke inn endringer raskere. Vi hadde snakket med teknisk veileder tidligere i prosessen om det ville være greit om vi brukte Team Foundation Server istedenfor Git under utviklingen, hvis vi trengte det. Det var greit hvis vi jevnlig oppdaterte en versjon av prosjektet på Git. Dermed gikk vi over til å jobbe på Team Foundation Server før vi satte igang native-utviklingen. Det viste seg raskt å være en bedre løsning for vår utviklingsstil Utviklingsprosess Dette kapittelet beskriver utviklingsprosessen vår på en kronologisk måte. Dette er kun en oversikt over hva som ble gjort, da mer tekniske detaljer finnes i de følgende avsnittene. Her kan leseren se hvordan vi arbeidet oss fremover i prosjektet, og hvordan oppdeling av oppgaver i iterasjoner formet vår utviklingsprosess Uke 1 (oppstart uten iterasjoner) I møtet 28. februar, hvor det ble bestemt at vi skulle gå over til native-utvikling, rakk ikke teknisk veileder å finne nye iterasjonsoppgaver. Dermed begynte vi denne uken med å gjøre forberedelser til native-utviklingen. Vi gikk over til Team Foundation Server tidlig og lagde deretter et nytt navigasjonsrammeverk, samt modellklasser for dataen vi får inn fra REST Uke 2 Denne uken begynte vi med å lære om MVVM-strukturen. Mye tid gikk med på å sette oss inn i MVVM, samt å utforske hvilke muligheter vi hadde i forhold til datainnhenting fra en RESTtjeneste. Det var vanskelig å finne noen god struktur som passet til denne applikasjonen og vi kom derfor litt på etterskudd i noen av ukens iterasjoner, og de ble dermed dyttet over i neste iterasjon. Mot slutten av uken begynte vi å jobbe med å forstå databindinger og de ulike avhengighetene til dette grensesnittet Uke 3 I denne uken hadde vi mye å ta igjen og vi var nødt til å begynne utviklingen for fullt. Vi delegerte utvikling av REST-innhentingen til en av gruppemedlemmene, imens de tre andre gruppemedlemmene satte igang med å få fungerende databindinger for modellklassene og ViewModelene. Her endte vi opp med å lage en klasse ObjectBase, med OnPropertyChanged, som modellklassene og ViewModelene kunne arve varslingsmetoder fra. Vi var nødt til å lage en stub-klasse som lager midlertidige objekter slik at vi kunne vise innhold, og lage funksjonalitet Uke 4 I denne uken hadde vi fått iterasjonsoppgaver om å få igang en fungerende på tv nå -side, kanalvisning og enkeltprogram-visning. Innhenting av data fra kundens REST-tjener 30

37 Prosessrapport fungerte ikke enda så vi jobbet fremdeles med stubs. Imens det ene gruppemedlemmet løste problemer med REST-innhenting gjorde de tre andre ferdig nesten all funksjonalitet rundt de tre viewene. Løsningene her ville også bli brukt som en mal i senere views Uke 5 Uke 5 var uken vi begynte å koble sammen de første viewene med informasjon fra kundens REST-tjener. De første dagene gikk med på å optimalisere deserialiseringen av data, siden det fortsatt var noen problemer. Løsningen viste seg å være en blanding av wrapper-klasser og attributtering av modellenes datafelter. For å gjøre ferdig på tv nå -viewet i applikasjonens hovedview, trengte vi også å implementere en form for bildeinnhenting. Vi valgte å bruke synkron bildeinnhenting i førsteomgang, siden dette virket som et greit utgangspunkt for senere optimalisering. Det ble derimot gjort et notat om at asynkron lasting av bilder kunne være å foretrekke grunnet raskere visning Uke 6 I denne uken skulle vi få til asynkron lasting av bilder etter at kanaler har blitt lastet inn. Dette gjorde vi relativt fort, og fortsatte derfor med å lage funksjonalitet for innlogging, utvikle flere nye views og fikse bugs og ytelsesproblemer rundt de ulike funksjonene vi allerede hadde laget. Til slutt var vi nødt til å få testet ordentlig på mobil. Frem til nå hadde vi hatt problemer med å få registrert studentbruker på Apphub og ventet på svar fra Microsoft, men til slutt sendte de oss et lisens for testing på mobilen. Da fant vi ut at ytelsen på mobilen var betraktelig bedre enn på Emulator. Teknisk veileder ville også at vi skulle implementere nedlastingsindikator på alle viewene som får innholdet sitt fra REST Uke 7 Denne uken var siste uke vi skulle jobbe med ny funksjonalitet, da vi hadde blitt enige med teknisk veileder om at det ville være en fordel om vi fikk en uke til å fikse bugs, rydde opp i kode, effektivisere kode og sentralisere kode. Dermed begynte vi på den utestående funksjonaliteten ved å en kanalvelger. Min kalender var allerede nesten ferdig, med ble brukt litt tid på å effektivisere og sentralisere funksjonaliteten rundt denne siden. Til slutt implementerte vi et varslingssystem slik at brukeren kunne få varsling før et program går Uke 8 Uke 8 ble dedikert til å fikse en rekke mindre issues som fortsatt måtte fikses før leveranse. Disse oppgavene inkluderte håndtering av frakoblet modus, gjøre kundens logo mer lesbar, ordne et rendering-problem med bakgrunnen, samt å gjøre applikasjonen temaavhengig. Filmleie-viewet ble også ferdigstilt uten videre problemer, men det ferdige produktet så ikke fullt så interessant ut som vi håpet. Etter samråd med våre veiledere, ble det også ønsket å inkludere coverbilde foran hvert bilde. Disse ble hentet inn på samme måte som kanallogoer - gjennom asynkrone kall til serveren. Frakoblet modus ble bestemt nedskalert i funksjonalitet, og hadde nå kun som mål å gjøre applikasjonen brukbar selv uten nett. Planlagte programmer ville fortsatt kunne bli vist og endret, men alle views som krever informasjon fra internett implementerte i stedet et par linjer med tekst som oppfordrer brukeren til å slå på dataoverføring på telefonen. 31

38 Prosessrapport Det ble også gjort noen endringer til kanalvelgeren, hvor visning av en ikke valgt kanals ContextMenu automatisk valgte denne kanalen. Dette var ikke ønskelig, og en løsning ble funnet på problemet. Å gjøre applikasjonen uavhengig av brukerens valgte tema var ingen lett oppgave, og målet ble heller ikke ferdigstilt denne uken. Alle fonter og tekster ble gjort temauavhengige, og et open-source rammeverk (Windows Phone ThemeManager) ble implementert for å endre fargen på blant annet application bars og system trayen. Det eneste gjenstående temaavhengige elementet på dette tidspunktet var MessageBoxer, som krevde en annen løsning. Resten av denne uken ble brukt på å rydde i og sentralisere koden vår, slik at den var i best mulig stand før innlevering Implementasjon av MVVM-strukturen Etter oppfordring fra veileder bestemte vi oss for å bruke MVVM-strukturen i applikasjonen. Dette er strukturen Windows Phone 7 er utviklet for, og hjelper med å separere brukergrensesnitt, data og logikk. I MVVM-strukturen er det Model-laget som skal ha ansvar for innhenting, sending og lagring av data. I enkle prosjekter vil objektmodellene være i ViewModel-laget, men i større prosjekter vil disse objektmodellene bli brukt i flere views, og da er man nødt til å ha objektmodeller et annet sted. Vi har valgt å kalle pakken til objektmodellene våres Model, og heller kalle det laget som har Model-ansvaret Controller. I MVVM-strukturen er det noe uklart hvilke deler som skal utføre hvilke oppgaver. For eksempel i Model-delen av strukturen, er det ikke nødvendigvis modellklasser, da ViewModels i mange tilfeller fungerer som modellklasser. I slike prosjekter vil Model-delen være ansvarlig for alle resterende arbeidsoppgaver, som innhenting, sending og lagring av data. Her bestemte vi oss for å lage en egen pakke kalt Controller, som tok på seg dette ansvaret, i og med at vi allerede hadde en Model-pakke for våre smarte modeller. I tillegg lagde vi også en pakke, Utility, der vi blant annet hadde statiske klasser med metoder og hjelpemidler som skulle være tilgjengelig fra overalt. I første omgang lagde vi en klasse, DateUtility, som skulle hjelpe oss å håndtere dato-logikk i applikasjonen Implementering av funksjonalitet Smarte modeller For å øke gjenbrukbarheten til koden vår, ønsket vi å plassere mesteparten av den UIspesifikke, logiske koden i modellaget. Denne praksisen - populært kalt smarte modeller - fører til tynnere ViewModels og mer sentralisert kode. Vi mente også at denne løsningen passet vårt prosjekt best, siden modellenes informasjon blir vist på lik måte flere steder i applikasjonen. Det som kjennetegner en smart modell er deriverte properties og funksjoner som arbeider med dataene internt i modellen og andre steder i applikasjonen (for eksempel maps med oversikt over kanalnavn og kanallogoer). Dette gir brukergrensesnittet et vell av informasjon å presentere, og arbeider i overenstemmelse med MVVM-rammeverket. 32

39 Prosessrapport REST-rammeverk For å kunne prate effektivt med REST-tjeneren, var det viktig å ha en standardisert måte å kontakte den. Vi bestemte oss derfor tidlig i prosessen for å implementere et rammeverk for å behandle denne kommunikasjonen. Etter å ha undersøkt hvilke muligheter som var tilgjengelige, satt vi igjen med to valg - bruke et eksternt rammeverk (REST.NET var lenge et plausibelt valg) eller bygge et lettvektsrammeverk som kun dekket våre behov. Siden våre kommunikasjonsbehov var relativt små i forhold til hva et komplett rammeverk kunne tilby, valgte vi sistnevnte alternativ. Kundens REST-tjener tilbyr HTTP-tjenester både over GET- og POST-metodene, og vi måtte derfor implementere generell funksjonalitet for begge muligheter. I tillegg implementerer metodene valgfri token-basert autentifikasjon for å kunne logge inn brukere og aktivere opptak. Metodene forventer en såkalt callback-funksjon, en funksjon som blir kjørt når kallet til serveren er ferdig. Om kallet feiler, bruker for lang tid, brukeren er ikke autorisert, eller om internettdekning ikke er tilgjengelig, blir passende exception returnert. Disse må bli tatt høyde for i callback-funksjonen på passende måte for hvert tilfelle. Resultatene blir returnert i en generisk modell kalt Result.cs. Denne inneholder en gitt modell, eventuelle exceptions og en enkel metode for å se om resultatet inneholder feil. Ved å tilby et likt grensesnitt for alle returnerte verdier, gjør dette jobben enklere ved databehandling i andre lag OnPropertyChanged-events og ObjectBase Når applikasjonen har mottatt informasjon fra REST-tjenesten, må brukergrensesnittet bli varslet om endringen i datagrunnlaget. For å forenkle denne oppgaven har WP7-plattformen inkludert et event-basert rammeverk som gjør nettopp dette. Vår implementasjon av dette står nøyere beskrevet i prosjektrapporten Søkefunksjonalitet Et av kravene til funksjonalitet i applikasjonen var søkefunksjonalitet for både filmleie og TV. Vi valgte i samsvar med interaksjonsdesignveilederen vår å implementere dette i samme view, og vise resultatene i et todelt pivot-view. For å implementere denne funksjonaliteten var det nødvendig med to kall til REST-tjeneren. Selve søket blir gjennomført på kundens REST-tjener, og er både raskt og effektivt. For å effektivisere søk videre, ble antall søkeresultater begrenset til 100 for TV og 30 for film (grunnet markant større datamengde for filmresultater). Resultatet ble en rask og effektiv implementasjon, som fungerer slik kunden ønsker Kanalvelger Med over 130 tilbudte kanaler, er det viktig for sluttkunden å kunne velge de kanaler som er interessante på en daglig basis. Det er også viktig at valget av disse gjenspeiles i resten av applikasjonen på en logisk og praktisk måte. Til slutt er det ønskelig at valg av kanaler virker intuitivt og smart. 33

40 Prosessrapport Ved førstegangskjøring av applikasjonen blir brukeren møtt med kundens standardpakke - et godt valg for flesteparten av både kundens betalende kunder og andre brukere av applikasjonen. Valget av kanaler gjenspeiles i flere views i applikasjonen. Mest tydelig blir dette i På TV Nå -viewet, der kun valgte kanaler presenteres. Videre vises dette i Filmer i dag -viewet. For å øke applikasjonens opplevde intelligens, ble det bestemt å implementere et system som automatisk velger en brukers bestilte kanaler ved innlogging. Om kanalvalget allerede har blitt endret før en eventuell innlogging, vil dette derimot ikke skje. Det blir da antatt at brukeren allerede har valgt de kanaler han eller hun er interessert i, og automatisk endring da ikke er ønskelig Kanalvisning I kanalvisningen skulle ukeprogrammet til én kanal vises i en pivotside. Hvert pivotelement representerte en dag. Det trengtes ett kall til REST for hver dagsprogram, slik at det i alt, for hele pivoten, trengtes 7 kall. Dette tar imidlertid noe tid å hente, og man vet ikke om brukeren vil sjekke mer enn dagens sendinger. Derfor valgte vi å laste inn dagsprogrammet for et og et pivotelement, ettersom brukeren navigerte dit. For å unngå å laste data som allerede er lastet la vi til en array i codebehind-filen, som sørget for å huske hvilke pivotsider brukeren hadde vært inne på (og dermed lastet ned dataen til). For å bestemme navnene på pivotelementene, altså i dag, i morgen, fredag osv, brukte vi en skreddersydd metode i DateUtility Brukere og glemte passord Kundens REST-tjeneste tilbyr både innlogging og utlogging av eksisterende brukere og en SMS-tjeneste for å få tilsendt et nytt passord til glemske brukere. Dette var funksjonalitet vi ønsket å implementere i vår applikasjon. Hvis en bruker logger inn gjennom applikasjonen, vil han forbli logget inn til en eventuell utlogging. Dette gjøres ved hjelp av sikker lagring av brukerinformasjonen internt i applikasjonen, og automatisk innlogging ved oppstart av applikasjonen. Når en bruker ønsker å få tilsendt et nytt passord, blir også dette gjort gjennom sikre kanaler. Et åpent REST-kall med et telefonnummer brukeren oppgir blir sendt til tjeneren, og tjeneren produserer, registrerer og sender ny kode til oppgitt telefonnummer Asynkron lasting av bilder For å øke hastigheten på datainnhentingen, var det ønskelig å dele opp skriftlige og grafiske data. Siden den skriftlige dataen inneholder mesteparten av all informasjon en bruker er på utkikk etter, ble det bestemt å presentere denne før eventuelle blider ble lastet inn. Dette ble oppnådd gjennom asynkron innhenting og presentasjon av bildefiler. Når informasjonen om elementet har blitt lastet ned, brukes setteren til bildepropertien til å hente inn bildet asynkront gjennom BitmapImage-klassens innebygde system for nedlasting av bilder på eksterne servere Sending av objekter mellom views Etter å ha implementert alle views med informasjon fra REST, innså vi at mye informasjon ble hentet inn flere ganger. Trykket man for eksempel på et program i kanalvisningen, ville 34

41 Prosessrapport kun ID-en til programmet bli sendt til neste view, og data ble hentet inn på nytt igjen. Dette var en enklere og tryggere tilnærming, men langt i fra den raskeste. Det ble derfor søkt etter en løsning for å sende objekter fra ett view til et annet. Siden selve konseptet ikke virket så vanskelig, og vi ikke hadde basert resten av applikasjonen på rammeverk som MVVMLight (som blant annet tilbyr dette gjennom såkalte Messageklasser), ble det bestemt å implementere på egenhånd. Funksjonaliteten ble implementert gjennom klassen NavigationUtility, og inneholder et statisk objekt og en metode for å navigere til elementets view. Det statiske objektet blir satt til elementet som skal navigeres til, og brukeren blir så tatt til det nye viewet. Det nye viewet sjekker så om det statiske NavigationUtility-objektet er av riktig type og matcher annen medsendt informasjon, og hopper over REST-kallet som ellers ville blitt brukt. Om objektet mangler av en eller annen grunn (for eksempel uferdig data), vil REST-kallet bli kjørt som vanlig. Denne funksjonaliteten er både skuddsikker og ressurssparende, og brukes i alle views der det er teknisk mulig og praktisk. Et enkelt grensesnitt og interne sikringer mot misbruk av funksjonaliteten gir videreutviklere et viktig verktøy Utforming av views Panoramavisningen, hovedsiden Allerede fra de første skissene bestod panoramaviewet, eller hovedviewet, av fire delsider: kalender, meny, på tv nå og filmer i dag. Det var disse 4 vi endte opp med til slutt også. Første skissen er vist under. Figur 6.6: Tidlig skisse for panoramavinduet Til å begynne med ville vi fokusere på å fremheve min kalender - en funksjon som var ny for denne applikasjonen, og som vi følte vi trengte å fremheve ovenfor brukerne. Derfor var dette 35

42 Prosessrapport den første siden som brukerne skulle komme til i de tidligste skissene. Det ble senere bestemt at på tv nå var viktigere å ha som første view, da dette ble sett på som mer essensielt for brukerne etter oppstart. Under følger en senere skisse av panoramavisningen. Figur 6.7: Senere skisse for panoramavinduet I denne skissen har logo og bakgrunnsbilde blitt fastsatt. Vi kom frem til at gråtonene fremhevet gulfargen godt, og ga designet et stilig preg. Bildene på film anbefalinger ble etterhvert nedprioritert av kunden, da det ikke finnes mulighet til å hente bilder til filmer som går på TV uten lisenser, noe Get ikke ville ta stilling til for øyeblikket. På dette stadiet var det ikke bestemt om panoramasiden skulle inneholde en application bar. Senere ble det bestemt at appliacation bar også skulle implementeres på panoramasiden slik at man har muligheten til å logge inn eller ut, eller hente data på nytt fra denne siden. I tillegg ble Get-logoen fremhevet, fremfor TV-guide, noe kunde ønsket. 36

43 Prosessrapport Figur 6.8: Ferdig implementasjon av panoramavisning På TV Nå I denne seksjonen har det blitt eksperimentert med både to og tre programmer for hver kanal. Etter hvert ble det bestemt at vi skulle gå for to programmer (nå og neste) slik at vi kunne gjøre plass for en progress bar til å vise fremgangen i programmet som går. Slik kan brukeren kjapt forstå hvor langt programmet har gått uten å måtte tenke eller se på klokken. Under utviklingen av denne applikasjonen dukket det opp flere nye TV-guide-applikasjoner i Windows Phone Marketplace som også hadde tatt i bruk progress bar Filmer i dag Hva filmer -siden skulle vise ble diskutert mye frem og tilbake - om det skulle vise filmer i filmleie, filmer på tv i dag eller en kombinasjon. Det var også usikkert om det skulle brukes tiles for denne visningen, eller en vanlig liste som i min kalender. Av flere grunner endte vi opp med å kun vise filmer som går på tv i dag. For det første ville en kombinasjon, med tiles, vært uaktuelt da vi kun hadde tilgang på bilder til filmer i filmleie - ikke for filmer på tv. For en ren visning av filmer i filmleie ville dette kunne forvirre brukeren - samtidig som det samme innholdet ville blitt vist i filmleie-delen (fra menyen) likevel. Å kunne få en rask oversikt over alle filmer på tv i dag mener vi er en funksjon som ville blitt satt pris på av brukerne Menysiden Menyen endret seg lite fra de første skissene til ferdig applikasjon. Den skulle linke til de øvrige sidene som ikke er vist i panoramaen; min kalender-pivoten, filmleie, kanalvelger, programoversikt og søk. Den siden ble aldri prioritert å lages grunnet tidsmangel Kalender (på hovedsiden) I og med at panoramaen generelt fokuserer på det som går i dag valgte vi å her kun vise programmer i brukerens kalender som går på tv i dag. 37

44 Prosessrapport Kanalvelger Vi ønsket at kanalvelgeren skulle være enkel, effektiv, lett forståelig og gi muligheten for å navigere til en hvilken som helst kanal. Vi hadde ingen skisser på det da vi starter arbedet på viewet, men vi ble godt fornøyd med resultatet vi endte opp med. Vi valgte å liste opp kanalene som trykkbare tiles. Ved trykk skrus kanalene av/på, slik at bare de valgte kanalene vises ut applikasjonen. Kanalene som blir skrudd av får 50% gjennomsiktige for å markere dette. Figur 6.9: Kanalvelger Figur 6.10: Context Menu i Kanalvelger 38

45 Prosessrapport Filmleie I filmleie-delen var det 5 kategorier av filmer som skulle vises; anbefalt, topp 25, premiere, HD-film og siste sjanse. Dette er kategorier satt av kunden fra før. Allerede fra de tidligste skissene ble dette delt opp i en pivot. Fordi brukere enklere husker bilder enn tekst, og for å gi sidene litt mer substans, ble det etter hvert lagt til coverbilde for hver film. Nedenfor: skisse til venstre, ferdig resultat til høyre. Figur 6.11: Tidlig skisse fra Filmleie Figur 6.12: Endelige versjon av Filmleie 39

46 Prosessrapport Filmvisning For dette viewet hadde vi ingen gode skisser før vi begynte. Vi hadde ingen skisser på denne siden da vi begynte utviklingen av den, og fulgte derfor samme stil som visning av enkeltprogram. Det ble eksperimentert med plassering av coverbilde på flere plasseringer, men grunnet dimensjonene til bildene vi får av REST-service, ble det bestemt at de skulle plasseres ved siden av metadataen slik at alt får plass på en side. Ved å klikke på bildet kommer man til et slideshow med alle bildene som er tilgjengelig for filmen. Det er også mulig å se trailer ved å klikke på på trailerikonet på bunn. Trailer vises i fullskjerm, landskapsorientering slik at større deler av skjermen kan utnyttes. Figur 6.13: Visning av leiefilm Figur 6.14: Slideshow for leiefilm 40

47 Prosessrapport Min kalender Tidlige skisser viste Min Kalender som et pivotview med 3 sider; min kalender, mine abonnementer og søk. Min kalender-delen skulle vise en oversikt over planlagte programmer, i kronologisk rekkefølge. Mine abonnementer skulle vise en grei oversikt over hva brukeren abonnerer på. Søk-delen ble sett på som overflødig, da vi bare kunne ha søk ifra applicationbar, som i andre views. Funksjonalitet som skulle tilbys i min kalender var: gå til program, opptak, varsling og fjern fra kalender. For abonnementer ville vi gi brukeren mulighet til å stoppe abonnement og deretter velge å enten beholde eller forkaste allerede planlagte programmer fra abonnementet. Alt dette ble løst med contextmenyer. Boksen som viser valget om brukeren vil beholde eller slette episode lot seg ikke lage med standard messagebox en for WP7. Blant annet derfor valgte vi å implementere en custom messagebox, som lar utvikler legge til flere knapper og kjøre metoder ved trykk. Min kalender-delen ble senere gitt overskriften planlagt, mens mine abonnementer ble navngitt abonnementer grunnet langt navn. Figur 6.15: Planlagte TV-programmer Figur 6.16: Abonnerte TV-serier 41

48 Prosessrapport Søk I tillegg til et generelt søkeord beskrev de første skissene muligheter for å søke mer spesifikt; etter dag, tidspunkt og kanal. Disse feltene ble etterhvert funnet overflødige da annen funksjonalitet i applikasjonen utfører denne oppgaven bedre, samt at søkefunksjonaliteten skulle fungere for både leiefilmer og TV-programmer. Figur 6.17: Tidlige skisse for søk Figur 6.18: Endelig søkevindu 42

49 Prosessrapport Søkeresultater For søkeresultater hadde vi to mulige trefftyper: programmer på tv og filmer i filmleie. For å gjøre søk enklest mulig ville vi ha ett felles søk for disse, og heller separere resultatene. Dette førte til et pivot-view, med én side for hver. Figur 6.19: TV-resultater Figur 6.20: Filmleie-resultater 43

50 Prosessrapport Kanalvisning (for én enkelt kanal) Som ellers i designet ville vi her gjøre det enkelt. En pivotside for hver dag, og en enkel liste med tidspunkt og programnavn. Farger viser om et program har gått, er påbegynt eller kommer. For å skifte dag kan brukeren enkelt swipe til høyre elle venstre, og se tv-program for en uke frem i tid. Vi hadde ingen skisser på hvordan dette viewet skulle se ut, men vi hadde sett for oss hvordan det kunne se ut. Figur 6.21: Kanalvisning 44

51 Prosessrapport Programvisning Skissen til denne siden foreslo et bilde fra programmet. Dette er ikke tilgjengelig fra datakilde, og idéen ble derfor forkastet. Ellers ble siden veldig lik, og nokstå typisk blant tvguide-applikasjoner. Programmets kanal og sjanger ble lagt på i ettertid, da vi mener dette kan være nyttig informasjon for brukeren. Figur 6.22: Siste skisse for programvisning Figur 6.23: Endelig programvisning 45

52 Prosessrapport 7 Kravspesifikasjonen og dens rolle Kravspesifikasjonen er mer eller mindre bestemt av kunden, er med på å definere prosjektets rammer og applikasjonens funksjonalitet. Den skal også gi en forståelse for oppdragsgiver og utviklere for hva funksjonaliteten Kravspesifikasjonen i prosjektet har hatt en dynamisk rolle. Dette fordi den er blitt fortløpende endret underveis i utviklingen. Grunnen til dette var ikke at vi, oppdragsgiver, eller kunden ikke klarte å se for oss hvordan det ønskede sluttproduktet, men fordi det var ønskelig med en dynamisk prosess der kunden var sikret å sitte igjen med noe fornuftig til slutt, hvis gruppen skulle få dårlig tid til å implementere alt. 7.1 Bakgrunn for kravspesifikasjonen Kravspesifikasjonen vår, som finnes i sin helhet som et vedlegg til denne rapporten, er et resultat av måten vi har utviklet applikasjonen på. I og med at vi har benyttet oss av Scrum, har dette gjort at kravspesifikasjonen har hatt en del endringer underveis. Dette gjelder i hovedsak rammeverket og hvordan ting skulle utvikles, men også i liten grad hvilken funksjonalitet som skulle utvikles og implementeres. Hvordan Scrum ble brukt som utviklingsmetode er beskrevet tidligere i prosessen under planlegging og metode Rammekrav Rammekravene til applikasjonen ble definert i en tidlig fase av prosjektet. Applikasjonen skulle være universelt utformet og kunne brukes av alle brukergrupper, selv om majoriteten av brukerne ville være unge menn - som beskrevet tidligere under målgruppe og behov. All interaksjon skulle være intuitivt utformet. Brukeropplevelsen skulle hele tiden ligge i bakhodet vårt under utviklingen. Designmessig skulle applikasjonen følge Microsofts Metroprinsipper, samt bidra til branding av kundens varemerke. Kunden hadde også satt krav til selve koden om at den skulle være så enkel og oversiktelig som mulig. Den skulle være godt strukturert, uten noen form for kommentarer. Som beskrevet tidligere i prosessrapporten skulle den også følge designmønsteret for WP7- plattformen med et MVVM-mønster (Model-View-ViewModel). Ellers var vi frie til å implentere funksjonaliteten som vi selv skulle ønske utover disse kravene, som ga oss en del friheter. Utover kravene som gjaldt kode og struktur, ble det også nevnt at koden skulle være utformet på en måte som gjorde det enkelt å lage utvidelser senere. Disse kravene ble brukt som et godt hjelpemiddel til å ha en overordnet Fortløpende endringer Ettersom kravspesifikasjonen ble definert gjennom iterasjoner og user stories gjennom Scrumprosessen vi har jobbet i, har den vært oppdatert regelmessig. Funksjonelle krav ble definert i iterasjoner på Github, som gjorde at disse fortløpende ble lagt til i kravspesifikasjonen. 46

53 Prosessrapport 7.2 Vår erfaring med kravspesifikasjonen Kravspesifikasjonen for vår del har mest fungert som et dokument med generelle retningslinjer og krav for hvordan koden skulle struktureres og skrives, og hvordan grensesnittet skulle utformes. Funksjonalitet tilhørte også kravspesifikasjonen, men var noe som hele tiden fortløpende ble fylt ut og endret underveis. Å jobbe med en kravspesifikasjon som har måtte endre seg fortløpende grunnet vår måte å utvikle på i Scrum har for fungert bra for vår del. 7.3 Kravspesifikasjonen og det endelige produktet Oppfyllelse av krav Alle iterasjoner som ble lagt ut på Github ble etter hvert fullført. Det eneste unntaket var kanskje programvisning, et view som skulle vise programmer som gikk på TV basert på tidspunkt, uavhengig av kanaltilknytning. Dette ble sett på som en tidkrevende oppgave som ble spart til slutt, og ble til slutt nedprioritert og droppet. En nærmere beskrivelse av dette viewet kommer under avsnittet om mulige utvidelser for applikasjonen. Ellers ble annen ekstra funksjonalitet som blant annet: Håndtering av frakoblet modus, logg ut, trailer i fullskjermvisning for filmleie, min kalender Tilbakemelding fra oppdragsgiver og kunde Kunden ga oss positive tilbakemelding i forhold til oppfylte krav. All funksjonalitet som var minstekrav av hva de ville ha i applikasjonen før vi leverte den fra oss ble implementert. I tilleg var også all ekstra funksjonalitet implementert. Med ekstra funksjonalitet menes den funksjonaliteten som var ønsket ut over minstekravene for funksjonalitet som kunden mente applikasjonen burde inneholde. 7.4 Konklusjon Kravspesifikasjonen har spilt en relativt stort rolle for utviklingen i prosjektet, spesielt for hva som gjaldt rammer og omfang av oppgaven. Funksjonalitet det stiltes krav til ble innfridd, og så godt som all ekstra funksjonalitet ble også implementert. 47

54 Prosessrapport 8 Avsluttende del 8.1 Ord fra veiledere Ved prosjektslutt fikk vi en tilbakemelding på arbeidet vårt fra oppdragsgiver. De var svært fornøyde med oss. Denne attesten i sin helhet ligger vedlagt under vedlegg på slutten av rapporten. 8.2 Ord fra Kunden Vi har ikke fått noen skriftlig tilbakemelding fra kunden. De har derimot ytret stor begeistring over sluttproduktet. Sitat fra Marius Haugen: Denne her går rett ut på markedet!. 8.3 Ord fra Microsoft Vi fikk tillatelse til av oppdragsgiver, og gleden av, å få vise frem applikasjonen vår til Microsoft Norge, for å høre hva de syntes om produktet. Den 19. januar var det seminar på HiO med Petri Willhelmsen som holdt foredrag og et lite introduksjonskurs til Windows Phone 7. Den samme personen møtte vi hos Microsoft 25. mai, og han ga oss på lang vei en god bekreftelse på følelsen vi satt igjen med selv - et godt, gjennomført produkt, og en applikasjon som føles godt integrert i telefonen. Vi ble invitert til Microsofts hovedkontorer på Lysaker for å la noen fagkyndige teste applikasjonen. Tidligere hadde vi gjennomført brukertester på alle slags type brukergrupper, men vi hadde lyst til å la en eller flere WP7-kyndige prøve applikasjonen, som hadde innsikt i hva WP7-plattformen handlet om og hva Metros designprinsipper innebærte. Hos Microsoft fikk vi ærlig og konstruktiv tilbakemelding på det ferdige produktet vi da hadde kommet fram til, som vi viste fram etter utviklingsstopp for prosjektet. Følgende er hva Petri Wilhelmsen, Developer Marketing manager & Academic Developer Evangelist hos Microsoft, hadde å si om resultatet vårt: Etter å ha testet Get TV-guide appen må jeg si meg meget fornøyd med opplevelsen. Ikke bare har utviklerne klart å bruke Metro Design grensesnittet slik Microsoft ønsker at Windows Phone appene skal være, men også klart å brande appen med kundens behov. Flyten var bra, og innholdet kom i fokus slik at det til enhver tid ikke var noe spørsmål om hvor i appen jeg befant meg, og hva jeg skulle oppnå. Appen føltes som en integrert del av telefonen og jeg trengte ikke å lære meg noe nytt for å bruke den. En vel gjennomført app - gleder meg til å kunne bruke denne selv. 48

55 Prosessrapport 49

56 Prosessrapport 8.4 Samarbeid i gruppen Ved at vi har jobbet sammen som gruppe ved flere tidligere anledninger, var vi forberedte på hvordan samarbeidet ville bli. Vi har vært gode venner siden første dag i fadderuka i 1. klasse, og har holdt sammen siden da, både i og utenfor skolen. Selv om vi har samme, høye, ambisjonsnivå er vi fire veldig ulike personer. Dette mener vi har vært positivt for oss som gruppe. Med ulike meninger har vi enklere fått belyst flere sider av en sak, eller flere løsninger på et problem. Slik har vi ofte kommet frem til gode løsninger på problemer, fremfor å velge den første løsningen som blir foreslått. I et prosjekt på størrelse med dette vil det selvsagt oppstå uenigheter. Disse har ofte skyldtes stort engasjement og ulik tankegang blant gruppemedlemmene. Dette har likevel løst seg fint hver gang, og vi har kommet opp med løsninger hele gruppen er fornøyde med. Verktøy som Skype og Google Docs har gjort det enklere for oss å ha et godt samarbeide. Gjennom hele prosjektperioden har vi kontinuerlig reservert grupperom på skolen, og lagt ut tid og rom-nummer i Google Calendar. Kalenderen har fungert som en oppslagstavle på hvor og når vi skal møtes hver dag, og dette har vært særdeles vellykket. Figur 8.1: Grupperom på skolen som ble reservert kontinuerlig under hele prosjekttiden 8.5 Veiledning fra HiOA Vår veileder fra HiOA var Thomas Sødring. Vi har ikke møttes ofte, men han har vært tilgjengelig til å svare på våre spørsmål via mail. Vårt første møte med Thomas var i starten av mai måned, da han ga oss grunnleggende tips om dokumentasjonen og presentasjonen. 8.6 Det ferdige produktet Basert på tilbakemeldinger fra kunden, veiledere og brukere er applikasjonen pen, responsiv, godt gjennomført og tilbyr det den skal av funksjonalitet og enda litt til. Vi mener en av hovedstyrkene ved vårt sluttprodukt er at det er allsidig og enkelt - det vil tilfredsstille de aller fleste behov, men er ikke for komplisert for de brukerne som bare kjapt vil sjekke hva som går på tv, eller har lite erfaring med WP7-plattformen. Applikasjonen er i hovedsak laget for kundens egne kunder, men er likevel en god og fullt brukbar TV-Guide for andre brukere. 50

57 Prosessrapport 8.7 Hva kunne vært gjort annerledes For utviklingen sin del er det tydelig at det hadde vært til å fordel om vi innså begrensningene til en hybrid løsning på Windows Phone 7, tidligere. Selv om beslutningen aldri var vår å ta, kunne vi endt opp med å ha en eller to uker mer på oss til å utvikle hvis vi hadde konfrontert teknisk veileder med utfordringene tidligere. Han hadde kolleger til rådighet som hadde stått ovenfor de samme problemstillingene. Selv om den opprinnelige koden fra perioden ikke endte opp med å bli brukt i sluttproduktet, tok vi med oss mye av lærdommen inn i nativeutviklingsfasen, til fordel. Da vi startet native-utviklingsfasen hadde vi ikke god nok tid til å sette oss inn i MVVMstrukturen, som er nokså tidkrevende å fordøye. Tiden som hadde blitt brukt på hybrid utvikling gjorde at vi hadde en rekke oppgaver som måtte utføres kjappest mulig. Dermed var vi nødt til å sette igang utviklingen av rammeverket for applikasjonen nesten umiddelbart. Dette gjorde at vi ikke fikk implementert et grensesnitt for å delegere oppgaver fra View til ViewModel, ICommand. Da vi kom over grensesnittet var det ikke god nok til til å lære eller implementere det, p.g.a. ny funksjonalitet som var forventet. Vi drøftet problemet med teknisk veileder, som ønsket at vi skulle fortsette med ny funksjonalitet fremfor å implementere ICommand. Hvis vi hadde implementert ICommand-grensesnittet ville applikasjonen fulgt MVVM-strukturen enda bedre, og vært noe ryddigere. 8.8 Konklusjon Prosjektet har vært en krevende læringsprosess innen prosjekthåndtering, forskjellige teknologier, verktøy og arbeidsmetoder. Selv med en rekke uforutsette utfordringer, har prosessen vært god. Etter hvert som bitene falt på plass gikk utviklingen raskere og raskere. Produktet vi leverte til kunden oppfylte kravene som var satt, samt så godt som alle ønskede tilleggsfunksjoner. Applikasjonen var godt gjennomført og nytenkende, og vil forhåpentligvis hjelpe kunden med å tiltrekke nye kunder. De siste 5 månedene har vist seg å være en uvurderlig læringsmulighet for oss. Vi har lært mye om alt fra planlegging og konseputvikling til iterativ utvikling i et Scrum-miljø. Vi har lært en god del om hvordan det er å jobbe i et konsulentmiljø for en seriøs arbeidsgiver gjennom våre ukentlige møter med teknisk veileder og vi har også hatt muligheten til å samarbeide med en interaksjonsdesigner og grafisk designer. Rent programmeringsmessig har vi blitt flinkere i en rekke språk og plattformer. Først og fremst har vi lært mye C#, XAML og JavaScript, men vi har også lært om hvordan man er nødt til å velge ut og ta i bruk nye verktøy for å utføre ulike arbeidsoppgaver. Vi har fått god innsikt i hvordan man tar i bruk en REST-tjeneste og hvordan man forholder seg til dataen man får inn. I tillegg har vi også blitt flinkere til å feilsøke, feilhåndtere og skrive effektiv kode. 51

58

59 Produktrapport

60 Produktrapport 1 Forord Denne rapporten er prosjektets produktrapport og redegjør for applikasjonens bruksområder, funksjonalitet, oppbygning, tekniske detaljer og hvordan man feilsøker. Rapporten er beregnet for både sensor, veileder, og eventuelle utviklere som skal arbeide med eller drifte applikasjonen i ettertid, men kan også leses av andre interessenter. Rapporten er beregnet for personer med datatekniske kunnskaper, spesielt om de benyttede teknologier, men grundige innføringer blir gitt for spesiell programvare, teknologi og teknikker som påkreves for å få fullt utbytte av dokumentasjonen. 2

61 Produktrapport Innholdsfortegnelse 1 Forord Innledning Gruppen Om oppdragsgiver Get AS BEKK AS Bakgrunn for oppgaven Dagens løsning Oppgavens mål Windows Phone Introduksjon til Windows Phone Metros designprinsipper Typografi Bevegelse Content, not Chrome - Fokus på innhold Autentisk digitalt Navigasjonsmuligheter Panorama Pivot Single Andre navigasjonsveier Tekniske krav til mobile enheter Kodespråk og verktøy Beskrivelse av applikasjonen Konsept Generell beskrivelse Design Funksjonalitet Kontekstuelle menyer (Context Menus) Struktur / navigasjon Struktur i kildekoden MVVM - en introduksjon Hvorfor bruke MVVM Generelt om struktur Presentasjonslaget (View)

62 Produktrapport Mellomlaget (Viewmodel) Modellaget Controller-laget Verktøy (Utilities) REST-laget Datagrunnlag (REST) Hva er en REST-tjeneste? Kundens REST-tjeneste Endpoints Svakheter og uregelmessigheter som må tas høyde for Inkonsekvent parsing av felter (lister) Inkonsekvent parsing av felter (tall) Wrappere Json.NET, deserialisering og converters Isolated Storage Brukere og sikkerhet Feilsøking Teknikker Runtime-feil og exceptions Breakpointing IntelliSense Grensetilfeller Tilbakemeldinger Tilbakemelding fra oppdragsgiver Tilbakemelding fra kunden Tilbakemelding fra Microsoft Utvidelsesmuligheter Videreutvikling av frakoblet modus Minimering av datatrafikk Bruk av live tile Sosial deling Bedre filtreringsmuligheter Hjem-knapp Endring av legg til i kalender -knapp i programsiden

63 Produktrapport 2 Innledning Denne innledningen inneholder bakgrunnsinformasjon for oppgaven, og finnes både i prosess- og produktrapporten. Innledningsvis vil vi beskrive hvem som har vært involvert i prosjektet, bakgrunnen for oppgaven og hva som har vært oppgavens mål. 2.1 Gruppen Gruppen bestod av tre dataingeniørstudenter og én informasjonsteknologistudent: Hans Petter Naumann, Kristofer Selbekk, Alexander Barve og Vegard Nyeng. Gruppemedlemmene har tidligere arbeidet sammen på skoleprosjekter, og kjenner hverandres faglige styrker meget godt. Vi valgte å danne denne gruppen da vi tidligere har hatt god kommunikasjon, sterke faglige kvaliteter og samme, høye ambisjonsnivå. Figur 2.1: Organisasjonskart over alle aktører 5

64 Produktrapport 2.2 Om oppdragsgiver I dette prosjektet har vi hatt to ulike bedrifter å forholde oss til, hvor vi skiller mellom kunde og oppdragsgiver. Kunden, Get AS, har hyrt inn BEKK, vår oppdragsgiver, til å utføre dette prosjektet. Ved prosjektslutt vil Get overta ansvaret for vedlikehold og videreutvikling av applikasjonen Get AS Get AS er en av Norges største leverandører av bredbånd og digital-tv. Med over 500 ansatte og over 1 million kunder, har Get alltid vært grensesprengende innen teknologi. Som første leverandør av bredbånd (1997) og første leverandør av digital-tv i verden med vifteløs HD PVR-dekoder (2007), har Get alltid arbeidet Figur 2.2: Get-logo for å bringe den nyeste underholdningsteknologien til hjem og arbeidsplasser over hele Norge. Get AS vil bli referert til som kunden i fremover BEKK AS Bekk er et konsulentselskap med omkring 300 ansatte, som utvikler IT-systemer for offentlige og private virksomheter. Bedriften, som er eid av Evry, har kontorer både i Oslo og Trondheim. Figur 2.3: Bekk-logo Til prosjektet vårt stilte Bekk med to veiledere: Dan Robert Ekrem og Hans Magnus Inderberg. Dan Robert har sin ekspertise innen interaksjonsdesign, og har bidratt mye innen konseptutvikling og interaksjonsdesign. Hans Magnus er programmerer, og var behjelpelig med innen implementeringsfasen. I tillegg ble vi bistått av grafisk designer Morten Kjøs Utengen, som assisterte oss innen designspørsmål. BEKK AS vil bli referert til som oppdragsgiver i fremover. 2.3 Bakgrunn for oppgaven Kunden har allerede utviklet TV-guide-applikasjoner for ios og Android-baserte telefoner, men ønsket å utvide sin portefølje med en applikasjon for Windows Phone 7, da mange eksperter har foreslått at dette også blir en viktig mobil-plattform i fremtiden. Det fantes ikke noe umiddelbart behov for støtte på denne plattformen, men kunden ville utforske de tekniske mulighetene og være ute på markedet før sine konkurrenter. Deres eksisterende TVguide-applikasjoner innholder en komplett tv-guide, mulighet til å sortere ut kanaler, igangsette opptak på kundens PVR-boks over nettverket, varsling på mobil før tvprogrammer begynner og oversikt over filmene tilgjengelige i kundens filmleie-tjeneste. 6

65 Produktrapport 2.4 Dagens løsning I dag har kunden applikasjoner for ios- og Android-baserte telefoner, i tillegg til webapplikasjoner tilpasset vanlige og mobile nettlesere. ios-versjonen av dagens applikasjon er portet med PhoneGap til Android, og er relativt like hverandre. Begge disse versjonene inkluderer funksjonalitet for å se tv-programmet for den kommende uken, filmer i filmleiedatabasen og søkefunksjonalitet, samt opptaksfunksjonalitet for innloggede brukere. Applikasjonene har fått gode, om enn varierende skussmål på sine respektive salgskanaler, og gjennom å analysere disse tilbakemeldingene fikk vi innsikt i hva vår versjon av applikasjonen burde inkludere. 2.5 Oppgavens mål Målet med prosjektet er å konseptualisere, planlegge og produsere en TV-guide-applikasjon for smarttelefoner basert på Windows Phone 7-plattformen. Applikasjonen som skal utvikles skal inkludere all funksjonalitet som finnes i dagens applikasjoner for ios og Android, og, om tiden tillater, noen nye funksjoner. Applikasjonen skal tilby: TV-guide Muligheten til å velge TV-kanaler som vises Søk i TV-programmet og filmleiedatabasen Fjernstyring av programopptak Muligheten til å lage varsling før et TV-program starter Applikasjonen bør tilby (om tiden tillater): Planleggingsfunksjonalitet Trailerstreaming ved filmleie I tillegg hadde vi følgende overliggende visjoner å strekke oss etter: Lage den beste TV-guiden i Norge Lage den beste WP7-appen i Norge I utgangspunktet skulle vi lage en hybridapplikasjon, som gjør det lettere å forvalte og oppdatere applikasjonen. Det ble det etter hvert tatt en helomvending på, siden det viste seg å være lite hensiktsmessig for plattformen. Vi endte da opp med å implementere applikasjonen i native-kode, C#. Begrunnelsen for dette følger senere i rapporten. Videre ble det ytret et ønske om at applikasjonen designes med hensyn på styrkene og designprinsippene til Windows Phone 7, og at nåværende informasjons-api er blir brukt til sitt fulle potensiale. 7

66 Produktrapport 3 Windows Phone 7 Her vil vi diskutere de styrker og kvaliteter denne plattformen tilbyr, hvilke retningslinjer for design som blir anbefalt, tekniske krav til telefoner, samt hvilke utviklingsverktøy som er tilgjengelige for utvikling av WP7-applikasjoner. I denne seksjonen vil vi gjøre rede for hva Windows Phone 7 (heretter kalt WP7) er, hvilke designretningslinjer og navigasjonsmuligheter plattformen gjør tilgjengelig, tekniske krav til hardware og hvilke kodespråk plattformen programmeres på. 3.1 Introduksjon til Windows Phone 7 Windows Phone 7 er Microsofts nysatsning for mobile enheter. Plattformen erstattet Windows Mobile i 3. kvartal 2010, og baserer store deler av sin grafiske utforming på designspråket Metro Figur 3.1: Windows Phone-motto (også utviklet av Microsoft). Plattformen ble utviklet i samarbeid med en rekke forskjellige hardware-utviklere (Nokia, Samsung, HTC m.fl.), og setter strenge krav til hardware-spesifikasjonene på telefonene som implementerer det. Sent i 2011 kom det en større oppdatering - kodenavn Mango - som blant annet ga støtte for multitasking. 3.2 Metros designprinsipper Metro er Microsofts egenutviklede designspråk, og brukes meget konsekvent på WP7- plattformen. Designspråket, som er basert på klassisk sveitsisk grafisk design, har hovedtyngden sin på bruk av typografi for å skille elementer fra hverandre. For å gjøre tredjepartsapplikasjoner mer tro mot resten av WP7-plattformen, har Microsoft satt sammen en rekke designprinsipper. Under følger en rask introduksjon til de forskjellige framlagte prinsippene, og hvordan vi har forholdt oss til dem Typografi Typografi er kunsten å visualisere tekst på en lesbar måte. Et sentralt poeng i Metro-design er å bruke størrelsen, tykkelsen og formen på teksten til å forme et visuelt hierarki, for å unngå å bruke grafiske elementer som skillelinjer og unødvendige ikoner for å gjøre samme jobben typografi kan oppnå. Microsoft har tilpasset sin egen Segoe-font til mobile plattformer, Segoe WP. Denne fonten er standardfonten i WP7. Det er intet krav om å kun bruke disse fontene, og vi har valgt å bruke en kombinasjon av Segoe WP og kundens egen font - FS Lola - i applikasjonen Bevegelse Bevegelse er her definert som animasjoner og overganger mellom forskjellige views i applikasjonen. Ved riktig bruk av animasjoner oppnår man et mer levende grensesnitt for brukeren, i tillegg til en raskere oppfatning av brukeropplevelsen - man føler at applikasjoner oppfører seg raskere og mer responsivt enn de nødvendigvis gjør. 8

67 Produktrapport Oppdragsgiver ønsket at dette designkravet skulle få mindre fokus enn de andre i vår applikasjon. Derfor har applikasjonen kun implementert enkle overgangs- og innlastningsanimasjoner Content, not Chrome - Fokus på innhold Metro oppfordrer til å fokusere brukeren på innholdet - og ikke inkludere unødvendige grafiske elementer kun for syns skyld. Dette er et godt prinsipp for mobile enheter, siden skjermstørrelse og bevegelses-basert interaksjon da er noe man må ta høyde for. I vår applikasjon - som er meget informasjonstung - hadde vi stort fokus på å maksimere lesbarheten, oversiktligheten og brukervennligheten gjennom nettopp dette prinsippet Autentisk digitalt Metro oppfordrer til å designe med enheten man designer for i bakhodet. En liten, men høyoppløselig skjerm og bevegelsesbasert, rask interaksjon gir muligheten for å utforme brukergrensesnittet autentisk digitalt. Med andre ord - ingen gjenspeilingseffekter, falske bokhyller og andre grafiske elementer som prøver å fremstille enheten som noe annet enn det den er. Vår applikasjonen følger dette prinsippet gjennomgående. Det er ingen tv-antenner, kabler eller andre grafiske elementer som pynter på grensesnittet - alt fokus er på å presentere selve innholdet på best mulig måte for enheten. 3.3 Navigasjonsmuligheter Windows Phone 7 tilbyr tre forskjellige visningsalternativer, kalt panorama -, pivot -, og single -views. Her følger en kort oversikt over hva de forskjellige er og hva de er ment for Panorama Panorama-visning (også kalt panoramaview) er en bred visning med et satt bakgrunnsbilde som beveger seg i en annen hastighet enn elementene som ligger over. Man kan bevege seg horisontalt bortover flere sidestilte views, og slik navigere seg rundt raskt og Figur 3.2: Panoramavisning i Windows Phone 7 enkelt. Sidene i et panoramaview er knyttet sammen i en slags sirkel. For eksempel, hvis man befinner seg i siden helt til venstre, og navigerer én mot venstre, så havner man på siden helt til høyre. Slik er det aldri vanskelig å navigere seg til det ønskede viewet. Microsoft anbefaler å bruke enten denne visningen eller pivot-visningen til applikasjonens oppstartsside, fordi man får en rask oversikt over et større spekter av funksjonalitet og informasjon. Når man er i en side i et panoramaview, vil man ofte kunne se litt av den neste siden til høyre. Slik får brukere et hint om at det finnes mer informasjon tilgjengelig. 9

68 Produktrapport Pivot Pivot-visning ligner på panorama-viewet i at det fungerer på lik måte - man navigerer seg horisontalt bortover flere sidestilte, men adskilte views. Pivot-views blir typisk brukt til å gruppere lignende views av lik viktighetsgrad. I motsetning til panorama kan ikke brukeren her se noe av siden til høyre, men derimot synes overskriften til den neste siden. Pivotsidene er knyttet sammen i en sirkel, i likhet med beskrivelsen av panoramaviewet Single Single-visning er spesielt tilpasset visning av detaljer. De har ingen sidestilte views, og er én-dimensjonale Andre navigasjonsveier I tillegg til de forskjellige visningstypene, finnes det andre måter å navigere gjennom applikasjonen på. Den første er såkalt ContextMenu, som er en navigasjonsmeny som dukker opp når man holder på et element i en liste, og ApplicationBar, som er en halvskjult rekke med ikoner og valg nederst på skjermen. 3.4 Tekniske krav til mobile enheter Figur 3.3: Pivotvisning i Windows Phone 7 Microsoft satt tøffe, men rettferdige krav til hardware-leverandørene da de lanserte Windows Phone 7. Alle enheter som skal implementere WP7 må minimum møte følgende spesifikasjoner: Capacitive, 4-point multi-touch screen with WVGA (480x800) resolution ARM v7 "Cortex/Scorpion" Snapdragon QSD8X50, MSM7X30, and MSM8X55 DirectX9 rendering-capable GPU 256MB of RAM with at least 4GB of Flash memory Accelerometer, ambient light sensor, proximity sensor and Assisted GPS FM radio tuner Six (6) dedicated hardware buttons back, Start, search, 2-stage camera, power/sleep and volume buttons Optional hardware: Front-facing camera, compass and gyroscope Spesifikasjoner er hentet fra Microsofts nettsider. 3.5 Kodespråk og verktøy Windows Phone 7-applikasjoner programmeres i Microsofts egenutviklede programmeringsspråk C#. Språket er et komplett, objektorientert språk, og er meget godt egnet til å utvikle avanserte og sammensatte programmer. Brukergrensesnittene struktureres og stilsettes i Microsofts egenutviklede XAML-strukturspråk. Microsoft har lagt til rette for at utviklere skal benytte seg av MVVM-strukturen der presentasjonslaget, dataen og logikken separeres (som blir forklart noe senere). 10

69 Produktrapport Windows Presentation Foundation (WPF) er rammeverket som tar seg av UI-rendring. WPF gir utvikleren mange sterke verktøy, inkludert databinding - som gir en enkel og effektiv kommunikasjonslinje mellom XAML-strukturkoden og forretningslogikken. Forretningslogikken (skrevet i C#) er basert på Microsofts.NET-rammeverk - og da en lettvektsversjon av.net spesialtilpasset WP7-enheter. Rammeverket tilbyr i tillegg endel praktisk ekstrafunksjonalitet som forenkler utvikling for mobile enheter. For å utvikle WP7-applikasjoner trenger man noen spesialtilpassede verktøy. Microsoft Visual Studio 2010 (med Windows Phone 7 SDK-tilleggspakke), Expression Blend 2010 og Windows Phone 7 Emulator er verktøyene vi brukte - og regnes som en satt standard i WP7- utviklingsmiljøer. Visual Studio 2010 blir generelt sett brukt som programmerings-ide, og tilbyr nyttig funksjonalitet som breakpointing (for debugging), intellisense, en kompilator, og testverktøy. Hva breakpointing og intellisense er, er beskrevet senere i denne rapporten. Expression Blend 2010 blir brukt som et UI-programmerings-IDE, og har et brukergrensesnitt tilpasset utvikling av attraktive, responsive og sammensatte UI-elementer. Windows Phone 7 Emulatoren er verktøyet som kjører selve applikasjonen på datamaskinen - for rask testing av funksjonalitet og utseende. 11

70 Produktrapport 4 Beskrivelse av applikasjonen Vi vil i denne seksjonen gjøre rede for den overordnede strukturen og funksjonaliteten som tilbys i TV-guide-applikasjonen slik at leseren får større utbytte av senere kapitler. Her vil vi gi en innføring til applikasjonens konsept, en generell beskrivelse av hva applikasjonen er og gjør, samt navigasjonsstruktur. 4.1 Konsept Før kodingen av applikasjonen ble påbegynt, gikk gruppen gjennom en grundig konseptutviklingsfase. Vi ønsket å utvikle en applikasjon som tok de beste elementene fra dagens mobile tv-guider, samt nye ideer vi og våre veiledere kom opp med, og sette dem sammen til et enkelt, brukervennlig og strømlinjeformet konsept. Flyten i applikasjonen skulle være intuitiv og effektiv, og det grafiske uttrykket skulle bidra til merkevarebygging for kunden. 4.2 Generell beskrivelse Applikasjonen er en TV-guide - et hjelpemiddel som skal bidra til å forenkle planlegging av tv-kvelden for sluttbrukeren og andre tv-tittere, i tillegg til å øke kundens salg av filmleietjenester. Brukeren blir presentert med en komplett oversikt over dagens tv-program, med søke-, planleggings- og opptaksfunksjonalitet, oversikt over kundens filmleieutvalg (inkludert filmtrailervisning), programvarsling og annen mindre, men smart, funksjonalitet. Nedenfor følger screenshots av et utvalg av sidene som er å finne i den ferdige applikasjonen Design Designet som ble valgt gjenspeiler kundens grafiske profil i alle ledd. Logo ble implementert på oppstartsskjerm og hovedsiden, og kundens selvutviklede font (FS Lola) ble brukt i union med WP7-plattformens egne Segoe WP-fontfamilie. Gulfargen, brukt gjennomgående i applikasjonen, er ment å fremheve kundens varemerke, og gråfargen gir en fin kontrast og fremhever denne. Metro designprinsippene var noe som ble fokusert da den grafiske fremstillingen til applikasjonen ble utformet. Fokuset ble lagt på å strukturere innholdet, og ikke unødvendig støy. Fargebruk og typografi gir informasjon og struktur til brukeren, fremfor å kun være pent. Et eksempel er bruken av farger i kanalvisning, der programmer har ulik farge ettersom de har gått, er pågående eller starter senere. Ved navigasjon mellom sidene er det lagt til animerte overganger. Standard overganger for WP7-plattformen er brukt for å gi applikasjonen en mer integrert følelse, og bidrar til at overgangen mellom views oppleves raskere enn de er. 12

71 Produktrapport Figur 4.1: Førstesiden Figur 4.2: Kanalvisning Figur 4.3: Filmleie 13

72 Produktrapport Funksjonalitet Applikasjonen inneholder mye funksjonalitet under sitt minimalistiske ytre. Brukeren kan logge inn og ut som han eller hun ønsker. Nye kunder, eller brukere som har glemt passord, kan hente ny kode ved å skrive inn telefonnummeret sitt. En innlogget bruker kan ta opptak av programmer, slik at de blir tatt opp på brukerens tvboks hjemme. En innlogget bruker vil også, ved å gå til kanalvelgeren, automatisk få satt opp de kanalene hun eller han har på boksen hjemme i tv-guiden. Kanalvelgeren er selvfølgelig også tilgjengelig for brukere som ikke er logget inn, og lar vedkommende velge kanaler å følge med på. Sett bort fra opptak er alt av funksjonalitet tilgjengelig selv om brukeren ikke er en betalende kunde. En spennende mulighet som tilbys i denne applikasjonen er Min kalender. Dette er en funksjon som hverken finnes i Kundens øvrige mobilapplikasjoner, eller i tilsvarande TV- Guider fra før av. Brukeren kan velge å legge programmet i kalenderen sin fra programsiden eller forskjellige kontekstuelle menyer rundt om i applikasjonen. Hvis programmet er en serie vil brukeren få valget om å legge til hele serien som et abonnement. Programmer i kalenderen, planlagte programmer, vil dukke opp kronologisk i kalenderen, slik at brukeren for en oversikt over planlagte programmer. Ved serieplanlegging vil alle programmene i den aktuelle serien, som går på tv de neste 7 dagene, ligge i kalenderen. Programmer og abonnementer kan fjernes som brukeren selv ønsker fra Min kalender-siden. Planlagte programmer for i dag vises på hovedsiden, mens alle planlagte programmer og abonnementer er å finne på Min kalender-siden. I på tv nå -viewet kan brukeren se hva som går på tv i øyeblikket, på de kanalene hun eller han har valgt. En gul linje representerer en progressbar som viser hvor langt et program har gått i forhold til lengden på sendingen. Fra denne siden kan brukeren gå inn på en hvilken som helst kanal i listen, og få oversikt over hva som går på tv på denne kanelen i dag og de neste 6 dagene. Hver dag har er en egen side i pivot-viewet, så å endre dag gjøres enkelt ved et swipe til høyre eller venstre. Brukeren kan også velge å bli varslet om et program. Dette gjøres like enkelt som opptak, ved et raskt trykk på programsidens varslingsknapp eller gjennom en ContextMenu. En beskjed vil bli vist på telefonen 10 minutter før programmets start. En innebygget reminder-funksjon i operativsystemet er her brukt, og sørger for at brukeren får varslingen uavhengig av om applikasjonen kjører eller ikke. For å implementere varslinger, blir Reminder-klassen brukt. OSet i versjon 7.5 gir ikke direkte tilgang til den innebygde kalenderen, og et kompromiss ble derfor tatt for å allikevel gi brukeren muligheten til å sette varslinger. Sluttbrukeren vil ikke merke videre forskjell, og resultatet blir det samme som gjennom direkte kalenderintegrasjon. Søkefunksjonen er tilgjengelig hvor enn man befinner seg i applikasjonen. Et søkeord er alt som trengs for å søke, og resultatene vises i to forskjellige sider i en pivot; én side for tvprogrammer og én for filmer i filmleiedatabasen. Dette gir et raskt, effektivt søk hvor brukeren enkelt kan finne det hun eller han leter etter. En oversikt over tilgjengelige filmer i kundens filmleie er delt inn i 5 hovedkategorier, og har fått sin egen side i applikasjonen. Her kan brukeren se hvilke nye filmer som har kommet ut, 14

73 Produktrapport hvilke som er i HD, anbefalte filmer, topp 25 og filmer som er på vei ut. Alle øvrige filmer som ikke ligger i en av disse kategoriene kan finnes via søkefunksjonen. Ved å gå inn på en film kan brukeren lese om filmen, se screenshots og eventuelt trailer om tilgjengelig. Trailer vises i liggende fullskjerm-modus. På hovedsiden finnes en delside som heter filmer i dag. Her får brukeren en oversikt over alle filmer som går på tv denne dagen, sortert etter starttidspunkt. Kun filmer som går på kanaler valgt av brukeren vises, slik at mest mulig uinteressant informasjon blir filtrert vekk. I Om appen -siden kan brukeren ringe kundens kundeservice eller besøke kundens kundesupportsider på internett Kontekstuelle menyer (Context Menus) Elementene på noen sider gir mulighet for å åpne en kontekstuell meny ved at brukeren holder en finger over elementet. Disse menyene gir brukeren ulike valg for dette elementet, som for eksempel funksjoner som hører til dette objektet. For eksempel vil contextmenyen til en film i filmer i dag -viewet gi 4 alternativer: gå til film, ta opp, varsle og legg til i kalender. Andre views som tar i bruk contextmenyer er kalender (gå til program, opptak, varsling, fjern program, stopp abonnement), på tv nå (gå til program, opptak), kanalvelger (gå til kanal) og søkeresultater for tv-programmer (gå til program, opptak, varsling, legg til i kalender). Disse contextmenyene bidrar til et renere design da de ikke synes før brukeren holder over et element. Om brukeren ikke er klar over at contextmenyene finnes, er likevel all denne funksjonaliteten, foruten stopp abonnement og fjern fra kalender, tilgjengelig via applicationbaren i enkeltsiden for et program. 15

74 Produktrapport Figur 4.4: Context Menu i "filmer i dag" Figur 4.5: Context Menu i Kanalvelger 16

75 Produktrapport Struktur / navigasjon Applikasjonens navigasjon ble nøye gjennomtenkt. Det var mye informasjon å presentere brukeren, og med tanke på mobilplattformen, liten plass å vise det på. WP7-plattformen tilbyr en rekke forskjellige navigasjonsmuligheter som gjør strukturering av applikasjonens brukergrensesnitt enkelt og strømlinjeformet. Ved oppstart bringes brukeren til en panorama-side med oversikt over hva som går på TV i øyeblikket. Den samme panorama-visningen inneholder en navigasjonsmeny, planlagte programmer for i dag og filmer som går på tv i dag. Videre graving nedover i navigasjonen vil enten bringe brukeren til en pivot-side eller single-side, avhengig av hva som skal vises. Her følger en oversikt over navigasjonsflyten i applikasjonen: Figur 4.6: Oversikt over navigasjonsflyten Gruppen mente denne løsningen på navigasjonen var best av flere grunner. Etter brukertester, sammenligning av lignende applikasjoner på flere forskjellige plattformer, og diskusjoner med kunden internt, kom vi frem til hvilken funksjonalitet som burde være enkelt tilgjengelig, og i hvilken rekkefølge elementene skulle sorteres i. Denne omfattende prosessen blir diskutert nærmere i prosessdokumentasjonen. 17

76 Produktrapport 5 Struktur i kildekoden Her tar vi for oss struktureringen av kode i applikasjonen. Applikasjonens hovedklasser benytter seg av en MVVM-basert kodestruktur for å skille de forskjellige applikasjonslagene. Vi betegner de ulike komponentene som presentasjonslag (View), mellomlag (ViewModel), modeller (Model), kontrollerlag (Controller) og verktøylag (Utility). Applikasjonen begynner med å kjøre filen App.xaml.cs, oppstartsfilen som intialiserer applikasjonen, samt laster inn og deserialiserer lagret data. Brukeren blir så sendt videre til viewet LoadingScreen.xaml, som laster inn data asynkront fra server. Denne seksjonen vil gi en kort introduksjon til kodemønsteret MVVM, samt en oversikt over de forskjellige lagene og hvilke roller de spiller. 5.1 MVVM - en introduksjon Applikasjonen bruker kodemønsteret MVVM (Model-View-ViewModel) for å strukturere kildekode. Det er et utviklingsmønster for applikasjonsutvikling, og er basert på det eldre utviklingsmønsteret MVC (Model-View-Controller). MVVM legger et klart skille mellom design-kode (user interface) og backend-kode. Modeller representerer maler for objekter, eksempelvis kanaler og programmer i dette prosjektet. Views er kodefilene som inneholder brukergrensesnittet - plassering og design av innhold som knapper og tekst. Disse filene er to-delt, med en XAML-basert struktur-del, og en C# basert logikk-del. Det siste laget i MVVM - ViewModels - fungerer som datagrunnlag for brukergrensesnittet, og henter inn informasjonen som skal vises i et view. Informasjonen består ofte av modeller, som viewmodellene kan endre på og restrukturere etter hvilke behov viewet har. Viewene bruker en av WPFs sterkeste verktøy - databinding - til å vise informasjonen i viewmodellene. Dette fungerer slik at et element i design-koden får satt en datakilde, som ligger i viewmodellen, for sine verdier. Denne datakilden spesifiserer dermed innholdet til elementet (om det er en liste, et tekstfelt eller en bakgrunnsfarge), og separerer struktur fra databehandling Hvorfor bruke MVVM Det er flere fordeler med å bruke MVVM som utviklingmønster. At koden for brukergrensesnittet og databehandling skilles gjør at utviklere som jobber med én del av applikasjonen kan gjøre det uten å påvirke/forstyrre det som skjer i en annen del, og vice versa. Dette gjør at utviklere kan fokusere på det de er spesialisert til, og man får mer effektiv utvikling. Selv om det bare skulle være én utvikler på et prosjekt, så vil ofte designønsker, etter brukertesting, endres mot slutten av produksjonen. Da er det gunstig å kunne endre på brukergrensesnittet uten at det påvirker forretningslogikken. MVVM gjør testing av forretningslogikk enklere; man får testet all logikk uten at selve designet blir involvert. Backend-utviklere kan dermed skrive tester for sitt arbeid uten å måtte ta høyde for de problemer som ofte oppstår ved programmatisk testing av brukergrensesnittet. 18

77 Produktrapport For WP7-applikasjoner anbefales det å bruke MVVM som utviklingsmønster. Microsoft skriver på sine websider at det er et naturlig mønster å bruke for XAML-baserte applikasjoner. Figur 5.1: Hvordan de ulike lagene forholder seg til hverandre 19

78 Produktrapport 5.2 Generelt om struktur Applikasjonen bruker en tilpasset implementasjon av MVVM-strukturen. I tillegg til de klassiske lagene for modeller, views og viewmodeller, inkluderer også denne applikasjonen eget Controller-lag, egne utility-klasser og en rekke andre elementer. Dette ble gjort for å maksimere gjenbruk av kode, separere ut datainnhentingsprosessen, og ikke minst for å separere logiske lag fra hverandre. Denne seksjonen vil beskrive de forskjellige lagene denne applikasjonen består av. Figur 5.2: Oversikt over klassene i kildekoden 20

79 Produktrapport Presentasjonslaget (View) Presentasjonslaget inneholder filene som definerer og strukturerer brukergrensesnittet (forkortet UI). Et view består av to filer - en strukturfil og en logikkfil (også kalt code-behind). Strukturfilen blir skrevet i strukturspråket XAML, og inneholder de grafiske byggestenene som sammen former brukergrensesnittet. Viewlagets logikkfiler inneholder event handlers og lyttere som XAML kobles til. Logikkfilene bruker vi for å koble viewet opp mot ViewModel, igangsette navigasjonshendelser og datamanipulasjon i ViewModelen. Viewlagets logikkfiler i MVVM inneholder minimalt med kode, og er i dette prosjektet begrenset til å inneholde en binding opp mot viewets viewmodell, samt logikk for å styre navigasjonshendelser og lignende. Mange MVVM-entusiaster gjør et poeng ut av å ha helt tomme logikkfiler. Dette er mer et spørsmål om såkalt best practice, og gjør lite for den totale ytelsen eller oversikligheten i applikasjonen. Gruppen bestemte seg for at et godt kompromiss - der lite eller ingen forretningslogikk ble godtatt, mens annen logikk for blant annet caching av informasjon og navigasjonshendelser ble bevart i codebehindfilene Stiler og Static Resources For å lette programmering, lesbarhet og gjenbrukbarhet, har gruppen programmert en rekke sentralt definerte stiler - eller statiske ressurser. Eksempler på disse stilene er fonter, farger og hele elementer. Disse er kodeblokker spesifisert kun én gang sentralt i applikasjonen, og beskriver layout og design på spesifikke elementer. Dette medfører langt ryddigere strukturfiler, og gjør store endringer i designet mye raskere å implementere, samt mer konsekvente. Figur 5.3: Opprettelse av en static resource Opprettelse av en static resource: Figur 5.4: Bruk av en static resource Mellomlaget (Viewmodel) Mellomlaget i MVVM, kalt en ViewModel, består av de funksjonene og datafeltene presentasjonslaget presenterer gjennom brukergrensesnittet. Viewet bruker databinding til å koble seg til viewmodelen, og data blir typisk lastet inn gjennom viewmodelens konstruktør. Siden storparten av dataene som vises i applikasjonen hentes inn asynkront over internett, er applikasjonen avhengig av å vise en innlastningsindikator i tiden før all data er overført til telefonen. For å oppnå dette implementerte vi PropertyChanged-rammeverket, som lar presentasjonslaget oppdatere seg selv for hver endring i mellomlaget. 21

80 Produktrapport PropertyChanged er en integrert del av WPF, men må implementeres eksplisitt. Derfor programmerte vi en baseklasse som alle ViewModels deler - ObjectBase - med blant annet denne implementasjonen. Systemet fungerer slik at når et datafelt i mellomlaget endres, sendes det ut en event (eller hendelse) som alle de aktive viewene lytter etter. Når hendelsen blir fanget opp, blir viewet tegnet på nytt, med oppdaterte data. Her er diverse kodeeksempler på hvordan en ViewModel og et View blir koblet sammen ved hjelp av databinding og onpropertychanged-events: Figur 5.5: ViewModel-instansen blir bundet til et view sin datakilde Figur 5.6: Databindingene blir skrevet i XAML-koden til viewet Figur 5.7: For hver property som kan bli oppdatert etter instansieringen av viewet, trengs det en PropertyChanged-event. Denne hender hver gang OnPropertyChanged()-metoden blir kalt Figur 5.8: OnPropertyChange-grensesnittet arves fra ObjectBase-klassen 22

81 Produktrapport Modellaget Applikasjonens forretningsmodeller inneholder informasjonen som blir vist i presentasjonslaget, og restrukturert i mellomlaget. Informasjonen blir hentet inn som JSONobjekter, og modellene er strukturert på en lik måte. Hver modell består av en rekke datafelter som gjenspeiler JSON-strukturen, samt noen deriverte felter. De deriverte feltene bruker de originale feltenes verdier, og returnerer formatterte verdier. Et godt eksempel på et derivert felt er hvordan vi setter aldersgrensestringen i en film ved å ta i bruk andre properties for å skreddersy resultatet: Figur 5.9: En derivert property Figur: En derivert property bruker som regel andre properties til å produsere et skreddersydd resultat. Denne typen modeller blir ofte kalt smarte, av den grunn at de gjør mer enn kun å samle et utvalg objekter og verdier. Dette var å foretrekke siden modellene blir brukt på liknende måte i forskjellige viewmodels, som ellers måtte implementere de samme funksjonene flere ganger Controller-laget I ordinære implementasjoner av MVVM blir data hentet direkte i modellene. Dette valgte vi bevisst å gå bort ifra. For mer sentralisering, gjenbruk og bedre oversikt valgte vi å hente data via controller-klasser - klasser dedikert til datahenting fra REST-tjeneren og fra isolated storage, samt håndtering av brukerdata. Vi endte opp med følgende kontroller-struktur: Kontroller TVController MovieController Rolle Håndterer all datainnhenting rundt tv-program, opptak og søk i tv-databasen Håndterer all datainnhenting rundt filmleie StorageController Håndterer alle kall til og fra Isolated Storage UserController Håndterer alle kall rundt brukere, innlogging og utlogging 23

82 Produktrapport I tillegg til å ta hånd om datainnhenting (og lagring), er kontrollerlaget ansvarlig for mesteparten av logikken i programmet. Slik blir mesteparten av forretningslogikken fjernet fra presentasjon og modellene, og gjør hele strukturen mer oversiktlig og enkel å utvide senere Verktøy (Utilities) Mange funksjoner og konstanter vil ofte bli gjenbrukt flere ganger gjennom applikasjonen, og av ulike klasser. Da er det fordelaktig å sentralisere disse for å gjøre koden mer effektiv og oversiktlig. Dette gjøres gjennom såkalte utility-klasser. Klassene gjør det også enkelt å finne og endre disse sentrale funksjonene og konstantene etter ønske. Hver klasse har en samling metoder og konstanter som har en eller flere likhetstrekk. For eksempel vil metoder som manipulerer dato og tid være samlet i èn utility-klasse - i vårt tilfelle kalt DateUtility. Converter-klasser faller også inn under utilities, men brukes kun av presentasjonslaget. Dette er metoder som for eksempel konverterer et nummer til en farge, eller en boolean til en Visibility-enum. Her er en full oversikt over våre Utility-klasser, og hva de gjør: Navn AppUtility DateUtility NavigationUtility NetworkUtility UrlUtility Settings Beskrivelse Oppsamlingsklasse for alle generelle funksjoner Metoder som konverterer datoer og tidspunkter Hjelpemiddel for å navigere mellom views med minimalt av REST-kall Metoder, events og properties som bidrar til å styre applikasjonen i varierende nettverksforhold Samling av adresser til bruk for REST-kall Samling av innstillinger som kan tenkes å endres på et senere tidspunkt FeaturedColorConverter Konverterer booleans til farger og tilbake igjen StateColorConverter VisibilityConverter Konverterer PlayStates-enumer til farger og tilbake igjen Konverterer booleans til Visibility-enums m.m Settings Etter ønske av kunde, ble en rekke variabler lagret sentralt i filen Settings.cs. Dette er variabler som kunne ønskes å endres fortløpende i en betatest-periode, som antall søkeresultater, standard -kanaler med mer. Disse ble implementert som statiske variabler, og er dermed enkelt tilgjengelig fra hele applikasjonen REST-laget For å lette kontrollernes kall mot REST-tjeneren, utviklet vi et sett med klasser for å standardisere kall mot REST. Disse ble internt kalt REST-laget, og fungerer som et slags underlag av kontrollerlaget. REST-laget gir mulighet for både GET- og POST-kall over HTTP-protokollen. Ved hvert kall sjekker metoden om man har internettilgang, samt om det var parsing-, autentifiserings- 24

83 Produktrapport eller server-feil ved utførelsen. Ved hjelp av egne exceptionklasser gjør dette systemet feilsøking og behandling av spesialtilfeller meget enkelt og oversiktlig. 6 Datagrunnlag (REST) For å få en full forståelse av hvordan applikasjonen henter inn data, er det viktig å ha en viss forståelse for datagrunnlaget - hvor dataene blir hentet fra. Kunden stilte med en selvutviklet webservice - basert på REST-modellen - som returnerer informasjon i JSON- eller XMLformat. I denne seksjonen vil du finne en forklaring av hva en REST-tjeneste er, hvordan REST-tjenesten til kunden fungerer å samarbeide med, hvilke endpoints som er tilgjengelig, og til slutt en oversikt over svakheter og uforutsett oppførsel som må tas høyde for. 6.1 Hva er en REST-tjeneste? REST står for Representational State Transfer. En REST-tjeneste er en såkalt webservice som er tilgjengelig over HTTP-protokollen, og tilbyr et grensesnitt for kommunikasjon mellom en server (REST-tjeneren) og en klient (her - mobilapplikasjonen) over internett. En REST-tjeneste må oppfylle en rekke krav for å bli ansett som RESTfull. Disse er: Separation of concern - En klient trenger kun å vite om grensesnittet til en tjener - og ingenting annet. Dette er for å øke portabiliteten til klienter. Tilstandsløs - Siden kommunikasjonen skjer over den tilstandsløse protokollen HTTP, kan ikke en REST-tjener lagre detaljer om en klient internt mellom kall. Cachebar - For å øke ytelse og skalering, må kall til tjeneren caches hvis de er like siden forrige kall, eller besvares på nytt. Lagdelt system - En klient skal ikke kunne merke forskjell på om den er koblet til den faktiske serveren eller en mellomserver - dette for å øke skaleringsmuligheter. Uniformt grensesnitt - Et uniformt grensesnitt på REST-tjeneren lar både tjener og klient utvikles uavhengig av hverandre. 6.2 Kundens REST-tjeneste Kundens REST-tjeneste er et avansert, komplisert og stort program. Heldigvis, på grunn av kravene som stilles til en RESTfull tjeneste, trenger ikke utviklere av klienten å sette seg grundig inn i hvordan denne tjenesten fungerer. Generelt kan det nevnes at kundens REST-tjeneste tilbyr både XML- og JSON-overføring av data over HTTP-protokollen, som gjør serialisering og deserialisering av data både enkelt og effektivt. Responstiden er kort (~ 500 ms ms) selv for omfattende kall, og grunnet egne kall for binære data (bilder, videoer etc), er datamengden overført minimal. REST-tjeneren bruker en JSON-parser kalt Jackson, et open-source prosjekt som tilbyr både rask og kvalitetssikret JSON-serialisering. 25

84 Produktrapport Endpoints Endpoints er grensesnittet for REST-tjenesten mot klienten, og kundens REST-tjener har et utvalg som er veldig nyttig for senere videreutvikling av applikasjonen. Disse er som følger: Tabell: Åpne REST-kall Metode URL for kall Beskrivelse GET /open/tvguide/batch Lister ut kanaler, pakker, sjangre GET /open/tvguide/events?[&fields=id,name,description...][&channels=1,2,3..][&start= t10:00][&duration={minutes}][&maxcount=0-n][&search=..] Henter tvprogrammer/events sortert på kanal. GET /open/tvguide/events/{eventid} Henter ut detaljer om en event GET /open/tvguide/channels Henter ut alle kanaler GET /open/tvguide/channelgroups Henter ut beskrivelse av kanalpakkene med kanalid'er POST /open/tvguide/pin/reset POST: "phone" Sender en tekstmelding til det spesifiserte telefonnummeret med ny pinkode GET Justerer størrelse på bilde med spesifisert enonic-id/key GET /open/moviesguide/shallowmovielists Henter navn og ID på alle filmlister GET /open/moviesguide/batch [moviesinlistcount={antall}] Henter filmsjangre og filmlister GET /open/movieguide/movielists Henter filmlister med filmer GET /open/movieguide/movielists/{listid} Henter en gitt filmliste GET GET /open/tvguide/eventgenres Henter ut alle eventsjangerere /open/image/cms/resize?key={enonic-content-key}&height={pixelheight}&width={pixel-width} /open/movieguide/movies?[&fields=id,title...][&fromindex=0-n][&maxcount=0- n][&search=...][&genres=1,2,3] Henter et gitt utvalg av filmer fra filmleiedatabasen GET /open/movieguide/movies/{movieid} Henter en gitt film GET /open/movieguide/moviegenres Henter filmsjangre 26

85 Produktrapport Tabell: REST-kall som krever autentifisering (uautoriserte kall returnerer status kode 403) Meto de POST POST URL for kall POST: "auth_tvguide_username", "auth_tvguide_password" [rememberme=true] POST: "auth_unregisteredcustomer_customerid","auth_unregisteredcustom er_dateofbirth","auth_unregisteredcustomer_postalno" [rememberme=true] Beskrivelse For å bli autentisert må man gjøre en POST som inneholder parameterne "auth_tvguide_username" og "auth_tvguide_password". Kunden kan da logge inn med enten telefonnummer/pin eller brukernavn/passord fra minside. Rememberme flagget kan brukes dersom man ønsker at brukeren skal være logget inn over tid For å autentisere en GET-kunde som ikke er registrert på minside må man gjøre en POST som inneholder parameterne ovenfor. Rememberme flagget kan brukes dersom man ønsker at brukeren skal være logget inn over tid GET /authenticated/tvguide/loginstatus Gir ut status på kunden som er logget inn (kundeid, organization, partner etc) GET /authenticated/tvguide/subscriptions Abonnementdetailjer for den innloggede kunden: loginstatus + channelsubscriptions (fungerer også for partnerkunder) GET /authenticated/tvguide/channelsubscriptions Henter ut kanalene til en GET-kunde (fungerer ikke for partnere) POST /authenticated/tvguide/pin/set POST: "phone", "pin" Lagrer/erstatter pinkode for å logge inn på tvguiden for det spesifiserte telefonnummeret (phone parameteret) POST /authenticated/tvguide/record/{eventid} Sender et opptak til dekoderen registerert på kunden 6.3 Svakheter og uregelmessigheter som må tas høyde for Grunnet kompleksiteten til kundens REST-tjeneste, er det noen spesialtilfeller som må tas høyde for. Denne seksjonen vil informere om de gruppen har funnet, og har måttet ta høyde for under utviklingen av applikasjonen Inkonsekvent parsing av felter (lister) Når man ber serveren om et spesielt sett med events (tv-programmer) eller filmer, vil JSONdataen som blir returnert være strukturert relativt inkonsekvent. Mange felter kan ha null eller flere medlemmer - og dette kan skape trøbbel under deserialiseringen av JSON. Et eksempel her er skuespillere som er med i en film - noen ganger kan REST returnere et enkeltfelt: actors : Jean-Claude Van Damme Andre ganger kan den derimot returnere en liste med skuespillere: actors : [ Angelina Jolie, Brad Pitt, Matt Damon ] 27

86 Produktrapport Dette er noe som må tas høyde for i JSON-deserialiseringen gjennom såkalte JSONconverters. Deserialiseringsrammeverket som blir brukt i applikasjonen (Json.NET) lar programmereren lage egne konverterere som tar høyde for slik inkonsekvent parsing Inkonsekvent parsing av felter (tall) Når man ber serveren om et spesielt sett med events (tv-programmer) eller filmer, vil JSONdataen som blir returnert være tall-sensitiv. Et godt eksempel på dette er titler til programmer. Når man ønsker å få ut programmet 24 - en klassisk historie om spesialagenten Jack Bauer - vil man få tilbake følgende utsnitt JSON: title : 24 Deserialiseringsrammeverket vil da anta at title -feltet er av typen int, mens det i virkeligheten er av typen string. Dette er noe som må tas høyde for i JSON-deserialiseringen gjennom såkalte JSON-converters Wrappere All respons fra REST-tjenesten blir returnert inkapsulert i såkalte wrappere - JSON-objekter som har som oppgave å innhylle returnert data i et ekstra lag. Dette er ofte et krav for gyldig JSON, og er noe som må tas høyde for på klientsiden. I denne implementasjonen har gruppen valgt å lage eksplisitte klasser som fungerer på samme måte som i JSON - kun for wrapping av indre objekter. Det er også mulig å lage såkalte JSON-converters - deserialiseringsrammeverket som blir brukt i applikasjonen (Json.NET) lar programmereren lage egne konverterere som tar høyde for wrapper-klasser. 6.4 Json.NET, deserialisering og converters Json.NET er et rammeverk for å serialisere og deserialisere mellom JSON og C#. Dette rammeverket har mange store fordeler over det innebygde DataContractJsonSerializer, men spesielt så er Json.NET mer fleksibelt i forhold til hvordan (de)serialiseringen blir gjort. For å kunne ta høyde for inkonsekvent serialisering fra server, ble det programmert såkalte converters, som blir brukt i deserialiseringen. Disse converter-klassene er spesiallaget for kundens REST-tjener og dens oppførsel, og tar høyde for problemer som feilformatterte lister og strenger. Converter-klassene implementeres ved å bruke en JsonReader, som leser gjennom en JSONstreng token for token. Et token i JSON er spesialtegn som separerer elementer, og ved å lese gjennom hvert token kan man ta høyde for alle situasjoner og legge inn tester for de spesialtilfellene som blir oppdaget. Systemet som er implementert i applikasjonen i dag er både robust og enkelt å videreutvikle. 28

87 Produktrapport 7 Isolated Storage Isolated Storage er WP7s interne rammeverk for lokal lagring av data. Et avgrenset lagringsområde blir reservert for hver applikasjon, og dette lagringsområdet blir benyttet som et privat filsystem. Vår applikasjon benytter dette for å lagre nedlastet data mellom kjøringer. Når man skal lagre data med Isolated Storage har man to muligheter, lagre til fil(er) eller lagre til Isolated Storage Settings. Sistnevnte er en fil som er innebygget i applikasjonens Isolated Storage område, med innebygget funksjonalitet for lagring og uthenting. Istedenfor å lage avanserte lagringsalgoritmer kan man enkelt lagre egendefinerte objekter. Lagring og uthenting av data blir automatisk håndtert etter delegering fra utviklernes side, så lenge programmereren klargjør dataen for lagring. Isolated Storage Settings er implementert som et Dictionary-objekt, som parer opp nøkler og innhold. Man kan lagre en instans med et nøkkelord, som senere brukes for å hente ut den samme instansen. For å lagre en instans av et objekt er instansens modell-klasse nødt til å: 1. implementere serialisering på feltene som skal lagres 2. spesifisere hvilke felter som ikke skal lagres (alle datatyper har ikke støtte for serialisering) Applikasjonens datamodeller implementerer DataContract-attributten, som delegerer til en klient hvilke felter som skal serialiseres, og hvilke felter som skal ignoreres. Lagring av data skjer når brukeren lukker applikasjonen. All informasjonen (foruten passord) samles i en wrapper-klasse definert for å forenkle lagring, samt videreutvikling. Istedenfor at eventuelle senere utviklere er nødt til å lage egne håndteringssystemer for tidligere versjoner av applikasjonen når man forbereder en oppdatering av applikasjonen, kan utviklerne nå endre på innholdet i modellklassen, mens selve lagringen skjer på samme måte. Passord blir lagret kryptert som en egen nøkkel hver gang en ny bruker logges inn, og blir fjernet ved utlogging. Ved oppstart av applikasjonen hentes lagret informasjon inn fra Isolated Storage før brukeren blir sendt videre til det første vinduet. Det er nødvendig at brukeren venter på denne innhentingen fordi innhenting av data fra REST avhenger av informasjonen i Isolated Storage. Feilhåndtering har blitt implementert i både innhentingen og lagringen. Ved første kjøring opprettes tomme lister, og standard-data for brukerne blir opprettet. Ved første lagring av data opprettes nye felter i Isolated Storage. 29

88 Produktrapport 8 Brukere og sikkerhet Mobile applikasjoner er en personlig opplevelse - og TV-guide-applikasjonens funksjonalitet bærer preg av nettopp dette. Det er for eksempel mulig å logge inn som en annen bruker, men informasjonen i min kalender, abonnementer og varslinger blir delt uavhengig av brukere. En slik forenkling er ønskelig for de aller fleste brukere slik at applikasjonen ikke tar for lang tid å sette opp, og er selvforklarende slik at brukere ikke behøver å lese instruksjoner. Det gjør at brukere slipper å stusse over hvorfor innhold blir borte hvis en annen person logger inn på applikasjonen for å starte et opptak. Innlogging eksisterer i dagens mobilapplikasjoner bare for å støtte èn funksjon - for å kunne fjernstyre opptak. All annen funksjonalitet i applikasjonen er tilgjengelig uten å være innlogget. Innloggingen skjer via REST-tjeneren, og gjør at applikasjonen ikke stiller store krav til sikkerhet da alle sensitive detaljer blir håndtert internt. Applikasjonen støtter funksjonalitet for automatisk pålogging ved oppstart, slik at en bruker forblir pålogget til han eller hun selv logger ut. Både passord og brukernummer blir lagret i Isolated Storage. Andre applikasjoner har ikke tilgang til applikasjonens lagringsområde, men for å øke sikkerheten krypteres passordet gjennom krypteringsalgoritmen ProtectData. 30

89 Produktrapport 9 Feilsøking Denne seksjonen vil beskrive teknikker og metoder for å finne, utbedre og rette eventuelle feil og svakheter i kildekoden, samt å diskutere de forskjellige feiltyper som kan oppstå, og hvordan man angriper problemet. Gruppen har selv brukt disse problemløsningsmetodikkene under utviklingen, og anser dem som sterke nok til å løse de aller fleste problemer som måtte oppstå. Å feilsøke en Windows Phone 7-applikasjon er relativt enkelt, gitt nok tid til å grave seg ned i programmet. Applikasjonen er velstrukturert, og med de rette teknikker og verktøy er feilsøking ingen vanskelig oppgave. 9.1 Teknikker Her vil vi beskrive de forskjellige teknikkene og verktøyene som burde bli brukt under eventuell feilsøking - tolking av runtime tilbakemeldinger og exceptions, breakpointing og riktig bruk av IntelliSense Runtime-feil og exceptions Hvis applikasjonen stopper under kjøring av kodelinje eller lasting av et spesifikt view, avslutter applikasjonen brått og uhøytidelig. Ofte når dette skjer, er det på grunn av såkalte uhåndterte exceptions. Slike uhåndterte feil gir som regel en informativ feilmelding til programmereren, og kan peke mot hvor feilen ligger og hva slags feil det er. Selv om mange exceptions er lite beskrivende - som for eksempel en NullReferenceException - er det mange feil som kun skjer ved utføring av spesifikke metoder. Ved aktiv bruk av aktuell dokumentasjon og breakpointing, er slike feil relativt raske å peke ut og rette opp. Figur 9.1: Feilmeldinger i Visual Studio 31

90 Produktrapport Breakpointing Breakpointing - eller teknikken ved å pause utføringen av programmet på bestemte punkter - kan være en meget effektiv måte å finne hvor en feil oppstår, og hva som resulterte i den. Hvis man finner et punkt i programmet rett før der man tror feilen oppstår, kan man gjennom IDEen sin (for eksempel Visual Studio 2010) utforske verdiene til lokale variabler, se hva som skjer linje for linje, og enkelt finne årsaken til at applikasjonen ikke fungerer som den skal. Figur 9.2: Breakpointing i Visual Studio IntelliSense IntelliSense er Microsofts system for å autofullføre variabelnavn, dokumentere funksjoner og mye annet. Systemet er integrert i Visual Studio 2010, og er i tillegg et godt verktøy for å se hvilke variabler, metoder og klasser som til enhver tid er tilgjengelig før kompilering. Dette letter programmeringsjobben betraktelig, og er en nyttig måte å sjekke hvilke referanser man har glemt å inkludere i en gitt klasse. Figur 9.3: IntelliSense i Visual Studio Grensetilfeller Ved feilsøking av problemer som kun skjer innimellom, er det viktig å sjekke grensetilfeller. Mange feil har blitt oppdaget ved overgangen fra én dag til en annen, én måned til en annen, eller andre overganger. Ved registrering av slike feil (for eksempel gjennom intern brukertesting eller innringninger til kundeservice), er det viktig å merke seg detaljene rundt problemet - som dato og 32

91 Produktrapport tidspunkt, søkeord, program forsøkt åpnet osv. Med disse detaljene står en feilsøker mye sterkere stilt i forhold til å løse slike irregulære problemer. 10 Tilbakemeldinger 10.1 Tilbakemelding fra oppdragsgiver Oppdragsgiver overleverte en attest til oss ved prosjektslutt. De var svært fornøyde med innsatsen vår. Attesten ligger som vedlegg til denne rapporten Tilbakemelding fra kunden Vi har ikke fått noen skriftlig tilbakemelding fra kunden. De har derimot ytret stor begeistring over sluttproduktet. Sitat fra Marius Haugen: Denne her går rett ut på markedet! Tilbakemelding fra Microsoft Vi fikk tillatelse til av oppdragsgiver, og gleden av, å få vise frem applikasjonen vår til Microsoft Norge, for å høre hva de syntes om produktet. Følgende er hva Petri Wilhelmsen, Developer Marketing manager & Academic Developer Evangelist hos Microsoft, hadde å si om resultatet vårt: Etter å ha testet Get TV-guide appen må jeg si meg meget fornøyd med opplevelsen. Ikke bare har utviklerne klart å bruke Metro Design grensesnittet slik Microsoft ønsker at Windows Phone appene skal være, men også klart å brande appen med kundens behov. Flyten var bra, og innholdet kom i fokus slik at det til enhver tid ikke var noe spørsmål om hvor i appen jeg befant meg, og hva jeg skulle oppnå. Appen føltes som en integrert del av telefonen og jeg trengte ikke å lære meg noe nytt for å bruke den. En vel gjennomført app - gleder meg til å kunne bruke denne selv. 33

92 Produktrapport 11 Utvidelsesmuligheter Applikasjonen er funksjonell, komplett og ferdigstilt slik den står i dag. Vi mener likevel at videre utvikling kan gagne sluttbrukeren i visse brukssituasjoner, samt å gi brukeren muligheten til å dele sin opplevelse gjennom sosiale medier. Denne seksjonen vil utdype muligheten for forskjellige funksjonaliteter og tillegg som det ikke fantes tid til å implementere innen prosjektets satte tidsfrister Videreutvikling av frakoblet modus Dagens applikasjon har begrenset funksjonalitet uten tilkobling til internett - en situasjon mang en mobilbruker finner seg i på vei til og fra jobb, på hyttetur eller til og med i hjemmet. I dag åpner applikasjonen, og lar deg se informasjon om alle dine planlagte programmer, men gir deg ikke tilgang til cachet informasjon fra sist gang du hadde dekning. Å videreutvikle denne funksjonaliteten er kun et spørsmål om smart og effektiv lagring av eksisterende data i Isolated Storage. Rammeverket rundt dette er allerede på plass i dag, så implementasjonen vil ikke være utfordrende Minimering av datatrafikk Mobile applikasjoner har en tendens til å spise opp mobilregningen til mange gjennom overdreven datatrafikk. Selv om dagens applikasjon er relativt konservativ på antall kall til REST-tjeneren, så kan mengden datatrafikk og responstid fortsatt nedjusteres gjennom videreutvikling av algoritmer for hvilke data som må hentes inn til enhver tid. Én måte å spare datatrafikk er å lagre kanallogoer lokalt på telefonen mellom tilkoblinger til trådløse nettverk. Grunnet lav støtte for lagring av PNG-bilder på WP7, ble dette ansett som en oppgave for tidskrevende for dette prosjektets tidsrammer Bruk av live tile En av de viktigste, innovate løsningene som har blitt implementert i Windows Phone 7 er live tile-systemet. En tile er rett og slett en firkant som okkuperer hovedmenyen på telefonen. I denne firkanten kan man ha en logo og en egen bakgrunnsfarge, og den kan fylles med tekstlig informasjon som kan forandres. Slik kan brukere få informasjon fra en applikasjon inn på hovedsiden uten å behøve å starte den. Det er selvfølgelig begrenset hvor mye funksjonalitet man kan tillegge en live tile, men det er en praktisk løsning for en hektisk hverdag. For å implementere live tile oppdateringer er man nødt til å benytte background tasks slik at selv brukere som ikke har kjørt applikasjonen på flere dager, fremdeles vil få oppdateringer i sin live tile. Det finnes flere alternativer i Windows Phone 7 for å synkronisere data i bakgrunnen, blant annet IntensiveTaskAgent for større mengder data og PeriodicTaskAgent for mindre mengder data regelmessig. Figur 11.1: Live tiles 34

93 Produktrapport Denne tjenesten er nødt til å hente inn tv-guide data og legge til nye oppdateringer i køen. Denne funksjonen har ikke blitt implementert fordi det er et tidkrevende system å sette seg inn i og tiden strakk ikke til. Men vi mener bruk av live tile vil være en naturlig prioritet for videreutvikling da det både gir mening for typen applikasjon som har blitt utviklet, og er en viktig del av Windows Phone 7. Et eksempel på en mulig funksjon vår applikasjon kunne hatt via en live tile er det neste programmet i brukerens kalender Sosial deling Å dele informasjon, opplevelser og oppdateringer på sosiale nettverk har blitt en trend de siste årene, og Windows Phone 7 har strålende integrasjon for nettopp dette. Implementasjon består av kun noen linjer kode, men grunnet manglende avgjørelser rundt om dette skulle bli implementert før kodefasen ble avsluttet, ble ikke dette implementert Bedre filtreringsmuligheter Applikasjonen tilbyr i dag, som de fleste andre tv-guider laget for telefoner, ingen filtreringsmuligheter for hva som går på tv til en gitt tid. For eksempel kunne man valgt klokken 21 i morgen, og fått et view liknende på tv nå, men med klokkeslettet 21 i morgen som utgangspunkt fremfor det klokken er nå. Dette var tanken å gjennomføre med Programoversikt -viewet, som er ført opp i kravspesifikasjonen under ekstra funksjonalitet. Det ble ikke tid til gjennomføring av dette viewet i dette prosjektet, men alt ligger til rette for at det kan bli implementert på et senere tidspunkt. Andre filtreringsmuligheter kunne vært filtrering basert på sjanger, kanaler o.l. Både programmer og filmer man får ifra REST har sjanger, så dette kan like enkelt implementeres som tidsfiltrering nevnt over Hjem-knapp I dagens versjon av applikasjonen finnes det ingen annen måte å navigere tilbake til hovedsiden enn å trykke back-knappen på telefonen. Ved mye navigering innover i applikasjonen vil brukeren trenge å trykke opptil flere ganger på back-knappen for å navigere seg tilbake til hovedsiden. Dette kunne blitt løst ved å ha en til hovedsiden -knapp, for eksempel i applicationbar. Dette vil være svært enkelt å implementere, og er kun et spørsmål om hva kunden ønsker Endring av legg til i kalender -knapp i programsiden På programsiden til et program som allerede er lagt til i kalender, er fortsatt legg til -ikonet, plusstegnet, synlig. Ved trykk gir den en beskjed om at programmet allerede er planlagt. En mulig utvidelse hadde vært å deaktivere (fade ut) dette ikonet hvis programmet allerede er planlagt. Eventuelt kunne ikonet gjøres om til et minus-tegn, og gi brukeren mulighet til å fjerne programmet fra kalender herfra. I likhet med hjem-knappen er dette en utvidelse som er enkelt å implementere, som bare avhenger av Kundens ønsker. 35

94 Produktrapport Referanser brukt:

95

96 Kravspesifikasjon

97 Kravspesifikasjon 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. Kravspesifikasjonen definerer i tillegg prosjektets rammer og krav til funksjonalitet og design. Utviklingsprosessen foregår etter den smidige utviklingsmetodikken Scrum. Å jobbe på denne måten vil si å levere produktet fortløpende i delleveranser slik at deler av funksjonaliteten blir implementert og kan bli godkjent av kunden. Kravspesifikasjonen er basert på de krav som ble stilt oss både ved prosjektstart og under utviklingsfasens iterasjoner. Kravene ble presentert oss som både individuelle user stories og referanser til eksisterende applikasjoner. Implementasjon av denne funksjonaliteten blir diskutert i prosess- og produktrapportene. Kravene ble delt i to forskjellige kategorier - minimumskrav og ønsket ekstrafunksjonalitet. Minimumskravene ble ansett som førsteprioritet, mens ønsket ekstrafunksjonalitet ble sett på som mulige arbeidsoppgaver om tiden tillatte. Kravspesifikasjonen har fungert som et styringsdokument for gruppen, som har endret seg fortløpende. Siden vi oppdaterte kravspesifikasjonen når vi mottok nye ønsker fra oppdragsgiver, har kravspesifikasjonen utviklet seg etterhvert som prosjektet har det. 2

98 Kravspesifikasjon Innholdsfortegnelse 1 Forord Innledning Bakgrunn for oppgaven Systemkrav Kundens krav til funksjonalitet Ønsket tilleggsfunksjonalitet Tekniske krav Krav til koden Designkrav Generelle designkrav Bruk av farger og fonter - merkevarebygging Dokumentasjonskrav Konklusjon

99 Kravspesifikasjon 2 Innledning Prosjektet gjennomføres som hovedprosjekt ved HiOA avd. for ingeniørutdanning i for Bekk Consulting AS og deres kunde Get AS. Det skal produseres en TV-guide-applikasjon for Windows Phone 7-baserte smarttelefoner. Applikasjonen skal ha samme funksjonalitet som dagens versjoner på ios- og Android-telefoner, og være designet i tråd med Metro designsprinsipper. Bekk skal utvikle denne applikasjonen for Get AS (heretter referert til som kunden) og vi vil utvikle applikasjonen for Bekk (heretter referert til som oppdragsgiver). Innledningsvis bestod kravspesifikasjonen av kundens krav til funksjonalitet, som innebærer at applikasjonen skulle ha samme funksjonalitet som kundens øvrige mobilapplikasjoner for ios og Android. Videre funksjonelle krav har blitt lagt til underveis i utviklingsprosessen. En konsekvens av dette har vært at vi ikke har hatt en kravspesifikasjon som et ferdig styringsdokument fra start av. Krav til design og kode har blitt satt i samhold med oppdragsgiver og kunden. 2.1 Bakgrunn for oppgaven Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. De har i dag tv-guide-applikasjoner for Android og ios-baserte telefoner, og ønsker en tilsvarende applikasjon utviklet til Windows Phone 7-plattformen. 4

100 Kravspesifikasjon 3 Systemkrav 3.1 Kundens krav til funksjonalitet Kundens grunnleggende krav er å implementere all funksjon dagens ios- og Androidapplikasjoner tilbyr. Følgende krav er satt av kunden og beskriver grunnleggende funksjonalitet til applikasjonen. Applikasjonen skal tilby: TV-Guide o Visning av hva som går på TV nå o Visning av hva som går på TV flere dager fremover o Visning av enkeltprogrammer o Muligheten til å endre kanalene som vises o Mulighet til å ta gjøre opptak av et program hvis man er logget inn o Mulighet til å legge inn varsel før enkeltprogrammer Filmleie o Visning av de ulike redaksjonelle listene med filmer o Visning av enkeltfilmer Mulighet til å logge inn Mulighet til å be om nytt passord Lokal lagring av brukerdata slik at applikasjonen har samme tilgang ved ny oppstart 3.2 Ønsket tilleggsfunksjonalitet Følgende krav er tilleggsfunksjoner, som gjennom utviklingsprosessen, ble ønsket av oppdragsgiver. Disse funksjonene er ikke nødvendigvis implementert i kundens eksisterende mobilapplikasjoner, men ønskes utforsket og eventuelt implementert. Selv om hovedfokuset var på å få til den grunnleggende funksjonaliteten kunden ønsket å ha i en TV-guide, var det flere andre funksjoner som ble prioritert inn etterhvert. Disse ble satt av veilederne i BEKK i samarbeid med gruppen, for så å bli godkjent av kunden: Håndtering av frakoblet modus Mulighet til å logge ut En planleggingsfunksjon der brukeren kan planlegge enkeltprogrammer og abonnere på favorittseriene sine Visning av trailere i filmleie-delen En oversikt over filmer som går på tv i dag 3.3 Tekniske krav Applikasjonen skal utvikles i C#og XAML, og kunne kjøres på alle versjoner av Windows Phone 7 Brukeren skal vente kortest mulig på at innhold laster Ved innlasting skal det vises en nedlastingsindikator, slik at brukeren skjønner at innholdet er på vei Kanallogoer og bilder skal lastes inn asynkront etter annet innhold er lastet 5

101 Kravspesifikasjon 3.4 Krav til koden Det ble av oppdragsgiver definert muntlig hva som er forventet av koden som blir produsert. Vi ble enige i at all kode og alle kommentarer skal skrives på engelsk, og føre en konsekvent linje på det. Ellers skal koden være mest mulig oversiktlig, og gjøre det enklest mulig for kunden å overta, vedlikeholde og videretuvikle applikasjonen. Utviklingsmønsteret MVVM skal benyttes for å strukturere koden Navn på klasser, metoder og variabler skal være såpass forklarende at det ikke er nødvendig med kommentarer Koden skal implementeres og struktureres slik at den enkelt kan utvides med ny funksjonalitet 6

102 Kravspesifikasjon 4 Designkrav 4.1 Generelle designkrav Enkel, brukervennlig design som er lett å sette seg inn i for en ny bruker. Bruk av prinsippene i Metro Design vil gjøre det enklere for brukere som er vant til Windows Phone 7 å sette seg inn navigasjon i applikasjonen. Logisk navigasjon - det skal være enkelt for brukeren å finne det innholdet han/hun leter etter. Ved omdirigering til en ny side skal det være logisk for brukeren hvorfor denne siden blir vist. Det skal kunne søkes fra hvor som helst i applikasjonen. Søkeresultater skal deles inn i to kategorier: resultater for tv-programmer og resultater for filmer i filmleie. Ved forsøk på opptak skal brukeren sendes til login-vinduet hvis han/hun ikke er logget inn. Det skal skilles mellom programmer som har vært og kommende programmer - for eksempel ved bruk av farger. Bruk av såkalte pivot views der det passer seg - for eksempel i kanalvisning, der kanalprogrammet for hver dag (i dag, i morgen osv) har hver sin side inne i pivoten. 4.2 Bruk av farger og fonter - merkevarebygging Kunden ønsker at applikasjonen skal gi assosiasjoner til deres merkevare ved å: Benytte oss av kundens egen font der det passer Eksklusivt bruke kundens gulfarge Bruke et mørkt eller lyst tema Presentere kundens logo og merkevare sublimt gjennom applikasjonen 7

103 Kravspesifikasjon 5 Dokumentasjonskrav Oppdragsgiver krevde ingen dokumentasjon. Likevel delte vi hele Google Docs-mappen til oppdragsgiver, som inneholder alle filer med dokumentasjon til alle involverte i prosjektet, i tilfelle diverse dokumentasjon skulle være ønskelig. 6 Konklusjon Kravspesifikasjonen har spilt en sentral rolle for oss da det gjaldt å definere prosjektets rammer og omfang. Prosjektets rammer var definert på en måte som gjorde at utviklingen av selve applikasjonen sin funksjonalitet var fleksibel og tilpasningsdyktig. Ved å ha et krav om at applikasjonen skulle ha samme funksjonalitet som kundens øvrige mobilapplikasjoner, men mulighet for ny funksjonalitet gjennom nye iterasjoner, hadde vi et godt fundament for hva som skulle jobbes med, samtidig som kunden var sikret noe brukbart ved prosjektslutt. Det ferdige produktet tilfredsstiller alle krav fra kunden, både med tanke på funksjonalitet, design og kode. All ekstrafunksjonalitet, foruten ett punkt, ble implementert. Dette var over all forventning fra kunden. Basert på dette, og tilbakemeldinger fra oppdragsgiver og kunden, legger vi til grunn at vårt produkt samsvarer med kravspesifikasjonen og overgikk forventningene til oppdragsgiver og kunden. Oppfyllelse av krav er i mer detaljert form beskrevet i produktrapporten. 8

104

105 Testrapport

106 Testrapport Innholdsfortegnelse 1 Innledning Mål med testing Funksjonalitet Responsivitet Oppførsel med varierende nettverkstilgjengelighet Godkjenning til Microsoft Marketplace Verktøy og enheter brukt ved testing Asus N53S (laptop) Samsung Omnia 7 (telefon) Nokia Lumia 800 (telefon) Hva slags tester ble utført? Testing i utviklingsfasen Testing på mobil Dekningstesting Brukertesting Test av funksjonalitet Testresultater Responsivitetstester Datainnhenting over forskjellige nettverksforbindelser Manuelle tester for Marketplace godkjenning Automatiske tester for Marketplace godkjenning Brukertester Kommentarer til brukertestrespons Konklusjon

107 Testrapport 1 Innledning Gruppen har arbeidet i en iterativ utviklingsprosess, og hver funksjon, hvert konsept og hver delleveranse har blitt grundig testet i emulator og på telefon før godkjennelse. Utviklingsprosessen var ikke testdrevet. Det ble ikke skrevet programmatiske tester for koden, og dette ble gjort av to grunner - gruppen hadde lite erfaring med denne type utvikling fra før av, og veilerede ønsket å fokusere på implementasjon og funksjonalitet over slike programmatiske tester. Dette dokumentet gir leseren en oversikt over hva slags tester som ble utført og resultatene de ga. 3

108 Testrapport 2 Mål med testing Ved testing av enhver mobil applikasjon, er det visse mål som bør prioriteres. Avhengig av plattform, hensikten til applikasjonen, sluttbrukeren og tidsrammer, vil testing bli utført til forskjellige standarder og nivåer. TV-guide-applikasjonen ble testet spesifikt for en rekke mål, som er beskrevet under. 2.1 Funksjonalitet At generell funksjonalitet virker som det skal er viktig for at applikasjonen i det hele tatt skal være brukbar. Alle knapper og navigasjonsmuligheter må derfor testes nøye. 2.2 Responsivitet Enhver mobil applikasjon skal være rask, lett og responsiv ved normal bruk. Verifisering av innlastningstider for data, forsinkelser ved navigasjon, kalkulasjonseffektivitet osv. er gode tester for å kunne forsikre seg om at generell responsivitet er på et akseptabelt nivå. 2.3 Oppførsel med varierende nettverkstilgjengelighet Mobile enheter er utviklet for bruk også utenfor hjemmet, og den aktuelle applikasjonen er spesielt beregnet for slikt bruk. Å teste applikasjonen på en mobil på forskjellige tilkoblinger (f.eks. 3G, Edge og WiFi), vil gi utvikleren stor innsikt i hvilke situasjoner problemer kan oppstå - og gi muligheten til å rette opp i slike problemer før lansering. 2.4 Godkjenning til Microsoft Marketplace For å få distribuert en Windows Phone 7-applikasjon, er det viktig å få den godkjent for Microsofts distribusjonssentral for apps - Marketplace. Visual Studio 2010 inkluderer et nyttig verktøy, med en rekke automatiserte og manuelle tester for å kunne sjekke om applikasjonen ville blitt godkjent for utsendelse gjennom denne salgskanalen. 4

109 Testrapport 3 Verktøy og enheter brukt ved testing Gjennomføringen av testene ble gjort på forskjellig typer hardware. Funksjonstesting og feilsøking ble i stor grad utført på en datamaskin, og generell brukertesting, nettverkstesting og responstesting ble utført på to forskjellige mobiltelefoner. 3.1 Asus N53S (laptop) Intel Core i7 firekjerneprosessor (2.2 GHz) 8 GB DDR3 internminne Windows 7 Ultimate operativsystem 3.2 Samsung Omnia 7 (telefon) Qualcomm QSD8250 énkjerneprosessor (1.0 GHz) 512 MB SDRAM internminne (antatt) 8 GB lagringsplass 4.0 AMOLED skjerm Ventelo tjenesteleverandør 3.3 Nokia Lumia 800 (telefon) Qualcomm MSM8255 énkjerneprosessor (1.4 GHz) 512 MB SDRAM internminne 16 GB lagringsplass 3,7 AMOLED ClearBlack skjerm NetCom tjenesteleverandør I tillegg til disse enhetene, disponerte vi også en LG E900 Optimus 7 gjennom utviklingsfasen. Selv om denne telefonen ble aktivt brukt for å finne og fikse feil i implementeringsfasen, var den derimot ikke tilgjengelig da de dokumenterte testene skulle gjennomføres. 5

110 Testrapport 4 Hva slags tester ble utført? Testing av funksjonalitet både i emulator og på telefon var et konkret mål for gruppen både før hver delleveranse og mens utviklingsfasen var i sine siste dager. Denne seksjonen vil diskutere både kontinuerlig testing, brukertesting på mobil og funksjonstesting, og hvordan de forskjellige testene ble utført. 4.1 Testing i utviklingsfasen I utviklingsfasen ble hver funksjon og hvert view som ble ferdigstilt analysert og testet grundig for alle mulige inn- og utdata de kunne bli utsatt for. Ytelsestester ble utført for prosessor- og nettverksintense oppgaver, og all kode ble gjennomgått for eventuelle svakheter for inkonsistente inndata. Denne prosessen førte til at det aldri hopet seg opp en rekke problemer hvor vi måtte løse mange store eller mindre problemer med en gang. 4.2 Testing på mobil Fra tirsdag 17. april ble ny funksjonalitet også testet på telefon - slik en sluttbruker ville oppleve det. Testene ble gjort innad i gruppen, samt av veiledere og kunden selv. Avhengig av hvilken fase implementasjonen var i, kunne applikasjonen til tider bli testet over en lengre periode for å simulere normalt bruk. For å sikre konsekvente resultater, ble applikasjonen alltid testet på to eller flere forskjellige telefonmodeller av to forskjellige brukere. Eventuelle forskjeller mellom telefonene ble notert, analysert og (om mulig) eliminert etter hvert som de ble oppdaget. Grensetilfeller ble testet ved ulogisk og rask navigasjon, og bruk i overgang mellom dager og måneder. For å sikre oss mot eventuelle problemer på grunn av sistnevnte, ble datosensitiv kode meget nøye gjennomgått for hånd Dekningstesting Mobildatadekning er notorisk for å variere avhengig av hvor man befinner seg. En applikasjon som er så avhengig av kontinuerlig tilgang til en ekstern server som vår, er derfor avhengig av å fungere riktig uansett dekning. Å teste applikasjonen i forskjellige dekningssituasjoner var derfor en viktig del av vår testing. Applikasjonen og alle dens nettverksrelaterte funksjoner ble derfor grundig testet med både Edge- og 3G-dekning, i tillegg til direkte tilkobling til trådløse nettverk (WiFi) med forskjellige båndbredder. Testing ble også gjennomført uten noen form for nettverkstilkobling. 4.3 Brukertesting Et av verktøyene som ble brukt for å nå målet om brukersentrert utvikling var hyppige brukertester. Både eksisterende og nye WP7-brukere, fagpersoner og andre ressurspersoner ble bedt om å prøve applikasjonen og gi tilbakemeldinger. Oppførsel, navigasjonsmønstre og typiske reaksjoner ble notert og analysert, og all tilbakemelding ble målt opp mot hverandre for å gi oss mer informasjon om hvordan applikasjonen kunne utvikles på en best mulig måte for brukeren. 6

111 Testrapport Hver brukertest ble delt opp i generelt inntrykk og en rekke forskjellige scenarioer hvor brukeren ble bedt om å fullføre en gitt oppgave. Hvis oppgaven ble oppfattet som vanskelig eller klønete av flere av brukerne, ble implementeringen av denne funksjonen revurdert og eventuelt endret. 4.4 Test av funksjonalitet Etter utviklingsfasen var avsluttet, gjennomgikk vi applikasjonen på forskjellige mobile enheter for å avdekke mulige mangler, feil og utbedringsmuligheter. Noen tester ble gjennomført flere ganger for samme operasjon, for å få et mer korrekt testresultat. Dette gjelder spesielt testene for å finne ut hvor raskt applikasjonen laster inn data. 7

112 Testrapport 5 Testresultater Denne seksjonen oppsummerer alle tester som ble utført på applikasjonen. Testene blir delt opp i fire deler - responsivitet, datainnhenting, Marketplace-tester og brukertester. Testresultatene ble oppnådd ved testing på to forskjellige mobile enheter, og er gjengitt for begge telefonmodeller (gjelder ikke brukertesting - her ble kun Nokia Lumia 800 brukt). Testresultatene er ofte ledsaget av korte kommentarer. OK betyr typisk at testen ble godkjent uten videre kommentarer. Eventuelle avvik, problemer eller forbedringspotensiale får videre anmerkninger for fremtidig videreutvikling. 5.1 Responsivitetstester View Aktivitet Kommentarer Nokia Kommentarer Samsung Oppstart Starte opp applikasjonen OK OK Main->generelt Innlasting av informasjon OK OK Navigering i panorama før all informasjon er hentet inn OK OK Gå ut av applikasjonen ved å trykke back-knappen OK OK Gå ut av applikasjonen ved å trykke hjem-knappen OK OK Main- >application bar Trykk på søk OK OK Trykk på last data på nytt OK OK Trykk på logg inn hvis logget inn OK OK Trykk på logg ut hvis logget ut OK OK Main->på tv nå Trykke på en kanal OK OK Bla i listen oppover og nedover OK OK Visning av ContextMenu til en kanal OK, litt lite responsiv OK Velge gå til program fra ContextMenu OK OK Velge gå til program fra ContextMenu til kanal som ikke har et program som går for øyeblikket OK OK Velge ta opp fra ContextMenu OK OK Velge ta opp fra ContextMenu til kanal som ikke har et program som går for øyeblikket OK OK Main->meny Velge et av valgene min kalender, filmleie, kanalvelger og søk OK for alle 4 OK for alle 4 Main->kalender Trykke på et program OK OK Bla i listen oppover og nedover OK OK Visning av ContextMenu til et program OK OK Velge gå til program fra ContextMenu OK OK Velge ta opp fra ContextMenu OK OK Velge varsle fra ContextMenu OK OK 8

113 Testrapport View Aktivitet Kommentar Nokia Kommentar Samsung Main->kalender Velge fjern fra ContextMenu OK OK Main->filmer i dag Trykk på en film OK OK Visning av ContextMenu til en film OK OK Velge gå til film fra ContextMenu OK OK Velge ta opp fra ContextMenu OK OK Velge varsle fra ContextMenu OK OK Velge legg til kalender fra ContextMenu OK OK Velge legg til kalender fra ContextMenu når filmen allerede er i kalenderen OK OK ChannelView-> generelt Laste inn data OK OK Gå inn / ut av view OK OK Navigering mellom dager OK OK Trykk på et program OK OK Trykk på søk, logg inn/ut i application bar OK OK ProgramView-> generelt Laste inn data OK OK Gå inn / ut av view OK OK ProgramView-> application bar Velge kalender (+), og så ja i prompt OK OK Velge kalender (+), og så ja i prompt med abonner på serien huket av OK OK Velge kalender (+), og så nei i prompt OK OK Velge kalender (+), og så nei i prompt med abonner på serien huket av Velge kalender (+), og så ja i prompt etter å ha gjort dette før (ikke abonnert) Velge kalender (+), og så ja i prompt etter å ha gjort dette før (abonnert) OK OK OK OK OK OK Velge varsling, og så ja i prompt OK OK Velge varsling, og så ja i prompt etter å ha gjort dette før OK OK 9

114 Testrapport View Aktivitet Kommentar Nokia Kommentar Samsung ProgramView -> application bar Velge varsling på et program som har startet OK OK Velge varsling på et program som er ferdig OK OK Velge opptak, og så ja i prompten OK OK Velge opptak, og så nei i prompten OK OK Velge opptak på program som har begynt OK OK Velge søk OK OK Velge logg inn / ut OK OK MyCalendarView-> generelt Navigér inn og ut av view OK OK Navigér mellom planlagt og abonnementer OK OK Bla i liste (begge views) opp og ned OK OK MyCalendarView-> planlagt Velg program OK OK Visning av ContextMenu for et program OK OK Velge gå til program i ContextMenu OK OK Velge ta opp i ContextMenu OK OK Velge varsle i ContextMenu OK OK Velge fjern i ContextMenu OK OK MyCalendarView-> abonnementer Visning av ContextMenu for en serie OK OK Velge stopp abonnement i ContextMenu, og velge ja i prompten Velge stopp abonnement i ContextMenu, og velge nei i prompten OK OK OK OK MyCalendarView-> application bar MovieGuideView-> generelt Velge søk eller logg ut / inn OK OK Innlasting av data, bilder OK OK Navigering mellom Pivot-views OK OK Trykke på en film OK OK 10

115 Testrapport View Aktivitet Kommentar Nokia Kommentar Samsung MovieGuideView-> generelt MovieGuideView-> application bar PickChannelsView-> generelt Bla i liste (alle views) opp / ned OK OK Trykke på søk eller logg ut / inn OK OK Lasting av side OK, laster litt tregt OK, laster litt tregt Bla i liste opp / ned OK OK Velge ingen kanaler OK OK Velge på alle kanaler OK OK (De)aktivere en kanal OK OK Visning av ContextMenu for en kanal OK OK Velge gå til kanal i ContextMenu OK OK PickChannelsView-> application bar SearchView-> generelt Trykke på søk eller logg ut / inn OK OK Lasting av side OK OK Navigasjon inn og ut fra forskjellige views OK OK Søke uten å ha skrevet noe inn i søkeboksen OK OK Søke med noe i søkeboksen OK OK SearchResultsView-> generelt Lasting av side, data OK OK Navigasjon inn og ut av view OK OK Navigasjon mellom Pivot-views OK OK Tilfelle: ingen treff på enten tv, filmleie eller begge OK OK SearchResultsView-> tv Velge et program OK OK Visning av ContextMenu til et program OK OK Velge gå til program i ContextMenu OK OK Velge ta opp i ContextMenu OK OK Velge varsle i ContextMenu OK OK Velge legg til i kalender i ContextMenu OK OK 11

116 Testrapport View Aktivitet Kommentar Nokia Kommentar Samsung SearchResultsView-> filmleie LoginView-> generelt Velge en film OK OK Lasting og navigering til og fra side OK OK Velge avbryt OK OK Logge inn med riktig brukernavn, passord OK OK Trykke logg inn uten å ha fylt inn informasjon OK OK Trykke logg inn med et feil nummer eller et manglende felt OK OK NewPasswordView-> generelt Navigasjon inn og ut av view OK OK Trykke hent kode med ukjent nummer, feilskrevet nummer eller intet nummer fylt ut OK OK MovieView-> generelt Lasting av view, data OK OK Mulig å vise trailer når trailer er tilgjengelig OK OK Ikke mulig å vise trailer når trailer ikke er tilgjengelig OK OK Vise screenshots fra film OK OK TrailerView-> generelt Laste inn og autospille trailer OK OK Navigere til og fra view OK OK Trykke på skjermen for å pause visning, og igjen for å starte OK OK 12

117 Testrapport 5.2 Datainnhenting over forskjellige nettverksforbindelser Disse testene sjekker alle kall til REST-tjeneren, og all datainnhenting (og deserialisering). Alle testene er målt omtrentlig, og er ikke ment som en referanse for videre millisekundsoptimalisering. Innhenting ble registrert på skalaen rask (uten nevneverdig ventetid), grei (et sekund eller to ventetid) og tregt (over tre sekunders ventetid). Aktivitet Kommentarer, Nokia Kommentarer, Samsung Oppstart (innhenting av maps, innlogging mm) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Hente på tv nå og filmer i dag (MainView) WiFi, 3G, Edge grei WiFi, 3G, Edge grei Hente dag (ChannelView) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Hente program (ProgramView) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Hente filmliste (MovieGuideView) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Hente film (MovieView) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Hente trailer (TrailerView) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Logge inn (LoginView) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Hente søkeresultater (SearchResultsView) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Ta opp (ProgramView, SearchView, m. fl.) WiFi, 3G, Edge rask WiFi, 3G, Edge rask Hente kanallogoer (PickChannelsView) WiFi, 3G, Edge tregt WiFi, 3G, Edge tregt 13

118 Testrapport 5.3 Manuelle tester for Marketplace godkjenning Testene ble utført på begge mobiler, men med like resultater. Kommentarfeltene for hver telefon er dermed sammenslått i disse testene. Testbeskrivelsene er kopiert fra Visual Studios Marketplace Test Kit. Tester som ikke er aktuelle for denne applikasjonen er utelatt. Test Beskrivelse (fra Marketplace Test Kit) Kommentarer Applicable Application Tile Images Multiple Devices Support Application Closure Application Responsiveness Application Responsiveness After Being Closed View the Application list. Verify that the small mobile app tile image is representative of the application. From the Application list, tap and hold the small mobile app tile of your application and select 'pin to start'. Verify that the large mobile tile image on the Start screen is representative of the application. Install your application on two or more Windows Phone devices. Verify that the application can install and uninstall without error. After testing the above, ensure your application is installed, and launch it. Comprehensively test application functionality and features to verify that there are no device-specific issues. Verify that the application does not cause the device to stop responding or crash. Launch your application. Navigate throughout the application, and then close the application. Verify that unexpected behavior does not occur during the closing process. Verify that the application remains responsive to user input and user interaction following an application error. Launch your application. Thoroughly test the application features and functionality. While testing the application, verify that the application does not become unresponsive for more than three seconds. Verify that a progress indicator is displayed if the application performs an operation that causes the device to appear to be unresponsive for more than three seconds. If a progress indicator is displayed, verify that the application provides the user with an option to cancel the operation being performed. Launch your application. Close the application using the Back button, or by selecting the Exit function from the application menu. Launch your application again. Verify that the application launches normally within 5 seconds, and is responsive within 20 seconds of launching. OK OK. Testet på Samsung Omnia 7, Nokia Lumia 800 og LG Optimus 7 (E900). Sistnevnte ble brukt i de fleste tester, men siden den har relativt like spesifikasjoner som Samsungmobilen, ble den utelatt fra de resterende testene. Testen ble gjennomført uten feil. OK, ingen application errors ble funnet. OK. Grundigere dokumentasjon på denne testen kan finnes under responsivitet -testen tidligere i dette dokumentet. OK Application Responsiveness After Being Deactivated Launch your application. Close the application using the Start button. Or, if your application does not run under a locked screen. Launch your application again. Verify that the application launches normally within 5 seconds, and is responsive within 20 seconds of launching. If your application includes pause functionality, pause the application. Launch your application again. Verify that the application launches normally within 5 seconds, and is responsive within 20 seconds of launching. OK 14

119 Testrapport Test Beskrivelse (fra Marketplace Test Kit) Kommentarer Back Button: Previous Pages Back Button: First Screen Back Button: Context Menus and Dialogs Phone Calls SMS and MMS Messages Application Responsiveness With Incoming Phone Calls and Messages Malicious Software Screening Language Validation Content and Themes Launch your application. Navigate through the application. Press the Back button. Verify that the application closes the screen that is in focus and returns you to a previous page within the back stack. Launch your application. Press the Back button. Verify that either the application closes without error, or allows the user to confirm closing the application with a menu or dialog. Launch your application. Navigate through the application. Display a context menu or dialog. Tap the Back button. Verify that the context menu or dialog closes and returns you to the screen where the context menu or dialog was opened. Ensure that the phone has a valid cellular connection. Launch your application. Receive an incoming phone call. Verify that the quality of the phone call is not negatively impacted by sounds or vibrations in your application. End the phone call. Verify that the application returns to the foreground and resumes. Close the application by tapping the Start button. Verify that you can successfully place a phone call. Ensure that the phone has a valid cellular connection. Ensure that the phone is not in Airplane mode by viewing the phone Settings page. Launch your application. Close the application by tapping the Start button. Verify that a SMS or MMS message can be sent to another phone. Confirm the phone has a valid cellular connection. Ensure that the phone is not in Airplane mode by viewing the phone Settings page. Send SMS and MMS messages to the phone and wait for up to 10 minutes. Close the application by tapping the Start button. Verify that notifications regarding the SMS or MMS messages are displayed on the phone either from within the application, or within 5 seconds after the application is closed. Ensure that the phone has a valid cellular connection. Ensure that the phone is not in Airplane mode by viewing the phone Settings page. Receive an incoming phone call, SMS message or MMS message. Verify that the application does not stop responding or close unexpectedly when the notification is received. After verifying the above step, tap on the message notification or receive the incoming phone call. If an incoming phone call was received, end the phone call. If an incoming phone call was received, verify that the application is displayed to the user and the application does not stop responding or close unexpectedly when the phone call is ended. If a message was received, verify that you can return to the application by pressing the Back button. Launch your application. Scan the application for malware. Verify that there are no viruses, malware or malicious software in the application. Review the product description of your application and verify that it is localized to the target language. Launch your application. Verify that the UI text of your application is localized to the target language. Navigate to the Settings page in the app list. Tap theme and change Background to 'Dark'. Launch your application. Verify that the text and visual elements of the application are visible and legible. Navigate back to the theme page under Settings, and change Background to 'Light'. Launch your application. Verify that the text and visual elements of the application are visible and legible. OK. Mange views modifiserer hvordan back-knappen fungerer, men alt fungerer på en logisk og intuitiv måte. OK OK OK OK OK OK - ingen virus eller malware ble funnet. OK OK 15

120 Testrapport Test Beskrivelse (fra Marketplace Test Kit) Kommentarer Technical Support Information Minimize Power Usage When Running Under a Locked Screen Launch your application. Verify that the application displays the application name, version information and technical support contact information in a location that is easy to discover. Launch your application. Lock the device. Verify that any user interface updates, active timers and other non-critical processing activities are halted by the application. OK OK Idle Behavior Under a Locked Screen Minimum Battery Life Under a Locked Screen Initial Launch Functionality Status of Background Transfers Launch your application. Ensure that no music files are playing on the device. Lock the device. Verify that the application does not play music, and the device stays idle. Fully charge the phone battery. Turn on Airplane mode in the phone Settings page. Launch your application. Lock the device. Verify that the battery life is at least 120 hours. Play a music file. Launch your application. Verify that while the application loads, it does not pause, resume or stop the actively playing music. Launch your application. Initiate a background transfer. Verify that there is a discoverable UI element that displays transfers that are in progress. Verify that the UI element correctly displays the background transfer. Activate the UI element that stops the background transfer. Verify that the progress UI element does not show the stopped background transfer. OK - applikasjonen har ingen musikkfiler å spille av, men testen ble allikevel gjort. OK OK OK 16

121 Testrapport 5.4 Automatiske tester for Marketplace godkjenning Visual Studios Marketplace Test Kit tilbyr også automatiserte tester. Disse sjekker detaljer rundt XAP-filens størrelse og innhold (app-filen som lastes ned fra Marketplace), ikonstørrelser og screenshots. Figur 5.1: Automatiske tester fra Visual Studio 17

122 Testrapport 5.5 Brukertester En av de viktigste testformene vi gjennomførte var kontinuerlige brukertester av både konseptet, delleveranser og den komplette applikasjonen. Testene gjengitt under er basert på det komplette produktet, og er spesialutviklet for denne applikasjonen. Testpersonene ble plukket ut på bakgrunn av deres bakgrunn, kunnskap, alder og diversitet. Ingen av testpersonene hadde tidligere brukt applikasjonen før, men noen hadde kjennskap til WP7-plattformen. Spørsmål / oppgave Respondent #1 Respondent #2 Respondent #3 Respondent #4 S: Hva er ditt førsteinntrykk av applikasjonen? Enkel, oversiktlig, pen og rask å bruke Jeg liker den, veldig responsiv Fin, men vanskelig å bruke uten å ha brukt WP7 før Den ser veldig gjennomført ut! O: Søk etter et program OK, raskt og intuitivt OK, likte oppdelingen av søkeresultater OK, likte oppdelingen av søkeresultater OK, enkelt og intuitivt. O: Planlegg et program OK, raskt og intuitivt OK, forstod raskt hvordan det fungerte OK, men noen problemer med å finne frem OK, raskt og intuitivt O: Finn en film du vil se på TV i kveld og sett på en varsling OK, raskt og intuitivt OK, fant med en gang oversikten. OK, raskt og intuitivt OK, raskt og intuitivt O: Se en trailer på en film i filmdatabasen OK, forstod når det ikke var trailer tilgjengelig. OK, forstod når det ikke var trailer tilgjengelig. OK, forstod når det ikke var trailer tilgjengelig. OK, forstod når det ikke var trailer tilgjengelig. O: Velg hvilke kanaler du ønsker å ha oversikt over OK, stusset over delay, ellers intuitivt OK, likte oversikten OK, likte oversikten OK, litt treg åpning, men fin når den åpner S: Er det noen funksjonalitet du savner i applikasjonen? Appen virker veldig komplett, og jeg føler at den dekker mine TVbehov på mobilen. Live tile som viste den planlagte programmer hadde vært stilig Virker som man har alt man trenger for å planlegge sofatilværelsen Nei, den virker helt ferdig S: Ville du anbefalt denne applikasjonen til venner og bekjente? Definitivt, har gjort det til endel allerede Jepp, det vil jeg definitivt gjøre Ja, men den var vanskelig å forstå seg på uten å ha prøvd WP7 før Definitivt. S: Hvordan har applikasjonen endret ditt syn på kunden? Jeg er allerede en god kunde av Get, og jeg likte appen godt. Kudos! Som Canal Digitalkunde fikk jeg nå lyst til å skifte leverandør Pen applikasjon, men jeg er nøytral til Get. Kult at de prøver ny teknologi, da. Veldig positivt. God bruk av farger og fonter, dette er veldig Get Kommentarer til brukertestrespons Generelt sett har responsen på applikasjonen vært gjennomgående god. Funksjonaliteten fikk kun positiv respons, bruk av applikasjonen ble oppfattet som rask og intuitiv, og kundens merkevare virket styrket hos alle testbrukere. Applikasjonen ble mottatt bedre av eksisterende WP7-brukere enn testbrukere med en annen mobilbakgrunn. Dette kan forklares med at applikasjonen i seg selv er meget plattformtro, og baserer seg på en viss kjennskap til hvordan man navigerer gjennom applikasjoner generelt. 18

123 Testrapport 6 Konklusjon Testrapporten har gitt oss en god oversikt over applikasjonens funksjonalitet, responstider og overføringstider. Ved hjelp av Marketplace Test Kit kan man også være relativt sikker på at applikasjonen vil bli godkjent til distribusjon gjennom Marketplace. De tekniske testene gjorde oss sikre på at denne applikasjonen både er stabil og vil by på få problemer for brukerne. Med dokumentert solid kode kan eventuelle videreutviklere også være sikre på at de har et godt grunnlag å bygge videre på. Testing av funksjonalitet og navigasjon gjorde oss sikre på at alle forskjellige navigasjonskombinasjoner førte til riktig view uten noen problemer. Videre forsikret vi oss om at all implementert funksjonalitet oppfører seg på riktig måte, og gjør det den er programmert til å gjøre. Responstid- og nettverkstesting var viktig av to grunner: optimalisering og brukeropplevelse. Ved å notere responstider på alle kall til eksterne servere over forskjellige båndbredder (Edge, 3G, WiFi etc) kunne vi optimalisere applikasjonen for alle tenkelige situasjoner. Resultatet ble en mer responsiv og raskere applikasjon som fører til knirkefri bruk for brukerne. Marketplace-testene ble også gjort meget grundig, og ble utført flere ganger for å være sikker på at applikasjonen vil bli godkjent av Microsofts kontrollører. Både automatiske og manuelle tester ble utført, og ingen feil ble oppdaget. Brukertesting var definitivt et viktig verktøy for oss under utviklingsprosessen. Eksterne respondenter ble spurt om sine meninger, og tilbakemeldingene deres bidro til å lage applikasjonen mest mulig brukbar for sluttbrukeren. Ved å ha en brukersentrert utviklingsmodell med hyppige brukertesting og tilbakemelding fra både veiledere, kunden selv og andre testpersoner, endte vi opp med et godt resultat. Produktet er intuitivt og funksjonelt som brukere mener både er enkelt å bruke, bidrar til økt merkevarebygging for kunden, og er noe testpersonene ville brukt i hverdagen. Ved å utvikle grundige tester slik som denne testdokumentasjonen, står fremtidige utviklere klare til å enkelt kunne sjekke at alle views, funksjoner og overganger fungerer slik de skal. Testingen ville gått raskere med programmatiske tester, men grunnet meget solid kode, vil endringer i kildekoden sjelden gjøre et utslag på testresultatene. Videre er testene fortsatt tilgjengelige for sjekker før lanseringen. Referanser:

124

125 Markedsundersøkelse

126 Markedsundersøkelse Innholdsfortegnelse 1 Innledning Om markedsundersøkelsen Hvorfor utføre en markedsundersøkelse på andre plattformer enn WP7? Forventninger Applikasjoner for ios TV-Guide (Knut Ørland) Beskrivelse Fordeler Ulemper Brukeromtaler Vår vurdering VG TVGuide Beskrivelse Fordeler Ulemper Brukeromtaler Vår vurdering Canal Digital TV-guide Beskrivelse Fordeler Ulemper Brukeromtaler Vår vurdering Get TV-Guide Beskrivelse Fordeler Ulemper Brukeromtale Vår vurdering Generelt for iphone apps Applikasjoner for Android TV24.co.uk Beskrivelse Fordeler Ulemper

127 Markedsundersøkelse Brukeromtaler Generelt for Android-Apps Applikasjoner for Windows Phone TV-Matchen.nu Beskrivelse Fordeler Ulemper Tilbakemeldinger fra brukere TV-Guide Sverige Beskrivelse Fordeler Ulemper Tilbakemelding fra brukere Dansk TV-Guide Beskrivelse Fordeler Ulemper Tilbakemelding fra brukere Generelt for WP7-apps Funn, tolkninger og analyse Konklusjon

128 Markedsundersøkelse 1 Innledning 1.1 Om markedsundersøkelsen Markedundersøkelsen ble utført av gruppen i fellesskap 25. januar Undersøkelsen ble utført ved å ta de mest populære applikasjonene på forskjellige plattformer, teste dem på relevante enheter, lese tilbakemeldinger fra brukere, og gjøre opp våre egne meninger om hver applikasjon. Formålet med denne undersøkelsen var å utforske hvilke applikasjoner som finnes i dag, hvilke styrker de tilbyr i forhold til dagens GET-løsninger, og hva applikasjonene har fått som tilbakemeldinger fra brukere. Dette dokumentet beskriver undersøkelsen og hva vi kom frem til. Til slutt vil vi gjøre oss en oppsummering av markedet, hvilke features vi vil anbefale skal bli implementert i vår egen applikasjon, samt en oppsummering av hvordan dagens Windows Phone 7-baserte (heretter kalt WP7) TV-guide applikasjoner løser navigasjon og sidevisning. 1.2 Hvorfor utføre en markedsundersøkelse på andre plattformer enn WP7? En applikasjon er i sin mest grunnleggende form et lite program som utfører en veldig spesifik funksjon. Alle applikasjoner, uavhengig av plattform, deler denne grunnleggende forutstetningen - selv om forskjellige plattformer løser bl.a. grafiske og hardware-baserte forutsetninger på forskjellige måter. Applikasjonen vi skal produsere vil også dele denne egenskapen, og vi mener en grundig markedsundersøkelse av de tre dominerende plattformene på smarttelefonmarkedet i dag - Apples ios, Googles Android og Microsofts Windows Phone 7 - vil gi oss økt innsikt i hvilken funksjonalitet som fungerer, er populær og tilfører gode aspekter til en TV-guide rent konseptuelt. 1.3 Forventninger Etter å ha utført en grundig markedsundersøkelse, forventer vi å få en god oversikt over hvilken funksjonalitet som er etterspurt, som finnes i konkurrerende applikasjoner, og som ikke er tilgjengelig i dagens applikasjoner på noen plattform. Vi forventer at denne markedsundersøkelsen vil gjøre utvelging av funksjonalitet enklere og mer presis, samt at vi sikrer at funksjonaliteten som implementeres er mer relevant i forhold til brukernes ønsker og forventninger. I forhold til grafiske designvalg, forventer vi å få inspirasjon fra dagens applikasjoner på WP7-plattformen. Navigeringsløsninger, informasjonspresentasjon og bruk av temafarger er eksempler på idéer vi kan hente fra å undersøke dagens WP7-applikasjoner nærmere. 4

129 Markedsundersøkelse 2 Applikasjoner for ios Apples ios-plattform tilbyr et enormt utvalg av applikasjoner. Selv om både grafikk og hardware er utformet på en annen måte enn på WP7-enheter, vil vi kunne hente mye relevant informasjon om funksjonalitet fra å undersøke de mest populære applikasjonene i App Store. 2.1 TV-Guide (Knut Ørland) 5

130 Markedsundersøkelse Beskrivelse TV-Guide applikasjonen er laget av Knut Ørland, og er optimalisert for bruk ved Altibox sine tjenester. Applikasjonen tilbyr et enkelt og til dels ikke veldig forseggjort grensesnitt. Man blir først presentert med en relativt minimal kanalguide ( Kanaler ), som man utvide etter eget behov. Kanalguiden bruker kun logoene til de forskjellige kanalene, en tilnærming som viser seg brukervennlig og forståelig. Ved trykking på de forskjellige kanalene får man en komplett 7- dagers liste over kanalens program. Funksjonalitet som trekkes frem i applikasjonen inkluderer: Redigérbar kanalliste Enkelt navigerbart 7-dagers program for hver tv-kanal Opptak (kun gjennom Altibox - koster ekstra) Legg til notifikasjon om program i native kalender-app Legg til program i Min TV-kveld, for planlegging av en kveld foran TVen Status på program som vises - når startet det, når slutter det, hvor lang tid er det igjen Statusbar på Nå og neste - viser grafisk hvor lenge det er igjen av et pågående program Autosøk - lagre populære søk Timeline ved horisontalt view Fordeler Applikasjonen er i stor grad optimalisert mot ios og dette gir applikasjonen en integrert følelse. Autosøk er en arbeidsbesparende og smart funksjon, og overraskelsen ved å bli presentert med en timeline når man snur enheten 90 grader var veldig positiv. Viewinndelingen var delvis logisk, og fungerte greit (men ikke veldig greit) til daglig bruk Ulemper Applikasjonen var ikke veldig pen å se på, ei heller imponerende på noen spesiell måte. Selv om alt fungerte relativt feilfritt, ga ikke applikasjonen inntrykk av å være veldig gjennomarbeidet eller designet med brukeren i fokus. Applikasjonen kostet 28 kr - en pris vi vurderte som for høy i forhold til hva man mottar Brukeromtaler Generelt sett er det veldig mye god tilbakemelding fra brukere. Begreper som Beste TVappen på markedet, Endelig en TV-guide som gir meg oversikt over alle de store kanalene som blir sendt i Skandinavia og Altibox-funksjonaliteten er fantastisk er noe som går igjen i kommentarfeltene. Kommentarene har tydelig preg av at applikasjonen har gått gjennom mye bugfixing fra lansering til i dag. Det har blitt rapportert (og klaget over) mye bugs, blant annet var det mye prat om å måtte reinnstallere applikasjonen hver gang den brukes. Alt i alt har tilbakemeldingen fra brukere vært positiv. Om det er fordi utvikleren fremstår som en norsk privatperson, eller om det er fordi applikasjonen er generelt sett veldig brukervennlig, fremkommer ikke. 6

131 Markedsundersøkelse Vår vurdering Denne applikasjonen gjør det meste rett i forhold til funksjonalitet - som er det vi ser på i denne markedsundersøkelsen av ios apper. Det denne applikasjonen tar litt på er et veldig lite inspirert GUI, samt en del setup-tid. Den er ikke smart på den måten at den vet hva du ser på, har sett på, har markert som favoritter før, og slike ting. Den er rett og slett en digital porting av en god gammeldags tv-guide, slik man finner dem bak i avisene. En god app - men ikke ekstraordinær. 7

132 Markedsundersøkelse 2.2 VG TVGuide 8

133 Markedsundersøkelse Beskrivelse VG TVGuide er laget av VG Multimedia og Okado, og er ikke tilknyttet noen spesiell innholdsleverandør. Førsteinntrykket til VG TVGuide er solid, brukervennlig, og full av smarte funksjoner. Etter å ha ventet litt på at appen laster (med en fin splash-screen), blir man ført til viewet På TV Nå, hvor man får en oversikt lik den tilgjengelig i dagens GET-applikasjon for ios. Man kan også bruke dette viewet til å se hva som går på TV på forskjellige hotpoints i løpet av kvelden (kl. 18, 20 og 22) - men å surfe gjennom tv-kvelden på annen måte er ikke like lett. Noe som må fremheves er hvordan VG presenterer programmene i sin TV-guide. I tillegg til generell informasjon om programmet (tittel, klokkeslett, kanal), vises en kort beskrivelse av programmet (noe vi regner med er tilgjengelig fra kanalen), samt linker til Søk i Wikipedia, Søk i IMDB, Søk andre tidspunkt, i tillegg til spesielle felter for filmer ( Se filminfo, VGs anmeldelse hvis tilgjengelig, Lesernes anmeldelser og Se bilder ). I tillegg er det en delingsfunksjon som tilbyr oppknytning om Twitter, Facebook og e-post (samt Tumblr og SMS). GUIen er mørk, og ser mye bedre designet ut enn f.eks. TV-guide applikasjonen omtalt over. De bruker mange smarte ikoner, som for eksempel terningkast-ikoner der terningkastet gjenspeiler den faktiske karakteren gitt (enten av VG eller brukere generelt). Man kan også velge hvilke kanaler som skal vises, under et innstillingspanel. Applikasjonen er ikke motion-sensitive, det vil si at den ikke forandrer utseende eller funksjon om enheten blir rotert 90 eller 180 grader. Med unntak av den klassiske VG-terningen, er det lite branding av VG i appen. Det er ingen logoer, pitcher eller forstyrrende elementer, med unntak av reklame for push-varslerabonnementet som er tilgjengelig til appen Fordeler Applikasjonen er for det meste veldig enkel å bruke, logisk bygd opp, og har mange smarte funksjoner. En av de beste funksjonene er utforsking av forskjellige kategorier (film, serier, sport etc), visning av andres favoritter, og hvordan programinformasjon blir presentert med lenker til forskjellige informasjonskilder, anmeldelser og delingsfunksjoner Ulemper Måten hotpoints og programvisning er implementert på, gjør applikasjonen veldig lite brukervennlig for brukere som vil utforske tv-kvelden. Det finnes ikke noe planleggingsverktøy for hva man vil se på i løpet av kvelden. Videre er det ingen enkelt tilgjengelig søkefunksjon, noe som er en stor svakhet designmessig. Ekstra betaling for pushvarsler virker kun som et irritasjonsmoment, og er åpenbart en måte å tvinge mer penger ut av brukerne. Reklame for dette virker om mulig enda mer irriterende. Videre er det ingen opptaksmuligheter, og varslig fungerte dårlig - spesielt gjennom pushnotifikasjoner. 9

134 Markedsundersøkelse Brukeromtaler Brukeromtalene til denne applikasjonen er også påvirket av irriterende bugs, samt negativ omtale av betaling for push-varslinger, dårlig implementasjon av planleggingsfunksjonalitet og til dels ukorrekte tider. Gjengående kommentarer inkluderer fungerer dårlig, kommer ikke inn på programmet etter en tids bruk og feil tidspunkt, spesielt i forhold til pushvarsler. Brukernes omtaler går fra veldig positive til veldig negative. Bugs ser ut til å være et stort problem, og upresise push-varslinger gjør sitt for å irritere allerede skuffede kunder som betaler ekstra for denne funksjonaliteten Vår vurdering Vi mener denne applikasjonen har veldig mange gode momenter, men at noen uheldige implementasjoner av funksjonalitet og upassende inntjeningsmuligheter trekker ned den generelle brukeropplevelsen. Noe overflødig funksjonalitet fungerer også som negative faktorer. Kategori-utforsking, deling på sosiale medier, og det å kunne se andres favoritter er definitivt gode idéer vi kan bruke i vår egen applikasjon. Vi forstår også at applikasjonen må være absolutt smertefri å bruke / oppdatere, samt at hverdagsbehov må implementeres mer strømlinjeformet enn andre, mindre populære features. 10

135 Markedsundersøkelse 2.3 Canal Digital TV-guide 11

136 Markedsundersøkelse Beskrivelse Canal Digital TV-guide er utviklet av Canal Digital AS, men har ingen implementert funksjonalitet for opptak, varsling på dekoder o.l. Ved åpning blir man ført til På tv nå -viewet - en enkel oversikt som ligner litt på både VGs TV-Guide og Get sin løsning. Fargetemaet er mørkt, med innslag av oransje gradients, som hjelper på å lyse opp en ellers grafisk dyster applikasjon. Ved trykk på de forskjellige programmene blir man ført til en oversikt over programmet til den aktuelle tv-kanalen, en grafisk fremstilling av hvor langt sendingen har kommet, og en mulighet til å lese mer om det aktuelle programmet. Dette viewet har også en kanalvelger (3 kanaler) nederst, hvor man kan se hvilke programmer som går på de forskjellige kanalene. En funksjon som kun Canal Digitals app har er muligheten til å sortere kanalene etter ditt eget ønske. Baksiden ved dette er at man må trykke Rediger for å kunne fjerne en kanal fra listen. At søkefunksjonalitet er implementert på toppen av På tv nå er veldig praktisk. Man kan diskutere om en global søkefunksjon er tilgjengelig kun gjennom På tv nå er passende, men funksjonaliteten er god - og bidrar til en god brukeropplevelse. Applikasjonen har likevel mange grunnleggende feil og mangler, samt endel problemer som stammer direkte fra dårlig planlegging og implementering. Et eksempel på dette er alfabetisk sortering av kategorier. Det er sjelden at man vil se i kategorien Andre før man ser i kategorien Film, og inndelingen i kategoriene Andre og Uklassifisert er også relativt ulogisk. Et annet problem med applikasjonen er hvordan programinformasjonen og muligheten til å favorisere eller dele programmetblir begravd under et ekstra view. Det hadde ikke vært noe plassproblem eller vanskelig å implementere, så det er mulig en generell designsvakhet Fordeler Applikasjonen har et særdeles innbydende GUI, og er relativ enkel i bruk. Den er intuitivt bygget opp, og etter en tids bruk vil den nok fungere veldig godt for den jevne bruker. Måten favoritter blir vist på er også veldig fin Ulemper Applikasjonen tilbyr lite eller ingen ekstra informasjon utover hva som blir gitt av kanalene. Det er ingen link til IMDB, det er ingen mulighet for brukerrating, ingen cover art, og generelt sett dårlig eller vanskelig tilgjengelig informasjon. I tillegg er det ingen synkronisering mellom applikasjonen og Canal Digitals kunder (og deres dekodere) Brukeromtaler Brukeromtalene til denne applikasjonen er relativt delt i sin oppfatning. Mange mener simplisiteten og GUIen er positivt, andre er plaget av bugs og manglende funksjoner. Populære kommentarer er enkel, lettfattelig, brukervennlig, imponert over design og brukergrensesnitt og savnet å kunne velge kanalpakke, eller i alle fall å kunne bare se valgte kanaler under kategorier. 12

137 Markedsundersøkelse Generelt sett har applikasjonen fått mye ros for brukervennlighet og enkelhet, og samtidig mye ris for at den ikke fungerer f.eks. etter en OS-oppdatering. Det er bemerkelsesverdig at en applikasjon med så lite funksjonalitet allikevel får såpass mye positiv feedback om brukeroplevelsen Vår vurdering Applikasjonen fremstår som pen å se på, men mindre funksjonelle enn andre på markedet. Det er mange åpenbare glipper som enkelt kunne blitt fikset, i tillegg til manglende oppkobling mot dekoder for Canal Digitals kunder. 13

138 Markedsundersøkelse 2.4 Get TV-Guide 14