Volgens Gartner 43 is er meer en meer behoefte aan web-applicaties met
een Web Meets Native functionaliteit. Kortgezegd: applicaties die draaien in de browser, waarbij functionaliteit buiten de sandbox van de browser ook gebruikt kan worden. Hierbij valt te denken aan bepaalde hardwarespecifieke eigenschappen als de camera, motion sensor of acccelaratiemeter van een apparaat.
Voor mijn applicatie raad ik sterk aan om te starten met hybrid applicaties in een native container. Groot voordeel van deze manier van werken is dat er minder specifieke coding per platform hoeft plaats te vinden. Door middel van frameworks als PhoneGap 44en Titanium 45 is het mogelijk om eenmalig de applicatie op te zetten, waarna het framework zorgt voor de implementatie per mobiel besturingssysteem.
Dit betekent kortgezegd dat de applicatie in de verschillende
applicatiemarkten kan worden gezet, maar dat de content via HTML / CSS en JavaScript wordt binnengehaald. Voordelen van hybride applicaties zijn dat alle functies van het apparaat kan aanspreken, de applicatie ook offline gebruikt kan worden en de meeste techniek al bekend is bij developers (html / css / javascript). Dit zorgt voor een kortere ontwikkelingstijd en een bredere markt, aangezien er niet per mobiel besturingssysteem hoeft te worden geprogrammeerd, maar alles via één universele applicatie wordt getransformeerd tot native containers per besturingssysteem.
Voor het verbinden met een server (van de applicatie) kan er bij PhoneGap gebruikt gemaakt worden van diverse netwerkprotocollen (bijv.
XmlHTTPRequest en Web Sockets) om makkelijk te communiceren met
allerhande backend services.
Alle functionaliteit die de applicatie nodig heeft, zoals bestandsmanagement, netwerkfunctionaliteit, GPS, contacten en notificaties kan worden opgelost met PhoneGap.
43 Smith, David Mitchell. Web meets native: Beyond hybrid. Gartner, 15 augustus 2010. 3 mei 2013. <http://bokeh.gerardkleinedeters.nl/onderzoek/bijlagen.zip> 44 PhoneGap. Adobe Systems Inc. 2013. 12 april 2013. <http://www.phonegap.com>
Wireframes
De wireframes zijn bedoeld om inzicht te krijgen in de plaatsing van functionaliteit en het aanbrengen van de logica achter de applicatie.
In de concurrentieanalyse 46 zijn een aantal concurrenten bekeken. Grofweg
hebben deze applicaties min of meer de volgende opbouw:
Rood staat voor identiteit van de maker, geel voor de content, groen voor
opties om content te manipuleren (van filters tot menu’s en tabbladen) en blauw staat voor opties met betrekking tot het manipuleren van het gebruikersprofiel (accountopties, uitloggen, etcetera). Deze opbouw zie je bijvoorbeeld ook terugkomen in de verschillende webapplicaties van Google. Als voorbeeld heb ik Gmail genomen, en de verschillende soorten functionaliteit op deze manier ingekleurd:
Dit principe geldt ook overigens ook voor veel andere (web)applicaties. In de eerste schetsen (te zien op de volgende pagina) is de applicatie op dezelfde manier opgebouwd.
De eerste schets om navigatiefunctionaliteit in kaart te brengen. Deze opzet is gekozen in navolging op de plaatsing van elementen die andere concurrenten hanteren. Al snel merkte ik dat ik hier niet mee zou uitkomen. Immers, nadat er is geklikt op ‘mail’, zou er nog een navigatielaag moeten zijn, waar gekozen kan worden voor ‘inbox’, ‘verzonden items’ of iets dergelijks. Dit geldt voor alle menu-items.
Het tweede wireframe maakt gebruik van een navigatielaag aan de bovenkant, waaronder de sub-items kunnen staan. De opdracht (die de functie als hoofdzone binnen de applicatie vervult) staat links. Vervolgens staat er in ‘dashboard-stijl’ de belangrijkste informatie uit verschillende zones. Nadeel van deze opzet is dat géén van de items op de pagina meer uitspringt. Uit de interviews en testrondes bleek dat er geen visuele ondersteuning aanwezig is voor de belangrijkste items. Veelgehoord: “Waar moet ik kijken?”. Deze opzet legt de lat om de applicatie te gebruiken te hoog en is op deze manier dus niet bruikbaar.
Dit wireframe is voortgeborduurd op het tweede wireframe en tracht meer rust te brengen door elementen weg te laten. De navigatie aan de bovenkant maakt gebruik van iconen en tekst. Daaronder wederom de opdrachtenbalk en aan de rechterkant vrije ruimte die gevuld kan worden met informatie over bepaalde opdrachten. In dit geval is er gekozen om drie komende opdrachten (binnenkort) te laten zien, met daaronder in tabelweergave de rest van de opdrachten binnen een bepaalde tijd (deze maand, dit jaar, alles). Uit de gebruikerstests bleek dat voornamelijk het ‘binnenkort’-gedeelte niet werd begrepen. Een lijst van opdrachten is wel handig, maar het ‘binnenkort’-gedeelte hoeft niet persé het belangrijkste te zijn. Immers, zo werd er geredeneerd, als het binnenkort plaatsvindt, dan is het meer een geheugensteuntje, en niet het antwoord op ‘wat moet ik nog doen’. Het geheugensteuntje staat nu dus in de weg en deze oplossing zorgt er niet voor dat duidelijk wordt wat er nog gedaan moet worden.
Na de eerste gebruikerstests met de eerste drie versies van de wireframes ben ik opnieuw gaan nadenken over de structuur. Belangrijk is om te zien wat je gedaan hebt en wat er nog moet gebeuren. Met dit in het achterhoofd heb ik bovenstaand ontwerp gemaakt. Dit ontwerp maakt geen gebruik van een sidebar- en contentconstructie, maar gaat uit van de volle breedte, die vervolgens wordt verdeeld over een grid van 12 kolommen (gelijke breedte). Binnen deze opstelling kun je dus creatiever omgaan met de ruimte. Uit de commentaren tijdens de gebruikerstest bleek dat iconen voor het weergeven van een bepaald zone niet werkt. De iconen zijn niet altijd zelfverklarend en derhalve niet altijd bruikbaar.