Overvejelser ved mobil-udvikling: Web-baseret kontra native. Jesper Nielsen

Størrelse: px
Starte visningen fra side:

Download "Overvejelser ved mobil-udvikling: Web-baseret kontra native. Jesper Nielsen"

Transkript

1 Overvejelser ved mobil-udvikling: Web-baseret kontra native Jesper Nielsen 9. juni 2013

2 Resumé One trending discussion regarding applications designed for a mobile platform, is whether to go native and thereby develop one app per platform, or to develop a web-based solution i.e. a HTML5 based solution. The arguments towards a HTML5 based solution, is a develop once, deploy anywhere concept. But is this feasible? The arguments towards native solutions are performance and a better user-experience, with the feat of having to develop in two, three or more programming languages in order to support the most popular platforms. This report will analyze the pros and cons in order to take the decision to go fully web-based, as well as suggest possible solutions for challenges.

3 Indhold 1 Introduktion Motivation Eksisterende mobile applikationer Applikation til Tablets Native versus HTML5 / Web Hypoteser / Problemstilling Afgrænsning Hybrid Browsere Teknologier ios Android HTML Vedlagt kode Relateret arbejde Sencha versus Facebook Native eller web-baseret User Experience Sikkerhed og privacy Opdatering af browsere Opsummering Metode Fremgangsmåde Analyse Eksperiment applikation Arkitektur Valg af Javascript rammeværk Code once - Deploy anywhere Observationer Javascript i eksperiment-applikationen Tilpas til mobil skærm

4 Styling af eksperiment applikationen Browsernes fortolkning af CSS Opsummering Nemmere vedligeholdelse Segmenteret hardware Media Queries Styling på tværs af browsere Javascript på tværs af browsere Javascript Framework JS Perf Opsummering Native user experience i en browser Kørsel i en browser Adresselinjen Anveldelse af fuldskærmstilstand Håndtering af browserens Tilbage-knap Offline funktionalitet Interface design Datalagring Performance test Brugerflade - Performance Order of events Opsummering Opsummering af analyse Diskussion 56 6 Konklusion Code once - deploy everywhere Nemmere vedligholdelse Bruger oplevelse Anbefaling

5 Kapitel 1 Introduktion 1.1 Motivation En af tidens helt store trends indenfor IT er mobile platforme. Med Apples iphone og det tilhørende operativsystem ios, Googles Android operativsystem og Microsofts Windows Phones og Surface tablets, er smartphones og tablets i høj kurs og der er flere mobile applikationer tilgængelige end nogensinde før. Der er flere og flere virksomheder der vælger de mobile platforme til. Noget af det seneste er diverse banker, der nu tilbyder mobile selvbetjeningsløsninger til deres kunder. Bankdata er en dansk bankcentral der er ejet af 14 danske banker. Deres største kunder tæller blandt andre Jyske Bank og Sydbank. Bankdata står for udviklingen og vedligeholdelsen af IT-systemer til medlemsbankerne. Herunder blandt andet netbank- og medarbejderportalen. Medarbejderportalen, herefter benævnt MEP, er en samling af systemer som bankernes rådgivere bruger i deres dagligdag. Dette gælder alt lige fra kunde-oprettelse, kredit-funktioner og lignende. Netbanken består af en privat- og en erhvervs-netbank. Netbanken og medarbejderportalen er bygget på IBM s Portlet standard og er funderet på IBM s Websphere Portal Server. Dog bliver de to systemer kørt på hver deres platform. Bankdatas vision for fremtiden er at de to platforme bliver konsolideret, så portletter fremover kan genbruges på tværs af netbanken og MEP. Det samme gør sig gældende for Bankdatas egen udviklede JSP tag-libraries. Blandt andet har Bankdata udviklet en række input-tags der genererer input felter med klient-validering. Situation er pt. at man har forskellige tag-libs til netbanken og MEP. Man vil gerne have konsolideret de forskellige platforme der eksisterer i dag, og dermed mindske antallet af de forskellige platforme. Derefter sigter Bankdata efter at lave en ny web-baseret løsning til mobile enheder, der med tiden også kan danne grund for den private- og erhversnetbanken samt Medarbejderportalen. Derfor bliver der overvejet at satse fuldt og holdent på web-teknologi til fremtidige mobile løsninger, så disse kan spille sammen med, 1

6 de resterende systemer, og at der eventuelt kan foregå genbrug af moduler på tværs af systemerne. 1.2 Eksisterende mobile applikationer Til alle bankerne, pånær Jyske Bank der har deres eget applikationsudviklingshold, har Bankdata udviklet mobilapplikationer til Android- og iphone- og Windows Phone platformen. Disse er bygget med native teknologi, og der er altså derfor tale om en applikation udviklet med Android SDK i sproget Java, en applikation udviklet med ios SDK i sproget Objective-C og en udviklet i Windows Phone SDK i sproget C#. Til løsningerne er der udviklet en middleware service der stilles til rådighed for de mobile applikationer via REST 1. Denne middleware sørger for kommunikation ned til Bankdatas COBOL moduler der tilgår data. Middlewaren står altså derfor for at hente data og udføre simpel forretningslogik, så som filtrering af konti, depoter osv. Denne middleware ville sagtens kunne benyttes af en eventuel ny web-baseret applikation, og spiller altså ikke ind i valget af native eller web-teknologi. 1.3 Applikation til Tablets Situationen er nu at bankerne også vil have udviklet en applikation til Tabletenheder, i første omgang primært Apples ipad. I forbindelse hermed har der været en del diskussioner og overvejelser om hvorvidt man skulle udvikle en native applikation, eller udvikle en HTML5 / Web-baseret løsning. En native applikation er skrevet direkte til enhedens hardware, og kan derved opnå en høj performance, da man skriver applikationen direkte til telefonens hardware. De to mest dominerende platforme er Android og iphone, med Windows Surface der langsomt begynder at få flere markedsandele. Applikationer til disse tre platforme bliver skrevet i henholdsvis Java, Objective-C og C#. Bankdata udvikler primært, som de fleste andre i finansbranchen, i COBOL og Java. Derfor vil det kræve at der bliver uddannet medarbejdere til at skrive og vedligeholde applikationer til Android, iphone og Windows Surface. Selv om sproget til Android også er Java, er det meget forskelligt fra det Java-kode der arbejdes med på Bankdata. Bankdata har en vision om at samle henholdsvis netbanken og medarbejderportalen på samme platform, sammen med den nye løsning til Tablet-enheder. Derfor er der et kraftigt ønske om at Tablet-løsningen bliver udviklet på den server løsning man har i huset, Websphere Portal Server, med web-teknologi. En ting der yderligere taler for at man benytter sig af en web-baseret løsning er at man i en hvis udstrækning har de fornødne udviklingskompetencer, i og 1 Beskrivelse af REST kan findes i [3] 2

7 med at man allerede har folk der arbejder med Portlet standarden, der er webbaseret og blandt andet benytter JSP Native versus HTML5 / Web Den store diskussion rundt omkring på Internettet og ude i industrien er om HTML5 som teknologi er blevet modent nok til at kunne konkurrere med de applikationer der er skrevet direkte til enhedernes hardware, altså de native applikationer. Facebook annoncerede for nyligt at de ville kassere deres HT- ML5 udviklede iphone og Android applikationer til fordel for helt ny-skrevne native udgaver af samme, og dermed vende HTML5 ryggen. Andre firmaer har success med HTML5. Et eksempel på dette er firmaet Sencha, der laver web-komponenter til opbygning af netop mobile applikationer. En anden spiller på markedet der satser på HTML5, er Google.[1, side 49, linje 35.] Og dette er selvom Google står bag en af de nævnte native platforme; Android. Der er altså ting der taler både for og imod en løsning henholdsvis baseret på native teknologi, og en løsning baseret på web-teknologi. Web-teknologien i de seneste år er kommet langt. Med HTML5 s indtræden på scenen er der kommet bedre understøttelse til de mobile enheder. Det er nu blandt andet muligt at udnytte forskellige enheders GPS, gyroskop, kamera med mere. Der bliver arbejdet på at gøre flere ting tilgængelige via Javascript, man kan for eksempel forestille sig at NFC-chips 3 vinder indpas. Men undgår man i praksis helt platformsproblemer ved at vælge en web-baseret løsning? De forskellige browsere i dag benytter sig af forskellige renderings-motorer, der opfatter HTML og CSS meget forskelligt. Nogen traditionel web-udvikling har lidt under i mange år. Det er altså ikke sikkert at en webside der ser fin ud i Googles Chrome browser, fungerer ligeså fint i Mozillas Firefox browser. Det er tilmed ikke alle browserne der, i skrivende stund, endnu understøtter de nyeste funktioner fra HTML Hypoteser / Problemstilling Bankdata har valgt at satse på en web-baseret løsning til deres nye tablet-bank. Men hvilke overvejelser skal der gøres når en virksomhed står overfor at skulle etablere sig på den mobile platform, hvad enten der er tale om telefoner eller tablet-enheder. Det store spørgsmål er om der skal vælges en native eller en web platform. For de fleste virksomheder som Bankdata vil det være nærliggende at vælge en web-baseret platform, på grund af de umiddelbare lavere udviklingsomkostninger. Umiddelbart ser Bankdata fordelene som værende følgende: Udviklerne skal kun kunne én teknologi (HTML5 / CSS3 / Javascript)

8 Man har selv styr over release af sin løsning fremfor at skulle være afhængig af de respektive App Stores Man kan med én web-baseret løsning ramme flere platforme. Man får kun én løsning at skulle vedligeholde. Men er den web-baserede vej i virkeligheden en silver bullet? Er det smertefrit at vælge en web-baseret platform frem for native? Der opstilles følgende hypoteser der kan være med til at afdække disse spørgsmål: Med en web-baseret løsning kan ambitionen om code once - deploy anywhere realiseres på mobile platforme. Ovenstående hypotese er meget overordnet. Kan det lykkes i den virkelige verden at udvikle en platformsuafhænging web-baseret løsning? Kan en webbaseret løsning umiddelbart fungere på de tilgængelige mobile web-browsere? Man får en mindre kodebase, og dermed en nemmere vedligeholdig kodebase, med en web-baseret løsning Ved at vælge at basere løsningen på native teknologi ville det give mindst to forskellige kodebaser at vedligeholde. En base til ios og en til Android. I teorien har man med en web-baseret løsning kun én kodebase at vedligeholde. Altså synes det som om at en web-baseret løsning med én kodebase vil have de laveste omkostninger i form af vedligeholdelse, og i form af at udviklerne kun behøver at koncentrere sig om web-programmering. Men kan det lade sig gøre i praksis? Kan denne ene kodebase køre ens i de forskellige browsere der i dag er på markedet? Med HTML5 kan man opbygge en web-baseret app der giver en native oplevelse En af de essentielle ting for en moderne mobil web-applikation er at brugeren skal kunne interagere med applikationen og få en oplevelse der ligner en native applikation. Den største forskel på de to typer applikationer er at en web-baseret nødvendigvis kører i en browser. Giver dette en native lignende følelse? Der er nødt til at blive opstillet strategier og anbefalinger for udviklingen af HTML5 apps, der gør at den web-baserede applikationen kommer til at føles som en native applikation, så godt som muligt. 1.6 Afgrænsning Hybrid En metode der er blevet kigget på i denne rapport, er den såkaldte hybridløsning. Der findes en række forskellige rammeværker, der tillader udviklere 4

9 at indkapsle HTML, Javascript og CSS i en native skal. Det vil sige at der bliver lavet en native applikation, der kun indeholder nok native kode til at starte applikationen op og derefter vise et web-view, med det indeholdende HTML, Javascript og CSS. Et af disse rammeværk er PhoneGap 4. Med dette rammeværk kan man med den native kode tilgå alle enhedens hardware funktioner. På en iphone inkluderer dette blandt andet: Kamera Gyrometer Kompas GPS Vibration En anden fordel ved hybride applikationer, er at applikationerne bliver publiceret gennem de respektive online butikker, såsom Google s Play til Android platform, og Apples App Store. Dette kan dog også anskues som en ulempe da man så er afhængig af producenternes godkendelsesprocesser inden at en given applikation bliver publiceret. En hybrid løsning er derfor fravalgt af Bankdata da det, ligesom med native udvikling til Apples enheder, også ville kræve at man indkøber Macintosh computere til udviklerne, eller benytter et rammeværk som for eksempel Xamarin 5. Xamarin tillader at man kan skrive applikationer til Android og ios med C# kode. Dette er dog også forbundet med en udgift, da Xamarin mindst koster $999 per platform om året. Rammeværket PhoneGap tilbyder at bygge applikationer for én, men dette anses af Bankdata for at være for ufleksibelt. Ved at vælge en ren web-baseret løsning er turn-around tiden på fejl-rettelser og nye funktioner ikke afhængig af eksterne påvirkninger, men kan udelukkende klares via Bankdata eget setup og produktionssystem Browsere Til desktop computere findes der efterhånden et stort antal web-browsere og sammen med disse næsten ligeså mange renderingsmotorer. Renderingsmotorerne sørger for at browseren kan fortolke HTML kildekode og rendere det på skærmen til brugeren. Der er i denne rapport kun kigget på de mest populære browsere, hvor de fleste samtidig er tilgængelige på mobile platforme. Disse er: Google Chrome - Webkit

10 Denne browser er tilgængelige på desktop, Apples ipad og Google s Android. Der vil dog ikke blive kigget på versionen til ipad. Chrome browseren er en god browser at udvikle i, blandt andet på grund af omfattende debug muligheder. Apple Safari - Webkit. Den indbyggede browser på Apples ipad - også tilgængelig på desktop computere. Android Browser - Webkit Den indbyggede browser i Google Android operativsystem. Internet Explorer - Trident Den indbyggede browser i Microsofts Windows Phone/Surface OS. Firefox - Gecko Vil blive benyttet til sammenligning med andre desktop browsere. Selvom de nævnte browsere, pånær Internet Explorer og Firefox til desktop, alle baserer sig på Webkit renderingsmotoren er der stadig en række afgørende forskelle. Det kommer en del an på hvilke versioner af de forskellige browsere man kører. Det er heller ikke alle browserne der fortolker Javascript ens. Slutteligt vil der også blive testet med en Windows Phone telefon. Windows Phone bruger, som almindeligt Windows, Internet Explorer som browser. Denne benytter sin egen renderingsmotor. I det seneste år har Microsoft bevæget sig ind i konkurrencen på de mobile platforme, med Windows Phone 7 og 8. Det seneste skud er Microsoft Surface. Et mobilt styresystem til Windowsbaserede tablets. Derfor er det også relevant at teste på Windows Phone, da Internet Explorer s motor er væsentlig anderledes end Webkit. 1.7 Teknologier Der er i denne rapport berørt emner der handler om disse teknologier ios ios platformen blev lanceret sammen med Apples iphone telefon i Det primære programmeringssprog til platformen er Objective-C. Objective-C 2.0 blev ligeledes lanceret i 2007 [12]. Sproget er et superset af ANSI C. Det vil sige at det bygger på sproget C. Så for udviklere på ios platformen er det et krav at kunne Objective-C. Applikationer skrevet til platformen skal signere med et validt certifikat for at kunne afvikles på en iphone eller ipad. For at få applikationen udgivet i Apple s App Store, skal applikationen indsendes 6

11 til Apple og gennemgå en godkendelsesproces. Hvad denne process præcist indeholder ved kun Apple. Godkendelsestiden ligger typisk mellem 7-14 dage for en helt ny applikation, og omkring 6-7 dage for en opdatering til en allerede udgivet app Android Googles bud på en mobil platform blev ligesom ios afsløret i 2007, og den første mobile enhed med Android blev solgt i I modsætning til ios er programmeringssproget til Android, Java. For at få udgivet en appliaktion på Googles butik - Google Play skal man ligeledes igennem en godkendelsesproces. Dog er godkendelsestiden her noget mindre, typisk vil en indsendt applikation eller opdatering blive godkendt i løbet af få timer ifølge Googles guide for klargøring af applikationer HTML5 HTML standarden har været tilstede siden starten af 90 erne. Den første version af HTML5 blev publiceret i Planen er at HTML5 specifikationen skal være endelig i HTML5 standarden bringer meget nyt med sig. I en mobil kontekst er noget af det interessante at det via Javascript tillader at tilgå forskellige enheders hardware, som for eksempel GPS, kamera og så videre. HTML5 bliver ofte brugt som en fællesbetegnelse for teknologierne: HTML5 Javascript CSS3 Derudover er der også funktioner i HTML5 der kan cache defineret indhold i et såkaldt cahce manifest, og dermed skabe funktioner der er tilgængelige offline. Der er ligeledes blevet mulighed for at gemme data i browserens lig klassiske databaser. Disse funktioner gør at HTML5 er velegnet til at afvikle applikationer på de mobile platforme. HTML5 udviklingen går rigtig stærkt. Der bliver hele tiden udviklet nyt Javascript funktioner der gør det nemmere at interagere med hardware funktioner i for eksempel mobile enheder. Det er nu for eksempelt muligt at tilgå en mobiltelefons kamera gennem et simpelt input-tag. Det har i et stykke tid også været muligt at tilgå GPS. Det er kun et spørgsmål om tid før mere af mobiletelefonernes hardware vil være tilgængeligt via Javascript API er

12 1.8 Vedlagt kode Ved rapporten er vedlagt følgende kode: App.html Eksperiment applikationen med indlejret styling og javascript. Js folder indholdende javascript: BrowserDetect.js Script fra Quirksmode.org, der viser hvordan man kan sniffe hvilken enhed der tilgår en side. iscroll.js Lille bibliotek der emulerer native scroll. jscroll.js jquery plugin der anvender iscoll.js, til at give jquery-lister bedre scroll funktionalitet. 8

13 Kapitel 2 Relateret arbejde Der er mange der har talt og skrevet om HTML5 de sidste par år. Og især om hvorvidt HTML5 kan være med til at flytte native mobil applikationer over på webben i stedet. Nogle af de store firmaer såsom Facebook og LinkedIn, har tidligere haft HTML5 applikationer pakket ind i en native skal, til iphone, ipad og Android, men har droppet deres HTML5 versioner til fordel for rene native versioner. Derfor er det relevant at undersøge hvad andre har foretaget af arbejde for at undersøge forskellene mellem HTML5 platformen og de native platforme. I det følgende kapital er der kigget på forskellige artikler der har berørt emner som native kontra web-baseret, user experience og sikkerhed. 2.1 Sencha versus Facebook En af de mest succesfulde websider og firmaer for tiden er Facebook. Facebook har et anslået antal af mobile brugere på 543 millioner 1 I et interview med nyhedssiden TechCrunch i september 2012, bekendtgjorde Facebooks grundlægger, Mark Zuckerberg, at den største fejl Facebook havde lavet, var at satse for hårdt på HTML5, fremfor native applikationer. 2 Dermed gik et de af største Internet firmaer pt., ud i offentligheden og sagde at HTML5 ikke var godt nok til at bygge en mobil applikation. Dette har affødt mange diskussioner på nettet. Har Facebook ret i deres udtalelser, eller var det simpelthen deres implementation og anvendelse der var grunden til at deres applikationen ikke performede godt nok til deres krav? Et firma der var hurtig til at tage til genmæle var Sencha 3. Sencha laver rammeværk og værktøjer til udviklere, primært beregnet til HTML5. Så Sencha udviklede noget de kalder for Sencha Fastbook - en pendant til Face- 1 million-mobile-users/

14 book. I bund og grund er Sencha Fastbook en web applikation der snakker med Facebook via dennes API. Sencha Fastbook henter altså de samme data som Facebook viser. I opbygningen af applikationen har Sencha gået i dybden af Facebook og set på hvorledes applikationen kunne optimeres i en HTML5 version. Sencha opdagede dog at mange af delene i Facebooks nyeste native applikationen (efter de havde droppet HTML5) stadig bestod af HTML sider. Helt droppet er HTML(5) altså ikke fra Facebooks side. Når man anvender Sencha Fastbook virker applikationen meget hurtig, når man for eksempel kigger på ens newsfeed som er kernen i Facebook. Newsfeedet er det der møder millioner af Facebook brugere når de logger på. Her er der updates fra alle ens venner - og altså dermed meget data der skal vises. Sencha s Fastbook løsning bærer meget præg af at de har udviklet specielle komponenter til at løse netop denne opgave. Dette har været muligt for dem, fordi de i forvejen har stor ekspertise i et bygge rammeværk til mobil udvikling. Det faktum at de har bygget nye komponenter, gør selvfølgelig at andre udviklere kan bruge disse til at opbygge deres egne applikationer. Men sagens kerne er at de er udviklet for at løse en specifik opgave. Man kan hurtigt komme ud for situationer hvor man skal løse et meget specifikt behov. For eksempel hvis man skal bygge en bank-løsning beregnet til ipad. Men dog beviser Sencha at man kan optimere på Facebooks newsfeed med HTML5, det kræver dog at man laver dybegående analyser på den funktionalitet man ønsker, for at kunne optimere denne bedst muligt. 2.2 Native eller web-baseret Andre Charland og Brian Leroux skrev i 2011 en artikel[1]. I denne artikel kigges på der emner man er nødt til at overveje, når man står overfor beslutningen om at skulle vælge native teknologi eller web til en løsning. I artiklen diskuteres følgende emner: Native kode versus web kode Brugerinterface kode User experience Performance De nævnte emner er i høj grad relevante og oplagte at kigge på. Artiklen nævner nogle Javascript rammeværk der kan bruges til at lave mobile applikationer på tværs af platforme (altså, de forskellige browsere). Artiklen kommer dog ikke ind på specifikke kodeeksempler, der for eksempel viser hvorledes man kan undersøtte de forskellige browsere og deres renderingsmotorer. Så artiklen mangler at påvise om de nævnte rammeværk klarer opgaven til fulde, eller om det er nødvendigt at kode specikke løsninger til specifikke problemer. 10

15 I artiklen HTML5 - bridging the mobile platform gap: mobile technologies in scholarly communication [11], stiller forfatteren en række fordele og ulemper op for henholdsvis native og web-baseret udvikling. Følgende er et uddrag af disse: Web-baseret Native Fordele Mindre udviklingsomkostninger hurtig time-to-market dynamisk indhold cross-platform HTML5 Ulemper internet forbindelse er krævet man skal tænke på hastighed og latency (forsinkelse i forbindelsen) Ændringer (I diverse web standarder) Fordele Den mest kontrollerede brugeroplevelse Native UI giver hurtigere grafik Ulemper Dyrere udvikling Mulig genopfindelse af hjulet Kan ikke deles mellem forskellige platforme Størrelse af data begrænset af klientens grænser Også her kan nogle af argumenterne diskuteres. Richard Padley mener at en af ulemperne ved native udvikling skulle være at man muligt genopfinder hjulet. Hvis man tager et kig på Sencha Fastbook, der som nævnt er web-baseret, var Sencha nødt til at udvikle specifikke web-komponenter, foreksempel feed listen, forfra for at optimere så meget så muligt. Så dette kan både være en ulempe på native- såvel som web-platformen. En ting ud fra ovenstående liste, der er værd at grave dybere i, er om det virkeligt er dyrere at udvikle til en native platform, og om det i virkeligheden er billigere at udvikle til en webplatform. Det er klart at hvis man vil understøtte to native platforme, Android og ios, skal udviklerne kunne to forskellige sprog. Men det er ikke sikkert at én udviklet web-løsning er nok til at understøtte flere platforme/browsere. I artiklen The Web as an Application Platform: The Saga Continues, skriver Tommi Mikkonen og Antero Taivalsaari at de tror at trenden med at skrive applikationer til de native platforme, og at det de kalder The Open Web vil 11

16 fejle, kun er midlertidig[10, side 127, "Native Web Client Applications ("Apps")]. De argumenterer for at med man med HTML5 og de mange nye funktioner som HTML5 bringer med sig, kommer tættere på et åbent web, der bliver mere og mere egent til desktop-agtige applikationer[10, Afsnittet: A. HTML5]. Men det store spørgsmål er om det også gælder for mobile applikationer. Den store forskel mellem desktop- og mobile applikationer er pt. touch-skærme. Det kræver mere af web-komponenter at understøtte touch fremfor et klik med musen. Dette er formentlig også grunden til at W3C 4 er gået i gang med at arbejde på en ny standard der forener input, herunder touch og input fra en mus, i en samlet standard kaldet Pointer Events 5. Men før denne standard er på plads, kræver det forskellig kode der håndterer input fra en mus, og touch input, specielt hvis der er tale om multi-touch, det vil sige at brugeren placerer flere fingre på skærmen. Det eneste der holder trenden med native applikationer i gang, er ifølge artiklen at det er nemmere at skabe en forretningsmodel med applikationer der skal installeres via en dedikeret App Store [10, side 172, Native Web Client Appliations ("Apps")]. Dette argument bruger de, selvom de i en anden artikel skriver at installation via en App Store virker klodset og giver en dårlig brugeroplevelse[9, A. Native Apps, sidste afsnit]. Men det giver en klar anledning til at udforske nærmere om hvorvidt web-baserede applikationer er i stand til at give samme brugeroplevelse som native applikationer giver. 2.3 User Experience Mikkonen og Taivalsaari skriver i [9] at opdatering og installation af native applikationer er klodset for brugerne og derved giver en dårlig user experience[9, A. Native Apps, afsnit 5]. Dette kan i høj grad diskuteres. Når man tilgår en Web-baseret applikation første gang, vil klienten sandsynligvis ikke have noget fra applikationen cachet. Dermed skal der også hentes mere data første gang, end ved de efterfølgende gange. Dette kan sammenlignes med en native installation. Med hensyn til opdateringer er det for eksempel med Apples ios 6.0 blevet lettere, da man nu ikke skal indtaste sin kode til sin App Store bruger, ved opdateringer. Ligeledes er der med ios6 indført inkrementelle opdateringer, så man ikke skal downloade hele applikationen igen for at få opdateringer. Dette kan sidestilles med web-baserede applikationer hvor det kun er nye elementer og resourcer i hen hold til browseren cache der bliver downloadet. Så dette argument kan ikke umiddelbart bruges til at vælge den ene eller anden platform. De nævner også at fragmentering i forhold til implementering af interaktionsmåder. Mikkonen og Taivalsaari skriver at forskellige apps der er udviklet af forskellige parter har forskellige måder hvorpå brugeren kan interagere med applikationen[9, A. Native Apps, afsnit 4]. Dette kritikpunkt kan ligeledes diskuteres, da det ikke vil være synderligt anderledes hvis der var tale

17 om web-baserede applikationer. Forskellige udviklere har forskellige måder at tænke uanset platform og teknologi. 2.4 Sikkerhed og privacy Et issue der har høj relevans når man snakker native applikationer versus webbaserede er sikkerhed. En native applikation er ofte en sammenpakket enhed der er signeret med et udvikler certifikat. Det er derefter de pågældende stores, såsom Google Play og Apple Appstore der sørger for at distribuere applikationerne ud til brugernes telefoner og andre enheder. Data der bliver gemt i applikationen bliver typisk gemt i applikationens sandbox 6. Men hvordan er sikkerheden i en web-baseret HTML5 løsning? I bund og grund er webapplikation en web-side der kan tilgås af en hvilken som helst enhed der har en web-browser tilgængelig. På de native platforme er der især en høj koncentration af malware (ondsindet software) til Android. Dette dokumenterer F-secure i deres sikkerhedsrapport fra 2012[2]. I rapporten dokumenterer F-secure yderligere at Android stod for 79% af mobil malware i 2012, mod 0.7% for ios og 0.3% for Windows Mobile[2, side 9]. Her kan man se en af fordelene ved at for eksempel Apple er så strenge med deres krav for at godkende en applikation til deres App Store. Dog er det som med alle andre platforme, at producenterne af malware er der hvor der er flest brugere, og flest penge at tjene. Når og hvis HTML5 applikationer begynder at dukke frem vil der højst sandsynligt også dukke malware frem. William West og S. Monisha Pulimood har skrevet en artikel[15] der analyserer sikkerheden i HTML5 applikationer, såvel som lagring af private data. I artiklen beskriver de blandt andet de nye muligheder der er med HTML5 for at gemme data, og har analyseret sikkerheden i disse. De skriver at sikkerheden i HTML5 vedrørende Web Storage er blevet bedre end tidligere, da man lagerer data via at client-side Javascript API. Og hvis et lagret stykke data forsøges tilgået af et andet domæne, end det domæne der gemte dataene, skal browseren kaste en exception.[15, (Afsnit Security)]. En anden fordel de påpeger ved at gemme data på klienten er at brugerens data ikke bliver kompromitteret hvis der skulle ske et indbrud på serveren. Og i modsætning til cookies, der bliver sendt til serveren via et HTTP request for at holde state, er der med de nye metoder i HTML5 ikke bruge for konstante HTTP request, der eventuelt kan sniffes 7. Dermed bliver trafikken også mindsket, der gør at performance kan blive forbedret. I artiklen[15] konkluderes der at HTML standarden er nødt til at blive holdt opdateret for at adressere sikkerheds og privacy trusler, men at gemme data client-side har flere fordele end server-side løsninger[15, (4. conclusion)]. I en anden artikel skrevet af Steve Mansfield-Devine[7] påpeges det at fordi HTML 5 teknologien stadig er relativt ny, (det må den siges stadig at være

18 Figur 2.1: Statistik over Android versioner - til trods for at artiklen er skrevet i 2010), handler det for udviklerne om at udnytte diverse funktioner i HTML 5 på den rigtige måde, da man endnu ikke kender mulighederne for eventuelle hackere og hvordan de kan udnytte web-baseret applikationer[7, side 5 (Bad Programming)] Opdatering af browsere De fleste desktop browsere i dag, bliver automatisk opdateret. Chrome og Firefox kan sættes til at checke for opdateringer og installere dem i stilhed, når browseren genstartes. Dermed er man sikret eventuelle fejlrettelser og lapning af sikkerhedshuller. Historien er lidt en anden på de mobile platforme. Her skal telefonernes eller tablettens operativ system holdes opdateret for at holde de indbyggede browsere opdaterede. Så her afhænger det i højere af grad om brugeren får opdateres deres telefoner. Og om de i det hele taget kan opdatere. Især Android platformen er ramt af dette. Visse Android telefoner har ikke haft særlig lang levetid, før at de ikke kunne installere de nyeste opdateringer. På Googles udvikler side 8 udgiver Google statistikker om hvilke Android versioner der er mest brugt. Følgende billede viser statistik fra slutningen af april Som det ses af billedet er der altså nogen overvægt til den såkaldte Gingerbread version af Android. Dette er ikke uvæsentligt, og det er nødvendigt at orientere sig om forskellene i versionerne. I og med at Gingerbread dækker 8 14

19 over versionerne 2.3.X og den nyeste, Jelly Bean, dækker over version 4.1.X og 4.2.X, må man antage at der er væsentlige forskelle. Så man er ikke i sikker havn ved at udvikle op mod de nyeste API er og funktioner. I så fald vil man afskærme en del brugere fra at anvende applikationen. Der kan med rimelighed konkluderes at sikkerheden i HTML5 ikke er dårligere end tidligere HTML standarder. Men som med alle systemer skal man tænke over hvordan man bygger sin applikation op. Men med hensyn til versionerne af de mobile operativsystemer, bør man orientere sig om sin brugerskare, og tage beslutning om hvilke versioner man vil understøtte. Der er i denne rapport ikke lavet yderligere analyse på sikkerheden i HT- ML5 baserede applikationer. 2.5 Opsummering Der er mange argumenter for og imod at vælge en web-baseret løsning. Men der er ikke umiddelbart noget i det relaterede arbejde, der kan tynge vægtskålen endegyldigt til den ene eller den anden platform. Facebook droppede HT- ML5 til fordel for en native app, men Sencha lavede et modspil i HTML5 der havde en tilstrækkelig høj performance. Til gengæld måtte Sencha lave en del krumspring i form af skræddersyede komponenter netop til dette formål, og brugte dermed ekstra arbejdsindsats på dette. Og hvis der skal ekstra arbejdsindsats til for at opnå tilstrækkelig performance, virker HTML5 måske ikke til at være den rigtige løsning. Men der bliver også nævnt fordele såsom lavere udviklingsomkostninger, og at man med en web-baseret løsning kan ramme flere platforme på én gang. Det bliver også påpeget at der i en web-baseret verden er en højere time-tomarket, da man ikke er afhængig af de respektive App Stores. Med web-baseret kode kan man, alt afhængig af sin interne release strategier, opdatere kode til kunderne når som helst. Men det er interessant at undersøge om det virkelig kan lade sig gøre at lave én løsning der kan bruges på tværs af forskellige platforme. I de relaterede artikler er der heller ikke skrevet noget om performance på de forskellige platforme. Hvor hurtige er de enkelte browsere for eksempel til at afvikle Javascript? Vil en web-baseret løsning performe ens på tværs af platforme? Med hensyn til, den knap så gode, opdateringsstatisik på især Android platformen, rammer dette både den native platform og den web-baserede platform. Opdateringer til et mobilt operativsystem vil oftest også indholde opdateringer til den indbyggede browser, der netop skal køre en web-baseret løsning. Så hvis ikke operativsystemet bliver opdateret, bliver den indbyggede browser det heller ikke. Så dette faktum vejer hverken for eller imod native eller web. Ud fra det relaterede arbejde vil fokus i denne rapport være på funktionalitet, performance og brugeroplevelse på tværs af platforme. 15

20 Kapitel 3 Metode Ud fra det relaterede arbejde er der fundet følgende fremgangsmåde der kan hjælpe med at undersøge de stillede hypoteser. 3.1 Fremgangsmåde 1. Udvikling af en simpel eksperiment applikation, der simulerer en liste af konti. Ved tryk på en konto, bliver man overført til en liste af fiktive posteringer. Der er i denne forbindelse bleve kigget på valg af en simpel arkitektur til applikationen der understøtter mobile applikationer. 2. Applikationen er blevet testet i henholdsvis Chrome, Safari og Firefox til Desktop, og derefter Safari på iphone og Androids indbyggede browser. Der blev kigget på om eventuelle værktøjer kunne anvendes for at skrive kode der kan understøtte flere browsere. 3. Der blev foretaget observationer i forbindelse med testen, om hvorvidt at applikationen fungerer ens i de forskellige browsere. Der blev herefter beskrevet problemstillinger i forbindelse hermed, og eventuelle løsningforslag. 4. Der blev undersøgt om en web-baseret kodebase er nemmere at vedligeholde. Herunder blev der kigget på emner som Javascript rammeværk, og generelle tilpasninger til de enkelte browsere. Og om nogle af disse havde indvirkning på kodebasens størrelse. 5. Der blev kigget på hvilke tiltag der kan gøres for at sikre en brugeroplevelse der ligger så tæt på en native applikation som muligt. Herunder design af brugerflade og performance. 16

21 Kapitel 4 Analyse For at analysere om en web-baseret løsning kan understøtte de stillede hypoteser, er der blevet beskrevet og udviklet en simpel eksperiment applikation. En analyse af applikationen med dens producerede kode er med til at påvise om de stillede hypoteser holder vand eller ej. Der blev i denne forbindelse valgt et Javascript rammeværk som løsningen skal bygges, og der blev fastlagt en simpel arkitektur. 4.1 Eksperiment applikation Eksperiment applikationen vil være en mock-up af en bank-applikation. Denne vil indeholde en simpel konto liste. Hvis der trykkes på en konto, vil man blive dirigeret over til en posteringsliste, der blot danner 100 liste-elementer, der skal udgøre posteringer. En af de første udfordringer man kommer til, når man skal designe en mobil web applikation, er arkitekturen. Kan man benyttes sig af en traditionel web-side arkitektur? Eller skal der tænkes i andre baner? En webside kan i sig selv heller ikke tilbyde megen funktionalitet til brugeren. Her kommer Javascript ind i billedet. Med Javascript kan man lave om på en webside med DOM-manipulation, hente data fra servere og mere. Men da Javascript er et sprog, der ikke er type stærkt, kræver det høj disciplin fra udviklerne, hvis disse eksempelvis er vant til typestærke sprog. Her kan et Javascript rammeværk være til hjælp. Et Javascript rammeværk pakker oftest funktionalitet ind i moduler og kombinerer CSS med Javascript funktioner, så det bliver nemmere for udviklerne at skrive brugbar kode. Man kunne forestille sig at en udvikler kunne tilføje én bestemt CSS klasse til et element for at gøre det træk-bart med en mus eller ved et touch-event. Rammerværket vil så gennemløbe DOM en for elementer med denne klasse, og tilføje funktionalitet på netop dette element, uden at udviklerne behøver at bekymre sig om det. Men hvilket rammeværk skal man vælge? I [1, side 50] nævnes der blandt Sencha Touch, jq Touch og jquery Mobile. Men der findes langt flere, og hvil- 17

22 ket eller hvilke af disse vil det være værd at satse på? Eksperiment applikationen benytter sig også af CSS3 da denne giver mulighed for nye funktioner såsom funktionalitet til at lave runde hjørner på elementer, animationer med meget mere. Alt sammen noget der gør det lettere for udviklerne at lave design af en applikation. Men fortolker browserne de forskellige CSS3 attributter og Javascript på samme måde? De nævnte problemstillinger vil eksperiment applikationen hjælpe med at afdække Arkitektur Valget af arkitektur i en web-baseret applikation skal tillægges lige så stor betydning som valget i en hvilken som helst anden applikation. Når man taler om mobile applikationer er der en række ting der skal prioriteres i forhold til brugerne. Applikationen skal gerne give brugerne en rigtig god oplevelse, så de ikke bliver trætte af at bruge den.. Traditionelt set består en web side, af mange sider i et stort hieraki. Når der navigeres mellem sider, sendes der et http-request til web-serveren med adressen på den side man gerne vil have sendt tilbage, for at vise den. Rent fysisk sker dette ved at den pågældende browser blanker den nuværende side, for at kunne rendere den næste side. Dette bevirker at brugeren oplever et blink inden den næste side vises. Der kan laves et par tiltag for at modvirke dette. Man kan sørge for at den gamle side der skal udskiftes og den nye side har samme baggrund. Hvis baggrund på den første side bliver cachet, behøver browseren ikke at fjerne baggrunden når den nye side bliver hentet. Derved virker udskiftningen ikke så hård. Man kan også lave et trick med CSS3, og sætte en side-transition op. Hvis man anvender nedenstående CSS attribut (her er endnu et eksempel på at det er nødvendigt med vendor prefixes) kan man få siden til at animere ind på skærmen: 1. fade animation { 2 opacity : 0 ; 3 webkit animation : show login ease in 0. 8 s ; 4 webkit animation f i l l mode : forwards ; 5 } 6 webkit keyframes show login { 8 from { opacity : 0 ; } 9 to { opacity : 1 ; } 10 } Det ovenstående definerer en animation der animerer opacity (gennemsigtighed). Når denne style-klasse fullscreen-login sættes på for eksempel bodyelementet, vil det, når siden bliver vist, se ud som om siden fader ind. Dette vil ligeledes hjælpe med at få sideskiftet til at se pænere ud. Men trods disse tiltag og tricks for at få sideskift til at se pænere ud, er denne arkitektur er ikke holdbar hvis web-siden skal ligne og efterligne opførsel 18

23 af en native mobil applikation. Mobile applikationer består oftest af skærmbilleder der for eksempel har en fast header eller footer. Når der navigeres, udskiftes der indhold, men headeren eller footeren forbliver fast. For at opnå en native oplevelse er dette altså også nødvendigt for en web-baseret mobil-app. Dermed er man nødt til at tænke i andre baner, end at strukutere sin applikation med mange forskellige fysiske HTML-sider. Der er udviklet et arkitektur-princip kendt som Single-page app. Denne teknik står beskrives blandt andet i [8] og i [4, side 205]. Dette princip går ud på at applikationen bliver bygget op omkring en enkelt HTML-side. Denne kunne for eksempel hedde app.html. Idéen med singlepage princippet er altså at lade hele web-applikationen implementere i forskellige views men, alt sammen inde for den samme HTML-fil/side. Derved kan man udskifte de forskellige views dynamisk via AJAX 1. Dette er med til at skabe en native-app lignende opførsel, og dermed give en bedre brugeroplevelse, da man derved undgår at browseren skal rendere en helt ny side, når man skifter indhold ud. Hvis en ny side skulle renderes ville dette oftest resultere i at brugeren oplever et blink, da den aktuelle side helt fjernes, og den nye side først skal hentes og renderes. I [4, side 205] nævnes der at dette er den fundamentale forskel på mobile apps skrevet med web-teknologi og almindelige web-sider. I udviklingen af den simple eksperiement-applikationen er der ved valg af Javascript-rammeværk, tilstræbt at den kan understøtte en Single-page app arkitektur. I det følgende afsnit er der kigget på valg af Javascript rammeværk der kan gøre udviklingen lettere, blandt andet fordi Javascript rammeværk kan tilbyde udvikleren funktioner, der understøtter flere browsere Valg af Javascript rammeværk Den nævnte eksperiment applikation skal kunne er at vise en liste af konti. Markuppen kunne se ud som følger: 1 <! doctype html> 2 <html> 3 < s t y l e type=" t e x t /css "> 4 # accounts { 5 height : 150px ; 6 width : 100px ; 7 background : grey ; 8 overflow : hidden ; 9 } 10 </ s t y l e > 11 <head> 12 < t i t l e >Accounts</ t i t l e > 13 </head> 14 <body> 15 <ul id=" accounts "> 1 19

24 16 < l i >Account 1</ l i > 17 < l i >Account 2</ l i > 18 < l i >Account 3</ l i > 19 < l i >Account 4</ l i > 20 < l i >Account 5</ l i > 21 < l i >Account 6</ l i > 22 < l i >Account 7</ l i > 23 < l i >Account 8</ l i > 24 < l i >Account 9</ l i > 25 < l i >Account 10</ l i > 26 </ul> 27 </body> 28 </html> Listing 4.1: Simpel konto liste Det ses af ovenstående HTML og CSS styling, at selve listen er begrænset til et fast område, med en bredde på 100 pixels og en højde på 150 pixels Det vil sige at listen er afgrænset fra resten af siden. På en tablet enhed, der typisk her en noget større skærm end en telefon, vil man typisk gerne kunne scrolle i et fastlagt område, fremfor at scrolle med hele den viste side. På en telefon, ville det typisk design være at lade listen fylde hele skærmen, og dermed scrolle hele siden, når man vil se flere konti. Qua at Bankdata gerne vil udvikle en applikation til tablets har eksperiment-applikation sigtet efter at anvende det først omtalte scroll. Ved den første test af koden viste der sig fint en liste af konti, men der kunne ikke scrolles i listen i det grå område. Man kunne derfor ikke se de sidste konti. Det var ikke muligt at scrolle i listen uafhængigt af siden. Hermed kunne det konkluderes at ren HTML(5) ikke umiddelbart er nok til at lade brugeren interagere med applikationen. Listen lignede som udgangspunkt heller ikke en mobil applikation. Tilføjelse af både ekstra styling og funktionalitet var nødvendigt. For at opsummere, så skal der gøres følgende for at listen ligner og opfører sig som en native scrolling liste: Listen skal kunne scrolle inden for et fast område Listen skal lave en bounce -effekt når toppen eller bunden nås. Der skal laves styling med CSS, for at undgå det rå HTML-look Der findes utallige OpenSource rammeværk i Javascript, der tillader at lave mobile komponenter, og kan hjælpe til med at opfylde kravene ovenfor. Nogle af de mest populære, er som følger, og bliver også nævnt i[1]: jquery Mobile Sencha Touch jq Touch 20

25 Dojo Mobile (Dojo er taget med da Bankdata allerede har det rammeværk inde i huset, og i øvrigt bliver leveret med Websphere server-løsninger). Et værktøj der kan bruges til at undersøge hvilket rammeværk er mest anvendt er Google Trends. Hvis man laver en søgning på Google Trends 2 vil man se at jquery Mobile er det mest søgte på Google; se nedenstående billede. Der skal dog tages forbehold for brug af Google Trends. Resultaterne påvirkes af alle søgninger foretaget på Google. Blandt andet er Dojo også et japansk udtryk, for et sted hvor man træner karate. Figur 4.1: Framework søgninger fra januar 2010 til januar 2013 jquery Mobile bygger på det meget populære jquery rammeværk. Fordelen ved dette er at der eksisterer en kæmpe brugerskare og dermed en hel del entusiaster der arbejder på at tilføje funktionalitet til rammeværket. Det har affødt at der findes mange forskellige plugins der udvider jquery og jquery Mobile med forskellig funktionalitet. For at anvende jquery skal der i HTMLdokument inkluderes de relevante filer. Man kan vælge at inkludere jquery direkte fra jquerys egne servere, eller man kan vælge at download jquery. jquery Mobile kan inkluderes ved at linke til de relevante filer, på følgende måde: 1 <link r e l =" s t y l e s h e e t " href=" http :// code. jquery. com/mobile /1.2.0/ jquery. mobile min. c s s "/> 2 < s c r i p t s r c =" http :// code. jquery. com/jquery min. j s "></ s c r i p t > 3 < s c r i p t s r c =" http :// code. jquery. com/mobile /1.2.0/ jquery. mobile min. j s "></ s c r i p t > 2 Listing 4.2: Inkludering af jquery og jquery Mobile 21

26 jquery Mobile indeholder en List View komponent, der kan lave en stylet liste. Denne anvendes ved at sætte en attribut, data-role på det HTML element, der skal agere liste. I koden der er vist i Listing 6.1, er det <ul> elementet der skal have denne attribut: 1 <ul id=" accounts " data r o l e =" l i s t v i e w "> Listing 4.3: Angivelse af rollen som List View Ved at anvende jquerys listeelement i koden vil man se at stylingen bliver ændret, så det mere ligner en native liste. Se nedenstående skærmbillede. Figur 4.2: Anvendelse af jquery List View Men der kan stadig ikke scrolles i listen uafhængigt af side-scroll. jquerys List View komponent ligger altså også op til at listen fylder hele skærmen, og at der scrolles på hele siden. Det er altså nødvendigt med yderligere kode for at opnå den ønskede funktionalitet. iscroll 3 er et bud på noget Javascript kode der kan give eksperimentet den manglende funktionalitet. Der eksisterer et jquery plugin der indkapsler koden fra iscroll 4. Pluginet er relativt let at anvende. Det kræver at man inkluderer to Javascript filer i sin HTML-kode. Ét script til iscroll, og ét til jscroll. Selve koden der skal skrives for at anvende i/jscroll kan ses i nedenstående: 3 4 https://github.com/vital101/jscroll 22

27 1 < s c r i p t s r c =" j s / i S c r o l l. j s "></ s c r i p t > 2 < s c r i p t s r c =" j s / j S c r o l l. j s "></ s c r i p t > 3 4 <div id=" scrollwrapper " > 5 <ul id=" accounts " > 6 < l i >Account </ul> 10 </div> < s c r i p t > 13 $ ( " # scrollwrapper " ). j S c r o l l ( ) ; 14 </ s c r i p t > Listing 4.4: Anvendelse af jscroll pluginnet. Der er indført et div element der wrapper vores eksisterende liste. iscroll fungerer nemlig på den måde, at den påfører scroll på det første child-element tilhørende det element som iscroll bliver tilknyttet. Det ses herefter at eksperimentet har opnået den ønskede funktionalitet. Listen kan nu scrolls uafhængig af resten af siden, og iscroll forærer tillige den ønskede bounce effekt, som er kendt fra den native ios platform. Men funktionaliteten kommer med en pris. Der bliver nu inkluderet 3 forskellige (jquery, iscroll og jscroll) Javascript biblioteker. (Der bliver inkluderet 4, hvis man ser på jquery og jquery mobile som to adskilte biblioteker). Dermed bliver der i princippet også 3 forskellige biblioteker der skal vedligeholdes og opdateres. Med hensyn til vedligehold kan der dog argumenteres for at man netop ikke skal bekymre sig om vedligehold, fordi det sørger forfatterne til rammeværket for. Men hvis der er brug for at lave ændringer i rammeværks filer, og det meget nødvendigt at holde styr på disse ændringer. Der kunne komme en opdatering, som man vælger at tage ind, der overskriver det kode man har rettet. I og med at der bliver anvendt 3. parts biblioteker er det også nødvendigt at kigge de enkelte bibliotekers licenser igennem. Må man frit ændre i koden og herefter bruge den? Skal der evt. betales for at bruge bibliotekerne til kommercielt brug? Dette er ting der er nødvendige at undersøge for man tager sådanne biblioteker i anvendelse. Nu er scroll i listen på plads. Herefter skal det gøres muligt at klikke på en konto og få vist endnu en liste indeholdende posteringer. Som tidligere skrevet i afsnittet på side 18 bliver applikationen bygget op omkring singlepage idéen. jquery har fin understøttelse for dette. Man kan med jquery nemt definere forskellige page blokke, ved at give <div> elementer den rette rolle. 1 <div id=" accountspage " data r o l e =" page "> 2 <div id=" scrollwrapper " > 3 <ul id=" accounts " data r o l e =" l i s t v i e w "> 4 < l i ><a href=" # postingpage >Account 1</a></ l i > 23

28 </ul > 8 </div > 9 </div > 10 <div id=" postingpage " data r o l e =" page "> 11 <p>postings... < / p> 12 </div > Listing 4.5: Angivelse af sider med jquery I ovenstående kode er der nu angivet to sider. En med ID = accountspage, og en med ID = postingpage. Ved at lade liste elementerne linke til posteringssidens id, vil indholdet af den første side dynamisk blive udskiftet med den anden side. Dermed ser det ud som om der bliver skiftet over til en helt ny side, men i realiteten er det stadig den samme app.html der bliver vist. Dermed undgår man at browseren laver et skifte, request, til en ny html side og dermed også at hele siden skal genindlæses. Dette er en vital funktionalitet hvis en web-applikation skal ligne en native. I en native applikation forventer man ikke at hele siden bliver blanket, det vil sige at den for eksempel helt hvid, for så derefter at vise elementer, og derfor burde en web-applikation heller ikke have denne opførsel. I koden herover, kan det også ses at der er tilføjet et <a> tag, der angiver et link. Dette link har en reference til posteringsidens ID, og ved tryk på linket, sker side-skiftet via AJAX. Dermed opnås den ønskede effekt, af single-page arkitekturen. Og i og med at man opbygge sin side med div -tags med atttributterne data-role= page kan man stadig bevare overblikket over de enkelte sider. 4.2 Code once - Deploy anywhere For at undersøge den første hypotese Det er muligt med en web-baseret løsning til mobile enheder at code once - deploy anywhere? er det omtalte eksperiment nævnt i metode-afsnittet, afprøvet i forskellige browsere og på forskellige platforme. Koden er testet i de forskellige browsere for at se om den samme kode virker på samme måde, på tværs af browserne. Der er blevet foretaget en række observationer der er relevante for hypotesen, og på baggrund af disse observationer kan der konkluderes på hypotesen. De observerede emner er følgende: Javascript i eksperiment-applikationen Tilpasning til mobil-skærm Styling af eksperiment applikationen 24

29 Browsernes fortolkning af CSS Observationer I det følgende afsnit er der beskrevet de observationer der blev foretaget under udvikling og test af eksperiment applikationen. På baggrund af observationerne kan der blive konkluderet på om hvorvidt det vurderes muligt eller ej at kunne Code once - deploy anywhere Javascript i eksperiment-applikationen Under udviklingen af eksperimentet, blev der blandt andet fundet en forskel i de forskellige browsere og deres fortolkning af Javascript. For at sætte en headertitel, når man skifter til posteringssiden, bliver teksten fra det valgte konto-element sat i session storage. (Mere om session storage i 4.4.4) 1 s e s s i o n S t o r a g e. setitem ( account, t h i s. innertext ) ; Når skiftet til posteringssiden er foretaget udføres følgende kode for at hente værdien fra session storage og sætte den på header-elementet: 1 $ ( " # a c c o u n t T i t l e " ). t e x t ( s e s s i o n S t o r a g e. getitem ( account ) ) ; I Chrome og Safari, blev der fint vist en titel i headeren. Men Firefox viste værdien 1 undefined Dette skyldtes at attributten innertext på objektet this (som i dette tilfælde er et <li> elementet) ikke kan fortolkes af Firefox browseren. Her er et eksempel på noget kode der ikke virker på tværs af browserne. Man kan altså relativt let løbe ind i af noget Javascript ikke bliver fortolket ens i de forskellige browsere. Det viser sig ved samme test på Windows Phone 7.5 giver samme fejl som i Firefox. Den indbyggede Internet Explorer browser viser også værdien: 1 undefined Faktisk viser det sig at der er flere umiddelbare problemer med at køre applikationen på Windows Phone. Som udgangspunkt bliver konto-listen fint vist, og man kan trykke sig ind på en konto for at få vist posteringerne. Men det er ikke muligt at scrolle i listen. Ved nærmere undersøgelse viser det sig at pluginnet jsscroll, der blev valgt for dets evne at tillade at scrolle i et fast defineret område, ikke understøtter Internet Explorer, men kun Webkit browsere. Dette gør at der kræves en høj disciplin med hensyn til at teste i de forskellige browsere, og undersøge de plugins man eventuelt vælger at anvende. Og det skal gøres tit. Hvis Chrome er den foretrukne udviklingsbrowser, kan man kode på noget funktionalitet i flere dage uden at afprøve det i eksempelvis Firefox. I en sådan situation kan det være svært at afgøre præcist hvilket 25

30 kode det er der fejler. Dette afhænger selvsagt at kompleksiteten. Så jo højere kompleksitet, jo oftere bør man teste i de forskellige browsere man vælger at understøtte. Hvis man forestiller sig en situation hvor udviklerne har udviklet en lang række funktionaliteter i for eksempel en måneds tid, og primært har brugt én browser til at teste, kan der være en lang række fejl i en anden browser. Og som ovenstående eksempel viser kan det være svært at angribe problemerne. Hvis man er på forkant med at teste er der bedre mulighed for at vide præcist hvilket kode man sidder med, og hvor man skal lægge sin indsats Tilpas til mobil skærm De beskrevne problemer viser sig, når man afprøver appliationen i mobile browsere. Både i Mobile Safari og i Androids default browser, opfører siden sig underligt. Som det ses af nedenstående skærmbillede fra Mobile Safari, virker siden som om den er zoomet ud. 26

31 Figur 4.3: Applikationen i Mobile Safari Men her viser HTML(5) at der er tænkt på mobil udvikling. Man kan ved hjælp af et såkaldt meta-tag, få browseren til automatisk at finde ud af hvor meget plads en mobil enhed har at gøre med: 1 <meta name=" viewport " content=" user s c a l a b l e =no, width=device width, 27

32 i n i t i a l s c a l e = 1. 0, maximum s c a l e =1.0 "/> Med ovenstående tag sætter man en viewport op. Altså, de rammer hvori siden skal eksistere. user-scalable=no angiver at zoom-niveauet på siden er låst. Brugeren kan ikke selv zoome ind eller ud. width=device-width angiver at siden automatisk skal tilpasse sig til enhedens skærm-bredde. initial-scale og maximum-scale sættes begge på 1.0; det vil sige at zoom-niveauet skal begrænses til 100%. Når dette tag bliver indsat opfører siden sig som i desktop browserne. Umiddelbart er der altså blevet bygget en app, der uden de store tilpasninger kører på de mest gængse desktop- og mobile-browsere Styling af eksperiment applikationen. Tidligere har det været omstændigt at skrive CSS (Cascading Style Sheet) der virkede på tværs af browsere. I eksemplet er der skrevet CSS der giver headerne på de to sider runde hjørner, øverst til venstre, og øverst til højre. CSS en til dette ser således ud: 1. roundcorners { 2 border radius : 10px 10px 0 0 ; 3 } Ovenstående er testet til at virke i Chrome, Safari og Firefox. Med det seneste release er Firefox er der netop kommet understøttelse herfor. Før dette var man nødt til at have endnu en linje CSS kode, der angav et såkaldt venderprefix til koden, for at få understøttelse i Firefox. 1. roundcorners { 2 moz border radius : 10px 10px 0 0 ; 3 } Det er dog stadig ikke alle CSS attributer der er understøttet vidt og bredt af browserne. Især Microsofts Internet Explorer browser halter bagefter. Hvis man gerne vil understøtte de nye Microsoft platforme, Windows Phone og Surface, er der i høj grad brug for at man undersøger browsernes understøttelse af forskellige CSS attributter. Der findes værktøjer der kan hjælpe udviklerne i sådanne situationer. Blandt andet SASS og Compass. SASS er en overbygning på CSS, det tillader en mere programmatisk tilgang til at skrive styling-kode. Blandt andet kan man lave indlejrede klasser, og anvende variable. Dette kan hjælpe med til at gøre stylingen lettere at læse. Compass er en samling funktioner til SASS, der ligesom SASS, via kompilering genererer CSS. I Compass findes der funktioner som udviklerne let kan anvende, der sørger for at genere kode med de forskellige vendor-prefixes. Men dette behøver udviklerne ikke koncentrere sig om. Et eksempel på SASS og Compass er givet i Når man skal udvikle en web-løsning, og vil danne sig et overblik over hvilke CSS attributter de forskellige browsere understøtter kan man anvende siden 28

33 Can I Use På denne side er der et komplet overblik over alle de forskellige CSS attributter og hvordan de er understøttet i browserne. Se nedenstående billede der viser understøttelsen af border-radius. Figur 4.4: Can I Use: border-radius Med Can I Use... ved hånden, kan det blive nemmere at få et overblik over hvilket CSS kode der er understøttet af de forskellige browsere. Det er dog nødvendigs ikke sikkert at man rammer helt plet, da nogle browsere stadig fortolker CSS forskelligt. Det vil det næste afsnit give et eksempel på Browsernes fortolkning af CSS Som nævnt er det ikke alle browserne der fortolker CSS helt på den samme måde, og heller ikke på trods af at de bruger den samme renderingsmotor. Et konkret eksempel herpå er afrundinger, når det kommer til beregninger af pixels. Når man i sin CSS kode anvender procent-vise attributter, er det browseren der skal stå for at beregne det egentlig antal pixels. Faktisk viser det sig at Chrome Desktop, Firefox Desktop og Safari alle håndterer det forskelligt. Firefox kan regne med halve pixels, hvorimod Chrome og Safari runder henholdsvis op og ned. Problemet kan illustreres ved at lave et div-element med en bredde på 101 pixels, illustreret med nedenstående kode-fragment: 5 29

34 1 <! doctype html> 2 <html> 3 4 < s t y l e type=" t e x t /css "> 5 # outerdiv { 6 width : px ; 7 height : px ; 8 background c o l o r : red ; 9 10 } 11 # innerdiv1, # innerdiv2 { 12 width :50%; 13 height : 100% 14 } 15 # innerdiv1 { 16 f l o a t : l e f t ; 17 background c o l o r : green ; 18 } 19 # innerdiv2 { 20 f l o a t : r i g h t ; 21 background c o l o r : orange ; 22 } 23 </ s t y l e > 24 <body> 25 <div id=" outerdiv " > 26 <div id=" innerdiv1 " ></div > 27 <div id=" innerdiv2 " ></div > 28 </div > 29 </body> 30 </html> Figur 4.5: Pixelafrunding - kode Der bliver lavet yderligere to div-elementer, der bliver lagt inden i det første element. Disse to div-elementer får at vide at de hver skal bruge 50% af den tilgængelige bredde, altså de 101 pixels. Den ydre div har fået en rød baggrundsfarve, og de to indre elementer har henholdsvis grøn og orange. Det man ville forvente med ovenstående kode er at de to indre elementer vil dække det ydre element. Så man burde ikke se nogen rød farve. Hvis man kører eksemplet i Chrome Desktop er dette også tilfældet. Ved brug af det indbyggede developer værktøj i Chrome ses det at størrelsen er delt 100% mellem de to elementer. Chrome har i dens beregninger valgt at runde op, således at innerdiv1 har fået en bredde på 51 pixels, mens innerdiv2 har fået en bredde på 50 pixels. Der kan argumenteres for at den ene pixel er noget man ikke vil lægge mærke til, da man er ekstremt tæt på det forventede visuelle resultat. Men blot én enkelt pixel kan have betydning. Dette ser man hvis man afprøver eksempelt i en Safari Browser, hvad enten det er desktop eller mobile. Safari vælger nemlig at runde pixel-antallet ned, så ledes at de to indre elementer hver får en bredde på 50 pixels. Dermed bliver der én pixel til overs. Det synes ved at der fremkommer en rød stribe mellem de to elementer på netop én pixel. Her bliver det visulle resulatat ikke som forventet, og i modsætning til 30

35 det forrige eksempel vil man her lægge mærke til det. Den browser der umiddelbart håndterer den givne problemstilling bedst er Firefox. Firefox kan tilsyneladende foretage beregningen med halve pixels, således at de to indre elementer hver får en bredde på 50,5 pixels. Nedenstående skærmbilleder illustreret problemstillingen. Resultatet i Chrome ses til venstre, Safari i midten og Firefox til højre. Figur 4.6: Pixelafrundinger i hhv Chrome, Safari og Firefox Det er umiddelbart op til den enkelte at bedømme om der kan ses forskel på eksemplet i Chrome og eksemplet i Firefox, da forskellen reelt set kun er at det grønne element, i Chrome, er en halv pixel bredere end det er i Firefox. Men i Safari er det noget nemmere at se at beregningen er gået galt, og her er man nødt til at gå ind og udbedre fejlen. Konklusionen på problemstillingen er altså at man, som det er nævnt før, kan lave noget kode der tilsyneladende ser fint ud i Chrome, men når det bliver testet på en ipad eller iphone, passer stylingen ikke helt længere. I ovenstående problemstilling er der umiddelbart ikke noget der kan hjælpe med at skrive noget kode, der får det til at virke på i de forskellige browsere. Hvis man ender i en lignende problemstilling er man næsten nødt til at arrangere sine elementer på en sådan vis at der ikke kan fremkommer halve pixels ved deling Opsummering I ovenstående analyse, kan man relativt hurtigt afvise hypotesen om at man kan kode en løsning én gang, for derefter at afvikle den overalt. Der er stadig store forskelle i hvordan de forskellige browsere på desktop- og den mobile platform fortolker Javascript og CSS. Man er altså derfor nødt til skrive specialiseret kode for at understøtte de forskellige platforme. Der findes som vist i ovenstående forskellige værktøjer til at hjælpe med udviklingen. Blandt andet Media Queries der er en del af CSS. Media Queries kan hjælpe med at undersøge dimensionerne på den skærm løsningen køre på, så man kan tilpasse løsnin- 31

36 gen hertil. SASS/Compass rammeværket kan hjælpe med at skrive de såkaldte vendor specikke CSS attributter, så udvikleren ikke skal skrive den samme attribut flere gange til de forskellige browsere. Med hensyn til Javascript er der også forskellige i hvordan browserne understøtter forskellige funktioner, som fx. med innertext som vist ovenfor. Også her er der forskellige rammeværk, som for eksempel jquery. Men dette er stadig ikke en garanti for at en anvendt funktion virker på tværs af browserne. En anden ting der gør det svært at Code once - deploy anywhere, er brugeroplevelsen. Som det er beskrevet i vil det gå ud over brugeroplevelsen hvis man designer en generisk løsning der kan passe på tværs af platformene. Og en generisk løsninger er nødvendigt for at Code once - deploy anywhere skal kunne være gældende. Så til trods for divers hjælpeværktøjer med mere, skal der stadig laves special tilpasninger for at tingene fungere éns på tværs af platformene. Derfor kan man ikke forvente at Code once - deploy anywhere hypotesen holder. 4.3 Nemmere vedligeholdelse Dette afsnit undersøger om det passer at man med en web-baseret løsning ender med at have en samlet, mindre og mere vedligeholdsvenlig kodebase. På native platforme ender man selvsagt op med én kodebase per platform. Og her er ingen kode-deling mellem disse kodebaser, når der ses på selve applikationerne. Applikationerne kan sagtens dele middleware, eksempelvis i form af et REST-interface der snakker med en Java eller Ruby backend. Emnerne der er blevet kigget på for at undersøge hypotesen er: Segmenteret hardware En web-baseret applikationen skal ligesom native kunne understøtte en række forskellige skærm-formater og hardware. Vil dette påvirke vedligeholdelsen af koden? Styling på tværs af browsere Det er ikke alt styling (CSS kode) der virker ens på alle platforme. Kan man indføre nogle tiltag for at understøtte dette? Javascript på tværs af browsere Javascript bliver nødvendigvis heller ikke tolket ens på tværs af browsere. Understøtter det valgte jquery de relevante browsere? Segmenteret hardware I løbet af de seneste år er der dukket mange forskellige mobile enheder op. Apple, har i skrivende stund fire forskellige telefon modeller: 32

37 iphone 3GS iphone 4 iphone 4S iphone 5 Derudover har de en række tablets: ipad 2 (2. generation) ipad, 3. generation ipad, 4. generation ipad Mini. På Android platformen er det en helt anden historie. Hvor Apple selv styrer produktionen af både hardware-enheder og software, er der frit spil på Android platformen. Google producerer softwaren, men der findes et hav af forskellige producenter af hardware enheder. Derfor findes der også mange forskellige hardwaresammensætninger og dermed også rigtig mange forskellige skærmstørrelser og skærmopløsninger. Det kan derfor være svært at teste en løsning på alle de forskellige Android enheder, simpelthen fordi det kan være svært at finde en fysisk enhed at teste på, så det kan være nødvendigt at bestemme sig for en håndfuld forskellige opløsninger man vil nøjes med at understøtte. Der findes en række firmaer der via Internettet tilbyder at man kan afprøve sin løsning på et udvalg af forskellige enheder. Ligeledes findes der værktøjer hvor ens side kan blive kørt i et tilpasset vindue, så man så at sige emulerer en enheds skærmstørrelse, og dermed også tester responsiviteten af ens løsning. Et eksempel på et sådant værktøj er Screen Fly 6 Men det er selvfølgelig også nødvendigt at kode løsningen så den kan tilpasse sig de forskellige opløsninger, hvis ikke man skal ende med for mange tilpasninger. En måde hvorledes man kan understøtte dette er ved at bruge en af funktionerne fra CSS3, Media Queries Media Queries En måde hvorpå man kan styre hvilke stylesheets der skal bruges på enheder med givne skærmstørrelse er ved at benytte følgende attributter fra Media Query: 1 min device width, max device width og 1 min device height, max device height 6 33

38 Med disse attributter kan man for eksempel angive at hvis en enhed har en minimumsbredde på 640 pixels, skal der benyttes ét stylesheet, og hvis enheden for eksempel har en minimumsbredde på 720 pixels skal der benyttes et andet. Dette vil se sådan ud i koden: ( min device width : 640px ) {... CSS KODE... } Der kan også laves kombinationer som følgende: ( max device width : 640px ) and ( min device width : 600px ) {... } Man slipper altså ikke får at skrive forskellige stylesheets, til understøttelsen af de forskellige opløsninger. Men det at styre hvornår et givent stylesheet skal benyttes er relativt nemt ved anvendelse af førnævnte attributter. Én ting er skærmopløsninger, en anden ting er at de nyere enheder indeholder såkaldte retina skærme. Retina Display handler om pixel densiteten af en skærm. Nedenstående er et billede fra Apples online butik 7 der viser en sammenligning af de forskellige ipad modeller, herunder display. Figur 4.7: Sammenligning af Apples ipads Yderst til venstre er displayet på ipad Mini, i midten er det ipad 2, og til højre er det 3. generation ipad med Retina display. Som det kan ses er der på 3.generations ipad en dobbelt så mange pixels per tomme, som på ipad 2. Det vil sige at foreksempel billeder/grafik der ser fint ud på ipad 2, vil virke grynet på en ipad med retina display. For at understøtte den høje pixel densitet, kan man derfor sørge for at lave sin grafik i to udgaver, én med dobbelt så høj opløsning som den anden. Den native Apple platform understøtter dette ved at man postfikser sine høj-opløselige billed- eller grafik sådan at man for eksempel har to filer: baggrund.png og Så sørger den native compiler automatisk for at vælge det rette billede til den rette skærm. Med en web-løsning har man ikke umiddelbart samme lette løsning. Det er dog muligt at finde ud af pixel densiteten på en enhed. Dette gøres igen ved hjælp af Media Queries: 7 34

39 ( webkit min device pixel r a t i o : 2) Det ses altså at man ikke måler på densiteten, men på ratio. Dette vil sige at hvis man for eksempel forstørrer et billeder med x2, vil én CSS pixel i virkeligheden bestå af 2x2 pixels på enheden, hvis denne har et retina display. Læg dog mærke til at ovenstående media query er pre-fixet med -webkit. Dette er altså specifikt for browsere der kører på webkit motoren. For Mozilla browsere vil man være nødt til at prefixe med -moz, og så videre. Her er altså endnu et eksempel på, at man er nødt til at have dobbelt kode for at opnå det samme resultat på tværs af browsere. Der er altså mulighed for at man med CSS kan understøtte enheder med højopløselige skærme, så disse får en god oplevelse. Det er dog stadig noget nær en umulig opgave at skulle understøtte alle former for skærme. Dette er ikke nødvendigs kun gældende på en web-platform, men også på native platforme Styling på tværs af browsere Som skrevet i afsnit vil man højst sandsynligt løbe ind i udfordringer der kræver at man skriver det samme kode to gange, for at tilpasse det til to platforme. Med hensyn til CSS er man med de forskellige browsere efterhånden kommet ret langt, så det ikke længere er nødvendigt at bruge vendor-prefixes på langt de fleste CSS attributter. Men for at være 100% sikker er det stadig en god idé at tilføje dem, eller i hvert fald lave mangfoldige tests. Der er stadig procent-dele af de mobile brugere der anvender browsere hvor det er nødvendigt. For at undgå at man nærmest får duplikeret kode, kan man som tidligere skrevet anvende SASS 8 og Compass 9. SASS er en udvidelse af CSS, og tilføjer en række ting som variable, man kan indlejre CSS klasser i hinanden, og mixins. Mixins kan forstås som gen-anvendelse af blokke af CSS kode. Ovenpå SASS kan man igen anvende Compass. Compass er populært sagt en samling af SASS mixins, og det er her hvor det begynder at hjælpe for udviklere. I stedet for at bruge tid på at skrive forskellige genbrugelige mixins, kan man med Compass allerede finde fungerende eksempler. Et konkret eksempel er border-radius. Fremfor at skrive et vendor-prefix på border-radius, kan man med Compass nøjes med følgende: " compass/ css3/border radius " 2. runde hjoerner border radius ( 5 px ) ; } Ovenstående vil, når det bliver kompileret resultere i følgende CSS kode: 1. runder hjoerner { 2 webkit border radius : 5px ; 3 moz border radius : 5px ; 4 khtml border radius : 5px ; 5 border radius : 5px ;

40 6 } Dermed behøver udvikleren ikke at tænke over vendor-prefixes, og kan skrive én linje kode der fungere i de gængse browsere. Men der er et par ulemper. Først og fremmest benytter ovenstående sig af både SASS og Compass. For at anvende SASS og Compass skal programmeringssproget Ruby være tilgængelig. Kompileringsværktøjet er nemlig skrevet heri. Dette kan være let at sætte op på en enkelt udvikler-maskine. Men hvis den pågældende virksomhed har dedikerede bygge-servere der sørger for at bygge applikationer og deploye dem på test- og produktionsservere, er det ikke sikkert at det er så ligetil at sætte op. Derudover skal det inkorporeres i den automatiserede bygge-proces. Og der kan argumenteres for at det faktum at CSS en først skal kompileres og eksempelvis bliver det i bygge-processen inden applikation installeres på en test-server, er det et trin der kan gå galt. Yderigere er det nødvendigt med en resource / udvikler der kan programmeringssproget Ruby, eller i hvert fald skal man have en udvikler lært op. Konfigurationen af SASS sker nemlig ved hjælpe af ruby-filer, derfor er en basis forståelse heraf nødvendig Javascript på tværs af browsere Som tidligere skrevet bliver Javascript ikke fortolket ens i alle de forskellige browsere. Et eksempel der tidligere er givet i er attributen: innertext. Attributten bruges til at hente den indlejrede tekst i et DOM element. Men hvor attributten er fint understøttet i Chrome, fejler den i Firefox, såvel som i Internet Explorer på Windows Phone. Løsningen på dette problem kan simpelt løses ved at anvende attributten innerhtml i stedet, der giver det samme ønskede resultat, og virker i alle browsere. Men hvis man forestiller sig andre funktioner der er væsentlig anderledes, og ville kræve at der blev kørt forskellige kode i henhold til den pågældende browser. Her kan en eventuel løsning være at anvende Javascript der er i stand til at lave Browser Detection. Og man kan endda ende i en situation hvor det ikke er nok at vide hvilken browser siden og koden bliver kørt i, men også hvilken version. Der findes mange kode eksempler med løsningen på nettet, som for eksempel dette fra Quirksmode 10 : 1 var BrowserDetect = { 2 i n i t : function ( ) { 3 t h i s. browser = t h i s. s e a r c h S t r i n g ( t h i s. databrowser ) "An unknown browser " ; 4 t h i s. version = t h i s. searchversion ( navigator. useragent ) 5 t h i s. searchversion ( navigator. appversion ) 6 " an unknown version " ; 7 t h i s. OS = t h i s. s e a r c h S t r i n g ( t h i s. dataos ) " an unknown OS" ; 8 }, 9 s e a r c h S t r i n g : function ( data ) { 10 for ( var i =0; i <data. length ; i ++) { 11 var d a t a S t r i n g = data [ i ]. s t r i n g ;

41 12 var dataprop = data [ i ]. prop ; 13 t h i s. v e r s i o n S e a r c h S t r i n g = data [ i ]. versionsearch data [ i ]. i d e n t i t y ; 14 i f ( d a t a S t r i n g ) { 15 i f ( d a t a S t r i n g. indexof ( data [ i ]. substring )!= 1) 16 return data [ i ]. i d e n t i t y ; 17 } 18 else i f ( dataprop ) 19 return data [ i ]. i d e n t i t y ; 20 } 21 }, 22 searchversion : function ( d a t a S t r i n g ) { 23 var index = d a t a S t r i n g. indexof ( t h i s. v e r s i o n S e a r c h S t r i n g ) ; 24 i f ( index == 1) return ; 25 return p a r s e F l o a t ( d a t a S t r i n g. s ubstring ( index+ t h i s. v e r s i o n S e a r c h S t r i n g. length +1) ) ; 26 }, 27 databrowser : [ 28 { 29 s t r i n g : navigator. useragent, 30 substring : " Chrome", 31 i d e n t i t y : "Chrome" 32 }, 33 { s t r i n g : navigator. useragent, 34 substring : "OmniWeb", 35 versionsearch : "OmniWeb/", 36 i d e n t i t y : "OmniWeb" 37 }, 38 { 39 s t r i n g : navigator. vendor, 40 substring : " Apple ", 41 i d e n t i t y : " S a f a r i ", 42 versionsearch : " Version " 43 }, 44 { 45 prop : window. opera, 46 i d e n t i t y : " Opera ", 47 versionsearch : " Version " 48 }, 49 { 50 s t r i n g : navigator. vendor, 51 substring : " icab ", 52 i d e n t i t y : " icab " 53 }, 54 { 55 s t r i n g : navigator. vendor, 56 substring : "KDE", 57 i d e n t i t y : " Konqueror " 58 }, 59 { 60 s t r i n g : navigator. useragent, 61 substring : " F i r e f o x ", 62 i d e n t i t y : " F i r e f o x " 63 }, 64 { 65 s t r i n g : navigator. vendor, 66 substring : " Camino ", 37

42 67 i d e n t i t y : " Camino " 68 }, 69 { / / f o r newer N e t s c a p e s ( 6 + ) 70 s t r i n g : navigator. useragent, 71 substring : " Netscape ", 72 i d e n t i t y : " Netscape " 73 }, 74 { 75 s t r i n g : navigator. useragent, 76 substring : "MSIE", 77 i d e n t i t y : " Explorer ", 78 versionsearch : " MSIE" 79 }, 80 { 81 s t r i n g : navigator. useragent, 82 substring : " Gecko ", 83 i d e n t i t y : " Mozilla ", 84 versionsearch : " rv " 85 }, 86 { / / f o r o l d e r N e t s c a p e s (4 ) 87 s t r i n g : navigator. useragent, 88 substring : " Mozilla ", 89 i d e n t i t y : " Netscape ", 90 versionsearch : " Mozilla " 91 } 92 ], 93 dataos : [ 94 { 95 s t r i n g : navigator. platform, 96 substring : "Win", 97 i d e n t i t y : "Windows" 98 }, 99 { 100 s t r i n g : navigator. platform, 101 substring : "Mac", 102 i d e n t i t y : "Mac" 103 }, 104 { 105 s t r i n g : navigator. useragent, 106 substring : " iphone ", 107 i d e n t i t y : " iphone/ipod " 108 }, 109 { 110 s t r i n g : navigator. platform, 111 substring : " Linux ", 112 i d e n t i t y : " Linux " 113 } 114 ] } ; 117 BrowserDetect. i n i t ( ) ; Ud over dette kode vil det være krævet at man handler på baggrund af hvad ovenstående giver som resultat. Det kræver også at man hele tiden vedligeholder sin kode, for at sørge for at det bliver tilpasset til nye versioner. Det er dog sjældent at der sker store ændringer ved hvert versionskifte i en 38

43 browser, men man kan aldrig være sikker. Og for eksempel opdaterer Chrome browseren sig selv, bagom ryggen på brugeren, derved kan ens brugere altså få automatisk opdateret deres browsere, og man er her nødt til at sørge for at ens kode virker i nyeste browser versioner Javascript Framework Ved at vælge et Javascript rammeværk, som for eksempel jquery / jquery Mobile, Sencha Touch eller lignende er man dog hjulpet et stykke af vejen. Disse rammeværk understøtter som oftest flere browsere, og i flere forskellige versioner. Tidligere i denne rapport blev jquery valgt til eksperiment applikationen. Ved et kig på jquery Mobile s hjemmeside 11, kan man finde en liste af understøttede browsere og versioner. jquery Mobile opdeler de understøttede browsere i A, B og C kategorier hvor A er bedst understøttet og C er mindst understøttet. I skrivende stund ser et uddrag fra A-kategorien således ud: Apple ios Android Android 3.2 Android 4.0 Android 4.1 Windows Phone Internet Explorer 8-10 (Testet på Windows Surface) Altså lover jquery at de ovenstående populære platforme er fuldt understøttet. Man burde altså med rimelig sikkerhed kunne anvende jquerys funktioner til eksempel DOM-manipulation uden at skulle bekymre sig om, hvorvidt de anvendte funktioner vil fejle i visse browsere. Man kan dog risikere at det i et eller andet omfang går ud over performance. Hvis koden skal kunne håndtere forskellige browsere og forskellige versioner, og det Javascript rammeværk nødt til at lave håndteringskode som det ovenstående i BrowserDetect.js. Det vil sige at der i virkeligheden bliver loadet mere Javascript ind i browseren end der reelt set er brug for. Det er også nødvendigt at holde øje med opdateringer til de forskellige rammeværk. Måske er der netop løst performance problemer i en ny opdatering, der gør det givtigt at skifte til en ny version. Men der kan også være sket andre ændringer. For eksempel har jquery i deres nyeste version, 2.0, valgt at droppe support for Internet Explorer 8 og nedefter. Det er derfor nødvendigt at vurdere om ens kunder bliver ramt af en sådan opgradering

44 JS Perf Der findes et værktøj der kan hjælpe med at analysere og optimere Javascript kode. På siden JSPerf.com kan man søge blandt mange forskellige test-cases eller skrive sine egne. For at illustrere performance forskellen ved at bruge et Javascript rammeværk som jquery, mod det at bruge ren Javascript, kan man skrive en simpel HTML side der ser således ud: 1 <html> 2 < s c r i p t s r c ="// a j a x. googleapis. com/ a j a x / l i b s /jquery /1/ jquery. min. j s "> </ s c r i p t > 3 <body> 4 <div id=" t e s t "> J S P e r f Test</div> 5 </body> 6 </html> For at sammenligne jquery og ren Javascript er der skrevet kode, der tager fat i div elementet, og finder den indlejrede tekst JSPerf Test. Testkoden skrevet med jquery: 1 var t e s t = $ ( t e s t ). innerhtml ; Testkoden skrevet med ren Javascript: 1 var t e s t = document. getelementbyid ( t e s t ). innerhtml ; Resultatet af testen, når den køres på JSPerf.com ser således ud: Figur 4.8: JSPerf.com test Det ses altså ud fra testen, der viser hvor mange operationer der er udført per sekund, kørt i Chrome at jquery i dette tilfælde i brugen af en ret normal og meget brugt funktion, getelementbyid, er hele 83% langsommere end ren Javascript. Men det er ikke kun sammenlignet med ren Javascript at der kan være performance at hente. Man kan med jquery også finde et dom-element ved at spørge på en given css klasse. Hvis man tilføjer en class attribut på div-element i ovenstående test, kan man lave følgende nye test: 1 <html> 2 < s c r i p t s r c ="// a j a x. googleapis. com/ a j a x / l i b s /jquery /1/ jquery. min. j s " ></ s c r i p t > 3 <body> 4 <div id=" t e s t " c l a s s =" t e s t C l a s s "> J S P e r f Test </div > 5 </body> 40

45 6 <html> Her efter kan man finde teksten i div-elementet med denne metode: 1 var t e s t = $ (. t e s t C l a s s ). innerhtml Men som det ses af nedenstående skærmbillede er by-class funktionen i jquery 37% langsommere end by-id. Figur 4.9: JSPer.com test med by-class Det kan altså også betale sig at undersøge hvilke interne funktioner i et Javascript bibliotek der performer bedre. I ovenstående tilfælde kan det bedst betale sig at hente elementet frem ved at bruge ID et hvis elementet altså har et sådant. Så man kan altså konkludere at det vil påvirke performance negativt, ved at trække et rammeværk som jquery ind i sin kode. Men som sagt giver det til gengæld fordelen, at man ikke behøver tænke så meget over understøttelse i forskellige browsere. Den bedste løsning må være at hvis man skal lave komplicerede Javascript operationer, at tjekke sin kode og optimere den via JSPerf.com og lignende værktøjer, for at få det mest optimale Javascript kode Opsummering Umiddelbart ses det at segmenteret hardware ikke som sådan giver en større kodebase til en web-baseret applikation. Man kan via CSS3 og media queries lave CSS kode der kan understøtte forskellige skærmstørrelser. Det giver selvfølgelig mere CSS kode at holde styr på. Men hvis man sørger for at strukturere sin CSS eller SASS kode, for eksempel ved at benytte includes og imports af kode, kan det holdes på et plan hvor det er til at overskue. Med hensyn til styling på tværs af browsere, kommer man til at skulle holde styr på lidt ekstra kode med den løsning der er foreslået. Der bliver et antal Ruby-filer man skal vedligeholde for at kunne komilere sin SASS kode. Denne hjælper dog i høj grad med at minimere det styling-kode man ellers skulle skrive for at opnå samme styling på tværs af browserne. Dog skal det indgå i overvejelserne hvor meget man vil opdatere SASS og Ruby for at få adgang til de nyeste funktioner. Så mens kodebasen ikke som sådan bliver større, bliver der ekstra 3. parts biblioteker man skal holde sig opdateret med. 41

46 Det samme er gældende for valg af Javascript rammeværk. Et givent Javascript rammeværk kan hjælpe med at skrive kode, der er kompatibel med flere browsere, og man undgår derved at skulle skrive forskellige kode til de enkelte browsere. Men med et 3. part rammeværk kommer en vedligeholdelsesopgave. Og den simple performance test der blev foretaget med Jsperf.com viser at man må gå på kompromis med performance. Om dette kan udmønte sig i et reelt performance problem afgænger af den enkelte løsning og applikation. Men det er klart en anbefaling af man løbende undersøger hvilke Javascript funktioner der kan foretages hurtigere ved at bruge en anden funktion i det valgte rammeværk, eller selv skrive en funktion i ren Javascript. Hypotesen kan konkluderes som sand, da man får en væsentlig mindre kodebase med en web-baseret applikation, fremfor native hvor man ville få 2-3 helt forskellige kodebaser. Dog kan det stadig blive vedligeholdelsestungt. 4.4 Native user experience i en browser I dette afsnit er der kigget på hvilke teknikker og funktioner der kan anvendes for at give en web-baseret applikation, det samme feel som en native applikation. For at undersøge hypotesen bliver der kigget på følgende emner: Kørsel i en browser Kan man få en web-app til at ligne og agere som en native app? Offline funktionalitet I en native app er man vant til at kunne starte applikationen op selvom der ikke er forbindelse til nettet, og eventuelt anvende nogle funktioner i applikationen. Kan dette gøres med en web-baseret applikation? Brugerflade design De native platforme har hver deres konventioner indenfor design af brugerflader. Kan dette understøttes af en web-baseret applikation? Datalagring Kan man udnytte enhedernes hukommelse når der skal lagres data i en web-baseret applikation? Performancetest Hvordan performer de enkelte browsere i forhold til hinanden? Performer samme web-baserede løsning ens i browserne? Brugerflade-performance Hvad kan der gøres for at forbedre oplevelsen af selve brugerfladen i en web-baseret applikation? 42

47 4.4.1 Kørsel i en browser Adresselinjen I en web-baseret mobil applikation er det unægteligt et faktum at der køres i en browser. Allerede her er rammerne for en brugeroplevelser der er lig en native brudt. Browseren vil umiddelbart altid være til stede, og vise en adresselinje øverst i billedet, samt oftest en form for toolbar nederst i billedet. Men der er visse tiltag der kan gøres for at forbedre oplevelsen. Der findes et meta tag der er meget brugbart når det kommer til at give en native lignende oplevelse med en web-baseret applikation. Dette tag er: 1 <meta name=" apple mobile web app capable " content=" yes " > Som navnet angiver, vil dette meta tag kun virker på Apple enheder, og kun i Safari browseren. På iphone og ipad, kan man pinne en web-side til den såkaldte hjemmeskærm. Det betyder at siden bliver oprettet som et bogmærke, men ligger som et ikon sammen med de andre applikationer der er installeret på telefonen. Når web-siden hentes frem på denne måde, vil der blive lavet en seperat instans af Safari browseren der kører i fuldskærm. Det vil sige at den normale adresse linje i toppen, og toolbaren i bunden af Safari bliver skjult. Det eneste der er tilgængelig er altså det web-siden viser. Altså er alle browser-elementer væk og man skjuler derfor for brugeren at applikationen i virkeligheden kører i en browser. Det er dog ikke alle meta tags der er standardiserede. Ovenstående tag til fuldskærmsunderstøttelse virker kun i Apples browser. På eksempelvis Android er man nødt til at håndtere problemet med en anden løsning. Men umiddelbart findes der ikke noget lignende der på samme relative lette måde, kan starte en applikation i fuldskærm, som med Apple-tagget. En umiddelbar løsning af anvende Javascript til at lave et automatisk scroll på siden, efter den er loadet for at scrolle adresselinjen ud af skærmen. Koden, der med fordel kan placeres lige under et eventuelt fuldskærms meta-tag til Apple browserer kan se således ud: 1 window. addeventlistener ( load, function ( e ) { 2 settimeout ( function ( ) { 3 window. s c r o l l T o ( 0, 1) ; 4 }, 1) ; 5 }, f a l s e ) ; Med dette eksempel vil browseren efter ét sekund scrolle ned nøjagtigt nok til at skjule adressenlinjen. Hvis man undlader at pakke scrollto kaldet ind i settimeout, vil det ske med det samme. Men faktum er at brugeren altid kan scrolle op og dermed få adresselinjen vist. Man kunne lave kode der lytter på ethvert scroll-event, og derefter sørger for at lave ovenstående scroll. Dette ville dog ikke være en løsning at foretrække. Man må respektere at løsningen netop afvikles i en browser, og lade brugeren gå til adresselinjen og indtaste en anden adresse hvis det er det brugeren vil. 43

48 Anveldelse af fuldskærmstilstand Den bedste løsning ville stadig være at benytte det benævnte meta-tag der starter Safari op i en fuldskærmstilstand. Det er dog nødvendigt at informere brugerne om denne mulighed, og afholde dem fra at forveksle funktionen Føj til hjemmeskærm med et almindeligt bogmærke. Det kræves altså at brugeren aktivt vælger at føje siden, og dermed applikationen, til hjemmeskærmen. På Apple enheder gøres det ved hjælp af Delfunktionen i Safari illustreret i nedenstående skærmbillede. Figur 4.10: Del-funktionen i Safari Med denne funktion får man mulighed for at dele siden via en række tjenester samt at tilføje den som bogmærke, og vigtigst i denne henseenden: at føje siden til hjemmeskærmen. 44

49 Figur 4.11: Delemulighederne i Safari Når Føj til hjemmeskærm vælges, bliver der tilføjet et nyt ikon på hjemmeskærmen i ios. Derved kan den web-baserede applikationen startes på samme måde som en native applikationen og vil altså starte i fuldskærm. Men da denne funktion kun er tilgængelig på Apples platform, kan det ikke anbefales at man designer sin applikation til kun at agere i fuldskærm. Man er nødt til at forvente at brugerne via browseren har mulighed for at trykke på en Tilbage-knap i browseren der går en side tilbage i historikken. Og dette er man nødt til at lade sin applikation kunne håndtere Håndtering af browserens Tilbage-knap Hvis man tager et nærmere kig på jquery og Single-page app arkitekturen, håndteres dette ved at udnytte anchor funktionaliteten i URL er, også kaldet 45

Procesbeskrivelse - Webprogrammering

Procesbeskrivelse - Webprogrammering Procesbeskrivelse - Webprogrammering Indholdsfortegnelse Forudsætninger... 1 Konceptet... 2 Hjemmesiden... 2 Server-side... 3 Filstrukturen... 3 Databasehåndtering og serverforbindelse... 4 Client-side...

Læs mere

Ikke bare endnu en e-bog... CoMPreNDo. Sådan kommer du i gang med din egen app. Og hvad skal virksomheden overhovedet bruge en app til?

Ikke bare endnu en e-bog... CoMPreNDo. Sådan kommer du i gang med din egen app. Og hvad skal virksomheden overhovedet bruge en app til? Ikke bare endnu en e-bog... CoMPreNDo. Sådan kommer du i gang med din egen app Og hvad skal virksomheden overhovedet bruge en app til? Titel: Sådan kommer du i gang med din egen applikation 1. udgave -

Læs mere

PHP Quick Teknisk Ordbog

PHP Quick Teknisk Ordbog PHP Quick Teknisk Ordbog Af Daniel Pedersen PHP Quick Teknisk Ordbog 1 Indhold De mest brugte tekniske udtryk benyttet inden for web udvikling. Du vil kunne slå de enkelte ord op og læse om hvad de betyder,

Læs mere

Get Skeleton. Boilerplate for Responsive, Mobile-Friendly Development

Get Skeleton. Boilerplate for Responsive, Mobile-Friendly Development Get Skeleton Boilerplate for Responsive, Mobile-Friendly Development Hvad er Get Skeleton?!? Get Skeleton er en lille samling af små CSS og JS filer, som giver dig adgang til ultra hurtig udvikling af

Læs mere

Mobile Engagement Platforms

Mobile Engagement Platforms KUPONER, VOUCHERS Mobile Engagement Platforms Brand Video Mobil kupon Tip en ven via sms Tilmeld nyhedsbrev Desktop ikon Nærmeste forhandler Del på Facebook Database Social & Mobile Coupons MOBIL INTERNET

Læs mere

Dan Rolsted PIT. Side 1

Dan Rolsted PIT. Side 1 Side 1 Side 2 Indledning I denne vejledning vil der vises hvordan Office 365 opsættes på de forskellige platforme, herunder IOS (ipad) og Android (HTC One). Derudover vil der også være vejledning til Windows

Læs mere

Vejle Mobil. workshop torsdag d. 09.02.2012. Laura Vilsbæk, Skybrud.dk Anders Bruun, Skybrud.dk

Vejle Mobil. workshop torsdag d. 09.02.2012. Laura Vilsbæk, Skybrud.dk Anders Bruun, Skybrud.dk Vejle Mobil workshop torsdag d. 09.02.2012 Laura Vilsbæk, Skybrud.dk Anders Bruun, Skybrud.dk Det skal vi kigge på i dag Trends og tendenser Tal og fakta Dig og din mobil Mobile muligheder Dig og din mobil

Læs mere

Politik vedrørende cookies og andre lignende teknologier. 1. Hvad dækker denne politik?

Politik vedrørende cookies og andre lignende teknologier. 1. Hvad dækker denne politik? Politik vedrørende cookies og andre lignende teknologier 1. Hvad dækker denne politik? Denne politik dækker dine handlinger relateret til Tikkurilas digitale serviceydelser. Denne politik dækker ikke,

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note Version 2.4 Der er over det sidste år lavet en lang række forbedringer, tiltag og fejlrettelser. Ændringer til forudsætningerne: o Klienten skal ved førstegangs login

Læs mere

Brugervejledning til Design Manager Version 1.02

Brugervejledning til Design Manager Version 1.02 Brugervejledning til Design Manager Version 1.02 Indholdsfortegnelse 1. Introduktion... 3 1.1 Det kan du med HostedShop Design Manager... 3 1.2 Feature list... 3 2. Design... 4 3. Filer og CSS... 4 3.1

Læs mere

Internet Information Services (IIS)

Internet Information Services (IIS) Internet Information Services (IIS) Casper Simonsen & Yulia Sadovskaya H1we080113 06-11-2013 Indholdsfortegnelse Problemformulering... 2 Hvorfor:... 2 Hvad:... 2 Hvordan:... 2 Problembehandling... 3 Introduktion...

Læs mere

Oftest stillede spørgsmål

Oftest stillede spørgsmål Oftest stillede spørgsmål Her finder du svaret på nogle væsentlige spørgsmål vedrørede brugen af Historiefaget.dk. Tekniske spørgsmål Elevernes navne stemmer ikke overens med deres eget Der kan være to

Læs mere

Mobile apps. App Academy. Velkommen! Vi starter kl. 17:00. Eksempler og links kan findes på http://appacademy.dk. www.appacademy.

Mobile apps. App Academy. Velkommen! Vi starter kl. 17:00. Eksempler og links kan findes på http://appacademy.dk. www.appacademy. Mobile apps Velkommen! Vi starter kl. 17:00 Eksempler og links kan findes på http://appacademy.dk Kristian Langborg-Hansen Partner i Underviser og foredragsholder Forfatter klh@appacademy.dk Planen for

Læs mere

GRAFISK PRODUKTION PORTFOLIO DAN KLESSEN BOOSTING BUSINESS MEDIEGRAFIKER SVENDEPRØVE

GRAFISK PRODUKTION PORTFOLIO DAN KLESSEN BOOSTING BUSINESS MEDIEGRAFIKER SVENDEPRØVE GRAFISK PRODUKTION OG WORKFLOW PORTFOLIO DAN KLESSEN BOOSTING BUSINESS MEDIEGRAFIKER SVENDEPRØVE PORTFOLIO DAN KLESSEN BOOSTING BUSINESS MEDIEGRAFIKER SVENDEPRØVE 04 INDHOLDSFORTEGNELSE Dokumentation 05

Læs mere

Forretningsmodeller for mobile applikationer

Forretningsmodeller for mobile applikationer Forretningsmodeller for mobile applikationer Indsigt og strategi Søren Kottal Eskildsen Alexandra Instituttet A/S Skabelon til forretningsmodel for mobile Click to edit Master title style applikationer

Læs mere

Underbilag 2.24 Kommunernes it-miljø

Underbilag 2.24 Kommunernes it-miljø Underbilag 2.24 Kommunernes it-miljø Indholdsfortegnelse Vejledning... 3 1 Indledning... 3 2 Sagsbehandling Klientmiljø... 3 2.1 Operativsystem... 3 2.2 Browser... 5 2.3 Runtime Miljøer... 6 2.4 Fysiske

Læs mere

Underbilag 2.24 Kommunernes it-miljø Kommunernes Ydelsessystem

Underbilag 2.24 Kommunernes it-miljø Kommunernes Ydelsessystem Underbilag 2.24 Kommunernes it-miljø Kommunernes Ydelsessystem Indholdsfortegnelse 1 Indledning... 3 2 Sagsbehandling Klientmiljø... 3 2.1 Operativsystem... 3 2.2 Browser... 5 2.3 Runtime Miljøer... 6

Læs mere

Google Tag Manager tracking

Google Tag Manager tracking Google Tag Manager tracking IDA Universe København, januar 2015 INDHOLD 1. INTRODUKTION... 3 2. TEST AF IMPLEMENTERING... 3 2.1. WASP Web Analytics Solution Profiler... 3 2.2. Firebug... 3 2.3. Tamper

Læs mere

Bilag 5: Kundens It-Miljø. Version 0.6 Bilag til dagsordenspunkt 9: Krav til kommunernes it-miljø.

Bilag 5: Kundens It-Miljø. Version 0.6 Bilag til dagsordenspunkt 9: Krav til kommunernes it-miljø. Bilag 5: Kundens It-Miljø Version 0.6 Bilag til dagsordenspunkt 9: Krav til kommunernes it-miljø. Senest opdateret d. 11. Oktober 2013 Indholdfortegnelse 1 Indledning... 3 2 Kundens IT-miljø - Løsningen...3

Læs mere

Studieordning del 3-2014

Studieordning del 3-2014 Studieordning del 3-2014 Valgfag Datamatiker AP Graduate in Computer Science Version 1.1 Revideret august 2014 Side 0 af 6 del 3 Valgfag 1. Valgfrie uddannelseselementer...2 2. Valgfaget Android...2 3.

Læs mere

Fra idé til virkelig med Azure Mobile Services

Fra idé til virkelig med Azure Mobile Services Fra idé til virkelig med Azure Mobile Services Niels Ladegaard Beck Holion nlb@holion.dk @nielslbeck Windows Developers in Denmark Azure App Service Mobile App Introduktion til Azure Mobile Services Platform

Læs mere

Pædagogisk IT. Vejledning i Office 365 til elever og deres familier. Version 4 Side 1. Kan udfyldes for at hjælpe med at huske

Pædagogisk IT. Vejledning i Office 365 til elever og deres familier. Version 4 Side 1. Kan udfyldes for at hjælpe med at huske Navn: Uni-login: Uni-login kode: Office365 email: Kan udfyldes for at hjælpe med at huske UNI-LOGIN @undervisning.kk.dk Version 4 Side 1 Indledning Velkommen til denne vejledning i Office 365, som introducerer

Læs mere

Du kan også bruge Dropbox sammen med din Iphone, Android telefon eller anden smartphone.

Du kan også bruge Dropbox sammen med din Iphone, Android telefon eller anden smartphone. Dropbox Introduktion til Dropbox Dropbox er en online tjeneste, hvor man ganske gratis kan få noget lagerplads til sine dokumenter, billeder og meget mere. Der er mange muligheder med Dropbox, som bliver

Læs mere

INDHOLDSFORTEGNELSE. Godt i gang med Android tablet... Indledning. KAPITEL ET... De første trin med din Android-enhed. KAPITEL TO...

INDHOLDSFORTEGNELSE. Godt i gang med Android tablet... Indledning. KAPITEL ET... De første trin med din Android-enhed. KAPITEL TO... INDHOLDSFORTEGNELSE Godt i gang med Android tablet... Indledning KAPITEL ET... De første trin med din Android-enhed Første gang... 8 Tilknyt Google-konto... 9 Sikkerhedskopiering... 10 Hjemmeskærmen...

Læs mere

SmartWeb Brugermanual

SmartWeb Brugermanual SmartWeb Brugermanual Table of Content Table of Content... 1 Best Practice SmartWeb:... 2 Implementering... 4 Egenskaber:... 5 Filer:... 7 Oprettelse af Kategori... 9 Sider og Tekster:... 11 Slideshow...

Læs mere

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund

Det Nye Testamente lyd-app. v. Stefan Lykkehøj Lund Det Nye Testamente lyd-app v. Stefan Lykkehøj Lund Indledning For nogle år siden, fik jeg Det Nye Testamente som lydbog på USB. I starten lyttede jeg en del med tiden blev det dog til mindre og mindre.

Læs mere

Håndbog. - MobilePass. Udarbejdet af: Maria Mathiesen Gældende fra: 25. februar 2015

Håndbog. - MobilePass. Udarbejdet af: Maria Mathiesen Gældende fra: 25. februar 2015 Håndbog - MobilePass Udarbejdet af: Maria Mathiesen Gældende fra: 25. februar 2015 Version Forfatter Dato Dokumentstatus 1.0 Maria Mathiesen 1. december 2014 Oprettet 1.1 Maria Mathiesen 16. december 2014

Læs mere

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO...

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO... INDHOLDSFORTEGNELSE INDLEDNING... 7 Kristian Langborg-Hansen KAPITEL ET... 9 I gang med App Inventor Installation af App Inventor... 10 Trådløs installation... 11 Installation af emulator (Windows)...

Læs mere

BESLUTNINGSBARRIEREN ER HØJERE

BESLUTNINGSBARRIEREN ER HØJERE At lave innovation og tænke nye forretningsområder kræver et velfunderet grundlag, der sikre kendskab til målgruppens behov og forretningens strategiske mål. Det er vigtigt at være sin position bevidst

Læs mere

Svar på de mest almindelige Citrix spørgsmål

Svar på de mest almindelige Citrix spørgsmål Svar på de mest almindelige Citrix spørgsmål Henrik Meyer og Ajâja Hyttel Oprettet: 24/6-13 Sidst revideret 14/5-14 h t t p s : / / c i t r i x. a a b n e t. d k Hvad er nyt i Citrix?... 2 Hvis du ikke

Læs mere

Kvik start opsætning af kamera det første du skal gøre:

Kvik start opsætning af kamera det første du skal gøre: Kom godt i gang Tillykke med købet af Valtronics Trådløst IP kamera. Denne quickmanual kan bruges til alle Valtronics IP kameraer. Kameraet giver mulighed for at fjenovervåge steder via sin mobiltelefon

Læs mere

ereolen.dk -Sådan downlåner du -Sådan anvender du på ebogslæser, tablet og smartphone

ereolen.dk -Sådan downlåner du -Sådan anvender du på ebogslæser, tablet og smartphone Side 1 af 18 ereolen.dk -Sådan downlåner du -Sådan anvender du på ebogslæser, tablet og smartphone Side 2 af 18 Indholdsfortegnelse ereolen.dk... 1 1. Første gang du vil anvende ereolen.dk... 3 1.1 Opret

Læs mere

GRAFISK WORKFLOW REDESIGN AF HJEMMESIDE

GRAFISK WORKFLOW REDESIGN AF HJEMMESIDE GRAFISK WORKFLOW REDESIGN AF HJEMMESIDE 2 REDESIGN AF FUTURECOM BUSINESS SOLUTIONS HJEMMESIDE OPGAVEN Den gamle hjemmeside skulles redesignes da den daværende hjemmeside var forældet (indhold og udseende)

Læs mere

GRAFISK PRODUKTION & WORKFLOW

GRAFISK PRODUKTION & WORKFLOW 24 APP FOR PRESIDENTS INSTITUTE Jeg arbejder til dagligt hos Presidents Institute og i den forbindelse fungerer jeg som projektleder på vores App som vi ønskede det. Der er blevet taget en masse nye beslutninger

Læs mere

EasyIQ ConnectAnywhere Release note

EasyIQ ConnectAnywhere Release note EasyIQ ConnectAnywhere Release note PC Klient 2.4.0.17 o Support for at Domain maskiner kan logge på ConnectAnywhere automatisk med Windows credentials Løsningen forudsætter/kræver at man logger på Windows

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Fjernadgang til BEC s systemer via Portal2

Fjernadgang til BEC s systemer via Portal2 Fjernadgang til BEC s systemer via Portal2 - tilgå applikationer og arbejdsplads via webbaseret portal (UAG) Udarbejdet af: Niklas Petersen Gældende fra: 24-08-2015 Version Forfatter Dato Dokumentstatus

Læs mere

STOFA VEJLEDNING ONLINEDISK INSTALLATION

STOFA VEJLEDNING ONLINEDISK INSTALLATION STOFA VEJLEDNING ONLINEDISK INSTALLATION I denne vejledning gennemgås installation af Stofa OnlineDisk samt opsætning, brugerflade og OnlineDisk Webportalen. Trin 1 Information om Stofa OnlineDisk Stofa

Læs mere

har jeg hentet nedenstående anmeldelse af et godt program til

har jeg hentet nedenstående anmeldelse af et godt program til Software Fra design af hjemmesider: har jeg hentet nedenstående anmeldelse af et godt program til Wordpress er intet mindre end et genialt program til hjemmesider. For det første er det gratis, og for

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

DOtAB. Teknisk rapport

DOtAB. Teknisk rapport DOtAB Teknisk rapport Indholdsfortegnelse Introduktion... 1 Systemarkitektur... 1 Teknologier... 1 Platforme for mobile enheder... 1 Kommunikations interfacet... 2 Udviklingsmiljø... 2 IDOtAB (service

Læs mere

Succes med intranet til Office 365. Den 13. august 2014 Webtop A/S s. 1

Succes med intranet til Office 365. Den 13. august 2014 Webtop A/S s. 1 Succes med intranet til Office 365 Webtop A/S s. 1 Hvem er jeg https://twitter.com/jeslas http://www.linkedin.com/in/jesslassen Webtop A/S s. 2 Hvad er Office 365 Office pakken (Word, Excel..) Skyudgaver

Læs mere

KRAV TIL INFRASTRUKTUR

KRAV TIL INFRASTRUKTUR KRAV TIL INFRASTRUKTUR VERSION 4.2.8 SEPTEMBER 2015 Indholdsfortegnelse 1 Generelt... 1 2 Servermæssige krav til -modulerne... 1 2.1 Systemmæssige krav i servermiljø... 1 2.2 Hardwaremæssige krav i servermiljø...

Læs mere

Design og udvikling af Android site specific browser

Design og udvikling af Android site specific browser Design og udvikling af Android site specific browser Diplom IT Eksamensprojekt 2011/2012 Forfatter: Shaymaa M. Yassen s082710 Vejledere: DTU Mads Nyborg NetDesign a/s Nino Martinez Kongens Lyngby 2011

Læs mere

Onsdags-workshops foråret 2014

Onsdags-workshops foråret 2014 Onsdags-workshops foråret 2014 Hver onsdag kl.15-17 Alle workshops er gratis 15. Januar: Google konto til meget mere end g-mail 22. januar: Google Chrome browseren fra Google 29. januar: NemID, borger.dk

Læs mere

TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE. Brugervejledning

TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE. Brugervejledning TEKNISKE FORHOLD VEDR. ADGANG TIL VP.ONLINE vp.online 2011 01-10-2011 Indholdsfortegnelse 1 PROBLEMER MED AT SE VP.ONLINE... 3 2 BROWSER KONFIGURATION... 6 3 SKRIVEADGANG TIL DREV... 7 4 SESSION TIMEOUT

Læs mere

GUIDE TIL CLOUD DRIVE

GUIDE TIL CLOUD DRIVE GUIDE TIL CLOUD DRIVE Dette er en guide du kan anvende til nemt at komme effektivt i gang med at anvende Cloud Drive Indholdsfortegnelse 1. Tilgængelige Cloud Drive klienter 2. Guide til Windows klienten

Læs mere

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau

Roskilde Tekniske Gymnasium. Eksamensprojekt. Programmering C niveau Roskilde Tekniske Gymnasium Eksamensprojekt Programmering C niveau Andreas Sode 09-05-2014 Indhold Eksamensprojekt Programmering C niveau... 2 Forord... 2 Indledning... 2 Problemformulering... 2 Krav til

Læs mere

Google Cloud Print vejledning

Google Cloud Print vejledning Google Cloud Print vejledning Version A DAN Definitioner af bemærkninger Vi bruger følgende stil til bemærkninger gennem hele brugsanvisningen: Bemærkninger fortæller, hvordan du skal reagere i en given

Læs mere

ELEMENTER Jeg vælger fonten Raleway, som er en af Googles mange gratis webfonte. Det er en grotesk skrift, som især bruges til websites, da de på

ELEMENTER Jeg vælger fonten Raleway, som er en af Googles mange gratis webfonte. Det er en grotesk skrift, som især bruges til websites, da de på Grafisk design Design af hjemmeside til indretningsarkitekt med firma navn enrico indret, som jeg tidligere har designet logo for. Firmaet laver udelukkende erhvervsindretning og målgruppen for sitet er

Læs mere

Løsningsbeskrivelse for log-in og signering med NemID. Valg af målgruppe og navigation omkring NemID på jeres tjeneste.

Løsningsbeskrivelse for log-in og signering med NemID. Valg af målgruppe og navigation omkring NemID på jeres tjeneste. Løsningsbeskrivelse for log-in og signering med NemID Valg af målgruppe og navigation omkring NemID på jeres tjeneste. Om dette dokument Indhold I dette dokument kan du finde en overordnet løsningsbeskrivelse

Læs mere

WORKFLOW. RESPONSIV HJEMMESIDE MED ET FARVETWIST Hjemmesidedesign og udvikling. www.mads-pj.dk/clothesly

WORKFLOW. RESPONSIV HJEMMESIDE MED ET FARVETWIST Hjemmesidedesign og udvikling. www.mads-pj.dk/clothesly WORKFLOW RESPONSIV HJEMMESIDE MED ET FARVETWIST Hjemmesidedesign og udvikling www.mads-pj.dk/clothesly DOKUMENTATION OPGAVE Opgaven jeg stillede mig selv, var at designe og kode et koncept til en webshop

Læs mere

Dan Rolsted PIT. Side 1. Version 9

Dan Rolsted PIT. Side 1. Version 9 Side 1 Side 2 Indledning I denne vejledning vil der vises hvordan Office 365 opsættes på de forskellige platforme, herunder IOS (ipad), Android (HTC One) og Windows mobile (Xxxxx). Derudover vil der også

Læs mere

Gratis kontorpakke til din tablet

Gratis kontorpakke til din tablet OPRET, REDIGER OG LÆS DOKUMENTER PÅ DIN TABLET: Gratis kontorpakke til din tablet DET FÅR DU OVERBLIK SVÆRHEDSGRAD Let Middel Svær Tekstbehandling Præsentation Regneark FOR ENHEDER MED Android ios (Apple)

Læs mere

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets.

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets. Dagens program Har alle fået? Har nogen betalt for meget? Hav jeres koder klar Domæner change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog Hvad er widgets Hvad er

Læs mere

INDHOLDSFORTEGNELSE. Windows 8.1... 5. KAPITEL ET... Den nye brugergrænseflade. KAPITEL TO... 23 Internet, e-mail, kontakter og kalender

INDHOLDSFORTEGNELSE. Windows 8.1... 5. KAPITEL ET... Den nye brugergrænseflade. KAPITEL TO... 23 Internet, e-mail, kontakter og kalender INDHOLDSFORTEGNELSE Windows 8.1... 5 KAPITEL ET... Den nye brugergrænseflade Sådan får du Windows 8.1 på din pc... 8 Startskærmen... 9 Skrivebordet... 10 Kvikguide til den nye brugergrænseflade... 11 Amulet-menuen...

Læs mere

REEFTlink Et banebrydende produkt til on-line overvågning af jeres produktionsapparat

REEFTlink Et banebrydende produkt til on-line overvågning af jeres produktionsapparat Rikard Karlsson, produktionschef hos Elektrolux, Ljungby, Sverige: REEFTlink er en komplet, dynamisk og fremtidssikret løsning, der dækker hele vores behov for Lean og Takt-baseret produktionsstyring.

Læs mere

Succes med intranet til Office 365

Succes med intranet til Office 365 Succes med intranet til Office 365 Agenda 8.30 9.00 Morgenmad og registrering 9.00 9.10 Præsentation af Webtop 9.10 9.45 Hvad er Office 365? 9.45 10.15 Hvad skal et moderne intranet kunne? 10.15 10.30

Læs mere

Guide til Umbraco CMS

Guide til Umbraco CMS web Guide til Umbraco CMS Indhold Indledning 3 Kompatible browsere 3 Log ind i Umbraco 4 Content-delen 5 Indholdstræet 5 Tilføjelse af en side/sektion 7 Sortering af indhold 12 Galleri 14 Mediebibliotek

Læs mere

HHBR. Design. Kvalitets vurdering. Opgaven. Målgruppe og Budskab. De Grafiske valg

HHBR. Design. Kvalitets vurdering. Opgaven. Målgruppe og Budskab. De Grafiske valg Opgaven Der skal designes en hjemmeside til en pensioneret revisor, som ønsker at starte en fritids beskæftigelse op, som privat revisor. Han Ønsker en hjemmeside der skal kort fortælle om hans forretning.

Læs mere

Guide til opdatering af Parrot CK3100 LCD, 3200LS Color, 3200LS+ og MK6100 med en Parrot Dongle

Guide til opdatering af Parrot CK3100 LCD, 3200LS Color, 3200LS+ og MK6100 med en Parrot Dongle Hvis man bruger en Bluetooth dongle fra Parrot (Parrot Dongle), så skal man følge nedenstående guide. Guiden er baseret med opdateringssoftware, version 3.4.1.0, til Microsoft Windows XP. For at kunne

Læs mere

Vejledning til brug af IT for nye elever

Vejledning til brug af IT for nye elever Vejledning til brug af IT for nye elever Vers.1. Okt 2014 IT Center Syd byder dig velkommen til Sønderborg Statsskole Denne vejledning er lavet for at gøre det nemmere for dig som elev, at benytte de forskellige

Læs mere

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk

OS2 Opgavefordeler. Løsningsbeskrivelse Version 2. Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk OS2 Opgavefordeler Løsningsbeskrivelse Version 2 Udarbejdet af Miracle A/S Simon Møgelvang Bang smb@miracle.dk 15/2/2015 Løsningsbeskrivelse for OS2 Opgavefordeler 1. Introduktion... 3 2. Kontekst... 3

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Microsoft IIS 6 Certifikat administration Følgende vejledning beskriver hvordan man installere et certifikat på en IIS 6 For support og hjælp til anvendelsen af denne vejledning kan du kontakte FairSSL

Læs mere

Min Kirke. - En kort introduktion. HappyHill v. Stefan Lykkehøj Lund ::: info@happyhill.dk ::: 23707131

Min Kirke. - En kort introduktion. HappyHill v. Stefan Lykkehøj Lund ::: info@happyhill.dk ::: 23707131 Min Kirke - En kort introduktion Introduktion Dette dokument beskriver kort en app som firmaet HappyHill har udviklet kaldet Min Kirke. Dette dokument skal fungere som en slags appetitvækker. App en findes

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

CONTENTS 1. KOM GODT IGANG... 3 2. JEG HAR WINDOWS 7 OG ØNSKER AT UDVIKLE APPS TIL WINDOWS PHONE 7... 4 2.1 Opret en DreamSpark konto... 4 2.

CONTENTS 1. KOM GODT IGANG... 3 2. JEG HAR WINDOWS 7 OG ØNSKER AT UDVIKLE APPS TIL WINDOWS PHONE 7... 4 2.1 Opret en DreamSpark konto... 4 2. CONTENTS 1. KOM GODT IGANG... 3 2. JEG HAR WINDOWS 7 OG ØNSKER AT UDVIKLE APPS TIL WINDOWS PHONE 7... 4 2.1 Opret en DreamSpark konto... 4 2.2 Download udviklingssoftware... 6 2.2.1 Hent Visual Studio

Læs mere

Visualisering. Kan opdeles i 2 dele Præsentations værktøj Portal

Visualisering. Kan opdeles i 2 dele Præsentations værktøj Portal Innofactor Plc 2000-2012 Visualisering Stigende krav til visualisering Brugervenlighed - flere brugere skal kunne anvende og lave visualiseringer Dynamisk Æstetisk Flere forskellige former for visualiseringer

Læs mere

Bilag 1 Kundens opgavebeskrivelse

Bilag 1 Kundens opgavebeskrivelse Bilag 1 Kundens opgavebeskrivelse Side 2 af 12 Indhold 1. Indledning... 3 1.1. Baggrund og formål... 3 1.2. Vision og mål... 3 1.3. Målgruppe... 3 2. Begreber... 4 2.1. Begrebsliste... 4 3. Opgavebeskrivelse...

Læs mere

Vejledning til RKSK s VDI konsulent login løsning juni 2015.

Vejledning til RKSK s VDI konsulent login løsning juni 2015. Vejledning til RKSK s VDI konsulent login løsning juni 2015. Den hidtidige login løsning via Citrix (login.rksk.dk) er lukket. Hvordan får man som konsulent adgang til RKSK s VDI Jumpstation? Ny bruger

Læs mere

Indhold. Grafisk workflow 3 Procesbeskrivelse 4 Inspiration 5 Skitser 6 Flowchart 7 Typografi og farver 8 Skelet 9 Storyboard 12 Html, css og seo 16

Indhold. Grafisk workflow 3 Procesbeskrivelse 4 Inspiration 5 Skitser 6 Flowchart 7 Typografi og farver 8 Skelet 9 Storyboard 12 Html, css og seo 16 GRAFISK WORKFLOW Indhold Grafisk workflow Procesbeskrivelse Inspiration 5 Skitser 6 Flowchart Typografi og farver 8 Skelet 9 Storyboard 2 Html, css og seo 6 Grafisk workflow Opgaven At skabe et nyt og

Læs mere

Information til nye kunder

Information til nye kunder Indhold I denne mini- guide finder du svarene på de spørgsmål, vi oftest bliver stillet, når pleje.net skal implementeres. Guiden er inddelt i seks afsnit, som indeholder: 1. Oprettelse af brugere og brugergrupper

Læs mere

Extension udvikling i Mozilla Firefox. Henrik Gemal

Extension udvikling i Mozilla Firefox. Henrik Gemal Extension udvikling i Mozilla Firefox Henrik Gemal Side 1 Hvem er jeg? Web udvikler hos TDC Laver TDC.dk og TDCOnline.dk Laver HTML, CSS, PHP Med i Mozilla projektet i mange år Udviklet et par extensions

Læs mere

Vejledning til Teknisk opsætning

Vejledning til Teknisk opsætning Vejledning til Teknisk opsætning v. 1.0 Adm4you, 2010. Indhold Kort om denne vejledning... 3 Generelt om easyourtime... 3 Installation af databasen... 3 Sikkerhed og rettigheder... 4 SQL Login... 4 Rettigheder

Læs mere

Kom i gang med SAS STPbaserede

Kom i gang med SAS STPbaserede make connections share ideas be inspired Kom i gang med SAS STPbaserede webapplikationer Lars L. Andersson Chefkonsulent Webapplikationer Interaktion med serverbaserede data via skærmbilleder leveret gennem

Læs mere

For dig som skal levere programmer til bideo.dk

For dig som skal levere programmer til bideo.dk For dig som skal levere programmer til bideo.dk Oktober 2011 - Version 5 INDLEDNING... 2 ANVENDELSE AF B2B.BIDEO.DK... 2 Den offentlige og den beskyttede webside... 2 Processen... 2 Før du bruger systemet

Læs mere

Common Denmark. Jan Koefoed-Nielsen. Common Denmark 01-01-2014

Common Denmark. Jan Koefoed-Nielsen. Common Denmark 01-01-2014 2014 Common Denmark Jan Koefoed-Nielsen Common Denmark 01-01-2014 2 Common Denmark Indhold Installation... 3 Iphone & Ipad... 3 Android... 8 Brugervejledning... 9 Login... 9 Profiler... 11 Møder... 15

Læs mere

Fold mulighederne ud med Microsoft Dynamics AX. Stærkere forretning med apps og mobile løsninger

Fold mulighederne ud med Microsoft Dynamics AX. Stærkere forretning med apps og mobile løsninger Fold mulighederne ud med Microsoft Dynamics AX Stærkere forretning med apps og mobile løsninger Agenda MOTIVATION Hvorfor mobility og ERP? TEKNIK Sikkerhed Infrastruktur LØSNINGER Standard løsninger fra

Læs mere

Mendeley er både en reference manager og et akademisk socialt netværk.

Mendeley er både en reference manager og et akademisk socialt netværk. Mendeley på PC er Mendeley er både en reference manager og et akademisk socialt netværk. Mendeley kan hjælpe dig med at organisere din forskning og samarbejde med andre online. Mendeley kan generere litteraturlister

Læs mere

Byg web sider. Introduktion:

Byg web sider. Introduktion: Introduktion: Du kender nu nogle enkle HTML tags, så nu er det på tide, at du kommer i gang med at lave din første side! Når du har nogle HTML-sider klar skal du have dem lagt op, så dine venner kan se

Læs mere

Installationsvejledning Danfoss SolarApp

Installationsvejledning Danfoss SolarApp MAKING MODERN LIVING POSSIBLE SOLAR INVERTERS Installationsvejledning Danfoss SolarApp DLX Serie - Invertere med integreret ConnectSmart www.danfoss.com/solar Indholdsfortegnelse Indholdsfortegnelse 1.

Læs mere

Installation og Drift. Aplanner for Windows Systemer Version 8.15

Installation og Drift. Aplanner for Windows Systemer Version 8.15 Installation og Drift Aplanner for Windows Systemer Version 8.15 Aplanner for Windows løsninger Tekniske forudsætninger Krav vedr. SQL Server SQL Server: SQL Server 2008 Express, SQL Server 2008 R2 eller

Læs mere

Apps og smartphones HMI. mobil devices og produktions-it. Anders Rolann, evikali A/S

Apps og smartphones HMI. mobil devices og produktions-it. Anders Rolann, evikali A/S Apps og smartphones HMI mobil devices og produktions-it Anders Rolann, evikali A/S Agenda Kort om evikali A/S Mobil Teknologi Smartdevices Fordele og ulemper ved smart devices Vision Brug af Apps i automation

Læs mere

Brugervejledning til chauffører. webtour.mobi. Version 2013-06-12. Opdateret og seneste version kan altid hentes på http://webtour.

Brugervejledning til chauffører. webtour.mobi. Version 2013-06-12. Opdateret og seneste version kan altid hentes på http://webtour. Brugervejledning til chauffører webtour.mobi Version 2013-06-12 Opdateret og seneste version kan altid hentes på http://webtour.dk/manual Der arbejdes til stadighed på at forbedre vores brugervejledning

Læs mere

Kravsspecifikation til Nationalpark App

Kravsspecifikation til Nationalpark App Kravsspecifikation til Nationalpark App Kravsspecifikation til Nationalpark App...1 1. Introduktion og platform...1 2. Ikke funktionelle specifikationer...2 3. Brugeroplevelse...2 4. Indholdsleverandører...2

Læs mere

Guide til opsætning af Google Analytics Nye kunder Visiolab introduktion

Guide til opsætning af Google Analytics Nye kunder Visiolab introduktion Guide til opsætning af Google Analytics Nye kunder Visiolab introduktion Denne guide vil gøre dig i stand til at opstille din Google Analytics konto. Ydermere vil den være en hjælp til at forstå hvordan

Læs mere

Dokumentation. Karen-Louise Fejerskov

Dokumentation. Karen-Louise Fejerskov Dokumentation Grafisk Workflow Et af produkterne, jeg skulle lave, var et redesign af FreQuence s info hjemmeside. A B Punkt 1 Ansvar: Jeg har selv stået for opsætningen af hjemmeside og selv bestemt,

Læs mere

Guide til MetaTraffic Pro

Guide til MetaTraffic Pro Guide til MetaTraffic Pro - dit statistikværktøj på din webside eller webshop DanaWeb benytter statistikværktøjet MetaTraffic Pro både på basis hjemmesiderne og til webshop hjemmesiderne. Du vil derfor

Læs mere

Web sider. Introduktion: Har du nogensinde spekuleret over, hvordan det verdesomspændende internet virker og hvordan man snakker med det?

Web sider. Introduktion: Har du nogensinde spekuleret over, hvordan det verdesomspændende internet virker og hvordan man snakker med det? Introduktion: Har du nogensinde spekuleret over, hvordan det verdesomspændende internet virker og hvordan man snakker med det? I dag skal du lære at lave hjemmesider, så du også kan bidrage til at opbygge

Læs mere

INDHOLDSFORTEGNELSE. Et stort spring... 7 Jesper Bove-Nielsen, forlagsdirektør. KAPITEL ET... 9 Introduktion til Windows 7

INDHOLDSFORTEGNELSE. Et stort spring... 7 Jesper Bove-Nielsen, forlagsdirektør. KAPITEL ET... 9 Introduktion til Windows 7 INDHOLDSFORTEGNELSE Et stort spring... 7 Jesper Bove-Nielsen, forlagsdirektør KAPITEL ET... 9 Introduktion til Windows 7 Windows 7-udgaver... 10 32- eller 64-bit version af Windows 7... 11 Hardware...

Læs mere

Guide til opsætning af Google Analytics Eksisterende kunder Visiolab introduction

Guide til opsætning af Google Analytics Eksisterende kunder Visiolab introduction Guide til opsætning af Google Analytics Eksisterende kunder Visiolab introduction Du modtager denne guide som en hjælp til forståelse af hvordan Visiolink applikationer fungere med Google Analytics. Ydermere

Læs mere

UNO vejledning. Indhold

UNO vejledning. Indhold UNO vejledning Indhold I denne vejledning finder du informationer omkring installering af de forskellige Uno produkter, derudover er der samlet de mest brugte funktioner til daglig brug af Uno UNO VEJLEDNING...

Læs mere

Opsætning af Outlook til Hosted Exchange 2007

Opsætning af Outlook til Hosted Exchange 2007 Opsætning af Outlook til Hosted Exchange 2007 Sådan opsættes Outlook 2007 til Hosted Exchange 2007. Opdateret 29. december 2010 Indhold 1 Indledning... 2 2 Outlook 2007 klienten... 2 3 Automatisk opsætning

Læs mere

10 gode grunde. - derfor skal du vælge Office365

10 gode grunde. - derfor skal du vælge Office365 10 gode grunde - derfor skal du vælge Office365 1. Bedre samarbejde på tværs af lokationer En stor del af arbejdsstyrken tilbringer i dag langt mere tid væk fra deres kontor end hidtil. Dine ansatte kan

Læs mere

MyArchive.kb.dk Selvarkivering af e-mails

MyArchive.kb.dk Selvarkivering af e-mails MyArchive.kb.dk Selvarkivering af e-mails Opsætningsvejledning til ipad Mail App Det Kongelige Bibliotek 22-11-2013 Denne vejledning beskriver brugeropsætning af ipad Mail App, således at en arkivskaber

Læs mere

FairSSL Fair priser fair support

FairSSL Fair priser fair support Small Business Server 2008 SSL certifikat administration Følgende vejledning beskriver hvordan man installere et certifikat på en SBS 2008 server. Ved bestilling af certifikater til Small Business Server

Læs mere

AirPrint vejledning. Denne dokumentation gælder for inkjet-modeller. Version 0 DAN

AirPrint vejledning. Denne dokumentation gælder for inkjet-modeller. Version 0 DAN AirPrint vejledning Denne dokumentation gælder for inkjet-modeller. Version 0 DAN Omfattede modeller Denne brugsanvisning gælder til følgende modeller. MFC-J450DW Definitioner af bemærkninger Vi bruger

Læs mere