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/

Advertenties

10 thoughts on “Vergelijkingscriteria

  1. Het punt ‘gemeenschap’ vind ik interessant. Tellen jullie dit handmatig? Of hebben jullie hier een plug-in voor gevonden/geschreven? Zodat het mogelijk is dit automatisch te tellen? Op deze manier zouden jullie dan een overzicht kunnen geven hoe de populariteit varieert over de tijd.

    • Ivm het tellen kunnen we gewoon rechtsbovenaan kijken op bijvoorbeeld https://github.com/jquery/jquery-mobile. Misschien kunnen we inderdaad een script schrijven dat alle data verzamelt.
      Ivm de populariteit dachten we te kijken naar Google Trends. Als je daar de naam van een raamwerk invult, krijg je een grafiek te zien. Als er zich pieken vertonen, zet Google er al automatisch bij waarom (meestal is dit door het uitbrengen van een nieuwe versie). Ook is het mogelijk om meerdere raamwerken op te geven, waardoor je hun populariteit onderling kan vergelijken.

  2. “De som van volgers, watchers en likes vormt de score voor het gemeenschapscriteria.”
    Dit vind ik zonder meer een gevaarlijke formule voor het meten van populariteit. Veel developers zijn op meerdere van die sites en je gaat wellicht heel veel stemmen dubbel tellen en dit zal een vertekend beeld geven van de realiteit.
    Google Trends is een interessante piste maar ook daar lijken mij intuïtief addertjes onder het gras te zitten. Persoonlijk ga ik bijvoorbeeld enkel op Google op zoek als ik iets niet vind in de documentatie. Een goed gedocumenteerd maar populair framework kan dus potentieel minder scoren dan een slecht gedocumenteerd framework.

    Wat productiviteit betreft ben ik akkoord dat het aantal uren werk een goede maatstaf is maar de productiviteit is ook sterk afhankelijk van de achtergrond, ervaring van de programmeur en kennis van het framework. Misschien jullie eigen achtergrond hiervoor vermelden?

    De categorie “gebruik” mist nog een belangrijk aspect, vind ik. Niet alleen is het belangrijk om te weten hoe volledig een framework is. Het is ook belangrijk om te weten hoe makkelijk het integreert met andere libraries en frameworks. Ik zou dat aspect aan deze categorie toevoegen en misschien voor een andere benaming gaan als “volledigheid en compatibiliteit”. “Gebruik” klinkt nogal vaag…

    “Ook bekijken we of de native look-and-feel per besturingssysteem door het raamwerk kan worden benaderd.”
    Veel frameworks proberen de native look en feel na te bootsen en falen hier in (het lukt niet of het framework verliest veel aan performance). De mobile community is er ook nog niet helemaal uit of het nabootsen van native L&F echt wel een goede zaak is (omdat het dus niet lukt). Als je dit als argument wil gebruiken, lijkt het me een goede zaak om eerst grondig te onderzoeken of dit effectief een goed idee is. Nogal wat mensen beweren dat HTML-interfaces hun eigen UI moeten hebben (referentie ontgaat me even) die niet noodzakelijk overeenstemt net de native L&F. Het lijkt me het onderzoeken waard maar misschien valt dit onderzoek buiten de scope van ons onderwerp.

    “Daarnaast zullen we een geïsoleerde test doen met het verzenden van een AJAX request, omdat sommige raamwerken altijd eerst een OPTION request sturen.”
    Dit is niet helemaal waar. Het pre-flighten van requests volgens de CORS specificatie is browser-specific en niet framework-specific. Ik vraag me wel af of een rendertest ook effectief het framework test en niet enkel de render capabilities van de browser. Ik zou voor deze test misschien eerder kijken naar de voor-/nadelen van static elementen (interface via HTML in jQuery) versus dynamic (interface via JS in Sencha) en dit bestuderen in de afwezigheid van een CSS.

    Dat zijn mijn bedenkingen. Just thinking out loud.

    • 1) Die laatste zin is zeker waar en daar hadden we ook al over nagedacht. De score blijft natuurlijk een indicatie. Enkele recente werken zoals HTML5 and JavaScript Web Apps en http://monocaffe.blogspot.be/2012/06/mobile-frameworks-comparison.html gebruikten al deze criteria.

      2) Dat zullen we zeker vermelden bij de verklaring van onze uren. Ook dachten we aan de volledige programmeeromgeving zoals bv. welke tools we hebben gebruikt die mogelijk een snelheidswinst/verlies verklaren.

      3) We hebben inderdaad op dat vlak ook andere criteria overwogen zoals bv. ik heb een bestaande app, hoeveel code kan ik hergebruiken om over te schakelen naar dat framework. Misschien moeten we dit nog eens herbekijken.

      4) Zeker een interessante discussie waar ik ook geïnteresseerd in ben. Het was vooral omdat deze feature uit de interviews met Capgemini naar voor kwam.

      5) Dat statement kwam vooral uit de ervaring met de frameworks zelf. Sencha Touch stuurde overal preflights, terwijl jQuery deze enkel stuurde conform met http://www.w3.org/TR/cors/. Maar inderdaad, we zullen dit eens herbekijken net zoals je laatst aangehaald punt.

      Bedankt voor de bedenkingen!

  3. Misschien ook de moeite om expliciet aan te geven welke van jullie criteria je ook waar in de literatuur terugvindt?

  4. Ik kan me zeer goed vinden in deze vergelijkingscriteria en ik vind het een goed om slechts 5 criteria te hanteren, maar ze wel redelijk breed te bekijken zoals jullie gaan doen.

    Zijn jullie ook van plan om iets te zeggen over plugins die jullie eventueel gebruikt hebben? Ik kan me voorstellen dat het gebruik van plugins in een framework een invloed heeft op jullie conclusies op vlak van bijvoorbeeld productiviteit en gebruik (en misschien zelfs ondersteuning en performantie).

    Conclusie: zeer goede post, duidelijke uitleg en goed gefundeerd, zoals we gewoon zijn van jullie!

    • Bedankt voor de feedback!

      Ivm de plugins, we zullen zeker enkele vermelden onder het puntje ‘gebruik’. Om sommige features van de POC te implementeren, zoals bijvoorbeeld de handtekening zetten, heb je plugins nodig. We zullen dan zeker vermelden dat eerst en vooral zo’n plugin beschikbaar is en of zo’n plugin makkelijk te gebruiken is om het framework uit te breiden.

      Bedankt!

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s