Virker din web-app også på en iPad?

Min medblogger Kurt Westh Nielsen skrev for et stykke tid siden i et blogindlæg om smartphones, at 'en webbrowser er den ultimative app'. Der er ingen tvivl om, at man bliver nødt til at overveje nøje, om det giver mest mening at udbyde noget given funktionalitet som en native smartphone app eller udnytte fleksibiliteten af at have en webapp - især når det drejer sig om applikationer, der skal fungere både på desktop-computere og mobile enheder eller tablet PC?er.

Smartphones er generelt kendetegnet ved en langt mindre skærmstørrelse end desktop-computere, og vil man udbyde funktionalitet til brug på en smartphone vil det i langt de fleste tilfælde give det bedste resultat, hvis applikationen (web eller native app) er tilpasset til brug på mobilen med en kraftig sortering i den information og funktionalitet, der tilbydes til brugeren.

iPads og andre tavle-PC'er, der har en skærmstørrelse, hvor det er mere rimeligt at sammenligne med en desktop-computer, kan man nemt komme til at overse i denne sammenhæng. Et mobil-interface vil ofte virke forsimplet og 'skrabet?, mens en almindelig hjemmeside eller web-applikation kan vise sig at opføre sig noget anderledes end man er vant til fra en desktop-computer.

Et par af de problemer, man kan snuble over ved at forsøge at genbruge en alm. web-applikation til en iPad, er følgende:

Brugeren har ikke nogen mus, og derfor er der også en lang række af de bruger-events i JavaScript, man plejer at benytte sig af, der aldrig vil blive fyret på en iPad, f.eks. 'onmousedown'. I stedet skal man benytte sig af de tilsvarende touch-events, bl.a. 'ontouchstart'. Man skal dog være klar over, at der også kan være noget default-opførsel på events'ene, som det er irriterende at få ødelagt, f.eks. skal man tænke sig om, når man laver drag-and-drop, da det at trække fingeren hen over skærmen normalt benyttes til at scrolle. Der findes i øvrigt udmærkede JavaScript-biblioteker til drag-and-drop på iPad'en, bl.a. gotProject.

På en desktop-computer vil en bruger normalt først bevæge musen hen over et område, før han klikker på det. Det kan man f.eks. benytte til at highlighte de elementer, der kan klikkes på, når brugeren er ved at være i nærheden. Det kan man ikke på samme måde på en iPad - brugerens finger kommer 'flyvende' fra oven og sætter fingeren netop på det punkt, man vil klikke på.

Og højreklikke kan man jo heller ikke med en finger - til gengæld kan man lave forskellig fuktionalitet alt efter hvor længe, brugeren holder fingeren nede (eksempelvis markere noget tekst i stedet for at klikke på den).

Er man vant til at bruge 'fixed' CSS positionering, dvs. at placere elementer et fast sted på skærmen, uanset om resten af siden scroller, så får man sig også en grim overraskelse når iPad?ens Safari insisterer på at scrolle hele siden som én lang side. Tilsvarende hvis man benytter IFRAMEs, så har de heller ikke deres egen scrollbar. Der er dog forskellige quirks, man kan benytte sig af for at få en nogenlunde tilsvarende funktionalitet, se f.eks. iScroll-biblioteket.

Og så behøver jeg vel ikke at gentage mig selv omkring hvor kikset man som iPad-bruger oplever det, når hjemmesider ikke tilbyder alternativt indhold til den Flash-løse del af befolkningen...

Hvad oplever du som udfordringerne, når et website eller en web-app skal fungere på både desktop-computere og tablets' Og har du et bud på løsningerne'

Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup

Jeg synes det er ærgeligt at Mobile decides ikke understøtter contenteditable. Hvis man vil editere Rich text, bliver man nød til at implementere det på en anden måde. Som fx Google docs. Hvis der er nogen der kender en god Rich text editor, a la contenteditable til Mobile decides, som man kan plugge ind i sin egen webapplikation, vil jeg meget gerne høre om det :-)

  • 0
  • 0
Allan Ebdrup

Måske. Virker din iPad også til internettet?

Det oprindelige spørgsmål er mere reelt end det. Men man kunne måske bedre stille det lidt bredere spørgsmål:

Virker din webapplikation også med et touch interface?

Visse dele af dit UI design vil blive påvirket af at tage hensyn til touch interfaces. Som jeg mener Anne-Sofie gennemgår meget fint, og ikke-iPad-specifikt.

Hvis du ikke tager hensyn til det, vil din webapp blive fravalgt, da der kun vil komme flere og flere devices med touch interface i fremtiden.

  • 0
  • 0
Anne-Sofie Nielsen

Vi er altså gået væk fra at lave applikationer der kun virker i specifikke browsere/devices.

Ja, det lyder jo rart, men hvad betyder det så i praksis?

a) At du vælger laveste teknologiske fællesnævner og f.eks. fravælger drag-and-drop og andre problematiske ting som beskrevet i blogindlægget

b) At du har fundet nogle gode værktøjer/biblioteker som tillader dig at abstrahere hen over problemer (og i så fald håber jeg, at du vil dele det med os andre)

eller

c) At du fravælger den stigende andel af potentielle brugere/kunder som ville have betjent din web-app / besøgt dit website via et device med touch-interface?

  • 0
  • 0
Allan Ebdrup

Jeg mener der er en løsning d
d) Du laver en UI der virker både med et touch-interface og for en der sidden med en almindelig mus.
Det kan du faktisk godt. Der er bare nogle regler du skal overholde.

1) Drag and drop skal du fx altid lave med et specifikt drag&drop ikon som man også kan hive fat i et touch interface.
2) Der er en vigtig event du har glemt: Du må ALDRIG være afhængig af onmouseover (den virker ligesom ikke med touch), men jeg vil mene at man alligevel er ude i noget snavs hvis din UI er afhængig af onmouseover.
3) 2 betyder også at du ikke kan regne med at brugeren kan se tooltips osv. Alle knapper skal være selvforklarende, bare du ser dem.
4) Ikke noget med små knapper eller ikoner man kan kilkke på, alting skal være "fingerstørrelse".
5) Flere?? Kom gerne med erfaringer.

Min erfaring er at selve applikationen faktisk generelt bliver bedre af at tage hensyn til touch. Du bliver nød til at lave en "renere" UI, med færre større knapper/ikoner, hvor alting skal have en mere umiddelbar tydelig funktion, da du ikke har tooltips og mouseover effekter til rådighed.

Hvis du gør det rigtigt ender det med at være en win-win situation, både for folk med touch-devices og folk med en almindelig mus.

  • 0
  • 0
Brian Matzon

Jeg har endnu ikke set lyset for at indføre browser-specifikke touch-(start, move, end). Der kan sikkert være nogle cases jeg ikke lige har set. Men grundlæggende bør det være browserens opgave at omsætte sit interface til de allerede eksisterende 'mouse' events.

Når det så er sagt, så kan jeg da godt se at vi på sigt skal arbejde mod nogle fælles planer for touch devices, i w3c regi eller anden inter-browser sammenarbejde. I stedet for specifikke browser løsninger (webkit/mozilla/trident etc).

Men grundlæggende snakker du jo ikke om generelle touch problem stillinger (gotProject = iPhone/iPad, iScroll (webkit)), manglende flash, ligesom overskriften er ret specifik omkring eet specifikt device.

  • 0
  • 0
Kai Birger Nielsen

Alternativet er at gå native og lave en ipad application og en android application osv. JP har en meget tankevækkende anmeldelse af iPad'en, hvor en af pointerne er at man fravælger sites der er trælse (flash og/eller besværlig touch-UI) og tilvælger applicationer (men kun hvis de er nødvendige for fx at få en superlækker udgave af Ingeniøren/Politiken/...).

Jeg tror bare ikke meget på udbredelsen af fx en Matas Ipad-application, så application-udvejen er der nok reelt ikke for ret mange af os.

Hmm, egentlig vil jeg vist græde tørre tårer, hvis det holder op med at være moderne med fx 5 flash-animationer på hver side.

Tak til Anne-Sofie for at tage det problem op.

  • 0
  • 0
Anne-Sofie Nielsen

Men grundlæggende snakker du jo ikke om generelle touch problem stillinger (gotProject = iPhone/iPad, iScroll (webkit)), manglende flash, ligesom overskriften er ret specifik omkring eet specifikt device.

Ja, det har du helt ret i - jeg valgte dog i mit blogindlæg primært at tale omkring iPad'en, da det er den eneste, jeg har erfaring med, men det er klart, at der er tilsvarende problemstillinger ved andre typer af tablets. Jeg synes bare, at det ville være falsk varebetegnelse at forsøge at skrive generelt om tablets, da jeg pt. ikke har erfaring med de øvrige.

Så det håber jeg, at der er nogle af læserne, der kan bidrage med! :-)

  • 0
  • 0
Casper Thomsen

Væsentligt og interessant emne. Personligt er jeg overbevist om, at vi med mobilens endelige gennembrud som webenhed de seneste år står over for et (nyt) paradigmeskifte for webudvikling, både teknisk og forretningsmæssigt.

Knap er vi nået til et punkt, hvor vi ikke længere skal slås vildt med kompatibilitet på tværs af browsere - før vi skal forholde os til, at vores brugere tilgår vores webprodukter fra en række vidt forskellige enheder, som stiller os over for andre og langt større udfordringer.

På det rent tekniske niveau har det en række konsekvenser, som Allan så fint redegør for, men også på det konceptuelle niveau skal vi tage højde for nye ting. Hvad er brugerens situation på henholdvis desktop / mobil / tavle-pc, når han tilgår vores site? Hvilket indhold og hvilke funktioner passer til den situation? Hvordan laver vi et interface, som både tilgås med mus og pegefinger?

Jeg er ikke enig med Brian i, at browseren selv kan håndtere disse forskelle, for det handler om meget mere end bare håndtering af forskellige Javascript-events. Og lige nu løser mange det med en forskellig kodebase for hver ny enhed, hvilket jo er uholdbart.

Hidtil har vi talt meget om desktop / mobil, men jeg er enig med Anne-Sofie i, at tavle-pc'er som en iPad skal betragtes som sin egen gruppe. Lige nu er fokus desværre på iPad-apps, men vi begynder at se sites, som også indtænker tavle-pc'er i forhold til webdelen - for eksempel Zeit.de
http://www.informationarchitects.jp/en/news-on-ipad-the-obvious-way/

Jeg faldt netop i dag over Touch Gesture Reference Guide, som er et interessant forsøg på at gøre udvikling af touch-interfaces på tværs af enheder mere tilgængeligt
http://www.lukew.com/ff/entry.asp?1071

Det er formentlig bare et af mange tiltag, som skal til for, at vi i fremtiden håndterer det som noget naturligt, at webadgang ikke er lige med en bærbar pc, men også kan hedde smartphone, iPad, Google TV eller hvad der nu dukker op.

Til orientering foregår 1 ud af 10 sidevisninger på version2.dk i dag fra en mobilenhed, nogenlunde 50/50 fordelt mellem iPhone og Android-enheder.

  • 0
  • 0
Casper Thomsen

Jeg savner utroligt meget boksen seneste debat på mobil versionen af version2.dk

Hvis du trykker på "Debat" i toppen af mobilsitet skulle du meget gerne få en oversigt over de seneste artikler/blogs med debat. Det ligger altså som et menupunkt, ikke som et element på forsiden.

Eller er det noget andet, du forestiller dig?

Mvh Casper

  • 0
  • 0
Michael Rasmussen

Jeg er bekendt med debat linket. Hvad jeg mangler i forhold til desktop udgaven er oplysningen om antallet af indlæg. Tidsangivelsen for seneste indlæg er ikke oplysende nok, da der kan være registreret flere indlæg indenfor samme tidsinterval, hvorfor jeg altid fokuserer mere på antallet af indlæg i debatten end tidspunktet for seneste registrerede indlæg.

  • 0
  • 0
Jakob Damkjær

"Det er vel reelt apple der skal sørge for at deres ipad virker til "internettet"?

Vi er altså gået væk fra at lave applikationer der kun virker i specifikke browsere/devices."

Derfor spoler vi et par år tilbage og ser på den gang Apple forkede KHTML til open source projektet webkit, browser libet der idag er basis for langt de fleste og mest udbredte mobile browsere... og en god del af browserne til desktopen (Safari og Chrome med flere).

OS HTML/JS

Symbian: Webkit / ?
WebOS: Webkit / ?
Android: Webkit / V8
BB Playbook: Webkit / ?
iOS: Webkit / SquirrelFish Extreme
WinPhone7: IE / Chakra

Det rigtigt gode spørgsmål er hvilken javascript engine de bruger.

For hvis googles android browser og chrome browser er de eneste der bruger V8/crankshaft JS enginen er det bedste valg hvis du vil ramme bredt blandt den ret overaskende diversitet der er blandt mobile OS platforme så kvalitetstester du din webapp mod webkits HTML layout render engine og JavaScriptCore (webkit JS enginen).

Det er jo selvfølgeligt muligt at andre engines bruges (fx V8 er den alle de andre webkit mobil implementeringer udover iOS bruger men så er det ikke noget der bliver slået på tromme over eller gjort opmærksom på...

Hvis der er nogen med nogle hårde fakta på JS engine diversiteten blandt de webkit baserede browsere så giv endenlig lyd.

Så lige pt er (kompatibel med Apples mobile webbrowser) = (kompatibel med meget store dele af internet browserene på mobile dimser).

Jup der er begrænsninger og en masse detaljer stadigt virker forskelligt mellem de forskellige platforme men mobil browsing idag hedder webkit hvis du ser godt nok efter (mm du har en af de der fancy windowsphone7 telefoner, bliver godt nok nice hvis WP7 får en GPU accelereret JS engine når de får IE9 ud i endelig version).

http://en.wikipedia.org/wiki/Chakra_(JavaScript_engine)

/Jakob

PS! idag er Google med i open source projektet webkit, men de var ikke med i det første lange stykke tid.

  • 0
  • 0
Frans Josef Meyer

.
Vi savnede, at kunne se og høre DR video og Lyd podcast nemt fra vores mobile enheder – så vi har lavet:

www.nempodcast.dk

Den dækker bl.a.:

iPad / iPhone / iPod Touch / Android / HTML5 / Flash afspilning af DR.dk Video og Lyd Podcast.

Målet har været - at samme web site - både skulle virke med mobil og desktop enheder.

Derfor kan man også dele et link til en given udsendelse - mailet, twittet osv...
uanset modtager platform...

DR omtaler den:

http://www.dr.dk/betalab/2010/07/14/dr-nu-pa-ipad/comment-page-2/#commen...

/Frans Josef Meyer

  • 0
  • 0
Log ind eller Opret konto for at kommentere