Slik får du Axure-prototypene dine til å fungere på mobil og nettbrett

Kjell Lybeck — Sat, 18 Feb 2012 22:12:49 +0000

Kjære kunde, “mobile first”…

I dag er det mer og mer vanlig å etablere seg i flere kanaler, men ikke alle er helt der enda. Morgan Stanley presenterte for en stund tilbake trender som sier at 91% av mobilbrukerne har mobilen innen 1 meters rekkevidde. Det nye “buzz wordet” er “mobile first”. The Economist presenterer frisk statistikk som “Every 4 seconds a child is born… and 15 mobile phones are sold”. Det er på tide å gjøre noe, ta noen valg.

Men mange forbinder “flerkanaleri” med økt kostnad, og man kvier seg litt. Hva om man prototyper en mobil løsning først, dette er jo raskt og enkelt å få til. I samme slengen kan man brukerteste det man lager for å få svar på om det man tenker fungerer på ordentlig.

Dette er vel dyrt? Egentlig ikke. Det blir en “Lakmustest” før man lager en ekte løsning, noe som er langt billigere enn å prøve å feile med ekte løsning.

Her er en oppskrift for hvordan man skaper en øyenåpner for kunden.

“Weapon of choice”

Axure RP Pro er et kraftig verktøy for prototyping av interaktive webløsninger. Når man skal lage prototyper tilpasset mobile enheter som iPhone og iPad er det noen hensyn du må ta for at prototypen skal fremstå korrekt i nettleseren på mobilen eller nettbrettet ditt.

Axure kan benyttes til å lage alt fra enkle skisser og wireframes til mer avanserte klikkbare og dynamiske prototyper. Verktøyet har et drag-and-drop widgets bibliotek hvor man enten kan benytte standardbibliotekene som følger med fra leverandøren, eller man kan tilpasse og lage egne bibliotek. Bibliotekene gjør at verktøyet er enkelt å bruke og man kan lage omtrent hva som helst, raskt, uten å skrive en eneste linje kode.

Prototypen

Vi valgte å prototype løsningen med en “standard mobil skjermbredde” på 320 pixler.

I prosjektet hvor vi første gang prototypet en mobil løsning, oppdaget vi at prototypen ble svært liten på mobilen når vi la den ut på webserveren. Mobilen vi testet på var en iPhone 4. Alt innhold ble svært lite og det ble presset opp i venstre hjørne som et frimerke slik skjermbildet under lengst til venstre viser.

Dette var verken realistisk eller optimalt i forhold til brukertesten vi hadde planlagt å gjennomføre. Vi prøvde derfor å løse problemet ved å øke størrelse på tekst og på skjermbredden i Axure til 480 pixler. Det ble litt bedre, men fremdeles ikke helt optimalt. Skjermbildet i midten over viser denne justeringen.

Vi fortsatte å eksperimentere til vi fant en mer optimal skjermstørrelse og landet på skjermstørrelsen 768 pixler. Skjermbildet over lengst til høyre illustrerer dette.

Lærdom: Vi hadde brukt lang tid med mye prøving og feiling for å komme fram til et resultat som vi ikke var fornøyde med. Vi hadde nå en prototyp som så grei ut på mobil, men som var håpløs å jobbe med i Axure. Den var håpløs fordi alt var gigantisk stort, man mistet oversikten og den var tung å vedlikeholde.

“Workaround”?

Det måtte da finnes en mer effektiv måte å jobbe på. Selvfølgelig gjorde det det. Et søk på Google viste at vi ikke var de eneste som hadde møtt på disse utfordringene. Litt magisk HTML-kode var alt som skulle til. Når man genererer en prototyp i Axure genereres et stort antall HTML-sider. Ved å inkludere en liten kodesnutt på hver av disse sidene i -taggen ble ting løst av seg selv, helt automagisk. I hovedsak var det tre varianter som dekker det meste.

1: Automatisk skalering

Dersom man ikke vet skjermstørrelsen man utvikler for, eller skal vise prototype på forskjellige enheter, er det hensiktsmessig og benytte en kodesnutt hvor skalering skjer automatisk. Den kan se slik ut:

Skjermbildene under viser forskjellen på en prototyp med 320 pixler bredde med og uten kodesnutten i -taggen.

Skjermbildene under viser forskjellen på en prototyp med 480 pixler bredde med og uten kodesnutten i -taggen

Skjermbildene under viser forskjellen på en prototyp med 768 pixler bredde med og uten kodesnutten i -taggen.

2: Overstyring

Ønsker man å overstyre hvordan den mobile enheten skalerer bredden på siden, kan man eksplisitt sette bredden inn i kodesnutten slik:

3: Begrensninger

Det er også mulig å sette begrensninger med kode slik at brukeren ikke har mulighet til å øke eller minske skjermstørrelsen. Dette kan gjøres på denne måten:

Eksperiment med iPad

Vi valgte samtidig å teste hvordan prototypen oppførte seg på en iPad. Vi testet med skjermbreddene 320, 480 og 768 pixler. Breddene 320 og 480 pixler utnyttet ikke iPad’ens skjermstørrelse særlig godt. Den beste skjermbredden var på 768 pixler.

Under følger skjermbilder av hva vi så når vi testet med de forskjellige skjermbreddene. Vi testet også her med og uten kode for automatisk skalering i -taggen:

Med 320 pixler bredde ble det seende slik ut:

Med 480 pixler bredde ble det seende slik ut:

Med 768 pixler bredde ble det seende slik ut:

Oppsummering

Så, var dette nybrottsarbeid? Sikkert ikke, men det gav oss svært nyttige erfaringer. Dette er ikke spesielt komplisert å få til når man har gjort det et par ganger, også var litt gøy også!

Hva har vi lært? Vi vet nå hvordan vi går fram og hvilke verktøy som kan benyttes til å prototype og til å testet mobile webløsninger. Slik vi ser det, men vi kan jo ta feil, så er dette en av de beste måtene å få testet nettopp dette på. Fremtidige prosjekter vil kunne gjennomføres raskt, effektivt og svært realistisk.

Videre vet vi ut i fra eksperimentering med skjermbredder, fontstørrelser og kodesnutter at dersom man skal lage en prototyp som både skal testes på iPhone og iPad bør den lages med en skjermbredde på 768 pixler med kodesnutten for automatisk skalering i -taggen. Skal man kun teste på iPhone fungerer alle skjermbredder så lenge kodesnutten er inkludert.

Oppskriften

1. Lag prototypen i Axure – jobb innenfor “standard mobil skjermbredde” på 320, 480 eller 768 pixler

2. Legg til en av følgende kodesnutter i HTML-filene for prototypen i -tag

Automatisk skalering:

Overstyring:

Ønsker man å overstyre hvordan den mobile enheten skalerer bredden på siden, kan man eksplisitt sette bredden inn i kodesnutten slik:

Begrensninger:

Det er også mulig å sette begrensninger med kode slik at bruker ikke har mulighet til å øke eller minske skjermstørrelsen. Dette kan gjøres på denne måten:

3. Legg prototypen ut på en webserver og åpne den på en iPhone eller iPad

Lykke til!

Automated functional testing of iPhone apps with iCuke

Aslak Hellesøy — Wed, 02 Jun 2010 12:05:20 +0000

Seeing the downloads of the open source BDD/Acceptance Testing tool Cucumber skyrocketing is great, but seeing what insane extensions the community comes up with is even greater.

UK-based super hacker and long time Cucumber contributor Rob Holland announced iCuke yesterday. iCuke is a Cucumber extension that lets you write automated functional tests for iPhone apps. Here is a little teaser…

iCuke from Aslak Hellesøy on Vimeo.

For questions about iCuke, please use the iCuke mailing list.

BEKK Open » iphone