Wikipedia tilpasset touch

Lesetid: 2 minutter

Hvordan kan jeg tilpasse Wikipedia til forskjellige touchenheter, og samtidig tilrettelegge for en god brukeropplevelse på disse enhetene?

Wikipedia tilpasset touch

Hvor stor forskjell er det mellom de ulike touch-skjermene vi bruker til daglig, og hva har disse forskjellene å si for meg som designer? Hvordan kan jeg lage en best mulig løsning for de forskjellige skjermene?

Mobil vs. nettbrett

Resultatet av prosjektet mitt er en nytenkning av hvordan Wikipedia kan se ut på smarttelefoner og nettbrett. Innholdet er det samme, men spesielt tilpasset til hver plattform.

  • Versjonen for nettbrett fremhever det visuelle innholdet på Wikipedia og gir deg mulighet til å gå fra artikkel til artikkel og lære nye ting.
  • Versjonen for smarttelefon fokuserer på hastighet og på raskt å finne informasjonen du er ute etter uten unødvendig nedlastingstid.

Forenkling av funksjonalitet

Det er mot innholdet i Wikipedia jeg har rettet mitt hovedfokus. For eksempel forstyrres ikke lesingen av linker og referanser, men samtidig kan de hentes frem ved et klikk dersom det er ønskelig.

Masteroppgave levert som film

Hovedbesvarelsen er levert på Kunst- og designhøyskolen i Bergen. Presentasjonen av oppgaven er en film, men selve oppgaven er egentlig et designkonsept for nettbrett og smarttelefoner.

Søkefeltet

Søkefeltet er plassert på bunnen av skjermen for å naturlig knyttes opp mot tastaturet når det er aktivert, samt for å være lett å nå. På touchenheter hvor tastaturet kommer opp på skjermen er dette en mer logisk inndeling av skjermen, heller enn å ha søkefeltet i toppen slik det ofte er vanlig.

Hurtighet

I det du starter opp programmet på smarttelefonen er tastaturet allerede oppe og klart til å søke. Ingenting lastes inn før brukeren enten søker, eller velger å gå inn på et av menyelementene på forsiden. Dermed er du klar til å søke med en gang programmet starter.

Enkelt

For å ha mest mulig fokus på innholdet på teksten, vises ikke linker og referanser. Disse må skrus på i menyen. På smarttelefonversjonen lastes heller ikke bilder inn, slik at artiklene skal lastes raskest mulig. Bilder er tilgjengelig fra menyvalg hvor du kan se disse i en egen bildemodus.

Fokus

Nettbrettversjonen presenterer artikler i to forskjellige versjoner: En tekstmodus og en bildemodus. På denne måten får du fult fokus på teksten når du leser denne, og du får presentert bildene størst og penest mulig når du ser på disse. I tekstmodus ser du et felt med bildeutsnitt øverst for å vise noe av bildeinnholdet i den enkelte artikkelen.

Content scroll

På nettbrettversjonen er innholdsfortegnelsen kombinert med scrollbaren slik at du visuelt kan scrolle gjennom innholdet i artikkelen, og dermed raskt komme til det du er ute etter.

FORFATTER
Marius Hauken
KATEGORIER
Informasjonsteknologi, Arkitektur og design, Teknologi
SPALTE
DATO
18.09.2012
Universitet
Kunst- og designhøyskolen i Bergen
Tittel
Same shit, different wrapping.
 
Gå til originaloppgave
KOMMENTARER

  • Spennende oppgave, skal sette meg ned med hele oppgaven en dag jeg har litt bedre tid 🙂

    Jeg synes det er supert at du har fokus på brukerens situasjon når hun bruker de forskjellige enhetene og lager grensesnitt som løser behov som måtte oppstå på farten eller i sofaen hjemme. Men jeg lurer litt på hva du tenker om at grensesnittene er såpass forskjellige fra “den vanlige” webversjonen og at brukere må forholde seg til tre grensesnitt til en og samme tjeneste?

    Har du tenkt å løse mobil og nettbrett-versjonen som apper eller er det en responsive webløsning?

    Har du gjort noe brukertesting av løsningene? Jeg er nemlig nysgjerrig på hvordan brukerne reagerte på en utradisjonell plassering av søkefelt. Plassering av søkefelt er jo noe gode, gamle web-guruer som Spool og Nielsen er svært uenige om.

  • Hei! Takk for det!

    Tanken min med oppgaven har vært å se mulighetene som de forskjellige enhetene har, og ikke la meg begrense av hvordan webversjonen ser ut og fungerer i dag. Jeg ønsket gjennom masteroppgaven å fordype meg mer i touch-enheter, men et naturlig videre steg i oppgaven hadde vært å se hvordan denne helheten kunne vært tatt over til en vanlig datamaskin med bruk av mus og tastatur. Her er behovene annerledes, og skjermstørrelsen større og mer variabel. Dette ble det dessverre ikke tid til i løpet av denne masterperioden.

    For å ikke la meg begrense i forhold til mulighetene på enheten var tanken fra starten at dette skulle være apper for de forskjellige enhetene, men slik jeg ser det kunne nok de endelige versjonene fungert greit som en responsiv nettløsning også da jeg ikke har brukt noen funksjoner som ikke støttes av javascript, HTML og CSS. (Unntaket her er nok content-scroll løsningen og bildene som scroller parallellt med teksten da Javascript på iOS stopper å kjøre i det du scroller). Når det er sagt ville nok en native app-løsning fungert raskere og bedre. I tillegg finnes det foreløpig ikke noe utkast for desktopversjon, og slik jeg ser det skalerer ikke nettbrettversjonen naturlig opp til denne størrelsen.

    Jeg har gjort litt brukertesting på enkle prototyper, ja. De fleste var riktignok før jeg valgte å knytte søkefeltet opp mot tastaturet og bunnen av skjermen. De testene jeg gjorde etter dette viste derimot ikke at dette var noe problem. Det er jo en ganske uvant løsning i forhold til tradisjonelle nettsider, men samtidig er det en mer logisk løsning i forhold til touch-skjermer hvor tastaturet kommer opp. Det blir på denne måten en sammenheng mellom inputområdet på en del av skjermen og resultatet på den andre delen av skjermen fremfor at dette er oppdelt slik det er vanlig. Jeg tror dette raskt kunne blitt en naturlig konvensjon på touch-skjermer. Dette er jo ikke et uvant brukergrensesnitt om du f.eks. ser til meldings-appen på iPhone som er inndelt på denne måten – kanskje derfor det har falt intuitivt for brukerne?

    Håper det var litt svar på det du lurte på. 🙂

  • Kristin Kokkersvold

    Takk for svar 🙂 Kunne spurt og gravd i en evighet, men bør nok lese oppgaven i sin helhet først – regner med jeg finner mye der.

  • Hei! Veldig spennende oppgave.

    Liker spesielt godt hvordan hver artikkel får et spesialtilpasset bilde, men hvordan kunne dette fungert i praksis? Har artikler generelt definert en hovedillustrasjon, eller må endringer gjøres hos Wikipedia for at det skal virke? Én mulighet er jo å velge et tilfeldig bilde tilknyttet artikkelen.

    Har du planer om å gi ut en fungerende app basert på oppgaven? 🙂

  • Hei, Helge!
    Takk for det!

    Tanken min i forhold til hovedbilde har vært at dette velges tilfeldig, men om et hovedbilde er satt velges dette. Et eksempel på dette er artikkelen om iPad som har et hovedbilde satt ute i høyre marg.

    Jeg har ingen umiddelbare planer om å gi ut en fungerende app basert på oppgaven, dessverre. Dette er tidkrevende og gir nok dessverre alt for lite inntjening i forhold til arbeidet som må legges ned. Et alternativ ville jo selvfølgelig vært om Wikipedia ville utviklet dette videre, men denne løsningen er nok litt for radikal. 😉 De jeg har vært i kontakt med i Wikipedia sier at dette er interessante innspill, men at de holder på med egne løsninger også..