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'
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
