Mobile-First: fremtidens tenkemåte i praksis

Mobile-First: fremtidens tenkemåte i praksis

Våren 2014 viste statistikken at antallet mobilbrukere hadde oversteget antallet desktopbrukere. Dette har forandret vår tilnærming til web-grensesnittet grunnleggende. I den amerikanske giganten Ciscos Visual Networking Index finnes det prognosetall som støtter vårt syn på at mobiltilpassete webløsninger har blitt et krav og at mobilebrukerens tilfredshet nå har første prioritet i grensesnittutvikling.

For hvilke løsninger er det relevant å anvende mobile-first metodikk? For hvilke brukere gjelder denne tilnærmingen? Eller, hvorfor vil en mobile-first løsning i noen tilfeller gi mer enn en vanlig reponsiv løsning? Da vi skulle redesigne Sporveiens intranett, fikk vi anledning til å tenke nøye gjennom utfordringene knyttet til en løsning som både skulle designes og utvikles i følge mobile-first prinsipper.

Du mener responsive nettsider ikke sant? Nei, jeg sa jo Mobile-first!

Når det gjelder front-end, har det tidligere vært snakk om enten responsive nettløsninger eller egne alternative mobilnettsider. Mobile-first konseptet dukket opp etter denne bølgen, og ble for første gang nevnt av Luke Wroblewski i 2009. (Hans første artikkel om dette temaet er fortsatt tilgjengelig).

Prinsippet er enkelt: man begynner med å utvikle en minimal basis og bygger gradvis opp flere lag for til slutt vise den høyeste teknologien. Det er viktig å presiere at mobile-first tilnærmingen ikke bare har fokus på mobiltelefoner. Den gir bedre ergonomi på alle mulige plattformer ved å holde seg til det grunnleggende.

Hva som er forskjellen mellom en responsiv løsning og en mobile-first løsning, er et ofte stilt spørsmål, men faktisk er det et feil spørsmål. Responsive nettsider er per definisjon funksjonelle på alle skjermer uavhengig av skjermens størrelse. Inntil nylig har responsive løsninger hovedsakelig vært beregnet for bruk på desktop med mulighet til å tilpasse seg mobil. Mobile-first løsninger er også responsive, bare at de i utgangspunktet er beregnet til mobilbruk med mulighet til å tilpasse seg desktop. Det er det, og bare det som er forskjellen. Det finnes derfor ikke noe løsning som er enten responsiv eller mobil-first, det finnes snarere klassiske responsive løsninger (desktop-first) og mobile-first responsive løsninger.

Spennende! Hvordan fungerer det i praksis?

Når det gjelder grafisk-, UI- og UX-design, skal man fokusere på mulighetene og begrensningene mobile enheter har. For eksempel finnes det uunngåelig oppførsel som touch, eller scroll som krever et tilpasset grensesnitt i første omgang. Dette krever større klikkbare områder og et sideskjelett bygd av blokker opp åå hverandre. Tastaturet kan fort være ubehagelig på mobil. Derfor bør bruk av skjemaer begrenses og forhåndsformaterte områder prioriteres. Tabeller, men også tabs navigasjoner, kan være vanskelige komponenter å tilpasse. Disse skal unngås eller formateres for å presentere data opp på hverandre i stedet for fra venstre til høyre.

Når man tar hensyn til alle komponentene sammen, er den viktigste begrensningen utvilsomt den reduserte plassen på skjermen. Fra et designperspektiv vil mobile-first tilnærmingen bidra til enklere bruk. Luft får en helt annen verdi og posisjonering av elementene utføres på en mer konservativ og forsiktig måte. Fokuset er på det som er grunnleggende og dette bidrar til at nøkkelfunksjoner er sentrale i løsningen. Tilleggsfunksjoner anses som overflødige og enten sløyfes de eller så blir de bare synlige dersom det er nok plass på skjermen.

Fra utviklingsynspunktet, gir en mobil-first tilnærming mange fordeler. Det er faktisk lettere å legge til CSS-stiler enn å fjerne eller omskrive dem, noe som ofte skjer med en klassisk responsiv tilnærming. Med Twitter Bootstrap løses dette ved bruk av media queries fra det minste til det største istedenfor motsatt. Generelle stiler er alltid for alle skjermer, men stilene for desktop lastes bare hvis skjermstørrelsen er stor nok.

/*==================================================
= Bootstrap 3 Media Queries =
==================================================*/

/*========== Mobile First Method ==========*/

/* Custom, iPhone Retina */
@media only screen and (min-width : 320px) {

}

/* Extra Small Devices, Phones */
@media only screen and (min-width : 480px) {

}

/* Small Devices, Tablets */
@media only screen and (min-width : 768px) {

}

/* Medium Devices, Desktops */
@media only screen and (min-width : 992px) {

}

/* Large Devices, Wide Screens */
@media only screen and (min-width : 1200px) {

}


På samme måten er det lettere - og mer logisk - å aktivere JavaScript moduler bare når de er nødvendige. Man kan velge å initialisere de største og mer komplekse modulene som er tenkt for bruk på desktop, bare når man er på desktop. Det mobile grensesnittet blir mye lettere og med bedre ytelse. Teknisk sett kan dette gjøres ved å beregne bredden av skjermen (tilpasset CSS media queries), ved å detektere nettleserens User Agent, eller ved å detektere mobilspesifikke kapasiteter (f.eks touch). Modernizr gir også en kombinasjon av flere av disse verktøyene.

Ingen tviler lenger på at innhold serveres best tilpasset platformen. Det vil si at når UI (grensesnittet) designes og utvikles for mobile enheter først er det hele UX (brukeropplevelsen) som løftes. Hele løsningen er optimalisert og fungerer med hensyn til både fordeler og ulemper til denne platformen. Til og med ytelsen er forbedret og løsningen lastes fortere og lettere enn det hadde vært mulig med en klassisk desktoptilnærming.

For og imot

Det finnes mange gode forklaringer som viser fordelene ved å bruke mobile-first og jeg er personlig veldig positiv til metodikken. Man må llikevel være klar over mindre ulemper, selv om de kan virke trivielle ift. hvor mye man faktisk får igjen.

Mobile-first løser ikke alt: Metodikken er relevant men den er ikke løsningen i seg selv. Mobile-first handler ikke bare om mobiler – til og med tabletter er mobile(!) - men først og fremst om små skjermstørrelser. Det betyr at det fortsatt er snakk om piksler, og at løsningen skal være optimal på de minste skjermene. Men hva hvis man har flest brukere på enheter som er 768px brede? Mobile-first kan da rett og slett ikke være den eneste design strategien man har. Man skal fokusere på små skjermer ja, men man skal ikke glemme hva brukeren faktisk har i hendene.

Mobile-first webløsninger skal og kan ikke konkurrere med native apper: Brukeropplevelsen på mobil er veldig forskjellig fra den på desktop. Når man velger å ha én web løsning som skal dekke begge områder risikerer man at man ikke treffer helt riktig, og det på begge platformene. Vil man tilfredstille begge brukertypene kan man ende opp med ikke å tilfredstille noen. Skal man virkelig ha mobilbrukere i fokus bør man fortsatt favorisere native mobile apper.

Mobile-first føles ikke naturlig å designe/utvikle ennå: Det kan oppleves som vanskelig, spesielt når det gjelder designbiten. Det er mange begrensninger som dukker opp allerede på trinn #1 av designet. Man må helt fra begynnelsen ta hensyn til lite plass og få ressursser med redusert ytelse. Mobil er dessuten ikke det området der man har bygget opp mest erfaring. I løpet av studiene og arbeidslivet har vel fokuset for de fleste så langt vært hovedsakelig på desktop.

Konklusjon

Skal man designe eller utvikle mobile-first må man forsikre seg om at det er behov for det. I vårt tilfelle har det vært et sosialt intranett med blant annet et personalisert nyhetsutvalg, en aktivitetsstrøm og andre funksjoner som brukeren sjekker regelmessig for å få informasjon om sin arbeidsdag.

Vi forstod veldig tidlig i prosessen at målgruppen skulle være mobil. Det er likevel viktig å huske på at noen nettsider med andre funksjoner kan ha en helt annen målgruppe. Ikke alt skal være mobile-first i 2015 og det sier seg selv at en mobile-first løsning kan bare være en suksess hvis brukerne er mobile!

Til slutt er det viktig å huske på at mobile-first er en helhetlig metode og kan anvendes på et helt prosjekt eller på deler av et prosjekt. Det er faktisk et tankesett, en hel filosofi som har kapasitet til å forenkle både arbeidsflyten og brukeropplevelsen. Har man behov og ressurser til å gå mobile-first er det uten tvil mye å få ut av det både for utviklingsteamet og brukerne.

Links to interesting documentations:

Luke W. Presentation of mobile first:
http://www.lukew.com/presos/preso.asp?26

Mobile first core concepts:
http://bradfrost.com/blog/mobile/the-many-faces-of-mobile-first/

How to technically start with a mobile-first responsive design:
http://www.html5rocks.com/en/mobile/responsivedesign/ 

KPI Mobile use :
http://think.withgoogle.com/mobileplanet/no/

Le Pontois, Marion

Le Pontois, Marion

Konsulent // Enterprise 2.0
marion.lepontois@acando.no

 

Om bloggeren:
Frontend utvikler som jobber med moderne rammeverk, med et spesielt øye for design og grafisk utforming. Solid erfaring fra store scrum prosjekter for virksomheter som Sporveien, Orkla og TINE. Opptatt av sluttbrukerens perspektiv og brukskvalitet. Interesse for problemstillinger rundt fleksibilitet på jobb og nye måter å arbeide på.

comments powered by Disqus