23. JANUAR 2015 FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING Innholdsfortegnelse Presentasjon ............................................................................................................................................ 2 Sammendrag ........................................................................................................................................... 2 Dagens situasjon...................................................................................................................................... 2 Mål og rammebetingelser ....................................................................................................................... 2 Mål....................................................................................................................................................... 2 Rammebetingelser .............................................................................................................................. 3 Teknologier ...................................................................................................................................... 3 Målgruppe ....................................................................................................................................... 3 Søkekriterier .................................................................................................................................... 3 Løsninger og alternativer ........................................................................................................................ 3 Løsninger ............................................................................................................................................. 3 Funksjoner ....................................................................................................................................... 3 Søkealgoritmen ............................................................................................................................... 4 No fuzz, just music ........................................................................................................................... 4 Analyse av virkninger............................................................................................................................... 4 Kutte ned omfanget og målgruppen for appen .................................................................................. 4 Cross-platform ..................................................................................................................................... 5 Minimal interaksjon mellom band og brukere .................................................................................... 5 Arbeidsplan.............................................................................................................................................. 5 Fremdriftsplan ......................................................................................................................................... 7 Presentasjon Gruppenummer: 24 Gruppemedlemmer: Emilie Strand, Rannveig A. Skjerve og Madeleine Rønning. Kontakt: Rannveig A. Skjerve, [email protected] Periode: 12.01.2015 til 26.05.2015 Oppdragsgiver: Accenture Kontaktpersoner/veildere i Accenture: Henrik Bjerke og Jonas Korssjøen. Veileder fra HiOA: G. Anthony Giannoumis. Oppgave: Utvikling av en app der publikum og artister/band i et lokalmiljø kan finne hverandre, samt konserter. Sammendrag Oppgaven er et proof of concept av vår egen idé, i regi av Accenture Norge. Ideen går utpå å lage en applikasjon for androidtelefoner som tilgjengeligjør lokale musikkmiljø for flere. Gjennomgående er "no fuzz, just music" et viktig konsept; fokuset ligger på bandenes konserter og utgivelser. Dagens situasjon Ettersom hovedfokuset i appen er musikk, er det nødvendig å se på eksisterende applikasjoner som omhandler musikk og hva som skiller oss fra disse. Programmer som Spotify og SoundCloud lar deg finne ny musikk, samt dele din egen. Denne typen programmer tilbyr ofte topplister av trendende musikk. Det er også websider som Bandsintown som ved hjelp av posisjonen din finner konserter på de kjente scenene i byen din. Unektelig finnes mange ulike plattformer for musikk, men disse glemmer ofte de små artistene og viktigheten av lokal tilhørighet. Ukjent musikk drukner i de mer populære og får ikke samme sjanse til å bli hørt. Dette ønsker vi å endre på, og det er her vår løsning i stor grad skiller seg fra eksisterende løsninger. Appen vil orientere seg rundt mindre band i ditt nærmiljø, og gjøre deres musikk tilgjengelig for flere. Tjenesten vil, ulikt de store musikkapplikasjonene, etablere et fellesskap der man får utvidet sin kunnskap og kjærlighet for lokal musikk. Mål og rammebetingelser Mål    Hovedmål: Tilgjengeliggjøre lokale musikkmiljø for flere Gi lokale artister større sjanse til å bli hørt Gjøre det lettere for publikum å finne både konserter og artister i sitt nærområde  Holde musikken i sentrum: Appen er ikke til for å bygge image, men for å dele musikk Rammebetingelser Teknologier  Programmeringsspråk: Java for Android  Utviklingsprogram: Eclipse  Dokumentering og databehandling: Word, Pixlr, Photoshop, Excel  Utviklingsmetodikk: Scrum  Kommunikasjon og fildeling: Lync, Dropbox  Versjonskontroll: Git  Tredjeparts API’er: Login med Facebook, Googlekonto Målgruppe Applikasjonens målgruppe er mennesker som er interessert i sin lokale musikkscene, både band/artister og publikum. Søkekriterier En stor del av appen går ut på at brukerne skal finne musikk basert på hva de liker. Å ta utgangspunkt kun i sjanger vil skape enkelte problemer, ettersom dette verken er beskrivende for musikk, eller for en persons musikksmak i alle tilfeller. Vi trenger en algoritme som sorterer på annet enn sjanger. Løsninger og alternativer Løsninger Målet for applikasjonen er veldig ambisiøst, og en fullstendig løsning for bygging og tilgjengeliggjøring av lokale musikkmiljø vil inkludere flere målgrupper som, selv om de har en felles interesse, vil ha svært forskjellige behov. Vi har derfor valgt å fokusere på en løsning som gir band mulighet til å annonsere sine konserter og gjøre seg kjent for publikum, samt for publikum å enkelt finne den informasjonen som er relevant for hver enkelt bruker. Ideen inneholdt i utgangspunktet to andre funksjonaliteter som vi har valgt å kutte ut.   En søkefunksjon for musikere, der en kunne spesifisere sine behov og finne en passende musiker Profiler for konsertarenaer der de kunne søke etter band, og annonsere sine konserter Vi har valgt å kutte disse funksjonene, slik at applikasjonen har en mer spesifikk målgruppe. Funksjoner Etter å ha definert omfanget av oppgaven har vi laget en skisse av hvilke funksjonaliteter applikasjonen skal ha.  For artister/band o Profilside med informasjon om artisten/bandet, lydklipp etc o Mulighet for å legge ut to hendelser    Konserter, med mulighet til å selge billetter om bandet ønsker det Utgivelser, med mulighet til å selge utgivelsen For publikum o Innlogging med Facebook-, eller Googlekonto samt mulighet for å opprette en egen bruker spesifikk for applikasjonen o Personlig profilside som er synlig for venner, om brukeren ønsker det. o Søke etter, eller få forslag til band og konserter basert på egne preferanser o Mulighet til å følge band slik at bruker får varsler om hendelsene bandet legger ut o Vennefunksjon: kunne legge til andre brukere som venner og kommunisere med disse o Meldinger. Brukere kan sende hverandre meldinger, bandforslag og konsertinvitasjoner. Søkealgoritmen Kriterier   Lokasjon Bruker kan spesifisere område eller la applikasjonen finne den ved hjelp av GPS, og også spesifisere radius for søk. Musikkpreferanser Band legger til referanser til andre band i sin profil. Når bruker oppretter sin profil, vil den bli bedt om å spesifisere hvilke sjangre som er av interesse for den, applikasjonen vil deretter foreslå band og konserter basert på dette. Etter hvert som bruker begynner å ha en liste av band og konserter, vil referansene til disse bandene spille inn i prioriteringen av søkeresultatene. No fuzz, just music Det er veldig viktig for oss at musikken alltid skal være i sentrum, og at kun nødvendig informasjon kommer fram til bruker. Vi har gjort flere valg for å forsikre oss om dette:     Band kan kun opplyse om konserter og musikalske utgivelser, ingen andre oppdateringer Det er ingen «vegger» man kan skrive på, og ingen kommentarer, kun en privat inbox Man må være venn med noen for å sende en melding Man må ha brukernavnet til en annen bruker for å legge dem til som venn, slik unngår man tilfeldige/fremmede venneforespørsler Analyse av virkninger Kutte ned omfanget og målgruppen for appen Ved å kutte ut funksjonene for konsertarenaer, og musikersøket, vil appen få en mer samlet målgruppe. Både konsertarenaer og musikersøk-funksjonen ville vært en ekstra gulrot for å få musikere til å registrere seg som brukere, men samtidig ville det gjort applikasjonen komplisert å bruke. I tillegg ser vi det som en fordel å lage en applikasjon for en målgruppe istedet for tre målgrupper med en sammenfallende interesse. Cross-platform Da vi begynte å diskutere teknologier hadde vi fortsatt en ide om at musikere skulle bruke appen til mer enn å legge ut informasjon om seg selv. Apple har tradisjonelt vært spesielt populært hos musikere, og vi mente derfor at det var viktig å gjøre applikasjonen tilgjengelig for iOS-brukere. Siden ingen av oss har erfaring med Objective C, ville vi prøve å finne alternativer som gjorde det mulig for oss å programmere i språk vi hadde mer erfaringer med. Vi så på alternativer som Xamarin og Titanium. Etter å ha kuttet fokuset på musikeres aktive bruk og råd fra veiledere valgte vi likevel å programmere native for android. Vi har alle erfaring med native apputvikling for android, noe som gir oss et godt utgangspunkt for å lage en app med bra kvalitet. Ved å programmere native for android, vil applikasjonen bli tilgjengelig for færre, men vi har valgt å legge vekt på applikasjonens kvalitet istedet, og mener at dette er en god prioritering. Minimal interaksjon mellom band og brukere I applikasjonen vår har vi valgt å legge strenge begrensninger for hva band kan legge ut og bruke den til. Dette har vi gjort bevisst for å unngå at den relevante informasjonen fra appen skal drukne i promoteringsgimikker fra artister/bandenes side. Det er mulig at noen artister/band vil mislike dette valget, men vi mener at det er dette som gjør applikasjonen vår unik og interessant i et marked fullt av musikkapper; "no fuzz, just music". Arbeidsplan Database    brukere: publikum og band/artister samtaler konserter Innloggingdesign  gjøre designet på innloggingssiden Innlogging    Facebook Google Registrering/egen bruker Brukerprofil   design instillinger en bruker har (bilde, endre passord, skru av og på notifikasjoner osv.) Bandprofil    design på bandprofil la en bruker kunne opprette band kunne opprette konserter Konsertprofil   brukere kan følge konserter lage konsertprofil (design) Bandfunksjoner     brukere kan følge band Mulighet til å laste opp lydfil Legge ut nye utgivelser Legge til referanser Vennefunksjoner    legge til venner og søke disse opp Venneliste Inbox-> sende meldinger, invitasjoner til konserter og bandforslag Søkesider  lage søkesidedesign Søkefunksjon      Lokasjon Sjangre Brukers konsertliste og bandliste Band/artisters referanser lage swipe funksjon mellom de forskjellige forslagene Betalingsfunksjon   kjøpe billetter kjøpe cd/utgivelser Notifikasjoner    få notifikasjoner når et band man følger skal spille en ny konsert komme opp på profilen din om hva du liker osv. Push/pull funksjon for varsler Fremdriftsplan