Hovedprosjekt. Høgskolen i Oslo og Akershus Våren Gruppe 3 Forprosjektrapport

Transkript

1 Hovedprosjekt Høgskolen i Oslo og Akershus Våren 2012 Gruppe 3 Forprosjektrapport

2 INNHOLDSFORTEGNELSE Presentasjon... 3 Gruppen... 3 Bedriften... 3 Sammendrag... 4 Dagens situasjon... 4 Native-applikasjon... 4 Mobil-webapplikasjon... 5 Løsningen... 5 Mål og rammebetingelser... 6 Krav... 6 Analyse av virkninger... 7 Konklusjon... 8 Vedlegg... 9 Arbeidsplan... 9 Risikoanalyse Gantt-diagram Kilder

3 PRESENTASJON Sted og dato: Oslo, 12. januar 2012 Tittel: A-Pressen Digitale Medier (APDM) Oppdragsgiver: A-Pressen Digitale Medier Kontaktperson: Brukervennlighet: Pål Nedregotten Leder produktutvikling Telefon: E-post: Teknisk: Simen Graff Jenssen Plattformeier Telefon: E-post: Veileder ved HiOA: Larissa Sjarbaini Gruppen Prosjektleder: Teknisk leder: Dokumentansvarlig: Cecilie Fjellhøy Cecilie Kirkaune Camilla Røhme Bedriften A-pressen er landets nest største mediekonsern og er største aktør innen lokale medier og kommersiell tv i Norge. Gruppen samarbeider med utviklingsavdelingen i A-Pressen Digitale Medier (APDM). 3

4 SAMMENDRAG A-pressen har en klar satsning på innovative løsninger og deres mål er å være ledende på brukervennlighet. På bakgrunn av dette ønsker de at gruppen skal komme med nye ideer og løsninger rundt fremtidens nettavis i mobilt format. Dette gjelder både utseende, brukervennlighet og funksjonalitet. Oppgaven blir hovedsakelig bestående av tre områder: front-end-utvikling, brukervennlighet og innovativ funksjonalitet. Oppdragsgiver ønsker at det skal utvikles en high-fidelity prototype til illustrasjon og demonstrasjon. DAGENS SITUASJON A-pressens nettaviser i mobil form er per dags dato statisk satt opp med bilder og overskrift, i noen tilfeller en liten ingress. I dagens samfunn er mobilutviklingen delt opp i to områder applikasjoner programmert native eller for web. Oppdragsgiver ønsker en mobil webapplikasjon som er mer enn en nettside; den skal føles som en native-applikasjon. Native-applikasjon Native-applikasjon er en mobilapplikasjon som lastes ned til en mobil enhet og bruker den innebygde funksjonaliteten, som for eksempel kameraet, GPS og brukerens adressebok. En native-applikasjon er utviklet spesifikt i henhold til hvilket operativsystem enheten har, nettopp grunnet bruk av funksjoner. Applikasjonene er programmert i programmeringsspråk spesifikt for plattformen de skal brukes på. Negative sider ved native-applikasjoner inkluderer tid og ressurser brukt til dobbeltarbeid ved utvikling av flere applikasjoner og ulikheter ved de forskjellige utgavene av applikasjonen. Hvis applikasjonen ikke utvikles til alle plattformer vil man risikere å miste potensielle brukere på grunn av tilgangsmangel. 4

5 Mobil-webapplikasjon Mobile webapplikasjoner er applikasjoner som kjører i nettleser. Den største fordelen med mobile webapplikasjoner er at de fungerer på tvers av plattformer og enheter. Dette fører til raskere utvikling, da funksjonalitet blir implementert kun én gang. Vedlikehold og oppdateringer blir også enklere, siden koden ligger på en webserver og ikke må gjennom godkjenning fra tredjepart. Problemet med ulikheter ved de forskjellige applikasjonene forsvinner også. Mobile webapplikasjoner kan finnes ved et enkelt søk i nettleseren, mens Native-applikasjoner må lastes ned. Webapplikasjoner har tradisjonelt vært avhengige av internettilkobling, men med HTML5-standarden er det muliggjort arbeid uten tilkobling. APDM ønsker at gruppen skal se for seg fremtidens webapplikasjon for aviser på nett. De er interessert i innovative ideer fra et nytt perspektiv, og ønsker en prototype som kan demonstrerer den funksjonaliteten gruppen kommer frem til. Gruppen vil få innsyn i APDM sine arbeidsmetoder og -prosesser og få tilsendt kode som et utgangspunkt for arbeidet. Det vanlige i dag er å utvikle native-applikasjoner for mobile nettaviser, og gruppens oppgave blir å undersøke om mobile webapplikasjoner er et reelt alternativ til nativeapplikasjonene. Foreløpig problemstilling er: Er en mobil web-appliasjon i HTML5 et realistisk alternativ til en native-applikasjon? Og hvilke funksjonelle muligheter ser man for seg at A-pressens lokalaviser har i fremtiden? LØSNINGEN LOKALAVIS.NO Lokalavis.no er A-pressens lokalaviser samlet under en web-applikasjon! Appen gir brukeren mulighet til å finne lokalavis ut fra sin lokalisjon. Applikasjonen vil også tilpasse seg etter brukerens egne preferanser. Om det skal være å lagre favoritter, foreslå artikler, fjerne uønsket innhold eller tilpasse brukergrensesnittet (farger, font-størrelse). 5

6 Nye funksjoner vil inkludere naturlig opplesning av artikler, forbedret bildevisning, samling av nettstedenes videoer og tegneserier. Bruker vil også ha mulighet til å starte fra siste side i avisen, som mange gjør med en papiravis! MÅL OG RAMMEBETINGELSER Målet med oppgaven er å utvikle en mobil webapplikasjon som føles som en nativeapplikasjon. Oppdragsgiver ønsker en webapplikasjon utformet på en mer interaktiv og intuitiv måte. Applikasjonen skal utnytte fordelene ved, og samtidig ta hensyn til begrensningene til, en touch-skjerm. Oppdragsgiver ønsker en high-fidelity prototype. Denne skal programmeres i HTML5 og CSS3 for utseende, med innslag av JavaScript og jquery for funksjonalitet. Koden vil ikke bli gjenbrukt, fokus vil være på å få frem funksjonalitet og brukervennlighet av løsningen. To områder fra nettsidens innhold skal inkluderes applikasjonsutviklingen; nyheter og bildevisning. Funksjonalitet som ikke er mulig å implementere med dagens teknologi vil bli illustrert ved bruk av Keynote og Flash Catalyst i en digital prototype. Krav - HTML5 prototype - Hovedside/splashside -> Mest lest/siste nytt - Navigasjon (dock) - Oversikt over artikler - Artikkel - Bildevisning / videovisning / lydklipp - Kommentar/tilbakemelding - Del på sosiale medier 6

7 - Digital prototype - Mulighet for å sende inn bilder/video på direkten - Favoritter/ lagring - Personalisering - Innstillinger kan sette egne preferanser, og/eller endre innstillinger satt av systemet - Introduksjon/brukerveiledning - frivillig, kan også være tilgjengelig gjennom innstillinger - Mulighet til å starte fra siste side (tegneserier) - Tilgjengelighet/Universell utforming: A av AAA. :Systemkrav - Kodet i HTML5, CSS3 og jquery Mobile - Koden skal validere i W3C og feilsøkningen i Mobile Safari - Mobile Safari, Chrome, Firefox - Navigasjon mellom alle sider og kategorier. Web-applikasjonen skal føles som en native app - full screen - automatisk tilpasning til skjerm - knapper (ikke linker) osv.. - funksjonalitet ved dobbel-tapp ANALYSE AV VIRKNINGER Gruppen valgte å jobbe med HTML5, CSS3, JavaScript og jquery etter krav fra oppdragsgiver. Gruppen ser at det er disse verktøyene som kan gi god funksjonalitet og brukervennlighet for sluttproduktet. Gruppemedlemmene har ikke jobbet mye med disse språkene tidligere, og jquery er helt nytt. Dette er en utfordring gruppen ser frem til å ta for seg. Dette blir en lærerik prosess som vil gi gruppemedlemmene kunnskap og erfaringer som kan tas med ut i arbeidslivet. 7

8 KONKLUSJON Ideene og funksjonaliteten gruppen har utarbeidet så langt er innovative for A- pressens nåværende nettaviser for mobile enheter. Prototypen vil være til nytte for APDM ved utvikling av nye mobile webapplikasjoner. God dokumentasjon og testing vil hjelpe oppdragsgiver med å velge hvilke deler av prosjektet det er ønskelig å ta med til en videre satsning. Prosjektet vil være utfordrende og lærerikt for gruppen. 8

9 VEDLEGG Arbeidsplan Aktivitet Beskrivelse Innledning Prosjektskisse Opprette gruppe Fordele ansvar Opprette webside Problemstilling Risikoplan Omfang Forprosjektrapport Fremdriftsplan Beskriver valgt prosjekt og oppdragsgiver. Det var tidlig enighet om å samarbeide med hovedprosjekt. Gruppemedlemmene har jobbet sammen ved tidligere prosjekter og er godt kjent med hverandres styrker. Fordeling av ansvarsområder falt naturlig på de tre hovedområdene av prosjektet. Design og publisering av nettside for samling av gruppens dokumenter. Krav fra HiOA følges. Idémyldring for å utvikle helhetsforståelse og målrettet handling. Vurdere hvilke risikoer som kan forsinke prosessen, samt sannsynlighetsgraden av disse. Avgrense og Tar for seg dagens situasjon, mål og rammebetingelser, løsninger, analyse av virkninger og en konklusjon Utformes som et gantt-diagram, og viser hvor lang tid gruppen beregner på de enkelte arbeidsoppgaver. Vedlegges sammen med arbeidsplan ved forprosjektrapporten. Kravspesifikasjon

10 Datainnsamling Dataanalyse Samle inn informasjon om hvilke teknologier som er tilgjengelige og hva som er mulig med disse. Finn ut behov krav og ønsker fra oppdragsgiver. Analysere dataene. Resulterer i konkrete krav og rammer for prosjektet i en kravspesifikasjon. Implementering Design Brukervennlighet Funksjonalitet Offline-mode Personlig tilpassing Prototyping i Flash Catalyst /Keynote Testing Brukertesting Planlegging Design av grafisk brukergrensesnitt. De ulike elementene skal klargjøres. Inkluderer forside, meny/dock, artikkel- og bildevisning. Valg og avgjørelser dokumenteres for bruk i sluttrapporteringen. Implementering av funksjonalitet for å gi følelsen av en native-applikasjon. Noe av funksjonaliteten skal være tilgjengelig uten internettilkobling. Brukeren skal ha mulighet til å velge funksjonalitet og utseende ut ifra personlige interesser og referanser. Den ønskede funksjonaliteten som ikke er oppnåelig med dagens teknologi skal vises ved bruk av Keynote og Flash Catalyst. Dette illustrerer de innovative ideene. Bruk av fokusgrupper til å teste den nye teknologien. Hvordan og hvor skal testingen gjennomføres? Gjennomføring Evaluering Evaluering av testresultatene skal dokumenteres for testdokumentasjonen. 10

11 Implementering av tilbakemelding Feil, tilbakemeldinger og forslag til ny eller forbedret funksjonalitet skal, om mulig, implementeres. Dokumentasjon Produktdokumentasjon Testdokumentasjon Prosessdokumentasjon Brukerdokumentasjon Beskriver prototypens egenskaper og funksjon. Dokumentasjon av planlegging, gjennomføring og resultater fra testing. Inkluderer også hvordan tilbakemeldinger ble brukt til nye iterasjoner av implementeringen. Det skal arbeides med prosessdokumentasjonen gjennom hele prosjektperioden. De ulike fasene av prosjektet beskrives. Problemløsningsmetoder og faglig utvikling beskrives Både tilbakemeldinger og presentasjon. Prosjektdagbok Korrektur Ferdigstilling og kvalitetssikring Prosjektdagbok føres gjennom hele prosjektperioden for et godt grunnlag for resten av dokumentasjonen. All dokumentasjon skal leses nøye gjennom av alle gruppemedlemmer før innlevering. Sluttdokumentasjon skal ferdigstilles og trykkes. 11

12 Risikoanalyse Risikonivåer: 1 til 2 Liten. Vil sannsynligvis forekomme, men er som regel enkle å håndtere og utgjør ingen større fare for prosjektet. 3 til 5 Middels. Kan skade prosjektet og ødelegge for fremdriften, men er ikke umulige å unngå eller jobbe for å kompensere for. 6 til 8 Stor. 9 til 10 Meget stor. Vil medføre større problemer og ødeleggelser for prosjektet. RISIKO SANNSYNLIGHET KONSEKVENS TILTAK Sykdom 1 til 2 ved Mer arbeid på Ved å dele arbeidet likt og/eller skade korttidssykdom, resterende mellom gruppemedlemmene, 3 til 5 ved mer gruppemedlemmer. vil ikke enkeltpersoner sitte alvorlige Hvis personen som med all informasjonens som sykdommer. forsvinner er trengs. Dermed kan alle prosjektleder så kan utføre alle oppgaver, dersom viktig informasjon bli et gruppemedlem uteblir borte eller viktige grunnet sykdom. forbindelser bli svekket. Uenigheter og misforståelser 1 til 2 Oppgaver kan ta mye lengre tid og må kanskje gjøres to ganger før man er fornøyd hvis det er noen som ikke har forstått hva som skal gjøres. Uenigheter kan løses demokratisk med flertalls avgjørelser. Misforståelser kan løses ved god kommunikasjon og ved å ha jevnligere møter. Informasjonstap 3 til 5 Hvis informasjon først er gått tapt er det vanskelig å innhente Back-up av alle filer og dokumenter gjøres ukentlig, man kan også bruke 12

13 den igjen. Dette betyr da dobbeltarbeid og mest sannsynlig et mindre godt sluttresultat. internett-baserte tjenester som Drop-Box til å gjøre alle dokumenter tilgjengelige for alle medlemmene i gruppen. Tidsmangel 3 til 5 Kan resultere i mangelfull rapport. Skippertak er beste løsningen om man først får dårlig tid, da er det bare å legge mest mulig tid ned for å få arbeidet ferdig i tide. For å unngå tidsmangel er det viktig med god planlegging av prosjektarbeidet. Gantt-diagram 13