Guide til udvikling af mobile løsninger i det offentlige

5 - Platformsafklaring

Det er relativt simpelt at indgå en aftale med en leverandør om at udvikle eksempelvis en iPhone-applikation, og få den lavet og distribueret. Men hvordan sikrer man, at den også virker, hvis Apple opdaterer styresystemet, eller hvis brugerne efterspørger ny funktionalitet? Eller hvis brugerne af Android-styresystemet også forventer, måske endda ligefrem kræver, at få en tilsvarende løsning.

Når man skal afklare sine platformsvalg, vil behovsafklaringen og indholds- og funktionalitetsafklaringen give meget input til den mere tekniske afklaring, der skal fastlægge, hvordan løsningen skal bygges, formidles og vedligeholdes. Man bør ligeledes have en klar idé om, hvad løsningen skal kunne udføre for dens brugere. Ikke desto mindre har man en række valgmuligheder og nogle tekniske beslutninger, der skal træffes. Det er den slags overvejelser dette afsnit handler om.

5.1 - Generelle overvejelser

Som med alle andre it-løsninger bør man som organisation undersøge, om der er nogle bindinger til løgningen eller nogle fordelagtige muligheder med hensyn til platformsvalg. En binding kan eksempelvis være en it-strategi, der skal følges eller en løsning, der skal benyttes. En mulighed kan omvendt være en eksisterende løsning, der kan genbruges eller tilpasses.

Det primære mål for enhver mobil løsning må være at ekskludere så få potentielle brugere som muligt. Ligeledes bør en myndighed altid stræbe efter at opnå den størst mulige platformsuafhængighed. Det kan opnås ved at understøtte så mange platforme, at man dækker det meste af et marked. Omvendt kan der være betydelige omkostninger ved at understøtte flere platforme både med hensyn til udvikling, vedligehold og drift.

Det er naturligvis vigtigt at afklare det potentielle brugergrundlag for den mobile løsning for at kunne vurdere om en business case kan holde. Udover at afklare det forventede antal brugere, skal det fastsættes, hvad brugerne må formodes at have behov for, herunder på hvilke platforme de befinder sig.

En mulig strategi kunne være, at services stilles til rådighed i form af applikationer på de platforme, der har flest brugere. Nogle myndigheder har eksempelvis udviklet løsninger udelukkende til Apples styresystem iOS og andre myndigheder til både iOS og styresystemet Android. Man må antage, at disse myndigheder har valgt netop disse platforme, fordi de rammer flest potentielle brugere. Ligeledes må man formode, at fraværet af applikationer til andre platforme skyldes, at gevinsten ved antallet af nye brugere, der kan opnås herved, ikke står til måls med udgiften til at udvikle og vedligeholde løsningen på sådanne platforme. Som offentlig myndighed skal man naturligvis også nøje overveje implikationerne af at fravælge at levere den mobile service til visse brugersegmenter på baggrund af platformsvalg. Er det eksempelvis en farbar vej udelukkende at udvikle en applikation til en iPhone, og kan man håndtere en kritik af valget?

En anden mulighed er at stille en service til rådighed som en netløsning, der kan tilgås af alle mobile enheder. Når man laver netapplikationer eller mobiloptimerede netsteder vil man typisk benytte samme strategi - dvs. optimere til flest mulige mobilbrowsere med henblik på at minimere omkostninger. Mange nyhedsmedier har eksempelvis et mobilt netsted, der er optimeret til mobile enheder med en trykfølsom skærm, men som virker i (næsten) alle browsere.

En vigtig afklaring er dog at finde ud af om løsningen skal være en applikation eller et mobilt optimeret netsted. Det handler de næste afsnit om.

5.2 - Normale netsteder

Mobile enheder tilgår internettet med de samme protokoller, som en normal computer gør det. Wireless Application Protokollen (bedre kendt som WAP), der var et forsøg på at levere WWW-indhold til mobiltelefoner er i realiteten uddød. I dag tilgås internettet i stedet af mange forskellige slags enheder, der har vidt forskellige egenskaber, og dermed bliver brugerens oplevelse også forskellig, afhængig af hvilken enhed, der anvendes.

Alle smartphones på markedet i dag har browsere, der er fuldt ud på højde med de browsere, man kender fra normale pc’ere. Den eneste markante forskel er, at de skal fungere på en mindre skærm. Men da langt de fleste netsteder ikke er mobiloptimerede har man taget højde for dette og implementeret løsninger, der gør det muligt at overskue og læse normale netsteder. Visningen af netsteder er oftest på moderne mobile enheder implementeret på den måde, at man zoomer ind på dele af netstedet, eksempelvis en kolonne med tekst.

Illustration af zoom på kolonneIllustration af zoom på kolonne
Illustration af zoom på kolonne

Et normalt netsted kan med andre ord være fuldt ud tilstrækkeligt, såfremt man ikke skønner, at man har et særskilt behov for at servicere mobile enheder, selvom brugeroplevelsen vil være nedsat på disse. Såfremt et netsted virker acceptabelt i browsere på mobile enheder, bør man derfor overveje, om det er nødvendigt at udvikle en mobil løsning (se afsnit om behovsafklaring).

Der er dog en række forhold, man bør være opmærksom på med hensyn til normale netsteder, som kan have betydning for, hvorvidt de er egnede på mobile enheder. Disse vil blive behandlet i det følgende.

Performance

Selvom mobile enheder ofte har lige så hurtige internetforbindelser til rådighed som pc’ere og lige så meget maskinkraft, er performance utroligt vigtigt i forhold til mobile enheder. Brugerne benytter ofte mobile enheder i kontekster, hvor tid er en væsentlig faktor, fordi man har behov for noget straksinformation, eksempelvis en køreplan en vejrudsigt eller lignende. Brugerne vil derfor have en tendens til at være mindre tilgivende over for ventetid end ved almindelige pc’ere. Dertil kommer, at mobile enheder med stor sandsynlighed vil blive benyttet i områder, hvor der ikke leveres hurtige 3G dataforbindelser. Endelig er det værd at være opmærksom på, at brugerne ofte betaler for forbrug afregnet i trafik målt i MB - især når de befinder sig i udlandet.

Flash/Java-applets og andre plugins

Hvor næsten alle pc’ere understøtter plugins som Flash, Silverlight og Java-applets i browseren, er det langt fra givet på mobile enheder. Apples iOS understøtter eksempelvis ingen af ovenstående teknologier, og understøttelsen på andre platforme varierer meget.

Hvis visningen af et netsted er afhængig af tilstedeværelsen af plugins kan man overveje at lave en mobil løsning uden samme afhængigheder.

Eksempel på netsted, der benytter Flash og som derfor ikke virker i Apples iOS.
Eksempel på netsted, der benytter Flash og som derfor ikke virker i Apples iOS.

Inputmetoder

Mobile enheder vil typisk have enten et fysisk eller et virtuelt tastatur, der som udgangspunkt fungerer tilfredsstillende i formular-felter. Man bør være opmærksom på, at mange mobile enheder, især enheder i telefonstørrelse, ikke er velegnede til at skrive tekster på. Brug af teksteditor-lag, såkaldte wysiwyg editors, hvor redaktører eller brugere kan skrive tekst, er typisk lavet med javascript oven på formularelementer, kan give problemer på visse mobile enheder.

Mange netsteder gør brug af såkaldte events, der aktiveres af musen. Det drejer sig eksempelvis om menuer, der folder sig ud eller tekst, der vises, når musen bevæger sig over noget indhold. På mobile enheder med trykfølsomme skærme er det kun events, der aktiveres med et klik, der virker. Man kan ikke svæve med fingeren over noget indhold ligesom man kan med en musemarkør. Klik-events, hvor indhold flyttes fra et sted til andet sted på siden, også kaldet drag and drop, vil heller ikke virke på mobile enheder, fordi flyt/drag-event’en er reserveret til, at brugeren med fingeren kan navigere rundt på netsiden.

Hvis implementeringen af inputmetoder gør, at man ikke kan benytte netstedet tilfredsstillende, kan man overveje at at lave en løsning, der er optimeret til mobile enheder.

Informationsarkitektur og navigation på normale netsteder

En kompleks navigationsstruktur er aldrig nogen god netpraksis, hvilket også blev diskuteret i funktionalitetsafklaringen, men for mobilbrugere af normale netsteder kan navigationsstrukturen praktisk taget umuliggøre brugen af et netsted. Det samme gør sig gældende for visse typer af navigationsblokke.

Hvis det er nødvendigt at bruge zoom-funktionen på et netsted med en mobil enhed, hvilket typisk vil være tilfældet, så skal man være opmærksom på, at en dyb navigationsstruktur mindsker overskueligheden betragteligt for brugeren. Brugeren ser nemlig kun et udsnit af netsiderne samtidigt med, at han/hun skal huske navigationstrukturen.

Navigationsblokke, der er gør brug af mouseover events, dvs. events hvor en markør svæver over en tekst for at folde en undermenu ud, kan være vanskelige eller umulige at benytte på en mobil enhed.

5.3 - Mobiloptimerede netsteder

Mobiloptimerede netsteder er netsteder, der er udviklet til at fungere på en mobil enheds internetbrowser, og som derfor undgår de faldgruber, der kan være ved at vise normale netsteder på mobile enheder, som beskrevet i forrige afsnit.

Typisk har mobiloptimerede netsteder færre muligheder, men er til gengæld fokuseret på at levere netstedets kerneservices på en måde, der fremmer brugeroplevelsen. Læs mere om hvilke overvejelser, man bør gøre sig, i afsnit 4 om funktionalitetsafklaring.

Eksempel: Aarhus kommunes mobiloptimerede netsted side om side med kommunens almindelige netsted.
Eksempel: Aarhus kommunes mobiloptimerede netsted side om side med kommunens almindelige netsted.

Illustrationen ovenover viser henholdsvis Aarhus kommunes mobile og normale netsted. Forskellen er markant, og det er helt tydeligt, hvilken løsning, der fungerer bedst på en mobil enhed med en lille skærm. I den mobiloptimerede version af netstedet har kommunen fokuseret på de forretningskritiske services, der er centreret omkring servicering af borgeren, og rent designmæssigt skalerer den til skærmen.

På det normale netsted er der foruden vigtige services også mulighed for at vise en mere mangfoldig præsentation af kommunen eksempelvis med artikler og billeder. Siden er kompatibel med mobile enheder, men den skalerer dårligt til en lille skærm. Omvendt ville det mobile netsted virke fattigt og ukomplet i en browser på en computer med en stor skærm.

Metoder

Der er flere metoder til at fremstille mobiloptimerede netsteder, og i næsten alle tilfælde er der god mulighed for at opnå platformsuafhængighed og understøtte mange brugere.

Når man vælger sin metode bør udgangspunktet så vidt muligt være på at udnytte de muligheder, den eksisterende løsning giver, såfremt en sådan findes. I visse tilfælde vil man skulle bygge et nyt netsted (til mobile enheder) op fra bunden, men i andre tilfælde vil man med relativt få midler kunne stable.table en mobil løsning på benene på baggrund af en eksisterende løsning.

LøsningBeskrivelse
Stylesheets

Hvis netstedet er fremstillet hensigtsmæssigt og hvis performance og svartider kan gøres acceptable.table, kan det være en forholdsvis billig fremgangsmåde at lave dem mobiloptimerede udgave af et netsted ved hjælp af stylesheets. Det relevante stylesheet aktiveres, når siden eksempelvis tilgås af en enhed med en lille skærm eller en skærm, der er har orientering som portræt.

CMS-løsningp Mange moderne content management systemer (CMS) er udstyret med funktionalitet eller udvidelser, der giver forholdsvis let mobilunderstøttelse. Det gælder eksempelvis for Plone, Umbraco, Joomla, Drupal og Wordpress. Typisk er der tale om out-of-the-box-løsninger, som i bedste fald blot vil kræve tilpasninger af farver, logo osv., men som iøvrigt sikrer en god brugeroplevelse på tværs af platforme
Nyt netsted

Hvis man vælger at lave et nyt netsted målrettet mobile netsteder, har man samtidigt også den bedste mulighed for at skræddersy løsningen. Selvom det nye netsted kan benytte samme database, som det eksisterende netsted og i et vist omfang også basere sig på eksisterende skabeloner, er det overvejende sandsynligt at denne løsning vil være den dyreste.

I udviklingen skal der tages højde for, at forskellige browsere på forskellige mobile enheder med forskellige skærmstørrelser renderer netstedet forskelligt. Omfanget af opgaven med at optimere til så mange platforme så muligt skal absolut ikke undervurderes i omfang.

Mashup-løsningHvis det indhold der skal formidles på mobile enheder, eksempelvis allerede findes i syndikeret form, eksempelvis som et RSS-feed, er det muligt at fremstille mashups, der henter informationen automatisk fra det normale netsted.

Designprincipper

Det er yderst vanskeligt at opnå, at alle mobilnetsteder opfører sig ens på tværs af forskellige mobile enheder og browsere. Selvom understøttelsen af webteknologier som HTML, CSS og javascript generelt er god, varierer mængden af implementerede funktioner fra browser til browser og fortolkningen af disse er også forskellig. Dertil kommer, at mobile netsteder skal tage højde for mange forskellige og typisk små skærme, der både kan vise netstedet i landskabs- og portræt-modus (når telefonen benyttes vandret eller lodret). Endelig skal man huske, at selvom netstedet typisk målrettes de mest udbredte platforme, kan det stadig være en fordel, hvis det mobile netsted også kan benyttes på ældre enheder, eksempelvis mobiltelefoner med simple browsere.

Som en tommelfingerregel bør man derfor benytte sig af nogle relativt konservative designprincipper, der bl.a. inkluderer, at det mobile netsted:

  • bør være simplere at navigere rundt i end det normale netsted og meget gerne med en lille linkdybde
  • indeholder færre elementer og billeder
  • minimerer scroll
  • undgår unødvendige velkomstskærme (splash screens)
  • tilbyder et link til det normale netsted, hvis et sådan et findes

Man bør naturligvis lave en afklaring af i hvilken udstrækning, man vil understøtte alle typer enheder. Ældre telefoner med browsere har en basal XHTML og CSS-understøttelse, men vil ikke være i stand til at afvikle javascripts og dermed AJAX. Omvendt er det kun relativt nye mobile enheder, der har topmoderne browsere, og hvis man udelukkende udvikler mod dette segment, risikerer man at tabe en mængde potentielle brugere.

Når man har afklaret, hvilket spænd af mobile enheder, som løsningen skal understøtte, er der en række designstrategier, man kan benytte for at nå flest mulige brugere.

Graceful degradationp Designstrategi, hvor en løsning udvikles til de nyeste og mest moderne platforme/browsere, hvorefter man indbygger håndtering af ældre platforme/browsere, der ikke understøtter al funktionalitet ved at give alternativer. Hvis en ældre browser eksempelvis ikke understøtter en menu lavet i Javascript, vil man ifølge strategien sikre, informationen gøres tilgængelig på en anden måde eksempelvis ved hjælp af HTML.
Progressive enhancementp Designstrategi, hvor en løsning først udvikles i sin mest basale form, så også ældre platforme/browsere understøtter den. Herefter udbygges løsningen gradvist med mere avanceret funktionalitet, som kun vises i moderne browsere/platforme. En menu vil eksempelvis først blive lavet i HTML målrettet ældre browsere, hvorefter man påfører javascript til menuen, som kun kan fortolkes i nye browsere.
Enhedsspecifikke løsninger

Designstrategier, hvor man udvikler flere versioner af en løsning målrettet forskellige i platforme, således at man effektivt kan tage højde for en platforms muligheder og begrænsninger. Denne strategi vil typisk kræve detektering af hvilke enheder, der tilgår løsningen, så en skræddersyet version kan vises på klientens platform.

Da der skal udvikles og vedligeholdes flere versioner, vil denne metode typisk være forbundet med flere omkostninger.

5.4 - Applikationer

En applikation, ofte kaldet mobil-app eller bare app, er software, der er skrevet specifikt til mobile enheder. De primære fordele ved applikationer er, at de kan give rige brugeroplevelser og gøre brug af enhedens hardware, såsom kameraet.

Et kendetegn for applikationer er ligeledes, at de installeres via platformsudviklerens netbutik - også kendt som en app store. Kendte eksempler på platforme er Apples iOS, Google Android og Microsofts Windows Phone 7. Konsekvensen heraf er, at udvikleren eller ejeren af applikationen skal sørge for at få den godkendt af netbutikinidehaveren, så den kan distribueres. Proceduren for godkendelse varierer fra leverandør til leverandør.

De fleste applikationer fokuserer på at give en så god brugeroplevelse som muligt omkring så få funktionaliteter som muligt - og hvis de indeholder flere funktioner, vil de stadigvæk typisk indeholde færre end én variant af applikationen til en almindelig pc. Eksempelvis vil en tekstbehandlingsapplikation til en mobilenhed indeholde langt færre muligheder end en tilsvarende til en normal pc. Dels fordi det vil være vanskeligt at gøre alle funktionaliteterne tilgængelige på en typisk mindre skærm, dels fordi det vigtigste på en mobilenhed typisk vil være teksten og ikke formatteringen af den. Applikationer, der viser vejret, vil typisk fokusere på at vise vejret i den kontekst, som brugeren befinder sig i, mens mere perifære vejroplysninger, som vil være tilgængelige på et netsted, typisk undlades.

Det kan være vanskeligt at fastslå forskellen mellem, hvilke funktioner et netsted udfører, og hvilke en applikation udfører. En tommelfingerregel er, at typisk vil en applikation have fokus på funktionalitet, mens et mobiloptimeret netsted primært vil formidle information. Der findes dog mange applikationer, der bryder med dette princip og eksempelvis udelukkende viser nyheder. Det kan give nogle fordele, men hvis man overvejer at lave en applikation, der udelukkende viser nyheder, bør man måske i stedet overveje et mobiloptimeret netsted - ikke mindst fordi det typisk er i en browser, man læser nyheder.

En typisk årsag til at vælge applikationer fremfor eksempelvis mobiloptimerede netsteder eller netapplikationer er, at de kan give en bedre brugeroplevelse skræddersyet til den pågældende platform. Når man laver dedikerede applikationer, vil der med platformen typisk følge en række designguidelines, der har til formål at sikre, at applikationen bedst muligt udnytter enhedens muligheder, fysiske knapper og en kongruens med andre applikationer - alt sammen for at gøre det lettere for brugeren. Når man laver en netbaseret løsning, vil man typisk forsøge at understøtte flere platforme, der har forskellige designguidelines, hvilket gør det yderst vanskeligt at maksimere brugeroplevelsen.

Applikationer har desuden adgang til til telefonens hardware, såsom kompas, kamera, gyroskop og kan afvikle krævende grafik. Samtidigt er der også udvidet adgang til styresystemets software-API’er, hvilket kan inkludere adressebog, kalender, fotoalbums, medieafspiller og multitaskning.

Platforme

Når man vælger at lave applikationer, står man samtidig over for en afklaring af, hvor mange forskellige platforme, man vil understøtte. Man bør her være særdeles opmærksom på, at hver platform vil kræve et separat udviklingsspor og et separat vedligeholdsspor.

Vælger man eksempelvis at lave løsning til både iOS-platformen og Android-platformen, skal der altså udvikles versioner til begge platforme. Derudover skal versionerne til begge platforme vedligeholdes og holdes ajour som minimum, når styresystemet bliver opdateret.

PlatformNokia har besluttet ikke at udvikle telefoner med Symbian-platformen fremover men i stedet benytte Windows Phone 7. HP, der har varetaget WebOS-platformen, har ligeledes meddelt, at de ikke længere vil udvikle mobile enheder. Af samme årsag beskæftiger dette dokument sig ikke med Symbian og WebOS, da de næppe vil få nogen stor brugerskare i Danmark. BlackBerry OS har i skrivende stund en meget lille udbredelse i Danmark og er derfor ikke behandlet her.Hardware
iOSIpad, Ipod Touch, Iphone fra Apple
Android350+ forskellige enheder fra forskellige leverandører. Det skønnes dog, at 50 enheder udgør 99% af det danske marked.
Windows Phone 78-10+ forskellige enheder fra forskellige leverandører

Det er værd at bemærke, at det udelukkende er Apples egne enheder, der kan benytte Apples styresystem, og at der er relativt få forskellige enheder, der benytter det. Det giver Apple en stor kontrol over platformen. Det kan man drage nytte af som udvikler af en applikation, idet man ved at følge nogle designguidelines relativt simpelt kan lave applikationer, der virker på alle platformens enheder. Apple skal godkende applikationer og opdateringer af disse, før de bliver tilgængelige i Apples appstore. Der er eksempler på, at denne proces kan tage relativt lang tid, og at applikationer af forskellige årsager afvises.

Windows Phone 7 har valgt en strategi, hvor hardwareleverandører kan levere enheder med styresystemet. Til gengæld er der skrappe krav til, hvilke hardwarespecifikationer disse enheder skal have netop for at sikre en ensartet brugeroplevelse. Microsoft skal godkende applikationer, der lægges i WP7’s Marketplace. Microsoft angiver, at godkendelsesproceduren er højst tre dage. Der er ligeledes mulighed for, at applikationer afvises.

Android-styresystemet er det mest udbredte styresystem til mobile enheder og bliver benyttet på mange forskellige enheder. Dette kan umiddelbart give en del udfordringer med hensyn til at få en applikation til at virke ensartet på tværs af alle disse enheder, men fragmenteringen relaterer sig primært til softwareversioner og skærmstørrelser, og da disse ikke varierer så meget, må det antages, at udfordringen er håndterbar. Der er ingen restriktioner for at oprette og opdatere applikationer i Android Market, hvilket er en fordel i forhold til vedligehold. Som udgangspunkt bliver applikationer kun afvist, hvis de indeholder malware eller er skadelige på anden vis. Der er ingen godkendelsesprocedure for at lægge applikationer i Android Market, hvilket gør det meget let at oprette og opdatere en applikation i denne netbutik.

Cross platform-løsninger

Der findes værktøjer, som kan “oversætte” applikationer fra en platform til en anden. På den måde kan man nøjes med at udvikle én løsning. Herefter kan man benytte værktøjet til at lave udgaver til at andre mobile platforme. Sådanne værktøjer vil typisk være vanskelige at benytte til mere komplekse løsninger, og som med netbaserede løsninger kan det være vanskeligt ramme et layout, der er hjemmehørende på de forskellige platforme.

Eksempler på værktøjer, der kan lave applikationer:

  • Phonegap
  • http://rhomobile.com
  • Appcelerator
  • Webview

“Find en frekvens” på henholdsvis Android og iOS. Applikationerne er lavet med Phonegap og er ens på begge platforme, men afviger fra både Androids og iOS’ designguidelines.“Find en frekvens” på henholdsvis Android og iOS. Applikationerne er lavet med Phonegap og er ens på begge platforme, men afviger fra både Androids og iOS’ designguidelines.
“Find en frekvens” på henholdsvis Android og iOS. Applikationerne er lavet med Phonegap og er ens på begge platforme, men afviger fra både Androids og iOS’ designguidelines.

5.5 Netapplikationer

En netapplikation, også kaldet web app, er et program, der afvikles ved hjælp af den mobile enheds indbyggede browser. Den primære fordel ved netapplikationer er, at de muliggør distribution uden at brugerne skal downloade og installere softwaren, idet programmet i virkeligheden er et netsted. Det betyder ligeledes, ideelt set, at afsenderen kun skal vedligeholde én platform målrettet mobile enheder. Samtidigt er det muligt at udnytte en række af de muligheder som internettet giver, såsom eksempelvis indeksering af søgemaskiner og mulighed for at der kan linkes direkte til netapplikationen.

Sammen med teknologier som HTML, CCS og Javascript muliggør dette, at man kan lave rige programmer, der ofte kan afvikles platformsagnostisk, så længe telefonen har adgang til internettet.

Ligesom en dedikeret applikation udfører en netapplikation typisk kun en begrænset mængde funktionalitet, men den behøver ikke være begrænset til dette.

Fødevareministeriets netapplikation “Lystfiskeri og fisketegn” giver mulighed for at købe et fisketegn og benytter telefonens geolokations API til at vise brugeren fredede områder i nærheden.Fødevareministeriets netapplikation “Lystfiskeri og fisketegn” giver mulighed for at købe et fisketegn og benytter telefonens geolokations API til at vise brugeren fredede områder i nærheden.
Fødevareministeriets netapplikation “Lystfiskeri og fisketegn” giver mulighed for at købe et fisketegn og benytter telefonens geolokations API til at vise brugeren fredede områder i nærheden.

En indvending mod netapplikationer kan være, at de, ligesom andre netsteder, kun virker, når den mobile enhed har adgang til internettet. Der findes dog muligheder for at understøtte offline browsing, som gør brug af et API, der er indbygget i de fleste moderne browsere. Kort fortalt lagres netapplikationen i enhedens hukommelse (cache), hver gang den besøges online. Er enheden uden for rækkevidde af internettet, vil netapplikationen stadig fortsætte med at virke med de data, som blev lagret, sidst netapplikationen blev benyttet med adgang til internettet. Det er ligeledes muligt at gemme indstillinger foretaget af brugeren i netapplikationen på enheden, således at de også vil være tilgængelige, næste gang brugeren benytter programmet.

De grafiske muligheder i netapplikationer er de samme, som kan opnås med et normalt netsted. Dog bør man afholde sig fra at benytte Flash, Silverlight og lignende teknologier, fordi understøttelsen af i disse er begrænset på nogle mobile enheder. Animationer og lignende afvikles derfor med javascript. Det er endnu ikke muligt at afvikle eksempelvis avanceret 3D-accelereret grafik og grafiske overgange vil typisk være mindre flydende, end det er kendetegnet på dedikerede applikationer.

Apples iOS giver mulighed for at tilføje netapplikationer til enhedens hjemmeskærm, angive et skrivebordsikon og skjule alle browserelementer. På den måde kan man lave netapplikationer, der til forveksling ligner applikationer, der er installeret på enheden via appstoren.

Fra browseren er der kun begrænset adgang til den mobile enheds hardware. På mange enheder er det muligt for browseren at få oplysninger om geolokation fra selve enheden, så netapplikationen kan give kontekstbaserede oplysninger eksempelvis ved at vise brugerens placering på et kort. Adgangen til anden hardware, såsom kompas, gyroskop og lignende, er dog yderst begrænset. Det er dog nærliggende at antage, at der vil ske en udvikling inden for dette område i de kommende år.

5.6 - Opsamling

Afstanden mellem netapplikation og applikationer må forventes at blive mindre over tid i takt med at programmer afviklet via browseren bliver mere og mere sofistikerede. Ikke desto mindre forventes der at gå adskillige år, inden det ikke vil have nævneværdige funktionalitetsmæssige konsekvenser at vælge det ene fremfor det andet. W3C står bag en standardiseringsindsats på området, der bl.a. har muliggjort, at netsteder og web apps kan gøre brug af geolokation bl.a. via mobiltelefonens GPS og offline caching.

LøsningstypeBeskrivelse
Normale netstederBrugeren tilgår myndighedens normale netsted med den mobile enheds indbyggede browser. I mange tilfælde er dette en tilstrækkelig løsning, og myndigheden skal intet foretage sig.
Mobiloptimeret netstedBrugeren tilgår en mobiloptimeret udgave af myndighedens netsted. Typisk vil man ved hjælp af stylesheets have tilpasset det normale netsted, så det fungerer bedre på en lille skærm ved at minimere antallet af kolonner og skjule indhold.
En netapplikationEn bruger tilgår et netsted, der fungerer som et program med enkelte funktioner stillet til rådighed af myndigheden.
En applikationEn bruger installerer en applikation, der fungerer som et program med enkelte funktioner stillet til rådighed af myndigheden, der kan gøre brug af telefonens hardware.

Man bør overveje følgende muligheder og begrænsninger, der gælder specifikke løsninger rettet mod mobile enheder:

Område(Mobiloptimerede) netstederNetapplikationApplikation
InternetadgangPåkrævet (HTML5 giver visse offline-muligheder). Brugeroplevelsen kan nedsættes drastisk, såfremt netforbindelsen eksempelvis er langsom.Påkrævet (HTML5 giver visse offline-muligheder). Brugeroplevelsen kan nedsættes drastisk, såfremt netforbindelsen eksempelvis er langsom.Ikke altid påkrævet, idet der er gode muligheder for at lagre indhold i applikationen. Applikationer, der viser nyheder eller lignende er naturligvis afhængige af en netforbindelse.
Hardwareadgang til kamera, accelerometer, mikrofon, GPS, hukommelse etcBegrænset til geo-lokation, off-line cache, højtaleradgang.Begrænset til geo-lokation, off-line cache, højtaleradgang.Typisk fuld eller næsten fuld adgang.
DistributionWebserver.Webserver.Oftest gennem app store / markedsplads. Vil ofte kræve godkendelse af tredjepart.
InstallationIngen.Ingen.Installation og opdatering på brugerens mobile enhed.
UdviklingWebudvikling med HTML/CSS/Javascript samt diverse backend-sprog.Webudvikling med HTML/CSS/Javascript samt diverse backend-sprog.Der skal udvikles en særskildt applikationer til hver platform, der skal understøttes med deraf følgende udviklingsværktøjer krav til kodesprog. Derudover skal der i visse tilfælde udvikles i backendsprog.
VedligeholdWorld Wide Web. Ændringer kan foretages på en server og være tilgængelige for alle.World Wide Web. Ændringer kan foretages på en server og være tilgængelige for alle.Der skal sikres vedligehold til hver platform, som der udvikles applikationer til.
SupportWebudvikling.Webudvikling.Der skal sikres support til hver platform, som der udvikles applikationer til.
MultitaskningBegrænset.Begrænset.Til stede.
Grafik/animationerHovedsageligt webudvikling med HTML/CSS/Javascript. Hovedsageligt webudvikling med HTML/CSS/Javascript. Rige platformsspecifikke muligheder.
User interfaceBrowser. Det kan være vanskeligt at overføre netsted til lille skærm.Browser. En del muligheder for at skabe applikationsagtigt user interface.Hurtigt, mange tilpasningsmuligheder. Gode muligheder for at skabe en god brugeroplevelse.
OmkostningerDer skal kun udvikles en løsning, der kan styres centralt. Løsningen kan typisk udarbejdes af webdesignere og udviklere med kendskab til valgte backend-teknologier.Der skal kun udvikles en løsning, der kan styres centralt. Løsningen kan typisk udarbejdes af webdesignere og udviklere med kendskab til valgte backend-teknologier.Flere omkostninger især hvis der skal distribueres til flere platforme. Tendens til at der skal bruges flere ressourcer, når der udvikles applikationer. Dette er dog ikke en generel regel. Løsningen skal udvikles af konsulenter, der har kendskab til de programmeringssprog, som er påkrævet af den enkelte platform.