GET THE MOST OUT OF YOUR APP WEB VS. NATIVE

GET THE MOST OUT OF YOUR APP

WEB VS.

NATIVE

Bachelorproef Arne Tesch

2

academiejaar 2015-2016

Woord vooraf Ik ben Arne Tesch, student New Media and Communication Technology (NMCT) aan de Hogeschool West-Vlaanderen in Kortrijk. NMCT is een praktijkgerichte opleiding met een breed aanbod aan keuzetrajecten. Tijdens het eerste academiejaar worden verschillende domeinen binnen de informatica behandeld. Gedurende de volgende jaren kan een traject worden samengesteld om te specialiseren in één gericht profiel. Mijn traject werden gekozen met de focus op ‘web & app development’. Computers en mobiele toestellen raken steeds meer ingeburgerd, en steeds meer gebruikers connecteren met het internet. Dit biedt veel kansen en mogelijkheden als ‘web & app developer’. De opleiding NMCT wordt afgerond met een drie maand durende stageperiode waarin je de kans krijgt om de kennis die je vergaard hebt in de voorbije jaren, in de praktijk te brengen in een professionele werkomgeving. Daar mijn keuzetraject zich specifieert op ‘web & app development’ was TapCrowd N.V. een ideaal bedrijf om stage te lopen. TapCrowd is een Gents bedrijf dat zich voornamelijk focust op mobiele applicaties voor evenementen, en dit voor alle platformen: iOS, Android, Windows Phone en ook HTML5web applicaties. Langs deze weg wil ik ook graag enkele mensen bedanken. Mijn promotor Stijn Walcarius die me begeleidde bij de uitwerking van dit project. Mijn stagebegleider Koen De Wegghleire, voor de steun tijdens het mijn stage. De personen binnen het stagebedrijf voor de kennis en kansen die me werden aangeboden.

In welke mate verschillen native applicaties van web applicaties voor mobiele toestellen

3



Samenvatting Wie “smartphone” zegt, zegt in één adem “apps”. Een smartphone-applicatie kan op meerdere manieren worden gebouwd. Elke ontwikkelwijze heeft zijn voor- en nadelen. In dit project wordt de focus gelegd op web en native applicaties. Native kan letterlijk vertaald worden als inheems, wat verwijst naar de manier waarop de applicatie in interactie treedt met het toestel. Een native applicatie wordt geïnstalleerd op een specifiek besturingssysteem en kan gebruikmaken van zowat alle functies van de smartphone. Voor web applicaties zijn de mogelijkheden om de functies van de smartphone te benutten beperkter. Een webapp is bereikbaar via de mobiele browser en vereist geen installatie. Mobiele toestellen worden steeds vaker gebruikt voor allerhande digitale diensten. Dit kan onder meer gaan over het regelen van vervoer met Uber, inkopen doen via het internet of het luisteren naar uw favoriete radiozenders. 1 Telkens wordt gebruik gemaakt van applicaties, of het nu gaat om ‘native’ applicaties of ‘web’ applicaties. Waarin deze twee ontwikkelwijzen verschillen en in welke mate de voordelen van de ene manier opwegen tegen de voordelen van de andere manier, wordt in deze bachelorproef onderzocht. In het onderzoek worden de development kosten, functionaliteit en ‘user interface’ van de twee manieren in kaart gebracht en vergeleken. Kernwoorden: smartphone,

native

en

web

applicaties,

mobiele

toestellen,

digitale

diensten,

besturingssystemen, mobiele browsers, kosten, functionaliteit, user interface

1

(“Mobile Internet Usage Skyrockets in Past 4 Years to Overtake Desktop as Most Used Digital Platform - comScore, Inc,” n.d.) (“Mobiel internetgebruik in België anno 2015 - Blog | Wijs,” n.d.)



4


Abstract Who says “smartphone”, says in one breath “apps”. A smartphone application can be built in several ways. Each development method has its advantages and disadvantages. This project is focused on native and web applications Native is a synonym for domestic, referring to how the application interacts with the device. A native application is installed on a specific operating system and can use almost all functions of the smartphone. For web applications, the ability to use the features of the smartphone is limited. A web app is accessed via the mobile browser and requires no installation. Mobile devices are increasingly being used for all kinds of digital services. This may include the transportation arrangements with Uber, making purchases over the Internet or listening to your favourite radio station. Each case requires use of applications, whether it is a native or a web application. In what these two development methods differ and how the benefits of the one way outweigh the advantages of the other, is examined in this bachelor thesis. The examination maps the development costs, features and user experience of the two methods, and compares them. Keywords: smartphone, native and web applications, mobile devices, digital services, operating systems, mobile browsers, costs, features, user interface


5



Verklarende woordenlijst Ø Afhankelijke variabele: Een variabele waarover men een voorspelling doet. Ø AngularJS:

Een

opensource

webapplicatieframework

met

als

doel

het

vereenvoudigen van zowel de ontwikkeling als het testen van Single Page applicaties. Ø API: Staat voor ‘Application Programming Interface’ en is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel van een toestel. Ø Application cache: Opslag van kleine gegevensbestanden (bv. aangepaste instellingen) en grote grafische bestanden om pagina’s in de toekomst sneller te kunnen inladen. Ø Besturingssysteem: Dit is het programma dat na het opstarten, in het geheugen van de smartphone geladen wordt en de hardware aanstuurt. Ø Broncode-editors: Een tekstbewerker, specifiek ontworpen voor het bewerken van de broncode van computerprogramma’s voor programmeurs. Ø Cross-platform: Een toepassing dat op meer dan één systeemplatform functioneert. Ø CSS: Staat voor ‘Cascading Style Sheets’ en zorgt voor de vormgeving van webpagina’s. Ø Debugging tool: Een debugging tool laat toe om het verloop van de code tijdens de uitvoering van de app te volgen. Ø Deductief onderzoek: Uitgaande van bepaalde theorieën tot een logische conclusie komen Ø Framework: Een geheel van softwarecomponenten dat gebruikt kan worden bij het programmeren van applicaties. Ø Geolocatie: Het bepalen van de geografische locatie van het toestel van een website. Ø Hierarchy viewer: Laat toe om op een snelle manier de user interface te debuggen en optimaliseren. Ø HTML: Staat voor ‘Hypertext Markup Language’ en is de taal waarmee je webpagina’s maakt. Ø Hybride applicatie: Een hybride applicatie is een combinatie van een native en web applicatie. De basis wordt opgebouwd zoals een native app, en vult een deel van de inhoud door een website. Dit geeft de vrijheid en flexibiliteit van een web app, en de kracht van een native applicatie. Ø Java: De programmeertaal voor het ontwikkelen van onder andere Android applicaties.



6


Ø JavaScript: Een veelgebruikte scripttaal om webpagina’s interactief te maken en web applicaties te ontwikkelen. Ø jQuery: Een gratis JavaScript-framework voor dynamische en interactieve websites, onder andere voor het bewerken van het DOM en CSS. Ø Kwalitatief onderzoek: Onderzoek met een beperkt aantal onderzoekseenheden en waarbij de focus ligt op het verkrijgen van informatie. Ø Meta-analyse: Het maken van een overzicht van eerdere onderzoeksbevindingen. Ø Native applicatie: Een platform afhankelijke versie van een toepassing voor smartphones, gecodeerd in een specifieke programmeertaal. De applicaties worden verspreid via een specifieke store en vereisen installatie op het toestel. Ø Navigatie-drawer: Glijdend menu aan de linker-of rechterkant van het scherm, dat zichtbaar wordt na het klikken op het hamburger-icoon. Ø Onafhankelijke variabele: Een variabele die men gebruikt om voorspellingen op te baseren. Ø Push berichten: Een kort bericht dat op het scherm van de telefoon getoond wordt, ook al is de app niet geopend. Ø SDK: Staat voor ‘Software Development Kit’ en is een verzameling van hulpmiddelen die handig zijn bij het ontwikkelen van computerprogramma’s voor een bepaald besturingssysteem. Ø Single Page Applicatie: Een webapplicatie of website die past op een enkele webpagina met als doel een vlotte gebruikerservaring te bieden. Ø Swift: Een programmeertaal ontwikkeld door Apple voor haar besturingssytemen iOS en Mac OS X. Ø Touch ID: Vingerafdruksensor ter vervanging van wachtwoorden. Ø User experience: Verwijst bij applicaties naar de gevoelens en gedachten over het gebruiksgemak en de functionaliteit van de applicatie. Ø User interface: De interface (intermediair) tussen een computer/mobiel toestel en de mens die de computer gebruikt. Ø Mobiele web applicatie: In basis een mobiele versie van een website. De vormgeving wordt aangepast aan de grootte van het scherm van een smartphone of tablet. De applicatie wordt ontwikkeld in HTML en JavaScript. Gebruik van de applicatie vereist geen installatie en kan gewoon via de mobiele browser. Ø Web SQL Storage: Een specificatie die het gebruik van client-side databases op mobiele toestellen mogelijk maakt.



7


Inhoudsopgave 1

TapCrowd NV. ........................................................................................................ 9

1.1

Omschrijving ............................................................................................................................... 9

1.2

Adres ............................................................................................................................................ 9

1.3

Logo ............................................................................................................................................. 9

1.4

Aantal werknemers ..................................................................................................................... 9

2

Onderzoeksvraag ................................................................................................ 10

2.1

Inleiding: context en totstandkomming onderzoeksvraag ................................................. 10

2.2

Persoonlijke motivatie .............................................................................................................. 11

2.3

Doelstelling ............................................................................................................................... 11

2.4

Methodologie ........................................................................................................................... 12

2.4.1

Meta-analyse ..................................................................................................................... 12

2.4.2

Persoonlijke ervaringen ................................................................................................... 12

2.4.3

Onderzoek tijdens stageperiode .................................................................................... 12

3

Analyse ................................................................................................................ 13

3.1

Onderzoeksterrein ................................................................................................................... 13

3.1.1

Kosten................................................................................................................................. 13

3.1.2

Functionaliteit .................................................................................................................... 14

3.1.3

User interface .................................................................................................................... 15

4

Persoonlijke ervaringen ...................................................................................... 18

4.1

Android Development: Remedi ............................................................................................. 18

4.1.1

Beschrijving ....................................................................................................................... 18

4.1.2

Kosten................................................................................................................................. 18

4.1.3


4.1.4

User interface .................................................................................................................... 19

4.2

Front End Development: Geofeelings ................................................................................... 19

4.2.1

Beschrijving ....................................................................................................................... 19

4.2.2

Kosten................................................................................................................................. 20

4.2.3


4.2.4

User interface .................................................................................................................... 20

4.3

Conclusie ................................................................................................................................... 21

4.3.1

Kosten................................................................................................................................. 21

4.3.2


4.3.3

User interface .................................................................................................................... 21

5

Onderzoek bij TapCrowd .................................................................................... 23

5.1

Stageomschrijving .................................................................................................................... 23

5.2

Onderzoeksbevindingen ......................................................................................................... 23



8


5.2.1

Kosten................................................................................................................................. 25

5.2.2


5.2.3

User interface .................................................................................................................... 26

5.3

6

Conclusies na stageopdracht ................................................................................................. 27

Oplossing ............................................................................................................ 28

6.1

Kosten ........................................................................................................................................ 28

6.1.1

Distributie en inkomsten .................................................................................................. 28

6.1.2

Werkuren ........................................................................................................................... 30

6.2

Functionaliteit............................................................................................................................ 31

6.2.1

SDK ..................................................................................................................................... 31

6.2.2

HTML5 ................................................................................................................................ 32

6.3

User interface ............................................................................................................................ 34

6.3.1

Native applicaties ............................................................................................................. 34

6.3.2

Web Applicaties ................................................................................................................ 36

6.3.3

Native vs. web applicatie ................................................................................................. 38

7

Kritische reflectie ................................................................................................ 39

7.1

Context van de applicatie ........................................................................................................ 39

7.2

Beperkingen van het onderzoek ............................................................................................ 39

8

Conclusies............................................................................................................ 40

8.1

Algemeen besluit ..................................................................................................................... 40

8.2

Persoonlijk besluit .................................................................................................................... 41

9

Afbeeldingen-en tabellenlijst ............................................................................. 42

10

Bronnen- & literatuurlijst ................................................................................. 44

11

Overzicht van de bijlagen ................................................................................ 47



1

TapCrowd NV.

1.1

Omschrijving

9


TapCrowd werd in 2009 opgericht door Brecht Fourneau en Miquël Vermeulen onder de naam ‘Mobile Juice’. Door het grote succes werd het bedrijf uitgebreid, en verdergezet als ‘TapCrowd’. TapCrowd is gevestigd in Gent en heeft ook verkoopkantoren in het Verenigd Koninkrijk, Nederland, De Verenigde Staten, Brazilië en Turkije. Het bedrijf richt zich in het heden voornamelijk op de ontwikkeling van mobiele apps voor professionele events en regelt de publicatie van de apps op alle leidende platformen, zoals iOS, Android, Windows Phone, evenals HTML5-hybride apps. Hiervoor beschikt het over een team van zestien werknemers, waaronder vier developers en één designer. Mijn stageperiode zal zich op deze dienst afspelen. TapCrowd telt klanten in Europa, Noord- en Zuid-Amerika en het Midden-Oosten. Enkele grote namen in het portfolio zijn Carrefour, Kia, Marketo, Nokia en SAP.2 In 2015 werd TapCrowd overgenomen door het Amerikaanse etouches. Etouches is een Amerikaans bedrijf gespecialiseerd in event management software. Door een samenwerking met TapCrowd, kan een betere mobiele ervaring worden gegarandeerd.

1.2 •

Adres Grauwpoort 1 9000 Gent België

1.3

Logo

Afbeelding 1: Logo TapCrowd N.V.

1.4 •

Aantal werknemers TapCrowd telt begin 2016 zestien werknemers

2

(“Gentse TapCrowd overgenomen door Amerikaanse event management specialist etouches - Technologie - DataNews - Knack.be - Data News.be,” n.d.)


10



2

Onderzoeksvraag

2.1

Inleiding: context en totstandkomming onderzoeksvraag

Anno 2016, beschikken wereldwijd maar liefs meer dan vier miljard mensen over een smartphone. Geschat wordt dat dit aantal enkel maar zal toenemen.3 Applicaties voor mobiele toestellen zijn ‘hot topic’.

Aantal smartphone gebruikers wereldwijd van 2013 tot 2018 2019

2017

Jaartal

2017 2015 2013

2019

2018 2016 2015 2014 2013

2011 2009

4,01

4,23

4,43

4,61

4,77

4,93

5,07

Aantal gebruikers uitgedrukt in miljard Grafiek 1: Aantal smartphone gebruikers wereldwijd van 2013 tot 2018

Een applicatie kan voor vele doeleinden gebouwd worden. De doelstelling bij het ontwikkelen van een applicatie is echter steeds een zo goed mogelijke user experience voorzien. Dit kan enerzijds gebeuren met een native applicatie, anderzijds door het bouwen van een mobiele website, wat vaak overeenkomt met een web applicatie of HTML5 Mobiele applicatie. Hoewel de doelstelling voor beide gevallen vaak gelijklopend is, verschilt een native applicatie in heel wat opzichten van een web applicatie. In deze bachelorproef wordt onderzocht welke factoren een rol spelen bij de keuze voor een bepaalde ontwikkelmethode. De onderzoeksvraag luidt dan ook concreet als volgt: Wat zijn de grootste verschillen tussen een web en een native applicatie en in welke mate zijn de verschillen bepalend voor de keuze van een ontwikkelmethode?

3

(“Mobile phone users worldwide 2013-2019 | Statistic,” n.d.)



11


Er werd reeds onderzoek gedaan naar de verschillen tussen beide methodes. Hierbij wordt telkens verwezen naar welke functionaliteit wel of niet ondersteund wordt bij de twee manieren. Het is echter niet steeds duidelijk welke factoren bepalend zijn, om een keuze te maken voor één van beide ontwikkelmethodes.

2.2

Persoonlijke motivatie

De populariteit van applicaties steeg de afgelopen jaren aanzienlijk. Voorspellingen tonen aan dat deze trend zich de komende jaren nog zal verder zetten. 4 Initieel werden enkel native applicaties ontwikkeld voor smartphones, sinds de komst van HTML5 (2012) is er echter een tweede speler op de markt, de “web applicatie” of “HTML5 mobiele applicatie”. Hierdoor werden de mogelijkheden bij het ontwikkelen van een applicatie verruimd. Zo kan één applicatie gebouwd worden die op verschillende platformen (iOS, Android, Windows Phone) zonder aanpassingen functioneert. Volgend uit het feit dat steeds meer mensen over een smartphone met internettoegang beschikken (zie 2.1), wordt een website die eveneens mobiel kan bekeken worden alsmaar belangrijker. Dit betekent dat zowel native applicaties, als web applicaties veel toekomstperspectief bieden. Met het oog hierop en aansluitend bij mijn interesses werd mijn studietraject samengesteld, bestaande uit web en app development modules. In de app development modules wordt de aandacht enkel gevestigd op native applicaties, terwijl in de web development module de focus vooral werd gelegd op web applicaties voor desktops. Om voeling te krijgen met web applicaties voor mobiele toestellen, werd TapCrowd als stagebedrijf gekozen. TapCrowd is gespecialiseerd in het ontwikkelen van evenementapplicaties, dit zowel native als niet-native. Inzicht krijgen in de verschillen tussen de twee manieren, is een fundamenteel punt voor de toekomstige developer.

2.3

Doelstelling

Het doel van deze bachelorproef is een beter zicht krijgen op de voor- en nadelen van beide ontwikkelmethodes, en welke factoren de keuze verklaren voor een native applicatie enerzijds, of een web applicatie anderzijds. Dit onderzoek zal dus de ontwikkelaar helpen bij het maken van de correcte keuze voor één van deze twee ontwikkelmethodes wanneer men de opdracht krijgt een applicatie te bouwen. Het is echter niet mogelijk om voor elke context een analyse te maken, en een oordeel of advies te schrijven. Het eindresultaat van het onderzoek moet een globaal beeld geven van de verschillen, op basis van dit beeld moet men zelf een oordeel kunnen vormen.

4

(“Number of mobile app downloads 2009-2017 | Statistic,” n.d.)



2.4

12


Methodologie

Zoals reeds eerder uit de onderzoeksvraag afgeleid kon worden, zal een vergelijkende studie worden opgemaakt over beide ontwikkelmanieren. De studie bestaat uit drie fases: een meta-analyse, een analyse gebaseerd op de ervaringen opgedaan tijdens semester vijf en onderzoek tijdens mijn stageperiode bij TapCrowd N.V. De resultaten uit het laatst vermelde onderzoek worden gebaseerd op persoonlijke bevindingen.

2.4.1

Meta-analyse

In de meta-analyse worden de onderzoeksbevindingen van eerdere onderzoeken naar de ontwikkelmanieren vergaard, en met elkaar vergeleken. Hiervoor werden drie onafhankelijke variabelen bepaald die het onderzoek moeten afbakenen. De variabelen luiden als volgt: de kosten voor het ontwikkelen van de applicatie, de functionaliteit van de applicatie op het toestel en de ‘user interface’ van de applicatie. Voor elk van deze variabelen wordt informatie ingezameld, deze informatie wordt uiteindelijk tegenover elkaar geplaatst om een duidelijk overzicht te geven van de verschillen tussen de twee ontwikkelmethodes. De afhankelijke variabele is dan de keuze die de ontwikkelaar maakt voor een native of web applicatie. Concreet kan dus gesteld worden dat een deductief onderzoek zal worden gevoerd om een oplossing te bieden voor de probleemstelling.

2.4.2

Persoonlijke ervaringen

In semester vijf krijgt elke student NMCT de kans zelf zijn studietraject samen te stellen. Zoals eerder vermeld bestond mijn studietraject voornamelijk uit app en web development modules. Op basis van de eindopdrachten van deze modules kon reeds ervaring opgedaan worden met web en native applicaties en vervolgens enkele persoonlijke oordelen worden geveld.

2.4.3

Onderzoek tijdens stageperiode

Tijdens mijn stage bij TapCrowd N.V. krijg ik de kans mee te draaien in een team dat elke dag zowel native als web applicaties ontwikkelt voor professionele events. Op deze manier heb ik de kans om zelf ervaring op te doen met de verschillende ontwikkelmanieren. Mijn persoonlijke bevindingen zullen eveneens in het onderzoek opgenomen worden.



3

Analyse

3.1

Onderzoeksterrein

13


De eerder vernoemde variabelen (zie 2.4.1) werden vastgelegd na het uitvoeren van een vooronderzoek. Uit het vooronderzoek werd afgeleid dat dit de drie aspecten zijn waarin de grootste verschillen kunnen vastgesteld worden tussen een native applicatie en een web applicatie.5

3.1.1

Kosten

Een vaste prijs kleven op het ontwikkelen van een applicatie is lastig. Een exacte kost kan pas opgemaakt worden, wanneer precies gedefinieerd is wat de applicatie zoal moet kunnen en welke inhoud de app moet bevatten. Een bedrijf, ambachtslui, … die een (native) app voor één platform wil laten ontwikkelen moet rekening houden met een kost van plusminus €15.000.6 Voor dit bedrag kan een basis applicatie worden gebouwd zonder veel extra functionaliteit, die compatibel is met slechts één platform. Indien de applicatie op meerdere platformen moet functioneren zal deze kost nog hoger oplopen. Een mogelijke oplossing is dan een web applicatie. Een cross-platform web applicatie ontwikkelen zal minder tijd vergen en ten gevolge ook de kosten drukken.

Afbeelding 2: best betalende iOS applicaties

5

(“Native app of web app? - Blog | Wijs,” n.d.) (“De web app versus de native app | Apps Ontwikkelaars,” n.d.) (“What is a Native Mobile App? - Definition from Techopedia,” n.d.) 6 (“Hoeveel kost een app? - ITNEXT,” n.d.) (“De kosten van een app laten maken? Zie wat andere apps hebben gekost: van € 2.500 tot € 100.000+ | Appspecialisten.nl,” n.d.)



14


De prijs voor een professionele web applicatie is insgelijks sterk afhankelijk van de complexiteit van de app. Hoe meer schermen de app bevat, hoe complexer het ontwikkelproces en hoe duurder de applicatie zal worden. Hierdoor kan de prijs van een HTML5 applicatie variëren van €2.500 tot €30.000.7 De basisprijs van een web applicatie ligt dus een stuk lager dan de gemiddelde kost voor een basis native applicatie. Er is echter ook een keerzijde aan de medaille. Een web applicatie vereist geen installatie via een application store. Dit betekent dat er ook geen opbrengsten kunnen voortkomen uit het aantal installaties. Een aantal web applicaties passen wel het principe van ‘in-app purchases’ toe om extra functionaliteiten toe te voegen. Om een duidelijk zicht te krijgen op welke methode het meest geschikt is voor een bepaald project, moet het verschil in kosten tussen beide methodes in kaart worden gebracht. Daarnaast moet ook de context van het project bekeken worden. Hoeveel budget is er beschikbaar? Hoe complex is de applicatie? Met andere woorden, welke functionaliteit is gewenst?

3.1.2

Functionaliteit

De complexiteit van een applicatie zal medebepalend zijn voor de keuze om een native applicatie enerzijds te ontwikkelen, of een web applicatie anderzijds. Dit onderzoek moet een overzicht geven welke functionaliteiten beide methodes al dan niet ondersteunen, en de ontwikkelaar helpen de juiste keuze voor een ontwikkelmethode te maken.

Afbeelding 3: Functionaliteiten van een applicatie

7

(“Kosten Website: Waarom is Maatwerk zo Kostbaar? - Mediaweb,” n.d.)



15


Om hier een correct oordeel te kunnen vellen, is het voor de ontwikkelaar noodzakelijk een duidelijk zicht te hebben op het doel van de applicatie. Dit kan namelijk al meteen de mogelijkheid tot keuze voor een ontwikkelmethode uitsluiten. Een web applicatie kan namelijk in veel mindere mate interageren met het toestel. Zo kunnen bepaalde hardware componenten door een web applicatie niet worden aangesproken. Hierdoor zijn de mogelijkheden beperkter om complexe zaken, zoals QR Code readers, vingerafdrukscanner voor ‘touch ID’, … in de applicatie te verwerken. 8

3.1.3

User interface

Een user interface design kan gezien worden als de hoeksteen van een goede en gebruiksvriendelijke applicatie. Het vormt de brug tussen het systeem en de eindgebruiker. De functionaliteit van een user interface draagt bij aan de gebruiksvriendelijkheid van uw applicatie en helpt de eindgebruiker de applicatie te gebruiken met zo min mogelijk inspanning en tijd.9

Afbeelding 4: 6 redenen om te investeren in mobiele gebruiksvriendelijkheid

8 9

(“Web- of native app ontwikkelen? - Emerce,” n.d.) (“User interface design | Conceptlicious,” n.d.)



16


Enkele statistieken die wijzen op het belang van een goede user interface in mobiele applicaties: 10 •

Gevolgen van een slechte user interface: (zie bijlage 2: infographic, het belang van een goede user interface) o 79% van de gebruikers zoekt een andere applicatie om de taak te voltooien. o 61% van gebruikers geeft aan de applicatie te stoppen, indien men niet meteen vindt wat men zoekt. o 52% van gebruikers zal zich minder snel als klant bij een bedrijf aansluiten, na een slechte mobiele ervaring.

Elk van de eerder vermelde platformen (iOS, Android en Windows Phone) hanteert enkele design richtlijnen waaraan de ontwikkelaar zich moet houden bij het bouwen van een native applicatie. Dit maakt dat de user interface van een native applicatie in vele opzichten zal verschillen van een web applicatie.

Afbeelding 5: User interface, native vs. web applicatie

10

(“30 UX Statistics You Should Not Ignore! [INFOGRAPHIC] | Experience Dynamics,” n.d.)



17


In een native applicatie zal de ontwikkelaar meer controle hebben over de user interface. Er hoeft geen rekening gehouden te worden met de beperkingen van browsers. De design richtlijnen van het desbetreffende platform moeten echter wel in acht genomen worden. Deze richtlijnen kunnen op hun beurt zorgen voor herkenbaarheid en vertrouwde componenten in de applicatie. Daarnaast kan een native applicatie ook meer interactie in de interface met de gebruiker voorzien, doordat gebruik gemaakt kan worden van de hardware componenten (camera, vingerafdruksensor, NFC) van de smartphone.

Afbeelding 6: Vingerafdrukscanner bij Apple



18


Persoonlijke ervaringen

4

Zoals reeds eerder vermeld in het voorwoord, werd mijn studietraject samengesteld met de focus op ‘web & app development’. Op deze manier werden al wat persoonlijke ervaringen opgedaan met het ontwikkelen van native en web applicaties voor zowel mobiele toestellen, als desktops. In semester vijf kregen we voor de modules Android en Front end development de opdracht een respectievelijk native en een web applicatie te ontwikkelen. De web applicatie werd hoofdzakelijk ontwikkeld voor desktop, maar moest eveneens toegankelijk zijn voor mobiele toestellen. Op basis van deze opdrachten werden al enkele persoonlijke ondervindingen opgedaan.

4.1

Android Development: Remedi

4.1.1

Beschrijving

Remedi is een applicatie die de communicatie tussen dokter/specialist en patiënt aanzienlijk vereenvoudigt. De dokter of specialist voert de tijdsloten in waarin afspraken kunnen worden gemaakt, terwijl patiënten kunnen intekenen op een dergelijk tijdslot. Dokters krijgen dagelijks een overzicht van de gevulde tijdsloten en de patiënten die ze zullen ontvangen. Patiënten krijgen op hun beurt een overzicht van de openstaande afspraken. Een dag voor de afspraak, krijgen ze bovendien een melding ter herinnering. Remedi werd in het kader van de lessen Android Development in het derde jaar New Media and Communication Technology met twee medestudenten ontwikkeld.

4.1.2

Kosten

Om applicaties in de Google Play Store te kunnen produceren, wordt een registratiekost van $ 25.00 gerekend. Deze kost is eenmalig en wordt aangerekend voor het aanmaken van een ‘Android developers-account’. De applicatie werd als bèta-versie gepubliceerd en er werden vervolgens geen kosten gerekend voor het downloaden ervan.

4.1.3

Functionaliteit

Voor de implementatie van de nodige functies werd gebruik gemaakt van enkele platformafhankelijke libraries en de Android SDK ontwikkeltools meegeleverd met Android Studio. Op deze manier kan op een relatief snelle manier functionaliteit in de applicatie worden gestopt. Enkele voorbeelden van SDK ontwikkeltools en libraries die benut werden tijdens het project: • •

SDK Tools: Debugging tool, hierarchy viewer, device monitor, … Libraries: Location services, roundedImageView, MaterialDateTimePicker, …



19


Hiermee werden onder andere de gegevens van de dokters opgehaald op basis van locatie, user interfaces opgebouwd en de codeerfouten gedetecteerd.

4.1.4

User interface

Voor de opmaak van de user interfaces werden de Android design richtlijnen11 strikt gevolgd. Beelden zeggen vaak meer dan woorden, onderstaand worden enkel screenshots uit de applicatie weergegeven.

Afbeelding 7: User interface - Remedi

Meer screenshots zijn te vinden in bijlage 6: Screenshots - Remedi.

4.2

Front End Development: Geofeelings

4.2.1

Beschrijving

Geofeelings is een Single Page web applicatie die real-time weergeeft waar in de wereld de mensen het gelukkigst zijn en zich goed voelen. De applicatie vraagt de gebruiker of hij al dan niet gelukkig is. Bijkomstig kan men een reden opgeven voor zijn geluk of verdriet. Het opgeven van de reden is geen verplichte stap, maar een leuke aanvulling. Uiteindelijk kan per regio bekeken worden hoeveel mensen zich goed voelen en waarom. De opbouw van applicatie is responsive, dit betekent dat de app eveneens toegankelijk is voor mobiele gebruikers.

11

(“Design | Android Developers,” n.d.)



4.2.2

20


Kosten

Daar het gaat om een web applicatie, kwamen er geen kosten kijken bij het ontwikkelen en publiceren van de app.

4.2.3

Functionaliteit

De app maakt gebruik van enkele HTML5 en Google API’s. Hiermee wordt bijvoorbeeld de kaart ingeladen, de locatie van de gebruiker bepaalt en gegevens van de gebruikers gecached. De implementatie van de vermelde functionaliteiten gebeurt met behulp van JavaScript en jQuery. De Single Page functionaliteit wordt verzorgd door AngularJS.

4.2.4

User interface

De user interface werd opgemaakt middels een combinatie van HTML5, CSS en jQuery. Onderstaand worden screenshots van de applicatie weergegeven in desktop en mobiele versie

Afbeelding 8: User interface – Geofeelings (Desktop en mobiel)

Meer screenshots zijn te vinden in bijlage 7: Screenshots - Geofeelings.



4.3

Conclusie

4.3.1

Kosten

21


De native applicatie ‘Remedi’ werd enkel ontwikkeld voor Android. Door het feit dat gebruik gemaakt werd van heel wat platform-afhankelijke SDK ontwikkeltools en libraries, zouden we, indien we de app cross-platform willen maken, het ontwikkelproces minstens driemaal moeten herhalen (Android, iOS en Windows Phone). Dit zou veel extra werkuren vereisen, daarenboven zouden de registratie kosten voor het publiceren van de app in de app stores eveneens driemaal betaald moeten worden. Voor de web applicatie is dit niet het geval. In de eerste plaats is de app meteen crossplatform, daarnaast moeten ook geen registratie kosten worden betaald. De ontwikkeltijd van een applicatie is ongetwijfeld de grootste kostendrager bij prijscalculatie van een app. Logischerwijze luidt de eerste vraag van een bedrijf/persoon die een applicatie wil laten ontwikkelen dan ook “Hoeveel tijd heb je nodig om het te maken ?”. De ontwikkeltijd is sterk afhankelijk van de complexiteit van de applicatie. Hoe complexer de app, hoe meer tijd nodig is om de app te maken. Het ontwikkelen van de applicatie ‘Remedi’ vergde meer tijd dan de web app ‘Geofeelings’. Dit heeft echter ook te maken met de mate waarin de ontwikkelaar vertrouwd is met de codeertaal. De ontwikkeltijd voor de Android applicatie kan ruwweg het dubbel geschat worden van de ontwikkeltijd voor de web applicatie. Uit voorgaande argumenten kan dus besloten worden dat het ontwikkelen van een web applicatie minder kosten met zich meebrengt dan een native applicatie.

4.3.2

Functionaliteit

Een vergelijking maken op gebied van functionaliteit tussen deze twee applicaties is niet erg relevant, daar het om twee zeer uiteenlopende apps gaat en bij de opgave van de web applicatie rekening werd gehouden met de mogelijkheden en beperkingen van de browser.

4.3.3

User interface

Wat betreft de user interface kan wel een relevante vergelijking opgemaakt worden. Bij het ontwikkelen van Remedi moesten bepaalde richtlijnen strikt gevolgd worden. Zo worden bijvoorbeeld de dimensies en opmaak van de navigatie-drawer standaard vastgelegd in de Android design richtlijnen.12 Voor de webapp is dit niet het geval, de ontwikkelaar bepaalt zelf de dimensies en opmaak.

12

(“Navigation drawer - Patterns - Google design guidelines,” n.d.)



22


Hetzelfde geldt voor de opmaak van knoppen, tekst velden en andere interface elementen. De web ontwikkelaar heeft dus meer vrijheid wat betreft het design van de applicatie. Anderzijds bieden de ontwikkelingstools (Visual Studio, Xcode en Android Studio) heel wat hulpmiddelen om relatief snel de user interface op te maken. De opmaak kan bij wijze van spreken gebeuren door het slepen en positioneren van elementen in de layout bewerkers.



23


Onderzoek bij TapCrowd

5

Zoals reeds omschreven werd in de voorstelling van het bedrijf (zie 1.1), worden bij TapCrowd zowel native als web applicaties ontwikkeld. Dit was een bepalende factor voor de keuze om er stage te lopen, daar mijn onderzoeksvraag zich specifiek richt op deze twee ontwikkelmanieren.

5.1

Stageomschrijving

Vanuit het kantoor in de iHub ontwikkelt TapCrowd een state-of-art platform waarmee iedereen een eigen mobile app kan samenstellen en publiceren. Met het platform kunnen zowel mobiele websites en web apps in HTML5 gepubliceerd worden, maar ook native apps die in de app stores kunnen worden geplaatst. De stage bestond erin om verschillende modules van het platform uit te werken, dit betekent volgende stappen: • • • • • •

Bekijken van bestaande oplossingen in de markt (marktonderzoek) Analyse uitschrijven: functioneel, datamodel, API calls, enz. Ontwikkeling Testing Integratie Documentatie

De eerste opdracht bestond uit het ontwikkelen van een ‘Find my car’ module voor iOS. Verdere opdrachten werden toegekend tijdens de stageperiode zelf.

5.2

Onderzoeksbevindingen

Voor het ontwikkelen van event applicaties gaat men bij TapCrowd niet op de standaard manier te werk. TapCrowd ontwikkelt een state-of-art platform waarmee een klant/bedrijf zelf de functionaliteiten in de app kan kiezen, weergave bewerken en inhoud toevoegen via diverse formulieren. Daarna kan de app gegenereerd en gedownload worden als iOS, Android of HTML5 app. Voor de HTML5 versie zijn er echter wel enkele beperkingen, zo kan bijvoorbeeld nog geen gebruik gemaakt worden van de camerafunctie.



24


Afbeelding 9: TapCrowd platform

Mijn eerste opdracht bestaat uit het ontwikkelen van een ‘find my car’ module voor het platform. Deze module wordt in eerste instantie ontwikkeld voor iOS, later moet de module uitgebreid worden zodat ook de Android en HTML5 versies worden ondersteund. De module biedt de bezoekers van een evenement de mogelijkheid om de plaats waar ze hun wagen parkeren aan te duiden op een map. Bij het verlaten van het event wordt op basis van hun huidige GPS coördinaten de afstand tot de geparkeerde wagen en de wandeltijd berekend. Op die manier heeft de bezoeker een idee hoelang hij ongeveer onderweg zal zijn naar zijn/haar wagen.

Afbeelding 10: Interface ‘Find my car’ module



25


De resultaten van het onderzoek tijdens de stageperiode worden gebasseerd op deze module.

5.2.1

Kosten

Een bedrijf of klant die een applicatie voor een evenement laat genereren door het TapCrowd platform, krijgt de applicatie automatisch in twee native versies (iOS en Android) en een web versie. Men betaalt dus steeds voor een totaal pakket. De prijs voor een event-applicatie is afhankelijk van het aantal gekozen modules en eventuele extra uitbreidingen of diensten. Zo kan bijvoorbeeld een werknemer van TapCrowd worden ‘ingehuurd’ om aanwezig te zijn op het evenement voor extra ondersteuning of kunnen logo’s en iconen aangepast worden aan een bepaalde stijl of thema. Het bedrijf/klant heeft vervolgens zelf de keuze om de app al dan niet betalend aan te bieden via de app stores. Het overgrote deel van de klanten van TapCrowd bieden de applicatie echter steeds gratis aan. Bij TapCrowd zijn twee developers aangesteld die verantwoordelijk zijn voor het ontwikkelen van de modules voor iOS en Android. Dit toont andermaal aan dat voor beide besturingssystemen een compleet verschillend ontwikkelingsproces wordt doorlopen.

5.2.2

Functionaliteit

De gewenste functionaliteit in de app wordt zoals eerder vermeld (zie 5.2 en afbeelding 8) gekozen uit een lijst van modules. Zo kan het bedrijf of de klant bijvoorbeeld de camera functie aanspreken, GPS locaties opvragen en een grondplan van het event inladen. De modules komen vervolgens in een lijst of gridview terecht, afhankelijk van de layoutkeuze die men zelf maakt. Het overgrote deel van de functionaliteiten zijn zowel voor de native als web app beschikbaar. Enkel de modules die gebruikmaken van de camera kunnen nog niet in de web app voorzien worden daar dit tot op heden door zeer weinig mobiele browsers wordt ondersteund. 13 De ‘find my car’ module die ik tijdens mijn stage moest uitwerken voor iOS zal in de web versie gebruikmaken van een google maps frame. In de native versies kan voor deze functionaliteit beroep gedaan worden op de platform SDK’s.

13

(“Can I use... Support tables for HTML5, CSS3, etc,” n.d.)



5.2.3

26


User interface

Het TapCrowd platform kan slechts in beperkte mate rekening houden met de design richtlijnen van het desbetreffende besturingssysteem. Er wordt steeds gestart vanuit een vaste template, die vervolgens aangepast wordt volgens de voorkeuren en gekozen modules. De user interface wordt in de drie gevallen erg gelijkaardig opgebouwd. De layout is zo goed als identiek, enkel de gebruikte componenten tonen verschillen. Voor de native versie worden de standaard compontenten van het platform gebruikt, de web app wordt opgebouwd in HTML5 en gedesigned met CSS. TapCrowd koos ervoor zelf een design stijl te ontwikkelen en deze te laten terugkeren in elke module van de gegenereerde app. Voornaamste reden om met een standaard template te werken is ‘herkenbaarheid’. Men wil een zekere herhaling van acties creëren zodat de gebruiker de app kan bedienen zonder al te veel te moeten nadenken. Een simpel voorbeeld is het gebruik van tabs in de navigatie. In een module met meerdere schermen kan genavigeerd worden door het swipen naar verschillende tabs. Deze manier van werken behoort niet tot de designrichtlijnen van iOS, maar behoort wel tot de stijl van TapCrowd.

Afbeelding 11: Gebruik van tabs op het TapCrowd platform



27


Herkenbaarheid creëren in de applicaties is eveneens de doelstelling van de design richtlijnen voor de verschillende platformen. Hieruit kan dus afgeleid worden dat dit een belangrijke factor is voor een succesvolle applicatie. Met ontwikkelingstools voor native applicaties zoals Visual Studio, Android Studio en Xcode kunnen de standaardcomponenten per platform erg eenvoudig in de applicatie verwerkt worden. Zo krijgen native applicaties in de meeste gevallen dezelfde ‘look-andfeel’. In een web applicatie is dit minder het geval, de ontwikkelaar heeft alle vrijheid om de componenten te designen volgens eigen voorkeur, waardoor herkenbaarheid creëren minder evident is.

5.3

Conclusies na stageopdracht

Hoewel een bedrijf/klant niet veel verschil zal merken in de applicatie en prijs van de native versies en web versie is achter de schermen toch heel wat verschil merkbaar. In de eerste plaats worden de native versies voor iOS en Android door twee verschillende personen ontwikkeld. De functionaliteit die aanwezig moeten zijn in de modules zijn de enige zaken die de twee versies gemeenschappelijk hebben. Voor het overige staan de twee ontwikkelprocessen volledig los van elkaar. Hierdoor wordt het aantal werkuren meteen verdubbeld. De web versie wordt gebaseerd op de native versies, maar vereist andermaal een compleet verschillend ontwikkelproces door een derde ontwikkelaar. Verder zal de user interface driemaal visueel zo goed als identiek zijn, maar moet hij toch telkens op een andere manier worden opgebouwd. Alle modules die ontwikkeld worden voor het platform kunnen in de toekomst hergebruikt worden. Hierdoor wordt steeds meer functionaliteit geboden en vergt het ontwikkelen van een event app voor een klant minder tijd dan wanneer telkens van scratch gestart moet worden.



28


Oplossing

6

Uit de analyse van de drie actoren kan afgeleid worden dat er heel wat verschillen zijn tussen een native en een web applicatie. Om een duidelijk zicht te krijgen op de mogelijkheden van beide ontwikkelmethodes, en een verantwoorde keuze te kunnen maken, worden de verschillen van de besproken variabelen in de volgende sectie uitgebreid besproken.

6.1

Kosten

De kost voor het ontwikkelen van een applicatie kan erg variëren. Een gemiddelde prijs bepalen voor het bouwen van een applicatie is zo goed als onmogelijk. Alles hangt af van de complexiteit en de platformen waarop de app beschikbaar moet zijn. Er bestaan reeds enkele tools, waarmee een prijscalculatie kan worden gemaakt voor het bouwen van een native app.14 Daarnaast zijn er ook nog de web applicaties of HTML5 applicaties. Elke recente mobiele browser ondersteunt HTML5. Hierdoor is een web applicatie ook meteen een cross-platform applicatie, wat tijd en kosten drukt.

6.1.1

Distributie en inkomsten

Native applicaties zijn makkelijk te vinden en te installeren via de Apple App Store, Google Play Store en de Windows Phone Store. Door een applicatie in de store te plaatsen en betalend te maken, kan een ontwikkelaar en/of bedrijf inkomsten verwerven met een applicatie. Van de verworven inkomsten moet men gemiddeld 30% ‘distributiekosten’ afstaan aan de verdelers (stores).15 Daarnaast kunnen ook ‘in-app purchases’ in de applicatie worden voorzien. Dit betekent dat de gebruiker de mogelijkheid heeft om extra zaken aan te kopen bij het gebruik van de app.

Afbeelding 12: Apple App Store, Google Play Store en Window Phone Store

14 15

(“How Much to Make an App,” n.d.) (“How Do Native Apps and Web Apps Compare? - Webmonkey,” n.d.)



29


Web applicaties kunnen niet in de vernoemde stores worden geplaatst. De gebruiker moet de applicatie zien te vinden via de mobiele browser. Hierdoor kan men voor een HTML5 applicatie ook moeilijk inkomsten innen voor of bij het gebruik ervan. Er staat nergens geschreven dat het niet mag, maar het is ongebruikelijk. Er hoeven echter geen distributiekosten te worden betaald. De inkomsten bij een web applicatie moeten worden gehaald uit reclame en eventuele abonnementskosten. Hiervoor moet een betalingssysteem worden opgezet, wat op zijn beurt een kost meebrengt onder de noemer ‘Interchange fees’ of ‘afwikkelingsvergoeding’. Dit is de vergoeding die afgestaan moet worden aan betalingsfirma’s zoals Visa en Mastercard. Het percentage van het transactiebedrag dat afgegeven dient te worden ligt echter een stuk lager (tussen 0,4% en 1,2%) dan de distributiekosten voor native apps.16

Afbeelding 13: Inkomsten en verdiensten via Apple’s App Store

16

(“European Commission - PRESS RELEASES - Press release - Antitrust: Commissie verbiedt multilaterale afwikkelingsvergoedingen MasterCard in EER,” n.d.)



6.1.2

30


Werkuren

Het ontwikkelen van een web applicatie vergt minder werkuren dan een native applicatie. Enerzijds doordat een web applicatie meteen zo goed als cross-platform is, anderzijds zijn ontwikkelaars reeds meer vertrouwd met de codeertaal achter de HTML5 apps (JavaScript).17 Onderstaande grafiek geeft een top tien van de meest gebruikte codeertalen tussen 2013 en 2015, uitgedrukt in percentages.

Afbeelding 14: Top 10 meest gebruikte codeertalen tussen 2013 en 2015

Er kunnen een aantal oorzaken opgesomd worden die ervoor zorgen dat het ontwerpen van een native applicatie meer werkuren vergt. Ten eerste is een native applicatie plaform-afhankelijk. Dit betekent dat een applicatie in evenveel versies (Java, Swift, …) moet geschreven worden als het aantal besturingssystemen dat men wil ondersteunen.

17

(“Ten charts that paint a fascinating portrait of the modern-day programmer - Quartz,” n.d.)



31


Daarnaast is Swift een vrij nieuwe codeertaal (2014) waardoor niet veel ontwikkelaars vertrouwd zijn met de syntax, en is ontwikkelen voor Android een vrij complex gegeven door het vele aantal SDK versies. 18 Ten slotte worden ook meermaals per jaar updates uitgebracht voor de drie besproken besturingssystemen. Hierdoor moet vaak ook de code van de applicatie een update krijgen.

6.2

Functionaliteit

De mogelijkheid bij native apps om de hardware componenten van de smartphone aan te spreken en gebruik te kunnen maken van enkele speciale functionaliteiten, zijn ongetwijfeld de belangrijkste overtuigingsfactoren wanneer ontwikkelaars native applicaties boven web applicaties verkiezen.

6.2.1

SDK

De SDK’s, beschikbaar bij het ontwikkelen van native applicaties, bieden de ontwikkelaar heel wat hulpmiddelen voor het implementeren van speciale technieken. Zo zijn er SDK’s voor spraakherkenning, het creëren van games, gebruik van 3D Touch … Hierdoor kan in een native applicatie meer geavanceerde functionaliteit voorzien worden. Het nadeel van SDK’s is dat ze platform-afhankelijk zijn. Elk van de besproken platformen hebben een eigen SDK. Indien de applicatie voor meerdere besturingssystemen beschikbaar moet zijn, is de ontwikkelaar geboden drie verschillende apps te bouwen.

Afbeelding 15: SDK’s per platform

In onderstaande tabel worden de belangrijkste functionaliteiten en compatibiliteit per ontwikkelmethode opgelijst. Het is een checklijst die de ontwikkelaar bij de hand kan nemen wanneer de keuze gemaakt moet worden een native of web applicatie te bouwen.

18

(“Android SDK: Which Version to Use and Why - LearnComputer,” n.d.)



32


Functionaliteit

Web applicatie

Native applicatie

Adresboek

r

Audio

a

Camera

r

Kompas

r

GPS

a

NFC

r

Multi-touch19

a

Push berichten

r

Fotobibliotheek

r

Bluetooth

r

a a a a a a a a a a

Tabel 1: Overzicht functionaliteiten per ontwikkelmethode

6.2.2

HTML5

Sinds de komst van HTML5 is het aantal functies die ondersteund worden door de verschillende mobiele browsers (iOS Safari, Android Browser, Chrome for Android, Edge) enorm toegenomen. Zo worden bijvoorbeeld geolocatie, application cache en Web SQL storage door zowat elke mobiele browser ondersteund.20

19

(“Developing for Multi-Touch Web Browsers - HTML5 Rocks,” n.d.) (“Mobile HTML5 compatibility on iPhone, Android, Windows Phone, BlackBerry, Firefox OS and other mobile devices,” n.d., p. 5)

20



33


Hierdoor kan gebruik gemaakt worden van GPS functies, offline functies en client-side databases (bv. SQLite) in een web applicatie. Deze trend zorgt ervoor dat de kloof tussen web applicaties en native applicaties, op gebied van functionaliteit, steeds kleiner wordt. Daarnaast heeft de ontwikkelaar in een web applicatie ook meer vrijheid wat betreft het design van de applicatie, doordat de design richtlijnen niet expliciet gevolgd moeten worden. Onderstaande figuur geeft de belangrijkste elementen van een HTML5 mobiele applicatie weer.

Afbeelding 16: Anatomie van een HTML5 applicatie

Zoals te zien is op de afbeelding, wordt een HTML5 applicatie opgebouwd aan de hand van drie componenten: HTML5, JavaScript en CSS. HTML is de codeertaal die de structuur van de applicatie bepaald. CSS zal de presentatie van de HTML-documenten beïnvloeden. In de afbeelding wordt hierbij verwezen naar de layout, typography, color… van de app. Met JavaScript wordt logica in de applicatie verwerkt. Hier zal bijvoorbeeld de GPS functie (location) en offline functie (offline storage) worden geïmplementeerd.



6.3

34


User interface

User interface en user experience worden vaak in één adem genoemd. Toch zijn het twee aparte zaken. Het ene kan echter wel gevolgen hebben voor het andere. Een goede user interface kan immers zorgen voor een betere user experience

6.3.1

Native applicaties

In een native applicatie worden bepaalde design richtlijnen en standaarden gevolgd die zorgen voor een herkenbare en eenduidige look-and-feel in de app. Voor elk van de drie platformen worden ontwikkelingstools voorzien waarin standaard user interface elementen (knoppen, tekst invoer velden, navigatiebalk, …) worden voorzien. Enkele gekende ontwikkelingstools voor native applicaties zijn: • • •

Android Studio (Android OS) Visual Studio (Windows Phone OS) Xcode (iOS)

Afbeelding 17: Ontwikkelingstools voor native applicaties

Deze programma’s voorzien de nodige functionaliteit om relatief snel en eenvoudig de layout van de schermen op te maken. Onderstaande afbeelding geeft de layout bewerker in Android Studio weer. In de tabel naast de weergave van het toestel staat een lijst met componenten die op het scherm gesleept en gepositioneerd kunnen worden.



35


Afbeelding 18: Android Studio, layout view

Hergebruik van standaard elementen zorgt dat de eindgebruiker intuïtiever met de applicatie interageert, waardoor men minder moet nadenken bij de handelingen. Hierdoor houdt men een beter gevoel over aan het gebruik. Onderstaande afbeelding geeft een voorbeeld van de iOS 7 standaard elementen. In de bijlagen vier en vijf zijn meer voorbeelden te vinden van design richtlijnen voor Android en iOS.

Afbeelding 19: iOS 7 UI Kit



36


Daarnaast kunnen ook unieke functies in de applicatie voorzien worden. Door gebruik te maken van de hardware componenten van het apparaat kan de app persoonlijker in interactie treden met de gebruiker. Bekende voorbeelden hiervan zijn de versnellingsmeter en de camera van de smartphone. De versnellingsmeter detecteert beweging, op die manier kan men de activiteit van de gebruiker meten of relevante push berichten sturen.

Afbeelding 20: Push bericht van de ‘life tracking’ app Breeze

Het nadeel van de functies en de design richtlijnen is andermaal dat ze platform-afhankelijk zijn. Dit impliceert dat, indien men de app in de drie stores wil publiceren, de applicatie driemaal op een verschillende manier gecodeerd moet worden. Dit vergt veel extra werkuren, en maakt dat de ontwikkelkosten hoog oplopen.

6.3.2

Web Applicaties

Een web applicatie is vaak de mobiele versie van een website, waarbij enkel de voornaamste zaken worden getoond. Hierbij worden de dimensies van de inhoud aangepast zodat ze in verhouding staan tot de grootte van het scherm. Een web applicatie wordt gebouwd in HTML, JavaScript en CSS en werkt met de mobiele browser van het systeem. Hierdoor is een web app platform-onafhanhankelijk. Er hoeft slechts één versie worden gemaakt voor de verschillende besturingssystemen. Dit is ongetwijfeld het belangrijkste pluspunt ten opzichte van native applicaties. De keerzijde van de medaille is echter dat rekening gehouden moet worden met de beperkingen van de browser. Dit betekent dat de hardware componenten van de smartphone niet kunnen worden aangesproken, waardoor minder functionaliteit kan worden geboden.



37


Onderstaande afbeelding geeft de ‘Zalando’ web applicatie weer op de drie eerder besproken platformen.

Afbeelding 21: Zalando web applicatie

Zoals te zien is op bovenstaande afbeelding, is de user interface driemaal identiek. Vaak wordt dit door de gebruiker als een negatief punt beschouwd, omdat de uniciteit van het platform ontbreekt. Een HTML5 applicatie kan in de meeste broncode-editors worden ontwikkeld en wordt vorm en functionaliteit gegeven door middel van CSS en JavaScript. Zoals te zien is in de grafiek op afbeelding 7 was JavaScript in het jaar 2015 de meest gebruikte codeertaal. Dit betekent dat veel ontwikkelaars vertrouwd zijn met de taal, waardoor het coderen van de app sneller gaat.


38


6.3.3


Native vs. web applicatie

Zoals af te leiden is uit 4.2.1 en 4.2.2 hebben beide manieren hun voor-en nadelen. Welke methode de beste oplossing blijkt, hangt steeds af van de applicatie die ontwikkeld moet worden. In tabel 1 werden reeds enkele belangrijke functionaliteiten opgelijst met de compatibiliteit per methode. Onderstaande tabel geeft overige verschillen weer, en het feit of dit als een voor-of nadeel kan worden beschouwd. Nadeel Voordeel Neutraal

Web applicatie

Native applicatie

Kosten

Lage kost, meteen crossplatform

Hoge kost, indien ontwikkeld wordt voor de 3 platformen

Code herbruikbaarheid / overdraagbaarheid

Platform-onafhankelijk, enkel rekening houden met browser compatibiliteit

Platform-afhankelijk

Toegang tot het apparaat

Geen SDK’s beschikbaar, slechts enkele API’s aanspreekbaar

Platform SDK’s geven volledige toegang tot de API’s en hardware van het toestel

UI consistentie

Geen standaard componenten, eigen implementaties / gebruik van frameworks

Platform voorziet standaard elementen voor een consistente look

Distributie

Geen app stores

Makkelijk vindbaar via app stores, maar impliceert distributiekosten

Performantie

Afhankelijk van de browsers en de netwerkconnectie

API’s en toegang tot hardware verbeteren de performantie

Inkomsten

Minder mogeljikheden, reclame

Meer mogelijkheden via app stores, maar gem. 30% distributiekosten

Tabel 2: Voor- en nadelen native vs. web applicaties

Het is dus zaak om de voordelen af te wegen tegen de nadelen en op die manier een beslissing te nemen. De infographic in bijlage 3 geeft een mooi overzicht van de factoren die de keuze voor een ontwikkelmethode kan beïnvloeden of in welke context een native of web applicatie beter geschikt is. 21 21

(“Responsive web design vs. mobile app development - TechRepublic,” n.d.)



39


Kritische reflectie

7

Het onderzoek is uiteraard niet waterdicht. Hoewel er alles aan gedaan werd om het onderzoek op een zo wetenschappelijk mogelijke manier uit te voeren, is het besef er dat een aantal factoren ervoor zorgen dat de conclusie steeds bespreekbaar zal zijn. Verder zijn er ook nog enkele beperkingen in het onderzoek die eveneens worden besproken.

7.1

Context van de applicatie

Zoals al vermeld werd in de uitwerking van het project, zal de context van de applicatie steeds een belangrijke rol spelen in de keuze voor een ontwikkelmanier. Enkele contextfactoren die die voorkeur kunnen beïnvloeden, en waardoor geen algemene sluitende conclusie kan worden gevormd zijn onder andere: • • • • • •

Beschikbaar budget Beschikbare tijd Nodige functionaliteit in de applicatie Doelpubliek Categorie waaronder de applicatie kan geplaatst worden …

Op basis van de context van het project kan één van de vermelde factoren voor de ene applicatie als voordeel beschouwd worden, terwijl het voor een andere applicatie eerder als nadeel zal beschouwd worden.

7.2

Beperkingen van het onderzoek

Een eerste beperking situeert zich in de onderzoeksmethode. Het onderzoek bestond uit het analyseren van bestaand materiaal en eigen ervaringen, opgedaan tijdens mijn stageperiode. In een ideaal scenario worden interviews afgenomen met ontwikkelaars en gebruikers van applicaties. Op deze manier zou de conclusie beter/meer gestaafd kunnen worden. Interviews werden echter niet afgenomen enerzijds door tijdsgebrek, anderzijds is het ook niet evident een statistisch relevant aantal ontwikkelaars en/of gebruikers te vinden. Het opstellen en afnemen van vraaglijsten vergt veel tijd, wat tijdens de stageperiode ontbrak. Een tweede, al zou ik het persoonlijk niet echt een beperking noemen, is het feit dat er geen bespreking van de apps per categorie of per project werd gedaan. Dit is namelijk een belangrijke factor bij de keuze voor een ontwikkelmanier, maar was in de beschikbare tijdspanne onbegonnen werk.



8

Conclusies

8.1

Algemeen besluit

40


Uit het vooronderzoek en de analyse bleek al gauw dat vaak dezelfde factoren als essentiële verschillen werden vermeld. Op basis van deze resultaten werd het onderzoeksveld afgebakend. Het onderzoek beperkte zich dus tot drie variabelen, waarbij de focus op de verschillen werd gelegd. Algemeen kan gesteld worden dat een native applicatie in elk opzicht een duurdere optie is dan een web applicatie. Hiervoor zijn enkele verklarende factoren die uitvoerig besproken werden in de oplossing van het onderzoek (zie 6.1). Zo zullen onder andere de distributiekosten en de verschillende besturingssystemen de prijs van een native applicatie doen aangroeien. Anderzijds kan met een native app wel op een eenvoudigere manier inkomsten worden verworven en zijn ze hierdoor ook beter vindbaar dan een web app. Op basis van deze bevindingen kan dus gesteld worden dat het beschikbare budget een bepalende factor zal zijn voor de keuze een native of web applicatie te ontwikkelen. Een tweede conclusie van het onderzoek is dat voor een native applicatie meer functionaliteit voor handen is dan in een web applicatie. De beschikbare SDK’s voor de drie besproken platformen helpen de ontwikkelaar om op een relatief eenvoudige manier, de hardware componenten van het mobiele toestel aan te spreken. Zo kunnen bepaalde functies in de applicatie worden verwerkt, die een persoonlijkere ervaring voor de eindgebruiker bieden. Dergelijke functionaliteit is echter niet steeds noodzakelijk, waardoor een web applicatie een waardig alternatief kan zijn. Er moet dus opnieuw rekening gehouden worden met de context van de applicatie en de gewenste functie. Een derde en laatste conclusie heeft betrekking op de user interface van de applicaties. Voor het ontwikkelen van een native applicatie zijn enkele ontwikkelingstools voor handen die de opmaak van de verschillende schermen een stuk vereenvoudigen. De ontwikkelingstools bevatten kenmerkende user interface componenten die zorgen voor een unieke gebruikerservaring per platform. Deze componenten in combinatie met design richtlijnen, beperken echter wel de vrijheid van de designer/ontwikkelaar. Aan de andere kant biedt het minder ervaren ontwikkelaars een ruggengraat om gebruiksvriendelijke apps te bouwen. In een web applicatie heeft men op vlak van user interface design alles zelf in handen. Er moet enkel rekening gehouden worden met de eventuele beperkingen van de browsers. Dit biedt meer kansen om bijvoorbeeld de branding van een bedrijf of winkelketen in de applicatie te verwerken. Een web app zal op elk platform hetzelfde uitzicht krijgen, wat door sommige gebruikers als negatief wordt beoordeels. Een afweging van de voor- en nadelen zal voor elke applicatie een ander resultaat opleveren. Een eenduidig standpunten innemen is dus niet mogelijk. De ontwikkelaar zal steeds de context van de te ontwikkelen applicatie moeten bekijken.



8.2

41


Persoonlijk besluit

Het doel van deze bachelorproef was de verschillen onderzoeken tussen native en web applicaties en een beter inzicht krijgen in beide ontwikkelmethodes. Dit lijkt mij een fundamenteel punt voor een ontwikkelaar van mobiele applicaties. Mijn studietraject en stage werd samengesteld met de ambitie om in de toekomst zelf mobiele apps te ontwikkelen. Dit onderzoek heeft mij, als junior developer, een betere visie gegeven op beide methodes. Tijdens mijn studies NMCT kreeg ik reeds de mogelijkheid om met beide ontwikkelmanieren te experimenteren. Ik kon echter moeilijk een oordeel vellen welke manier het meest toekomstperspectief of kansen biedt. Een sluitende conclusie kan echter niet gevormd worden, zonder de context waarin de applicatie zich bevindt grondig te bestuderen.



9

42


Afbeeldingen-en tabellenlijst • Afbeeldingen: o

Afbeelding 1: Logo TapCrowd N.V.

o Afbeelding 2: Best betalende iOS Applicaties o

Afbeelding 3: Functionaliteiten van een applicatie (“Finest Studios - Responsive Websites, E-shops, Mobile apps, SEO, Video Production,” n.d.)

o

Afbeelding 4: 6 redenen om te investeren in mobiele gebruiksvriendelijkheid (“Infographics & blog images op Pinterest,” n.d.)

o

Afbeelding 5: User interface, native vs. web applicatie (“Native App vs. Mobile Web App: A Quick Comparison,” n.d.)

o

Afbeelding 6: Vingerafdrukscanner bij Apple (“A Fingerprint Sensor: Why Motorola Failed and Apple Won’t (AAPL),” n.d.)

o

Afbeelding 7: User interface – Remedi

o

Afbeelding 8: User interface – Geofeelings (Desktop en mobiel)

o

Afbeelding 9: TapCrowd platform (“TapCrowd - How it works - TapCrowd,” n.d.)

o

Afbeelding 10: Interface ‘Find my car’ module

o

Afbeelding 11: Gebruik van tabs op het TapCrowd platform

o

Afbeelding 12: Apple App Store, Google Play Store en Windows Phone Store

o

Afbeelding 13: Inkomsten en verdiensten via Apple’s App Store (“HTML5 vs Native Mobile App Development: Which option is best?,” n.d.)

o

Afbeelding 14: Top 10 meest gebruikte codeertalen tussen 2013 en 2015 (“Ten charts that paint a fascinating portrait of the modern-day programmer Quartz,” n.d.)

o

Afbeelding 15: SDK’s per platform



o

43


Afbeelding 16: Anatomie van een HTML5 applicatie (“When to make Mobile Native Application or Web Application | WebDesignerGeeks - Web Designer, Web Developer blog,” n.d.)

o

Afbeelding 17: Ontwikkelingstools voor native applicaties

o

Afbeelding 18: Android Studio, layout view (“Basic information about project structure and Android Studio interface | Android4Beginners.com,” n.d.)

o

Afbeelding 19: iOS 7 UI Kit (“Download iOS7 UI Kit PSD on Behance,” n.d.)

o

Afbeelding 20: Push bericht van de ‘life tracking’ app Breeze (“RunKeeper launches ‘life tracking’ app Breeze to make Fitbit irrelevant | BetaBoston,” n.d.)

o

Afbeelding 21: Zalando web applicatie

• Tabellen en grafieken: o

Grafiek 1: Aantal smartphone gebruikers wereldwijd van 2013 tot 2019

o

Tabel 1: Overzicht belangrijkste functionaliteiten per platform

o

Tabel 2: Voor- en nadelen native vs. web applicaties



10

44


Bronnen- & literatuurlijst

•

30 UX Statistics You Should Not Ignore! [INFOGRAPHIC] | Experience Dynamics. (n.d.). Retrieved February 5, 2016, from https://www.experiencedynamics.com/blog/2015/03/30-ux-statistics-you-shouldnot-ignore-infographic

•

A Fingerprint Sensor: Why Motorola Failed and Apple Won’t (AAPL). (n.d.). Retrieved February 24, 2016, from http://www.fool.com/investing/general/2013/09/15/a-fingerprint-sensor-whymotorola-failed-and-apple.aspx

•

Android SDK: Which Version to Use and Why - LearnComputer. (n.d.). Retrieved February 7, 2016, from http://www.learncomputer.com/android-sdk-which-versionto-use/

•

Basic information about project structure and Android Studio interface | Android4Beginners.com. (n.d.). Retrieved February 7, 2016, from http://android4beginners.com/2013/06/lesson-0-4-basic-information-aboutstructure-of-a-project-and-android-studio-interface-what-is-what/

•

Can I use... Support tables for HTML5, CSS3, etc. (n.d.). Retrieved February 23, 2016, from http://caniuse.com/#search=camera

•

De kosten van een app laten maken? Zie wat andere apps hebben gekost: van € 2.500 tot € 100.000+ | Appspecialisten.nl. (n.d.). Retrieved February 4, 2016, from https://www.appspecialisten.nl/kennisbank/de-kosten-van-een-app-laten-makenzie-wat-andere-apps-hebben-gekost-van-%E2%82%AC-2500-tot-%E2%82%AC

•

Design | Android Developers. (n.d.). Retrieved February 12, 2016, from http://developer.android.com/design/index.html

•

Developing for Multi-Touch Web Browsers - HTML5 Rocks. (n.d.). Retrieved February 6, 2016, from http://www.html5rocks.com/en/mobile/touch/

•

De web app versus de native app | Apps Ontwikkelaars. (n.d.). Retrieved February 2, 2016, from https://www.apps-ontwikkelaars.nl/web-app-versus-native-app/

•

Download iOS7 UI Kit PSD on Behance. (n.d.). Retrieved February 7, 2016, from https://www.behance.net/gallery/Download-iOS7-UI-Kit-PSD/9301119

•

European Commission - PRESS RELEASES - Press release - Antitrust: Commissie verbiedt multilaterale afwikkelingsvergoedingen MasterCard in EER. (n.d.). Retrieved February 7, 2016, from http://europa.eu/rapid/press-release_IP-071959_nl.htm

•

Finest Studios - Responsive Websites, E-shops, Mobile apps, SEO, Video Production. (n.d.). Retrieved February 4, 2016, from http://fineststudios.eu/services.php



45


•

Gentse TapCrowd overgenomen door Amerikaanse event management specialist etouches - Technologie - DataNews - Knack.be - Data News.be. (n.d.). Retrieved February 8, 2016, from http://datanews.knack.be/ict/gentse-tapcrowdovergenomen-door-amerikaanse-event-management-specialist-etouches/articlenormal-587055.html

•

Hoeveel kost een app? - ITNEXT. (n.d.). Retrieved February 4, 2016, from http://www.itnext.nl/hoeveel-kost-een-app/

•

How Do Native Apps and Web Apps Compare? - Webmonkey. (n.d.). Retrieved February 6, 2016, from http://www.webmonkey.com/2010/08/how-do-native-appsand-web-apps-compare/

•

How Much to Make an App. (n.d.). Retrieved February 6, 2016, from http://howmuchtomakeanapp.com/

•

HTML5 vs Native Mobile App Development: Which option is best? (n.d.). Retrieved February 5, 2016, from http://www.slideshare.net/appcelerator/appceleratorhtml5-prezfinal/6-accounts_tied_to_credit_cards

•

Infographics & blog images op Pinterest. (n.d.). Retrieved February 5, 2016, from https://www.pinterest.com/pin/370702613054979076/

•

Kosten Website: Waarom is Maatwerk zo Kostbaar? - Mediaweb. (n.d.). Retrieved February 24, 2016, from https://mediaweb.nl/blog/kosten-website/

•

Mobiel internetgebruik in België anno 2015 - Blog | Wijs. (n.d.). Retrieved February 2, 2016, from https://wijs.be/nl/trends-inzichten/blog/detail/mobielinternetgebruik-in-belgie-anno-2015

•

Mobile HTML5 compatibility on iPhone, Android, Windows Phone, BlackBerry, Firefox OS and other mobile devices. (n.d.). Retrieved February 6, 2016, from http://mobilehtml5.org/

•

Mobile Internet Usage Skyrockets in Past 4 Years to Overtake Desktop as Most Used Digital Platform - comScore, Inc. (n.d.). Retrieved February 2, 2016, from https://www.comscore.com/Insights/Blog/Mobile-Internet-Usage-Skyrockets-inPast-4-Years-to-Overtake-Desktop-as-Most-Used-Digital-Platform

•

Mobile phone users worldwide 2013-2019 | Statistic. (n.d.). Retrieved February 3, 2016, from http://www.statista.com/statistics/274774/forecast-of-mobile-phoneusers-worldwide/

•

Native app of web app? - Blog | Wijs. (n.d.). Retrieved February 2, 2016, from https://wijs.be/nl/trends-inzichten/blog/detail/native-app-of-web-app

•

Native App vs. Mobile Web App: A Quick Comparison. (n.d.). Retrieved February 5, 2016, from http://sixrevisions.com/mobile/native-app-vs-mobile-web-appcomparison/



46


•

Navigation drawer - Patterns - Google design guidelines. (n.d.). Retrieved February 12, 2016, from https://www.google.com/design/spec/patterns/navigationdrawer.html#

•

Number of mobile app downloads 2009-2017 | Statistic. (n.d.). Retrieved February 4, 2016, from http://www.statista.com/statistics/266488/forecast-of-mobile-appdownloads/

•

Responsive web design vs. mobile app development - TechRepublic. (n.d.). Retrieved February 2, 2016, from http://www.techrepublic.com/blog/webdesigner/responsive-web-design-vs-mobile-app-development/

•

RunKeeper launches “life tracking” app Breeze to make Fitbit irrelevant | BetaBoston. (n.d.). Retrieved February 7, 2016, from http://www.betaboston.com/news/2014/04/17/runkeeper-breeze-step-trackerapp-fitbit-jawbone-alternative-mobile/

•

TapCrowd - How it works - TapCrowd. (n.d.). Retrieved February 17, 2016, from http://tapcrowd.com/how-it-works/

•

Ten charts that paint a fascinating portrait of the modern-day programmer - Quartz. (n.d.). Retrieved February 7, 2016, from http://qz.com/381403/ten-charts-thatpaint-a-fascinating-portrait-of-the-modern-day-programmer/

•

User interface design | Conceptlicious. (n.d.). Retrieved February 5, 2016, from http://conceptlicious.nl/user-interface-design/

•

Web- of native app ontwikkelen? - Emerce. (n.d.). Retrieved February 2, 2016, from http://www.emerce.nl/achtergrond/web-app-native-app-ontwikkelen

•

What is a Native Mobile App? - Definition from Techopedia. (n.d.). Retrieved February 4, 2016, from https://www.techopedia.com/definition/27568/nativemobile-app

•

When to make Mobile Native Application or Web Application | WebDesignerGeeks - Web Designer, Web Developer blog. (n.d.). Retrieved February 6, 2016, from http://webdesignergeeks.com/mobile/windows-phone/when-to-make-mobilenative-application-or-web-application/



11

47


Overzicht van de bijlagen

•

Bijlage 1: Infographic, kosten van een applicatie

•

Bijlage 2: Infographic, het belang van een goede user interface

•

Bijlage 3: Infographic, keuze maken voor een web of native app

•

Bijlage 4: Design templates voor Android

•

Bijlage 5: Design templates voor iOS

•

Bijlage 6: Screenshots - Remedi

•

Bijlage 7: Screenshots - Geofeelings


Bijlage 1: Infographic, kosten van een applicatie


Bijlage 2: Infographic, het belang van een goede user interface


Bijlage 3: Infographic, keuze maken voor een web of native app


Bijlage 4: Design templates voor Android


Design templates voor Android


Design templates Android


Design templates Android


Design templates voor Android


Bijlage 5: Design templates voor iOS


Design templates voor iOS






Bijlage 6: Screenshots - Remedi


Bijlage 7: Screenshots - Geofeelings


Screenshots Geofeelings


GET THE MOST OUT OF YOUR APP WEB VS. NATIVE

Recommend Documents