Nu apps gemeengoed zijn geworden en organisaties hun it-ondersteuning aan het 'verAppen' zijn, komen steeds meer ‘traditionele’ applicatie ontwikkelaars in aanraking met de app-ontwikkelwereld. Te vaak gaan zowel klant als ontwikkelaar te kort door de bocht bij dergelijke trajecten, aangezien ze in de veronderstelling zijn dat het net een applicatie-ontwikkeltraject is.
Wat betreft het proces klopt dit vergelijk op hoofdlijnen. Hoewel een Agile aanpak zoals SCRUM veel sneller als voordelig en haalbaar wordt gezien door de klant, dan nu nog bij Applicatie- ontwikkeling het geval is. Het gaat echter om de details, waarbij het belangrijk is om meteen vanaf het begin van het traject te realiseren dat het maken van een app niet simpelweg het verkleinen van een desktop applicatie is, toevallig voor een kleiner scherm.
Zo zal er procentueel veel meer inspanning (moeten) gaan naar het ontwerp van de gebruikersinterface. Standaarden en best-practices voor gui-ontwerp binnen de Windows- omgeving en het web kunnen niet gemakkelijk overgezet worden, enkel gezien het feit dat er geen ‘muis’ is. Dit heeft niet alleen impact op de grootte van objecten, maar ook op de wijze van interactie: klikken is toch iets heel anders dan aanraken en ‘swipen’. Applicaties worden aan een bureau gebruikt, of iets wat hier op lijkt. De interface van een app dient echter met meer omgevingen rekening te houden, zoals ‘on-the-go’ of ‘lean-back’, welke in interface aspecten heel anders kan zijn. Ook zaken die te maken hebben met de verschillende scherm variaties (aspect-ratio, pixel density, resolutie, oriëntatie) zijn zaken die enigszins lijken op web-development, maar waar een app toch heel anders op reageert.
Context
Naast deze variabele omgeving, is het zo dat er rekening gehouden moet worden met de ‘constante gedeelde aandacht'. Niet alleen het ‘on-the-go' scenario kan zorgen voor een langdurige pauze in interactie (bijv. bij het overstappen naar een andere trein), maar ook het feit dat er interrupties (zoals email, sms, doorkomende gesprekken, etc.) kunnen voorkomen dat er geen aaneengesloten use-case wordt doorlopen.
Deze interrupties kunnen ook in de categorie van de verbinding zijn, zoals het wegvallen hiervan. In een traditionele applicatie zal er simpelweg een melding komen, aangezien dit een weinig voorkomend scenario is. Bij een app zal het vaak echter netter afgehandeld moeten worden, en zo nodig moet de app in de ‘offline modus' worden geplaatst.
Meer dan één smaak
De applicatie-ontwikkelaar is veelal bekend met het toespitsen van een toepassing op één omgeving. In de app wereld is er meer dan één smaak. Vooral het ‘natuurlijk gebruik' van een app Operating System, zoals iOS of Android, is herkenbaar en daarom belangrijk voor een gebruiker. Veel cross-platform apps die hier geen rekening mee houden worden als ‘onhandig' of ‘lelijk' beschouwd. Dit betekent niet alleen visueel, zoals de bekende ‘draaischijven' voor lijstselecties, maar tevens ook hardware-matig. Zo is het ‘not done' om een back-knop, zoals veel gezien bij iOS, op het scherm te plaatsen terwijl Android devices hier standaard een native knop voor hebben.
Het beheer van deze meerdere smaken komt dan ook vaker om de hoek kijken bij apps, wat tevens in mindere mate het geval is met applicatie-ontwikkeling voor het web en de bijbehorende ondersteuning van de verschillende browsers. In dat geval zijn het meer ‘tweaks', waarbij in het geval van apps er een volledig andere ontwikkelomgeving, inclusief taal, benodigd is voor native apps. Nu kan er gekozen worden voor de zogenaamde ‘cross-platform' omgevingen (zoals Sybase, PhoneGap, Appcelerator, et cetera), maar aan elk voordeel zit uiteraard een nadeel.
HTML5 apps worden als uiteindelijke cross-platform oplossing gezien. Waarbij de 'HTML'-term vaak onterecht enkel wordt gezien als online en ‘web'. HTML5 heeft de kracht om volledige offline apps te creëren, inclusief het gebruik van hardware zoals gps en lokale opslag van gegevens. De kracht van de huidige hardware (dual-core of zelfs quad-core) heeft inmiddels ook de ‘traagheid' uit dergelijke apps gehaald. Helaas is HTML5 echter nog een semi-standaard omdat de verschillende omgevingen nog niet alles op de juiste manier ondersteunen.
Naast bovenstaande verschillen zijn er uiteraard nog vele andere details, zoals het distributie model (App Store) en de verschillende verdienmodellen.
Als afsluiting nog een kort lijstje van tips uit de praktijk:
• Besef dat de app valt of staat bij de gui (een ontwikkelaar heeft niet altijd designer skills);
• Maak vroegtijdig prototypes (of gebruik een Agile aanpak zoals Scrum;
• Itereer en simplificeer;
• Kies een platform dat past bij de app en de doel-omgevingen (native, web, cross-platform);
• Test op verschillende platforms op verschillende devices;
• Respecteer de omgeving (zowel iOS als de context van de gebruiker).
Goed stuk. Ik mis echter nog wel een ander belangrijk verschil m.b.t. de stores. Het feit dat de verschillende stores ook zo hun eigen eisen aan de Apps stellen is een duidelijk verschil met het alleen rekening moeten houden met de afnemer.
Zeker mee eens, waarbij je in de context van App Stores als belangrijkste onderscheid in verschil met applicatieontwikkeling kan maken:
* Het verkoopmodel, zet je de App in een publieke Appstore; is het een gratis ‘companion app’ waarbij je verdienmodel op de serverkant van de oplossing is gericht. Of zet je de App in een interne ‘Enterprise App Store’, etc;
* Het verschil in wijze van uitrol: bij publieke app stores dient men rekening te houden met bijbehorende processen (tijdsduur (updates!), goedkeuring, etc);
* Het verschil van versies door de App stores in combinatie met cross-platform. Bij dergelijke uitrol is het mogelijk dat App’s op oude versies draaien en nog niet geupdate zijn, of dat de versies ongelijk lopen over de verschillende OS’en;
* Het verschil in requirement eisers, inderdaad niet enkel de business/IT organisatie, maar ook een publieke App Store vereist bepaalde requirements;