Test

Dit is een popup

Drie vuistregels voor het bouwen van apps

Mobiele toepassingen, meestal apps genoemd, gaan niet meer weg. Wie software bouwt, kan dus niet meer om de mobiele variant heen. Daarom vind je hier nuttig advies voor het bouwen en verbouwen van je software.

1. Begin bij mobiel
Het lijkt een open deur maar het blijft heel belangrijk om te vertrekken vanuit dit principe: bouwen voor een mobiel toestel vergt heel andere bouwprincipes dan voor een toepassing die met een groot scherm wordt gebruikt. Ten eerste draait de toepassing sowieso op een kleiner scherm. Lichtjes kleiner in het geval van een tablet maar fors kleiner voor een smartphone.

Een kopie van de webtoepassing voor groot scherm is dus allesbehalve aangewezen. “Je moet inderdaad fors inboeten op beschikbare schermruimte, maar eigenlijk is dat minder belangrijk zolang de essentiële functionaliteit bewaard blijft”, aldus David Zuanelli van Compuware EMEA.

[related_article id=”161563″]

Essentiële functionaliteit is bijvoorbeeld de grootte van een aanraakknop op een aanraakscherm, “en dat kan verschillen van toestel tot toestel”. Vandaar wellicht ook Zuanelli’s voorkeur voor ontwikkelen voor elk specifiek (type) toestel, zie ook hieronder.

Het leidt Kenny Desmet, projectmanager bij Uniway, tot de volgende conclusie: “Als je apps moet bouwen voor verschillende platforms, begin dan met de mobiele app. Die heeft het kleinste scherm, en uit ervaring weten we dat het veel eenvoudiger is om elementen aan een scherm toe te voegen dan ze er nadien weer uit te moeten halen.”

Dit advies – mobile first – werd ook al gegeven door David Nuescheler van Adobe, die er nog de volgende bedenking aan toevoegde: “Mobile first kun je opsplitsen in twee andere credo’s. Ten eerste: ga ervan uit dat je voor verschillende types hardware zult moeten ontwikkelen. Ten tweede: ga ervan uit dat je toepassing vroeg of laat met een aanraakinterface zal moeten werken. De volgende generatie is nu al amper andere schermen gewend: als mijn peuter mijn pc-scherm aanraakt en geen reactie krijgt, denkt hij dat de pc stuk is.”

2. Hergebruik
Om mobiele apps te bouwen of verbouwen zijn er twee strategische keuzes, rekent Kenny Desmet ons voor: “Ofwel bouw je de apps specifiek voor je mobiel toestel, ofwel bouw je een toepassing met een responsive design, een ontwerp waarmee een toepassing zich aanpast aan het scherm waarop het wordt getoond.

"Dit wordt nu mogelijk gemaakt door HMTL5 en CS3, de recentste versies van deze webontwikkelomgevingen die met een diversiteit van mobiele toestellen rekening houden.”

Het grote voordeel is natuurlijk dat je de mobiele app slechts eenmaal moet ontwikkelen, en niet eenmaal per toestel, wat met de haast onvermijdelijke doorbraak van Windows Phone al snel op vier platforms neerkomt: BlackBerry, iPhone, Android en Windows.

Toch zijn er partijen die ervan overtuigd zijn dat het voor elk nieuw platform herbeginnen is. David Zuanelli bijvoorbeeld, die er meteen ook aan toevoegt dat dit voor een ander probleem kan zorgen: “Vele appsbouwers laten het werk van het omzetten naar specifieke toestellen over aan derden. Maar dan word je wel weer afhankelijk van de kwaliteit van hun werk.”

De kwaliteit en snelheid van je gebruikerservaring kan dus verschillen van toestel tot toestel voor dezelfde app, maar niet noodzakelijk omwille van de kwaliteit van het toestel maar ook van de derden die de software aan het toestel hebben aangepast.

Kenny Desmet nuanceert dit beeld: “Soms is het beter om opnieuw te beginnen, met name als je gebruik wil maken van de specifieke mogelijkheden van een toestel. Winkellokalisatie bijvoorbeeld kun je alleen inbouwen met de eigen functionaliteit van een toestel, in afwachting dat dit ooit in HTML 5 wordt aangeboden.

"Ook spelletjes die de volle kracht van een mobiel toestel willen benutten worden voorlopig beter native ontwikkeld. Maar het blijft altijd afwegen: als je niet hergebruikt en vanaf nul opbouwt, heb je driemaal dezelfde ontwikkelkosten. Dat moet het dan ook waard zijn.”

Jos Ruijten van Cegeka, ten slotte, biedt ook nog een handig beslissingscriterium: “Als je toepassing veel invoer van gegevens vergt, kies je beter voor een webgebaseerde app. Als integratie met de hardware of rest van het toestel belangrijk is, kies je eerder voor een native app.”

3. Let op de gebruikerservaring
We vermeldden het al hierboven: de gebruikerservaring speelt een grote rol in de populariteit (of het gebrek daaraan) van een app. “Eindgebruikers verwachten dat de mobiele toepassingen minstens even snel reageren als de toepassingen op een vast toestel. Alles wat langer dan twee of drie seconden duurt, kan je een potentiële klant kosten. Desondanks hebben mobiele toestellen bijna per definitie minder verwerkingskracht dan een desktop-pc”, aldus David Zuanelli, die meteen ook een schuldige aanwijst.

“iPhone- en Android-toestellen hebben voor deze toestand gezorgd: zij bouwden toepassingen die uit de cloud leken te komen, maar eigenlijk op het toestel zelf draaiden en daarom snelle reactiesnelheden konden garanderen. Nu is dit de norm geworden voor de gebruikerservaring.”

Allesbehalve een makkelijke opdracht dus, vooral omdat verschillende factoren de gebruikerservaring kunnen beïnvloeden: het netwerk waarop je surft natuurlijk, maar ook het toestel waarop je de app gebruikt en zelfs de browser kunnen een bepalende rol spelen. “Hoe nieuwer het toestel of de browser, hoe hoger de downloadsnelheid”, geeft Zuanelli als vuistregel mee.

Daarbij maakt het merk niet zoveel uit: “De leveranciers houden elkaar toch de hele tijd scherp, dus de verschillen tussen de recentste types zullen eerder beperkt zijn.”

De conclusie is duidelijk voor Zuanelli: “Wanneer je een app bouwt, probeer dan zo goed mogelijk te weten voor welk publiek je werkt: waar wonen ze, welk type toestel gebruiken ze het meest, op welk netwerk bevinden hun toestellen zich het vaakst, en zijn er specifieke piekperioden waarop de app intensief wordt gebruikt? En houd rekening met al deze factoren wanneer je echt aan de slag gaat.”

Mobiele toepassingen, meestal apps genoemd, gaan niet meer weg. Wie software bouwt, kan dus niet meer om de mobiele variant heen. Daarom vind je hier nuttig advies voor het bouwen en verbouwen van je software.

1. Begin bij mobiel
Het lijkt een open deur maar het blijft heel belangrijk om te vertrekken vanuit dit principe: bouwen voor een mobiel toestel vergt heel andere bouwprincipes dan voor een toepassing die met een groot scherm wordt gebruikt. Ten eerste draait de toepassing sowieso op een kleiner scherm. Lichtjes kleiner in het geval van een tablet maar fors kleiner voor een smartphone.

Een kopie van de webtoepassing voor groot scherm is dus allesbehalve aangewezen. “Je moet inderdaad fors inboeten op beschikbare schermruimte, maar eigenlijk is dat minder belangrijk zolang de essentiële functionaliteit bewaard blijft”, aldus David Zuanelli van Compuware EMEA.

[related_article id=”161563″]

Essentiële functionaliteit is bijvoorbeeld de grootte van een aanraakknop op een aanraakscherm, “en dat kan verschillen van toestel tot toestel”. Vandaar wellicht ook Zuanelli’s voorkeur voor ontwikkelen voor elk specifiek (type) toestel, zie ook hieronder.

Het leidt Kenny Desmet, projectmanager bij Uniway, tot de volgende conclusie: “Als je apps moet bouwen voor verschillende platforms, begin dan met de mobiele app. Die heeft het kleinste scherm, en uit ervaring weten we dat het veel eenvoudiger is om elementen aan een scherm toe te voegen dan ze er nadien weer uit te moeten halen.”

Dit advies – mobile first – werd ook al gegeven door David Nuescheler van Adobe, die er nog de volgende bedenking aan toevoegde: “Mobile first kun je opsplitsen in twee andere credo’s. Ten eerste: ga ervan uit dat je voor verschillende types hardware zult moeten ontwikkelen. Ten tweede: ga ervan uit dat je toepassing vroeg of laat met een aanraakinterface zal moeten werken. De volgende generatie is nu al amper andere schermen gewend: als mijn peuter mijn pc-scherm aanraakt en geen reactie krijgt, denkt hij dat de pc stuk is.”

2. Hergebruik
Om mobiele apps te bouwen of verbouwen zijn er twee strategische keuzes, rekent Kenny Desmet ons voor: “Ofwel bouw je de apps specifiek voor je mobiel toestel, ofwel bouw je een toepassing met een responsive design, een ontwerp waarmee een toepassing zich aanpast aan het scherm waarop het wordt getoond.

"Dit wordt nu mogelijk gemaakt door HMTL5 en CS3, de recentste versies van deze webontwikkelomgevingen die met een diversiteit van mobiele toestellen rekening houden.”

Het grote voordeel is natuurlijk dat je de mobiele app slechts eenmaal moet ontwikkelen, en niet eenmaal per toestel, wat met de haast onvermijdelijke doorbraak van Windows Phone al snel op vier platforms neerkomt: BlackBerry, iPhone, Android en Windows.

Toch zijn er partijen die ervan overtuigd zijn dat het voor elk nieuw platform herbeginnen is. David Zuanelli bijvoorbeeld, die er meteen ook aan toevoegt dat dit voor een ander probleem kan zorgen: “Vele appsbouwers laten het werk van het omzetten naar specifieke toestellen over aan derden. Maar dan word je wel weer afhankelijk van de kwaliteit van hun werk.”

De kwaliteit en snelheid van je gebruikerservaring kan dus verschillen van toestel tot toestel voor dezelfde app, maar niet noodzakelijk omwille van de kwaliteit van het toestel maar ook van de derden die de software aan het toestel hebben aangepast.

Kenny Desmet nuanceert dit beeld: “Soms is het beter om opnieuw te beginnen, met name als je gebruik wil maken van de specifieke mogelijkheden van een toestel. Winkellokalisatie bijvoorbeeld kun je alleen inbouwen met de eigen functionaliteit van een toestel, in afwachting dat dit ooit in HTML 5 wordt aangeboden.

"Ook spelletjes die de volle kracht van een mobiel toestel willen benutten worden voorlopig beter native ontwikkeld. Maar het blijft altijd afwegen: als je niet hergebruikt en vanaf nul opbouwt, heb je driemaal dezelfde ontwikkelkosten. Dat moet het dan ook waard zijn.”

Jos Ruijten van Cegeka, ten slotte, biedt ook nog een handig beslissingscriterium: “Als je toepassing veel invoer van gegevens vergt, kies je beter voor een webgebaseerde app. Als integratie met de hardware of rest van het toestel belangrijk is, kies je eerder voor een native app.”

3. Let op de gebruikerservaring
We vermeldden het al hierboven: de gebruikerservaring speelt een grote rol in de populariteit (of het gebrek daaraan) van een app. “Eindgebruikers verwachten dat de mobiele toepassingen minstens even snel reageren als de toepassingen op een vast toestel. Alles wat langer dan twee of drie seconden duurt, kan je een potentiële klant kosten. Desondanks hebben mobiele toestellen bijna per definitie minder verwerkingskracht dan een desktop-pc”, aldus David Zuanelli, die meteen ook een schuldige aanwijst.

“iPhone- en Android-toestellen hebben voor deze toestand gezorgd: zij bouwden toepassingen die uit de cloud leken te komen, maar eigenlijk op het toestel zelf draaiden en daarom snelle reactiesnelheden konden garanderen. Nu is dit de norm geworden voor de gebruikerservaring.”

Allesbehalve een makkelijke opdracht dus, vooral omdat verschillende factoren de gebruikerservaring kunnen beïnvloeden: het netwerk waarop je surft natuurlijk, maar ook het toestel waarop je de app gebruikt en zelfs de browser kunnen een bepalende rol spelen. “Hoe nieuwer het toestel of de browser, hoe hoger de downloadsnelheid”, geeft Zuanelli als vuistregel mee.

Daarbij maakt het merk niet zoveel uit: “De leveranciers houden elkaar toch de hele tijd scherp, dus de verschillen tussen de recentste types zullen eerder beperkt zijn.”

De conclusie is duidelijk voor Zuanelli: “Wanneer je een app bouwt, probeer dan zo goed mogelijk te weten voor welk publiek je werkt: waar wonen ze, welk type toestel gebruiken ze het meest, op welk netwerk bevinden hun toestellen zich het vaakst, en zijn er specifieke piekperioden waarop de app intensief wordt gebruikt? En houd rekening met al deze factoren wanneer je echt aan de slag gaat.”

appsbouwenmobielsoftwaretechzoneverbouwen

Gerelateerde artikelen

Volg ons

ICT Jaarboek 2021-2022 – TechPulse Business

ICT Jaarboek 2021-2022 – TechPulse Business

Bestel nu!