Perception et réalité, les secrets d’une application WEB fluide

Perception et réalité, les secrets d’une application WEB fluide

Depuis que des applications mobiles ont migré  des technologies natives vers des technologies WEB, l’essentiel des informations transite par le réseau radio. Le développeur doit tenir compte des aléas de réception dans la conception de son application.

Lorsqu’on interagit avec une application, il est aujourd’hui difficile de concevoir un temps où il ne se passe rien.

Entre 100 et 300 ms, on ressent une légère perception de délai. Au-delà de 1 seconde, l’attention sur la tâche en cours diminue. Au-delà de 10 secondes, commence le lent travail de frustration qui amène à la plainte aux équipes IT ou à la suppression de l’application.

Il y a dix ans, en voyant un spinner sur la page, on savait que l’application avait pris en compte notre demande, et on attendait patiemment. Avec la mise en place des réseaux 4G et bientôt 5G, la généralisation de la fibre optique, on est plutôt dans le registre « Ma demande est pourtant simple, pourquoi la réponse n’est pas immédiate ? ».

Le spinner est aujourd’hui synonyme de lenteur. La latence ne fait plus partie de notre référentiel et une application mal conçue ne supporte pas les aléas réseaux. La sanction de l’utilisateur est immédiate : Il change d’application.

Où est passé le temps ?

En montagne, il n’y a pas de temps gagné, il n’y a que du temps perdu. Ce proverbe montagnard signifie que pour atteindre l’objectif, il n’est pas question de supprimer les actions liées à la sécurité des grimpeurs. Mais le travail permet d’optimiser le temps passé.

Le développeur n’a pas d’impact sur la vitesse de transmission du réseau, mais il doit travailler à :

• Optimiser les temps de calcul des serveurs de données
• Concevoir un protocole de communication efficace entre le client et le serveur applicatif
• Mettre en place les bonnes stratégies de rendu visuel de l’information.

Ce travail d’optimisation est important pour toutes les applications. Il devient impératif dès qu’une application doit gérer un grand volume de données.

Voici quelques règles que nous gardons en tête dans la conception de nos interfaces utilisateurs.

Diffuser l’information au bon rythme

La première chose est de garder de la puissance disponible pour que l’équipement, PC ou mobile, puisse faire autre chose que charger l’application :

En d’autres termes, éviter le freeze.

Les applications LivingObjects utilisent des composants front complexes : Création de graphes et des cartes en utilisant du canvas, utilisation de WebGL pour les cartes, sélecteurs de données avec des listes de milliers d’objets…,

Il nous est donc impossible de développer suivant le principe : « On a reçu l‘info du back. Vite, on envoie la sauce, le navigateur se débrouillera. ».

La suite, tout le monde l’a connu au moins une fois : freeze de la souris, voile blanc qui se dépose sur l’onglet et popup déclarant « l’onglet ne répond pas, voulez-vous recharger ? ».

Les stratégies suivantes s’imposent :

• Un chargement asynchrone des blocs constituant la page par pas de multiples de 100 ms en fonction de la taille du composant.
• Un affichage « utile » des données en commençant par celles qui sont visibles par l’utilisateur.

Tenir l’utilisateur en haleine

Un retour systématique et instantané sur chaque clic est aujourd’hui devenu la norme pour toutes les applications web. Mais exprimer par un effet sur le clic, que la demande a été prise en compte n’est plus suffisant. Il faut aussi que la réponse arrive rapidement.

La stratégie du « skeleton screen », apparue récemment, est maintenant utilisée par la plupart des géants du Web. Luke Wroblewski utilise le premier ce terme et donne la définition suivante :

“Un skeleton est la version blanche de la future page, dans laquelle la donnée sera chargée progressivement.”

Il s’agit de construire le squelette de la page en remplaçant les zones de texte ou images non encore disponibles par des petits blocs gris ou de couleur neutre qui apparaissent instantanément. La donnée réelle remplace progressivement ces blocs lorsqu’elle devient disponible. Ces blocs permettent de basculer d’une perception d’un process intégral de chargement, à un process plus restreint de chargement de la donnée.

Cette stratégie donne une illusion d’instantanéité qui garantit l’engagement cognitif de l’utilisateur.

Ce travail sur l’expérience utilisateur, d’abord réalisé sur les applications mobiles, bénéficie aux applications web PC. En respectant ces principes, on amène une fluidité d’utilisation proche des applications PC natives.

Références :

https://developers.google.com/web/fundamentals/performance/rail , guideline donnée par l’équipe Google sur la conception des interfaces

https://uxdesign.cc/what-you-should-know-about-skeleton-screens-a820c45a571a pour comprendre plus en détail le fonctionnement des skeleton