Tech 3741 x bekeken

Het geheim van gebruikersinteracties met ongeduldige gebruikers

11 mei 2016 - User Not Found

Het maakt niet uit hoe lang je als ontwikkelaar over situaties nadenkt, een gebruiker zal de applicatie altijd anders gebruiken dan verwacht.

Een veel voorkomende oorzaak van “gaten” in een applicatie is het doen van de aanname dat een gebruiker op dezelfde manier nadenkt als dat men zelf doet. Een gebruiker heeft per definitie niet dezelfde kennis over de werking van de applicatie als dat de programmeur heeft. Een veel voorkomend gevolg hiervan is dat de gebruiker minder lang bereid is om te wachten, als dat de ontwikkelaar gedacht had.

Een favoriet selecteren

Een mooi voorbeeld van een situatie waarbij een ongeduldige gebruiker veel roet in het eten kan gooien, is bij het markeren van een favoriet liedje in een lijst met nummers. Het concept is vrij simpel: ieder liedje heeft een icoontje in de vorm van een hartje wat de huidige favoriet status representeert: als hij blauw is, is het een favoriet en als hij grijs is, is hij het niet. Het hartje is vervolgens klikbaar om het nummer als favoriet te (de-)markeren. In de volgende afbeelding is nog geen enkel nummer als favoriet gemarkeerd.
Lucas2
De achterliggende code om een nummer als favoriet te markeren is vrij eenvoudig. De gebruiker klikt op het icoontje bij het gewenste nummer. Vervolgens wordt er een verzoek naar de server gestuurd, welke het nummer in de database als “favoriet” markeert voor de gebruiker. De server geeft antwoord op het bericht en het verzoek  is afgerond. De vraag is nu: wanneer wordt het icoontje blauw?

Als Front-end ontwikkelaar is het cruciaal om hier goed over na te denken. Men zal de reacties en het gedrag van de gebruiker moeten gaan aannemen en hierop moeten anticiperen tijdens het uitwerken van de code.

Direct actie ondernemen of even wachten?

De feedback naar de gebruiker kan op verschillende manieren worden afgehandeld. Zo kan men ervoor kiezen om direct het icoontje blauw te maken, zodat de gebruiker gelijk ziet dat het nummer als favoriet is gemarkeerd. Het probleem is hierbij echter dat het nummer pas favoriet is, als de server het verzoek heeft afgehandeld. Mocht de gebruiker zijn browser sluiten vóórdat het verzoek is afgerond, dan zal het nummer niet als favoriet gemarkeerd zijn. Als hij de volgende keer het nummer bekijkt, zal hij ook verbaasd zijn dat het liedje niet is opgeslagen als favoriet.

Een alternatief is om het icoontje pas aan te passen, zodra het verzoek op de server is afgerond. Op deze manier weet je 100% zeker dat het icoontje synchroon loopt met de status in de database. Ook hier zitten echter weer nadelen aan. Als de server het op dat moment druk heeft, kan de gebruiker de impressie krijgen dat er niks gebeurt; het duurt even voordat het icoontje blauw wordt. Een resultaat kan zijn dat de gebruiker op dat moment meerdere malen op het icoontje klikt om het als favoriet te markeren. Dit kan als gevolg hebben dat er op de server situaties optreden waar geen rekening mee gehouden is.

Hoe kunnen we zorgen dat de gebruiker toch direct feedback krijgt en weet dat hij eventjes moet wachten tot alles is afgerond?

Non-stop feedback

Een mooie tussenweg, is om de gebruiker op de hoogte te stellen van het hele proces dat doorlopen wordt:

  • Zodra de gebruiker op het icoontje klikt, is deze niet meer klikbaar.
    De gebruiker kan nu niet meer per ongeluk meerdere verzoeken naar de server sturen.
  • Het icoontje wordt aangepast naar een laad icoontje/draaiend cirkeltje, hiermee wordt de gebruiker geattendeerd op een actie die gaande is.
  • Het verzoek wordt verstuurd naar de server en de browser wacht tot deze is voltooid.
  • Het icoontje wordt aangepast naar het blauwe hartje. De gebruiker wordt op de hoogte gesteld dat de actie is voltooid.
  • Zodra het verzoek binnen is, wordt het icoontje weer klikbaar.
    De gebruiker is nu in staat om het liedje weer favoriet-af te maken.

Good is good enough

Het probleem dat hierboven beschreven is, is opgelost op basis van aannames. Men neemt aan dat een gebruiker ongeduldig kan zijn, dat een gebruiker zijn browser sluit na het aanklikken van een favoriet of dat een gebruiker meerdere keren gaat klikken als er niet direct duidelijke feedback is. Door middel van aannames kunnen veel problemen en ongewenste situaties voorkomen worden. 

Het lastige is om hier niet in door te schieten. Wat als een gebruiker een favoriet selecteert en daarna direct de computer uitschakelt? Gaan we dan cookies implementeren die alles bijhouden om vervolgens alles te gaan synchroniseren met de server?  

Voor mij zou het antwoord nee zijn, maar zoals vrijwel altijd is het voornamelijk van de situatie afhankelijk. Het geschetste probleem hierboven is relatief eenvoudig te abstraheren naar enkele kritischere bedrijfsprocessen, waarbij het weer wél cruciaal zou kunnen zijn om data altijd op te slaan. 

Als Front-ender kan het maken van te veel aannames erg veel werk kosten, maar als men hier mee om kan gaan, kan het enorm veel werk, tijd, moeite en frustraties besparen!

 
 
 

User Not Found

Reacties ()