Inhoudstafel en thesistitel

Hieronder kan je de inhoudstafel van onze thesistekst vinden. Momenteel zijn we hoofdstuk 2 (literatuurstudie) aan het herschrijven en hoofdstuk 3 (raamwerken) en 4 (vergelijking) aan het aanvullen. We hopen een draft van deze 3 hoofdstukken aan het einde van deze week naar onze begeleider en Capgemini te kunnen doorsturen.

  • Voorwoord
  • Samenvatting
  • Lijst van figuren
  • Lijst van tabellen
  • Lijst van afkortingen
  • 1 Inleiding
  • 2 Literatuurstudie
    • 2.1 Mobiele apparaten
    • 2.2 Mobiele besturingssystemen
    • 2.3 Mobiele applicaties
    • 2.4 Mobiele webbrowsers
    • 2.5 HTML5, CSS3 en JavaScript
    • 2.6 Mobiele HTML5 raamwerken
    • 2.7 Vergelijken van raamwerken
  • 3 Mobiele HTML5 raamwerken
    • 3.1 jQuery Mobile
    • 3.2 Sencha Touch
    • 3.3 Kendo UI
    • 3.4 Lungo
    • 3.5 Overzicht
  • 4 Vergelijking
    • 4.1 POC
    • 4.2 Vergelijkingscriteria
  • 5 Evaluatie
    • 5.1 Omkadering
    • 5.2 Productiviteit
    • 5.3 Gebruik
    • 5.4 Ondersteuning
    • 5.5 Performantie
  • 6 Besluit
  • Bibliografie

Onze thesistitel is ook gefinaliseerd.
Nederlands:

Vergelijkende studie van raamwerken voor de ontwikkeling van mobiele HTML5-applicaties

Engels:

Comparative study of frameworks for the development of mobile HTML5 applications

Vergelijkingscriteria

De titel van onze thesis bestaat uit twee delen: ‘Comparative study of frameworks’ en ‘for the development of mobile HTML5 applications’. Aan beide moet evenveel aandacht worden besteed, dus concentreerden we ons nu eens op het eerste deel: hoe gaan we de mobiele HTML5 raamwerken vergelijken.

Na veel opzoekwerk en lange discussies hebben we samen beslist aan welke criteria we het best de raamwerken onderwerpen om een zo goed mogelijke vergelijking te maken. We bedachten 5 categorieën: gemeenschap, productiviteit, gebruik, ondersteuning en performantie. Elk raamwerk krijgt voor elke criteria een score. Als besluit zullen we een ‘spiderweb’ van de criteria creëren waar de scores van de raamwerken opstaan. Hoe we deze criteria exact zullen onderzoeken wordt in onderstaande secties uitgelegd.

Echter, alle verschillen tussen de raamwerken zijn niet volledig in deze 5 criteria onder te brengen. Sommige eigenschappen van het raamwerk staan reeds in onze literatuurstudie vermeld. We hebben besloten om deze informatie niet te dupliceren in deze sectie. Deze criteria bevatten:

  • Het bedrijf dat het raamwerk aanbiedt
  • De marktadoptatie van het raamwerk (belangrijkste klanten)
  • De licenties en kosten die samen gaan bij het gebruik van het raamwerk
  • Betalende probleemoplossingen (professionele ondersteuning)
  • De laatste nieuwe versie van het raamwerk
  • De documentatie, handleidingen en voorbeelden die voorhanden zijn
  • Bibliotheken waar het raamwerk op steunt
  • De tools die de programmeur kan gebruiken om sneller te ontwikkelen

Wel zullen we proberen één grote vergelijkingstabel te maken als appendix die alle verschillen, dus ook de hier voornoemde, zal bevatten.

Gemeenschap

De gemeenschap en populariteit van een raamwerk is makkelijk in cijfers uit te drukken. We voorzien een tabel waar we per raamwerk het aantal volgers op Twitter, watchers/forkers van GitHub en aantal likes van Facebook zullen onderbrengen [1;2]. Een grafiek van Google Trends, die het zoekvolume op Google uitzet per tijd, zal voor elk raamwerk na deze tabel worden toegevoegd.
De som van volgers, watchers en likes vormt de score voor het gemeenschapscriteria.

Productiviteit

De productiviteit moet een indicatie geven hoe lang het duurt om met het raamwerk vertrouwd te raken. Hiervoor gaan we het feit uitbuiten dat we deze thesis met twee maken. Elk zullen we de proof-of-concept (POC) in twee verschillende raamwerken maken wat het totaal op 4 raamwerken brengt. De tijd die nodig is om de volledige POC te implementeren is een indicatie voor de productiviteit. Ook zal elk van ons een loginscherm maken in de andere twee raamwerken [3]. Als Tim de POC implementeert in raamwerken A en B en Sander in raamwerken C en D, zal dus Tim ook een loginscherm maken in raamwerken C en D en vice versa.  Dit scherm bevat UI-elementen, validaties en backend integratie. We kunnen dit dus als voldoende steekproef beschouwen om ervaring met een raamwerk te testen. De tijd die ieder nodig heeft om dit scherm te bouwen, geeft ook een indicatie van de nodige leertijd.
De som van de uren voor het implementeren van de POC en het loginscherm vormt de score voor de productiviteit.

Gebruik

Om het verschil in gebruik van de raamwerken te onderzoeken, zullen we steunen op de logboeken die we hebben bijgehouden tijdens het implementeren van de POC. We gaan er vanuit dat de POC relevante kenmerken bevat om de raamwerken zoveel mogelijk uit te buiten. We zullen bij het vergelijken de moeilijkheden groeperen zodat het snel duidelijk wordt welke functionaliteit in een bepaald raamwerk moeilijker/makkelijker te implementeren is. Een hogere score wordt toegekend wanneer bepaalde functionaliteit reeds aangeboden wordt door het raamwerk. Een lagere score betekent dat een plugin werd gezocht. Wanneer een hack noodzakelijk was om de functionaliteit te beogen, zal de laagste score worden toegekend.

Ondersteuning

We zullen een scenario uitwerken waarbij we het gebruik van de POC doorlopen. Dit scenario zullen we op een reeks van verschillende mobiele apparaten herhalen [1]. Bij het mislukken van een stap in het scenario, zal een punt worden afgetrokken. Hierdoor kunnen we een score bekomen hoe goed de applicatie, geïmplementeerd in een bepaald raamwerk, scoort op een bepaald apparaat. De gebruikte apparaten en versies van besturingssystemen en browsers zullen worden bepaald aan de hand van de marktaandeel en de beschikbaarheid van deze apparaten aan het departement HCI.
Een kanttekening hierbij is of het raamwerk ondersteunt de webapplicatie om te vormen tot een native applicatie. Ook bekijken we of de native look-and-feel per besturingssysteem door het raamwerk kan worden benaderd.

Performantie

Een laatste criterium is de performantie. Dit zal worden uitgedrukt in de tijd nodig om te applicatie te renderen. Hierbij zullen we verschillende testen doen. Ten eerste zullen we gebruik maken van de volledige POC. We zullen kijken naar de rendertijd van de applicatie aan de hand van Google Page Speed [4]. Daarnaast zullen we een geïsoleerde test doen met het verzenden van een AJAX request, omdat sommige raamwerken altijd eerst een OPTION request sturen. Verdergaand op het versturen van requests zullen we kijken hoe lang het duurt vooraleer een expense daadwerkelijk verzonden is naar de backend. Vervolgens zullen we ook geïsoleerde testen doen met UI-elementen. Hierbij zullen we een pagina voorzien van 1000 buttons en meten hoe lang het duurt tot deze pagina gerendert wordt. Als laatste zullen we een test op de aparte loginschermen uitvoeren. Hier kunnen we dan ook het aantal lijnen code bekijken en de bijhorende performantie. De redenen waarom we ook deze geïsoleerde applicatie gebruiken is omdat we ervan uitgaan dat niet de volledige POC in ieder raamwerk zal kunnen worden geïmplementeerd. Dit is in tegenstelling tot de geïsoleerde login applicatie, waarbij we exact kunnen vergelijken.

—–

Referenties

[1] Sarrafi, A. (2012). Mobile JavaScript frameworks, Evaluation and Comparison. Codefessions. Retrieved February 19, 2013, from http://www.codefessions.com/2012/04/mobile-javascript-frameworks-evaluation.html

[2]Ayuso, A. (2012). Mobile Frameworks Comparison. Monocaffe. Retrieved February 19, 2013, from http://monocaffe.blogspot.be/2012/06/mobile-frameworks-comparison.html

[3]Burris, C. (2012). Sencha Touch vs. JQuery Mobile Cage-Fight REMATCH ! Retrieved February 19, 2013, from http://stvjqm.mobivant.com/presentations/svj/

[4] Morgan, J. (2011). How to Measure Website Performance with Three Free Tools. Retrieved February 19, 2013, from http://usabilityetc.com/2011/08/measure-website-performance-with-free-tools/

Planning

We hebben na de meeting met onze begeleider een volledige planning uitgewerkt. We konden gebruik maken van de reeds gewerkte uren om correcte schattingen te maken. Hieronder kan je de planning bekijken. Deze planning geldt per persoon. Dit betekent dus 2 frameworks elk, wat het totaal brengt op 4 frameworks die we gaan vergelijken.

Planning thesis

Met deze planning kunnen we dus in totaal 4 mobiele HTML5 frameworks vergelijken. Jammer genoeg zien we geen mogelijkheid om 5 of 6 frameworks te vergelijken. Hieronder volgt de Gantt-grafiek die onze planning nog concreter maakt.

Planning Thesis

Update week 8

Na onze deadline van 4 november zijn we begonnen met de implementatie van de POC. Afgelopen weekend werd ook de backend vrijgegeven zodat onze POC ook echt functioneel zal kunnen werken. Tijdens de implementatie zullen we een logboek bijhouden welke problemen we hebben tegengekomen en hoe we die concreet hebben aangepakt. Deze logboeken kunnen op de volgende links worden bekeken:

Daarnaast kan de code bekeken worden op GitHub op de volgende link: http://tinyurl.com/HTMobieL

Update week 6

Na onze conference call op donderdag, hebben we de voorgestelde POC (over het delen van documenten) herbekeken.

We kwamen er achter dat deze POC niet de kern van onze thesis bevat, namelijk het vergelijken van HTML5 frameworks die hoofdzakelijk bestaan ​​uit UI-elementen.

We hebben wat onderzoek gedaan over de haalbaarheid van het huidige voorstel voor de POC. We vonden dat zowel de toegang tot de camera en het bestandssysteem in  HTML5 nog niet overal wordt ondersteund. Push notificaties via Web Sockets ligt ergens in het midden:

We zouden daarom graag een app hebben die de volgende dingen bevat:

  • form elements (zoals date pickers)
  • form validation
  • lay-out
    • responsive design
    • pagina’s (header, content en footer)
    • dialogs
    • navigatie en menu’s
    • tooltips, meldingen, …
  • werkbalken, knoppen, icoontjes
  • canvas en afbeeldingen (zoals taartdiagrammen)
  • beeld, video en audio

Daarnaast zijn we nu ook bezig met het schrijven van onze literatuurstudie. We hebben ook een geraamte opgesteld hoe we beide ons framework in de tekst zullen voorstellen, zodat we eenzelfde structuur hebben en toch apart kunnen schrijven.

Dankzij de interviews zullen we ook zeker aandacht besteden aan de volgende puntjes die belangrijk zijn bij de keuze van een framework, met name:

  • marktadoptie: wie gebruikt het al?
  • toekomstgericht: welk bedrijf zit er achter het framework?
  • support: een bug moet snel kunnen worden opgelost
  • aanpasbaarheid: hoe gemakkelijk kan je componenten aanpassen/toevoegen?
  • ondersteuning voor devices: enkel onderseuting voor iOS en Android of ook andere platformen?
  • performantie: performantie kan bijvoorveeld verschillen tussen de platformen onderling
  • documentatie: bijvoorbeeld liefst voorbeeldcode in de documentatie
  • tools: goede tools die onder andere code completion voorzien

HTML5 features

Voor onze Proof-of-Concept is het belangrijk dat zoveel mogelijk features van HTML5 benut worden.  Hieronder volgen de 8 belangrijkste focuspunten die HTML5 beoogt:

  • Multimedia:  de nieuwe video en audio tags maken het mogelijk audio- en geluidsfragmenten te embedden zonder third party plugins.  De noodzaak van de Flash plugin voor video applicaties wordt vaak in vraag gesteld.
  • Offline & Storage:  Mobiele devices en hun onstabiele connectiviteit in acht genomen voorziet HTML5 offline opslag in de cache (in plaats van cookies),  lokale opslag in de browser en een file API om bestanden te manipuleren.
  • Performance & Integration:  Web workers maken het mogelijk om langdurige Javascript taken in de achtergrond uit te voeren zodat web applicaties dynamische en snel blijven.
  • Semantics:  Een hele hoop nieuwe tags verzorgen meer semantiek binnen webpagina’s.  Ze zorgen voor een gebruiksvriendelijke aanpak voor zowel programeur als gebruiker.  Het gebruik van e-readers en search engine optimization zijn daarbij twee belangrijke factoren.
  • CSS3:  Hand-in-hand met HTML5 laat het toe pagina’s meer op te maken en uit te breiden met effecten.  Verschillende formaten van mobiele devices en een dynamische oriëntatie verplichten ook het dynamisch layouten van webpagina’s.
  • 3D,  Graphics & Effects:  De nieuwe canvas tag in samenwerking met enkele lijnen Javascript blijkt enorm krachtig.  Tekeningen en animaties waren nog nooit zo simpel zelf te programmeren.
  • Connectivity:  Web sockets en server-side events kunnen data naar clients pushen om een meer efficientere connectiviteit te garanderen.
  • Device Access: Webapplicaties kunnen meer en meer device-aware features benutten zoals native applicaties dat kunnen.  Het beste voorbeeld momenteel is de Geolocation API die je huidige locatie kan achterhalen met behulp van de ingebouwde GPS.

——

Reference

[1]: HTML5:  the missing manual,  Matthew MacDonald, 2011
[2]: HTML5 Poster