Mobiele applicaties zijn helemaal hot. Eigenlijk tel je als bedrijf niet mee als je geen mobiele app levert aan je klanten. Niet alleen de usual suspects als Nederlandse Spoorwegen en OV9292 maar ook Albert Heijn, TNT Post, QPark en Rabobank proberen actief een plekje te verwerven op het meest private stukje electronica wat we kennen: onze telefoon.
Technisch is het ook niet zo moeilijk: er zijn voor Apples iOS, Googles Android en Microsofts Windows Phone zeer goede ontwikkelstudio’s beschikbaar. Het is geen drag-and-drop ontwikkelwerk, maar het scheelt erg weinig. De applicaties zijn functioneel vaak geen rocket-science. Feit is dat als je voor de desktop kunt ontwikkelen je ook voor de telefoon kunt ontwikkelen.
Toch zit er wel een voetangel. Een groot deel van de gedownloade applicaties blijft ongebruikt. Slechts 25% van de gebruikers koopt ooit een applicatie. Dus er zijn wel degelijk een hoop applicaties die bij nader inzien gewoon “rommel” zijn in de ogen van de gebruiker.
In dit artikel gaan we in op wat de rommel van de top-applicaties onderscheid. We beginnen met het uitleggen van het meest fundamentele verschil tussen desktop en mobiele applicaties: de gebruikerscontext. Daarna kijken we naar de impact hiervan op de user-interface en gebruikte techniek.
Gebruikerscontext
De gebruiker en zijn context is zonder twijfel het grootste verschil tussen desktop en mobiele applicaties. De desktop gebruiker zit in het algemeen relaxed op een vertrouwd plekje zijn werk met zijn computer te doen. Kern hiervan is dat hij de omgeving vertrouwt en dat hij bezig is met zijn werk op de computer. De mobiele gebruiker is bezig in een onvertrouwde omgeving en heeft zijn telefoon nodig om hem te helpen beslissingen te nemen in die omgeving. Kern hiervan is dat de gebruiker in een onvertrouwde (wellicht zelfs onbetrouwbare of potentieel vijandige) omgeving bezig is beslissingen te nemen waarbij zijn telefoon hem moet helpen. De mobiele gebruiker moet, in tegenstelling tot de desktop gebruiker, real-life beslissingen nemen en wil eigenlijk helemaal niet bezig zijn met die applicatie. De mobiele applicatie is voor de gebruiker is slechts een noodzakelijk kwaad om zijn omgeving beter te begrijpen.
Doordat de mobiele applicatie slechts een middel is tot een hoger gebruikersdoel, ontstaat er een soort ongeduldigheid bij de gebruiker. Als de applicatie te traag is of teveel aandacht opeist zal hij de applicatie terzijde schuiven en gewoon “blind” beslissingen gaan nemen zoals hij vroeger ook deed: op een gegeven moment moet je als gebruiker gewoon die trein gaan pakken, in plaats van uitzoeken welke van de vele opties de meest optimale is. De wereld om de applicatie gaat door, en de gebruiker dus ook, met of zonder applicatie.
Gek genoeg is de benaderingswijze van veel software ontwikkelaars er een van het laten krimpen van een desktop-applicatie. Men heeft een veel te veel informatie in de applicatie, de user interface is te complex en er wordt vaak geen rekening gehouden met technische beperkingen van mobiele toestellen.
Keep it simple
Een van de belangrijkste basisprincipes is “hou het simpel”. Dat klinkt makkelijk, maar de praktijk wijst uit dat het ontzettend moeilijk is een applicatie eenvoudig te maken voor de gebruiker: het vereist de moed om keuzes te maken.
Een van de belangrijkste keuzes is het beperken van de applicatie tot één heel specifieke taak van de gebruiker. Een mobiele applicatie dient een bepaald doel en daar moet dus niet teveel franje in komen, omdat dat domweg in de weg gaat zitten bij gebruik. Een interessant voorbeeld hiervan is bijvoorbeeld de NS Reisplanner Xtra, die geen enkele informatie bevat over de prijs van een reis. Hij is puur bedoeld om mensen treinzreizen efficient te laten plannen. Overigens moet ook bij deze applicatie wel een kritische kanttekening worden gezet: er is een deel in de applicatie gereserveerd voor marketing-acties, wat kostbare ruimte in de navigatiebalk kost. Als men dergelijke informatie zou willen bieden, zou men eigenlijk moeten overwegen een tweede applicatie te bouwen. SPB Traveller doet dit structureel: alle onderdelen (vluchtplanning, currency-converter, woordenboek, etc.) worden ook als losse applicatie geinstalleerd, zodat er vlot genavigeerd kan worden.
User interface
Een belangrijk onderdeel van de applicatie is de user interface. Belangrijk is om te onthouden dat de gebuiker niet de tijd, zin of aandacht heeft om precieze handelingen uit te voeren. Ook moet informatie zeer overzichtelijk zijn om snel te kunnen analyseren. Dit betekent dat de applicatie hier ook op ingericht zijn. Dit uit zich op verschillende vlakken: het visuele deel van de de user interface maar ook de page-flow en de informatie die ingevuld moet worden in de interacties.
Een belangrijke wake-up call voor GUI ontwerpers is dat mensen hun applicatie ook gebruiken, maar dan ook echt overal. Onderzoek laat zien dat veel mensen hun telefoon gebruiken als ze in bed liggen of op de WC zitten. Maar ook treinstations en bushaltes zijn vaak favoriete plekken om even wat te gaan doen. Dit laatste brengt nogal wat uitdagingen, zeker in Nederland en noord Europa. Mensen hebben ’s winters handschoenen aan of zijn onnauwkeurig door de koude. Kleine controls op zo’n telefoonscherm zijn dan ook volstrekt uit den boze, gewoon omdat het niet te bedienen is. Een scherm moet goed te bedienen zijn met een dikke handschoen aan of koude handen. Ook mensen die meer bezig zijn met hun omgeving zitten nog wel eens een paar milimeter mis. Grote knoppen met duidelijke gevolgen zijn dan ook essentieel. Daar faalt eigenlijk de iPhone GUI al een beetje: daar staan eigelijk al te kleine knoppen op.
Bedenk ook dat een gebruiker veelal informatie in een oog-opslag moet kunnen interpreteren, zonder al teveel analyse van zijn kant. In de desktop wereld kun je probleemloos informatie op een visueel aantrekkelijke, maar onoverzichtelijke, manier presenteren: de gebruiker moet er toch nog zijn eigen analyse op los laten. Een mobiele gebruiker wil graag snel hapklare informatie hebben die zijn beslissing in de wereld zal gaan beinvloeden. Je eindigt dan al snel in tabel-georienteerde vormgeving. Visueel wellicht niet de mooiste oplossing, maar vaak wel de meest effectieve. Soms moet je een hele andere aanpak kiezen: file-informatie moet je wellicht niet als lijst van files weergeven (wat een behoorlijke wissel trekt op de topografische kennis van de gebruiker), maar meer als kaart van Nederland met rood snelwegen of gekleurde gebieden.
Denk ook aan het minimaliseren van “vereisten” van een huisstijl. Bijvoorbeeld de NS heeft in haar NS Reisplanner Xtra een plaatje zitten die bijzonder veel ruimte inneemt. Ruimte die anders door nuttige informatie gebruikt zou kunnen worden. Maar ook zaken als logo’s, beeldelementen en standaard icoontjes kunnen op een klein scherm wel eens zeer veel ruimte kosten of erg onduidelijk overkomen. Het is verstandiger om te kijken hoe de applicatie het beste uit de verf komt, en dan pas een huisstijl hier passend in te krijgen, dan de huisstijl leidend te laten zijn.
Page-flow is een volgend punt van aandacht. Die moet niet te complex zijn, maar zeker ook niet te lang. Een gebruiker raakt snel afgeleid, en de vraag “waar was ik ook al weer” is foutgevoelig en helpt niet bij het vlot uitvoeren van de dingen die hij snel wilde doen. Idealiter bestaat een handeling uit maximaal 3 tot 4 verschillende schermen die erg duidelijk maken waarmee de gebruiker bezig is.
Denk ook over de gevolgen van de pageflow na: de gebruiker is bijzonder doelgericht en zal alles doen om die taak te volbrengen. Het beste voorbeeld hiervan is het navigatiepakket van de ANWB, wat niet toeliet dat de gebruiker de bestemming invoerde of wijzigde als de auto bewoog. Doel van de ANWB was om veiliger weggedrag te stimuleren. Gevolg was echter dat de gebruiker met enige vorm van creativiteit de GPS deactiveert en vervolgens alsnog zijn bestemming ingeeft/wijzigt. Gevolg is dus een agressievere en veel meer afgeleide bestuurder dan de bedoeling van de ANWB was. Ongemerkt zitten dit soort zaken in elke applicatie: een tunnelvisie van hoe het gebruiksscenario verloopt is handig, maar zeker niet altijd de realiteit.
Ingevoerde informatie is een verhaal apart. Veel devices kennen een on-screen toetsenbord of zelfs een (klein) fysiek toetsenbord. Veel ontwikkelaars zien dit als een excuus om dit ook te gebruiken. Het gebruik van zo’n toetsenbord is alles behalve comfortabel: er zijn zelfs specifieke RSI-varianten voor dit soort gebruik ontdekt. Een paar tekens is vaak nog te doen, maar grotere stukken tekst zijn voor gebruikers vaak erg vervelend. Soms is het een bruikbaar scenario om complexe informatie via een website in te voeren en dan naar het toestel te syncen. Zo werken de reisschema’s van TripIT bijvoorbeeld. Voorkomen dat een gebruiker veel informatie moet invoeren is belangrijk omdat het afleid van het primaire doel van de gebruiker: zijn omgeving managen.
Technische mogelijkheden en beperkingen
Ook technische mogelijkheden en beperkingen spelen een sterke rol bij de kwaliteit van een mobiele applicatie. Het is voor een geruiker zeer vreemd als technische mogelijkheden onbenut blijven of als je ingaat tegen technische beperkingen.
Een smartphone heeft zeer veel technische mogelijikheden. Technisch gezien zijn ze bijna gelijk aan laptops van 3 jaar terug met office volledig geinstalleerd. Maar een smartphone weet tegenwoordig ook zijn eigen locatie en heeft een camera. Het is voor gebruikers dan ook zeer vreemd als je als applicatiebouwer daar geen gebruik van maakt. Het zou bijvoorbeeld bijzonder vreemd zijn als je bij de NS Reisplanner de startlocatie handmatig zou moeten ingeven. Hoogstwaarschijnlijk is dat het dichtsbijzijnde station. Maar ook verwacht de gebruiker bijvoorbeeld dat Appie, de Albert Heijn boodschappenlijst, gewoon automatisch het juiste filiaal selecteert. Maar de gebruiker verwacht ook integratie met de agenda en contactpersonen. Gewoon omdat het technisch mogelijk is en hem veel complex werkt bespaart.
Maar de smartphone kent ook zijn technische beperkingen: met name de acuu is een van de belangrijkste. Als je als applicatie de accuduur significant verkort, door veel van de GPS, CPU of internet-verbinding te vragen, dan pak je figuurlijk de telefoon van de gebruiker af. Je verkort de bruikbare tijd van een telefoon voor de gebruiker. Dus veel enenrgie gebruiken door intensief energie-slurpende hardware te gebruiken is niet verstandig. Dat is de manier om slechte reviews te krijgen met de opmerking “battery drain”.
Een ander punt is de internetverbinding. De telecom-operators willen ons erg graag laten geloven dat hun netwerk overal aanwezig is met voldoende bandbreedte. Dit is niet het geval: de dekking door hun netwerken valt in de praktijk gewoon erg tegen. Zelfs al zou je goede dekking hebben, valt de kwaliteit daarvan vaak tegen door verstoringen door gebouwen of warmtewerende beglazing. Bovendien raken netwerken erg snel overbelast: een grote storing op Utrecht Centraal en je krijgt in de wijde omtrek geen data-verbinding meer. Een volledige afhankelijkheid van internet is dus iets wat je als ontwikkelaar moet zien te vermijden als het mogelijk is.
Conclusie is dus dat het bij mobiele applicaties veel minder over de harde techniek van API-calls en code gaat, maar veel meer nadenken over hoe de applicatie gaat functioneren in de context van een gebruiker die iets wil realiseren. Bij mobiele applicaties gaat het veel meer om hoe de gebruiker snel zijn beoogde taak kan realiseren, en dat vergt speciale aandacht voor wat de functionaliteit is, hoe de GUI er uit ziet en de oplossing technisch wordt opgezet.