Moet een app er precies hetzelfde uit zien en hetzelfde werken op Android en iOS, of mogen er verschillen tussen de twee zijn? Het lijkt zo vanzelfsprekend dat een app er hetzelfde uit dient te zien op verschillende apparaten. Logisch toch ook, zou je zeggen? Anders snappen de gebruikers hoe de app op het ene platform werkt, en niet op het andere, toch? Niets is minder waar. Laat me het uitleggen.

Laten we beginnen met de vraag: Wat heeft de gebruiker van de app er aan dat de iOS versie identiek is aan de Android versie? Waarom is die daar bij gebaat?

Je kunt er op twee manieren voor kiezen om de app op beide platformen identiek te laten werken en ogen, ieder met eigen redeneringen er achter.

• Een consistent (en dus meer herkenbaar) design gebruiken op beide platformen -> hierdoor hoef je niet aan verschillende stijlen te werken voor de twee versies. Dit kan marketingtechnisch en soms budgetair voordelen bieden.
• Een gelijke gebruikerservaring bieden -> Om gebruikers die overstappen van Android naar iOS of andersom, een gelijke ervaring te geven, zodat ze zonder moeite kunnen uitvinden hoe die op het nieuwe platform werkt.

Je kunt dus op het vlak design en gebruikerservaring twee gelijkende apps maken. De eerste, design, zal ik niets aan af doen. Integendeel, een consistent kleurenpalet, dezelfde afbeeldingen, veelal dezelfde iconen etc. kunnen ter herkenning voor de gebruiker belangrijk zijn om een consistent beeld bij de gebruikers van beide platformen te creëren.

Ter herkenning eenzelfde uiterlijk op beide platformen dus. Maar waar ligt de grens?

Design

Voor een opdrachtgever had ik (bij mijn werkgever Auxilium B.V., niet als freelancer) het genoegen de iOS variant te maken van een app voor ouderen. Een collega zou de Android app maken. Dit leidde tot interessante discussies. Want die Android app, moest die er nou hetzelfde uitzien als de iOS app?

De klant was er duidelijk in: Er mogen geen verschillen tussen de Android versie en de iOS versie van de app zijn, tenzij strikt noodzakelijk. Dit ging ver. Zo was er de tekst onder de iconen van de tab bar (de knoppenbalk, zie afbeelding):

Die was op iOS wat slecht leesbaar door de kleine letters die daar gebruikt worden, zo oordeelde de klant. De grootte van de tekst onder die knoppen kan daar echter niet zomaar worden aangepast, die is standaard bij iOS apparaten. Daarom kon die tekst onder de knoppen maar beter weggehaald worden, oordeelde de contactpersoon. Dit is prima zou je zeggen, als de klant oordeelt dat de doelgroep niet veel heeft aan tekst die te klein is voor het gemiddelde gezichtsvermogen van hen die de app gaan gebruiken, dan is het prima om het weg te halen. Zolang de knoppen zelf maar duidelijk aangeven waar ze voor staan en wat er achter zit.

Het gevolg was echter dat dit conflicteerde met de eis dat Android en iOS versies van de app gelijk aan elkaar moesten zijn. Aangezien je in Android de tekstgrootte van de knoppenbalk wél kan aanpassen, speelde daar het probleem van de onleesbare tekst niet. Toch moest ook daar de tekst in zijn geheel verdwijnen, om ervoor te zorgen dat de apps gelijk bleven.

De vraag is echter waarom de twee versies zo identiek moeten zijn.  De klant was waarschijnlijk de enige gebruiker van de app die tijdens het gebruik een Android tablet en een iPad (iOS) naast elkaar hield om te zoeken naar verschillen. Want wat heeft de gebruiker van de app er aan dat de iOS versie identiek oogt aan de Android versie? Waarom is die daar bij gebaat?

Het voorbeeld met de kleine letters onder de iconen brengt ons tot de kern van wat we hier kunnen leren. De contactpersoon van de opdrachtgever verwarde hier namelijk identiek met voor beide platformen even intuïtief en bekend. Een iOS gebruiker is er namelijk bij gebaat dat het voor hem intuïtief werkt en oogt, op een manier die vergelijkbaar is met andere iOS apps en gebruikmakend van componenten die specifiek voor het iOS platform zijn. Die kleine letters onder de iconen, die zijn net zo klein in elke andere app die de standaard knoppenbalk van iOS gebruikt, en dat zijn er heel veel. Met andere woorden, als een gebruiker geen eerdere problemen had om de iPhone of iPad te hanteren, dan is een extra app die dezelfde standaard componenten gebruikt geen enkel probleem. Integendeel, het voelt vertrouwd aan, en niet als iets waar men aan moet wennen. In dit geval was het dus geen goede beslissing. Niet alleen onnodig, maar mogelijk zelfs contraproductief. Het is daarom belangrijk, zoals ik hierboven schrijf, om identiek niet te verwarren met op intuïtief gebied een gelijke ervaring.

Gebruikservaring

Een app moet vooral intuïtief begrepen worden door de gebruiker. Dat gebeurt A. door visuele componenten te gebruiken die kloppen met wat een gebruiker op dat specifieke platform (iOS of Android) kan verwachten, en B. door de structuur (de infrastructuur, hoe je bijv. van hoofdscherm naar een nieuwsbericht gaat, of hoe je een stap terug gaat in een boomstructuur) van de app in te delen op een manier die logisch is voor de gebruiker van dat specifieke platform.

Dat betekent bijvoorbeeld dat je er bij Android van uit kan gaan dat een telefoon of tablet een “Terug” knop heeft, die voor oudere Android versies vaak de enige manier was om terug te gaan, maar gebruikers in nieuwere versies ook een “Omhoog” knop hebben. Bij de terugknop verwacht een gebruiker teruggebracht worden naar een hoger niveau van bijvoorbeeld een menu, en als hij deze blijft drukken, dat de app er uiteindelijk mee zal worden verlaten. Bij de omhoogknop, verwachten gebruikers dit niet. iOS heeft echter helemaal geen terugknop. Omhoog gaan in een menustructuur gebeurd alleen middels een omhoogknop net zoals Android in nieuwere versies ook heeft toegepast. De app verlaten doe je door de home knop.

Dat betekent dat de “Omhoog” knop in Android wel handig, maar niet noodzakelijk is. Terwijl bij iOS deze omhoogknop absoluut noodzakelijk is om te kunnen navigeren door de app, is deze dat bij Android dus niet. Dat zijn typisch zaken waar je je design en infrastructuur  van de app op moet aanpassen. Daarnaast is het bijvoorbeeld sinds grotere iPhones van belang om na te denken waar je bepaalde knoppen plaatst. Een iOS gebruiker moet altijd met de vinger helemaal naar boven in het scherm om terug te gaan, tenzij je andere methodes implementeert zoals het naar rechts vegen vanaf de rand van het scherm, om zo een stap terug in het menu te gaan. Dit zijn zaken om rekening mee te houden als je wilt dat gebruikers de app met één hand kunnen bedienen.

Het argument om identieke apps te maken voor een gelijke gebruikerservaring is dus zeer zwak. Sterker nog, om een gelijkwaardig intuïtieve (niet te verwarren met gelijke) gebruikerservaring op ieder platform te geven, zal je juist een unieke aanpak per platform moeten nemen. Door verschillen in hardware, software en conventies op beide platformen moet je zo dicht mogelijk bij de gebruikers van dat platform gaan staan, en niet een gewogen gemiddelde nemen van de twee en die fictieve, niet bestaande gebruiker te bedienen.

Dit artikel is geschreven door Arjan van der Laan

Rechten: Uitgelichte afbeelding afkomstig van Dutch Cowboys

Gerelateerd: Interessant artikel die de laatste verschillen tussen beide platformen onder de loep neemt is een van Mashable. Google maps