KNappen 2.0

Sommeren er helt klart over og vi går i gang med KNappen 2.0 samtidig som vi brukertester 1.0. Her er våre tanker så langt.

Planen for versjon 2 av KNappen er basert på en justert produktstrategi, prosjektgruppa sine egne erfaringer med første versjon, tilbakemeldinger fra testbrukere og stadig mer etablerte konvensjoner for tilsvarende kartbaserte tjenester. Det er i denne versjonen ønskelig å både gjøre noen endringer, introdusere noe ny funksjonalitet, men ikke minst gjøre en del forenklinger – både teknisk og i forhold til brukeropplevelsen. Vi tror at noe av den utviklingen som vil kreves i forbindelse med slike forenklinger vil gi gevinst i forhold til fjerning av unødvendig kode, begrense mulige feilkilder og gi en mer responsiv og bedre brukeropplevelse.

 

Planen for versjon 2 er delt opp i et antall prosjektmoduler som vi tror er uavhengige nok til at de både kan spesifiseres, estimeres og jobbes med individuelt. Denne inndelingen er gjort både med tanke på funksjonalitet og brukeropplevelse og de tekniske løsningene. Dette er ikke ment som en fullverdig eller endelig spesifikasjon av versjon 2 av Knappen. Målsetningen er å skape en felles forståelse av målsetninger, avdekke viktige problemstillinger og å komme fram til beskrivelser av ulike moduler.

Prosjektmoduler

Forenklet henting av innhold

Problemene knyttet til henting av innhold fra flere kilder ser ut til å være mange og relativt store. For å forenkle henting av innhold, begrense logikk for bearbeiding av innhold i applikasjonen og gjøre det mulig å filtrere og aggregere innhold på tvers av kilder (clustering) så ønsker vi derfor å begrense henting av innhold til bruk av Norvegiana. Det vil mest sannsynlig innebære at noe nytt innhold må legges inn i Norvegiana, men for dette prosjektet kan en forutsett at dette gjøres. Helt konkret betyr det at all kode og logikk for å hente innhold fra Folketelling 1910 og Wikipedia skal fjernes og at dette innholdet skal kunne hentes fra Norvegiana i stedet. Visning og brukeropplevelse for dette innholdet skal være den samme som for andre kilder.

 

Kartvisning og filtrering

Svaret på det grunnleggende spørsmålet for denne tjenesten – «Hva finnes av informasjon for dette området?» – krever i dag at en bruker forholder seg til flere ulike konsepter som innholds søk, stedssøk, oppstartsinnstillinger, parallelle kategoriserings og filtreringsprinsipp og ulike mengdebegrensninger. I sum gjør dette at interaksjonen blir relativt kompleks og at resultatet blir begrensende i forhold til den informasjonsmengden og rikdommen som en egentlig prøver å formidle.

 

Målet i neste versjon er at en prøver å forenkle dette så mye som mulig. Valg som i dag må gjøres av brukerne kan gjøres i form av mer dynamisk logikk i applikasjonen. Og ved hjelp av visuell design og interaksjonsdesign så er ønsket å kunne vise mer informasjon på ulike nivå – større mengder informasjon, mer dynamikk i forhold til hva som er viktig og relevant og bruke noen flere visuelle virkemidler for å formidle og la brukerne navigere i større informasjonsmengder. De konkrete endringene en derfor ønsker å se på er:

• Visning av alle informasjonspunkt som finnes for et kartutsnitt – i stedet for et begrenset antall punkt fra at gitt midtpunkt
• Nedlasting av kartblader og informasjon som ligger utenfor synlig område for å oppnå raskere visning når manøvrerer seg rundt i kartet.
• Dynamisk/konfigurerbar grense for visning av punkt for et kartutsnitt – globalt og knyttet til kategorier. Enten dynamisk knyttet til mengde (er det over et maks antall punkt for et utsnitt og evt. en kategori så må en zoome lenger inn) eller knyttet til zoom-nivå (f.eks. at folketelling kun vises for definerte zoom-nivå).
• Dynamisk visning av punkter i kart – f.eks. mindre punkter ved store antall eller større punkter for utvalgte typer eller kategorier.
• Asynkron lasting og visning av punkter i kart – ikke låse kart og vise spinner som i dag
• Vise statisk informasjon om at man må zoome lenger inn for å få opp punkter i kart når dette er tilfelle
• Global filtrering basert på kategori (basert på revidert og forenklet kategoriliste) med mulighet for å fritt velge en eller flere kategorier som skal vises
• Global filtrering basert på fritekst – i kombinasjon med kategori(er)
• Fjerne konsept for søk etter innhold – det primære søkegrensesnittet er kartvisningen
• Ingen bla-funksjonalitet i lister – i stedet bruke dynamisk lasting om det er nødvendig å begrense innholdet. Innhold i lister og i kart skal alltid være det samme.
• Vise infobokser for enkeltpunkt direkte i kart – visuelt knyttet til valgt punkt.
• Visning av clustere – selve clusteringen vil gjøres på i Norvegiana og clustere vil returneres som andre punkter, men med antall «underpunkter» som attributt i stedet for kategori, tittel etc.

Gi tilgang til alle punkter ved overlapp – dette er tenkt som noe litt annet enn clustering på høyere nivå. Selv på laveste zoom-nivå er det i dag et problem at punkter overlapper og dermed i praksis ikke er tilgjengelig. Det er derfor et ønske at en ser på mulighet for å kunne nå disse punktene – også fra kartet. En vanlig måte å løse dette på er at en ved klikk på en samling overlappende punkter får opp en enkel liste.

Ruter

Ruter – begrensede mengder informasjonpunkter på tvers av kategorier, kilder eller andre attributter – vil være et sentralt konsept for å kunne filtrere innholdet og skape relevante brukeropplevelser med denne applikasjonen. For å få dette til å fungere i forhold til de ønsker å behov som ulike aktører har for å lage slike utvalg så er det ønske om å endre å utvide den eksisterende rutefunksjonaliteten.

 

• Legge til mer informasjon på selve ruten for å gi mer kontekst og en rikere brukeropplevelse. Aktuelle informasjon er beskrivelse, bilde(r), eier/institusjon og emneord.
• Styring av rekkefølge – valgfri styring av rekkefølge og synlig presentasjon av rekkefølge
• Lagring av ruter i samme infrastruktur som Norvegiana bruker – i stedet for en egen lagring av ruter på Evry sin server. Fordelen med det er at man kan forholde seg til ett grensesnitt for all henting av informasjon og at objektene man får tilbake for en rute vil være de samme som ved andre spørringer mot samme grensesnitt.

 

I tillegg er det to alternativ som vi ønsker å se på:

 

• Fjerne mulighet for å definere og vise egne ruter for alle. Dette er i dag løst på en måte som vil fungere dårlig på sikt – med lokal lagring og manglende autentisering. Muligheten for å definere ruter bidrar også til å gjøre grensesnitt og brukeropplevelse mer unødvendig kompleks for de som ikke ønsker å bruke denne funksjonaliteten.

 

• Forbedre funksjonaliteten for å definere personlige ruter. Introdusere autentisering (standard 3. parts autentisering som Google og Facebook) og knytte autentisert bruker til egendefinerte ruter. Lagre egendefinerte ruter samme sted som anbefalte ruter.

 

Forbedret detaljvisning

Gjennomgang av all visning av innhold fra alle kilder med tanke på å forbedre presentasjonen i forhold til visuell design, gruppering og prioritering av innholdselementer og konsistens. Vi ser for oss ulike visninger for ulikt innhold.

 

Deling, sosiale medier og brukerbidrag

Introdusere tydelige og enkle funksjoner for deling av innhold på ulike nivå – knyttet til URL-er til en åpen visning av innholdet i applikasjonen. Tydelige lenker til grensesnitt for innlegging av eget innhold for utvalgte kilder – selv innleggingen vil skje eksternt.

 

Åpen web-versjon

For å senke terskelen for å få tilgang til informasjonen som finnes i denne tjenesten generelt og spesielt med tanke på deling av innhold direkte med andre eller i sosiale medier så er det ønske om å etablere en åpen nettleserbasert visning. I så stor grad som mulig bør denne være basert på samme kode og de samme visningene som bruke i applikasjonen ellers, men man må altså kunne nå de sentrale visningene av innhold direkte med URL-er for kartutsnitt med tilhørende filtreringsvalg og ruter med tilhørende kartutsnitt. Denne visningen må kunne fungere både i en vanlig nettleser og i mobile nettlesere slik de gjør i applikasjonen ellers.

Polygoner og linjer

Ikke alle steder kan representeres via ett punkt i kartet, f.eks Bygdøy kongsgård, . Fokstua naturreservat eller historiske vandreruter. Vi ønsker derfor å ha muligheten til å visualisere både linjer og polygoner i kart – sammen med punkter som i dag. Vi ser for oss ulike visninger på ulike stadier. Når man har zoomet langt ut vil man få presentert et område som et punkt. Når man kommer nærmere ønsker vi at man skal bli presentert med et transparent område.

Off-line

Norge er et land hvor store deler ikke har mobildekning. For å få en app som dekker Norge er nedlasting for bruk off-line svært viktig. Knyttet til ønsker om endring for håndtering av ruter er det også behov for en gjennomgang av funksjonaliteten rundt lokal lagring av utvalgt medieinnhold.

 

Vi ønsker at det skal være standardvalg å laste ned bilder og tekst, mens at det må tas et aktivt valg for å laste ned lyd eller video. Dette kan gjøres for hele ruta eller for kun en enkelt fortelling i ruta. Om man er på trådløst nett eller ei og hvor mye det er å laste ned må selvsagt kommuniseres.

Menyer og ikoner

Gjennomgang av menyer og ikoner i både kart og ellers med tanke på konsistens og enkelhet og i forhold til endringene i funksjonalitet som er skissert over.

• Fjerne dialog for generelt søk
• Fjerne oppstartsinnstillinger
• Fjerne «Liste» fra hovedmeny
• Fjerne «Kart» fra hovedmeny
• Introdusere valg for filtrering av kart – i kart
• Fjerne bunnmeny for kartvisning
• Flytte kartvalg til innstillinger
• Flytte valg for ny rute til Ruter fra hovedmeny
• Flytte stedssøk til kart – integrert med kartvisning

Enkel oppstartsdialog

Visning av ekstern webside ved første oppstart for en installasjon av appen