Cet article est une traduction et une adaptation d’un article paru sur le blog Stadia dédié à son développement. L’article original peut être consulté ici.
Dans cette nouvelle série d’articles, nous allons détailler certains des aspects les plus techniques du travail sur une plate-forme comme Stadia et comment nous avons travaillé pour atteindre la simplicité dans un monde de complexités pour nos utilisateurs finaux. Dans cette première partie, nous nous attaquons à certains défis spécifiques à Android et iOS, et d’autres sont à venir.
Il s’agit de la première partie de notre série sur la gestion de la manette Stadia dans notre application mobile avec Flutter.
La configuration matérielle est un défi sous-estimé dans l’électronique grand public. Il s’agit à la fois de l’une des premières expériences de l’utilisateur avec le produit et d’une prouesse technique très difficile, ce qui conduit à un équilibre délicat entre des priorités concurrentes. Le processus de configuration de la manette Stadia est un exemple concret de cet équilibre. La manette est l’un des éléments clés qui font de l’utilisation de Stadia une expérience exceptionnelle, il est donc essentiel que les utilisateurs puissent être prêts à jouer aussi facilement que possible. Une fois qu’une manette est sortie de sa boîte, sa configuration prend moins d’une minute à la plupart des gens, mais cela implique beaucoup plus de choses sous le capot que ce que l’on pourrait croire.
Dans cette série d’articles, j’aborderai les défis auxquels notre équipe a été confrontée lors de la mise en œuvre de la configuration des manettes dans l’application mobile Stadia, les décisions d’architecture que nous avons prises pour améliorer à la fois la cohérence et la compréhension de notre code et comment l’utilisation de Flutter a augmenté notre productivité et la qualité de l’expérience utilisateur.
La configuration du matériel peut être une opération étonnamment difficile
À première vue, la configuration de la manette Stadia peut sembler être un processus relativement simple. L’utilisateur doit allumer la manette, utiliser l’application mobile Stadia pour trouver la manette et s’y connecter via Bluetooth, lui envoyer des informations d’identification Wi-Fi, puis commencer à jouer.
Sur la base de cette seule description, il semble que tout le monde devrait être capable de configurer sa manette avec succès à chaque fois. Malheureusement, ce genre de succès universel n’est possible que dans des conditions idéales. Une personne qui configurerait une manette Stadia neuve et entièrement chargée, en utilisant un téléphone et un routeur WiFi spécifiques, qui a déjà configuré de nombreuses manettes et qui ne se trompe jamais de mot de passe Wi-Fi, à l’intérieur d’une cage de Faraday, aurait probablement une excellente expérience.
Cependant, il existe des milliers de téléphones et de routeurs Wi-Fi différents sur le marché, chacun ayant ses propres particularités (en fait, nous essayons de prendre en charge le plus grand nombre possible d’entre eux !). De même, le processus d’installation est soumis à des facteurs environnementaux et humains : des choses inattendues peuvent se produire et l’installation ne se déroule pas toujours comme prévu.
Pour combler l’écart entre les conditions idéales et les conditions réelles, nous pouvons utiliser le concept de « réussite de l’utilisateur ». Pour qu’un utilisateur réussisse le processus de configuration, il doit disposer d’une manette correctement configurée, savoir comment l’utiliser et comprendre ce qui se passe à chaque étape du processus.
Il existe un grand nombre de facteurs susceptibles d’empêcher un utilisateur de réussir et nous les aborderons plus tard. La thèse centrale est la suivante : il est asymptotiquement difficile d’atteindre un taux de réussite de 100%. Plus l’application Stadia s’approche de ce taux de réussite, plus il est difficile de l’améliorer.
Bien sûr, tout le monde souhaite que le taux de réussite des utilisateurs soit le plus élevé possible et que l’expérience soit la meilleure de sa catégorie. Cependant, l’effort total disponible pour mettre en œuvre le flux d’installation est limité de deux façons notables.
Premièrement, le nombre de personnes travaillant sur le projet est limité et elles ne peuvent faire qu’un certain nombre de choses à la fois. Deuxièmement, il y a une quantité déterminée de temps pour compléter le projet. À un moment donné, les manettes commenceront à sortir de la chaîne de production pour arriver dans les mains des utilisateurs. Lorsque les utilisateurs recevront leur manette, ils devront être en mesure de la configurer.
Ces facteurs conduisent à des compromis entre différents aspects du flux de configuration.
Une façon d’envisager ces aspects consiste à regrouper les tâches nécessaires à l’écriture du flux en trois piliers : exactitude, fiabilité et accessibilité.
Des efforts doivent être déployés pour chacun de ces aspects, mais l’équipe ne peut pas s’investir uniquement dans un ou deux d’entre eux. Si l’un des aspects fait défaut, le flux de configuration aura l’impression d’être incomplet, voire brisé, et le succès des utilisateurs en souffrira. Au fur et à mesure que chacun de ces aspects est expliqué plus en profondeur, il devrait devenir évident que chacun d’entre eux doit être soigneusement équilibré avec les deux autres.
L’exactitude
L’exactitude est l’idée que le flux d’installation peut configurer un appareil. À un certain niveau, il s’agit d’un enjeu de taille. S’il est possible de suivre le flux et d’obtenir un matériel fonctionnant correctement à la fin, même avec un tas d’hypothèses, le flux peut être considéré comme « correct », du moins jusqu’à un certain point. Avec ce strict minimum, le flux ne fonctionnera que dans des conditions idéales très spécifiques. Si la personne assise dans la cage de Faraday mentionnée plus haut peut être satisfaite de cet état de fait, d’autres personnes peuvent ne pas l’être.
Pour que le flux de configuration soit fonctionnel pour tous nos utilisateurs potentiels, l’application doit faire le moins d’hypothèses possible. La suppression de chaque hypothèse augmente la surface sur laquelle le flux de configuration doit être correct, ce qui accroît la complexité du flux. Dès que l’application cesse de supposer que l’utilisateur ne dispose que d’une configuration Wi-Fi spécifique, le flux d’installation doit être capable de gérer plusieurs configurations. Une fois que le flux cesse de supposer que l’application a déjà invité l’utilisateur à accorder des autorisations système, nous devons commencer à vérifier chaque autorisation et inviter l’utilisateur lorsqu’une autorisation est nécessaire.
Selon une définition stricte de l’exactitude, le flux n’a pas besoin d’être gracieux ou même particulièrement utile. Il suffit que le dispositif puisse être configuré correctement, avec un ensemble donné de contraintes et d’hypothèses, et que l’utilisateur ait la possibilité de relancer le processus si quelque chose ne va pas.
De même, si un appareil peut passer par le flux de configuration et se retrouver mal configuré ou inopérant, le flux peut difficilement être qualifié de correct. Cela peut être extrêmement frustrant, c’est pourquoi identifier les cas où une mauvaise configuration peut se produire et faire le minimum pour l’éviter fait partie de cette même définition d’exactitude.
Un autre obstacle qu’il convient de noter est que la définition de « correct » pour un flux de configuration matérielle peut être une cible mouvante, en particulier lorsque le matériel est développé en même temps que le flux. Par exemple, le protocole d’installation peut être modifié ou étendu, ou il peut y avoir des différences entre les révisions du matériel qui nécessitent des changements. Par conséquent, même en visant le strict minimum, il peut être difficile d’atteindre l’exactitude.
La fiabilité
La fiabilité consiste à rendre le flux de configuration résistant aux défaillances techniques et à les corriger si possible. Plutôt que de toujours redémarrer en cas de problème, le flux d’installation devrait tenter de le résoudre en premier lieu, ou être conçu pour éviter le problème de manière proactive. La fiabilité repose sur l’exactitude et peut être beaucoup plus complexe à mettre en œuvre.
Il existe un certain nombre de situations au cours desquelles des défaillances techniques peuvent survenir. Tout d’abord, il peut y avoir des problèmes de communication sans fil. L’application Stadia communique avec la manette par Bluetooth Low Energy (BLE) et la manette se connecte par Wi-Fi pour transmettre les données pendant le jeu. Ces deux modes de communication peuvent être affectés par le bruit (si une personne vit dans un immeuble avec de nombreux réseaux Wi-Fi, par exemple) ou par la puissance du signal, ce qui peut entraîner une perte de données pendant la transmission. En d’autres termes, la communication sans fil peut échouer de manière aléatoire.
Une autre source de difficultés tient au nombre impressionnant de combinaisons de marques, de modèles et de versions de systèmes d’exploitation que nous prenons en charge. L’application Stadia est disponible à la fois sur Android et iOS, avec une prise en charge des anciennes versions de chacun d’eux, et sur de multiples facteurs de formes d’appareils. Par conséquent, il y a une grande matrice de différences logicielles potentielles devant être prises en compte. Par exemple, il existe des nuances dans la façon dont le balayage BLE fonctionne sur chaque système d’exploitation (OS), et celles-ci doivent être intégrées dans l’application pour garantir la compatibilité. Les appareils fonctionnant avec la même version de système d’exploitation peuvent également avoir des exigences différentes. Par exemple, une marque spécifique de téléphone peut nécessiter des autorisations supplémentaires pour effectuer un balayage BLE. Pour que la configuration matérielle soit réussie avec ce type de téléphone, il faut en informer l’utilisateur.
Les autres sources de défaillance peuvent être très variables. Le téléphone d’un utilisateur peut avoir une antenne peu fiable. Une manette peut être à court de batterie, ou perdre de l’énergie au milieu de la configuration. Un utilisateur peut mettre l’application en arrière-plan ou désactiver le Bluetooth pendant l’installation. Un routeur WiFi peut ne pas se connecter à la manette. Le contrôleur peut avoir une mise à jour logicielle obligatoire qui ne s’installe pas correctement. Ce sont tous des exemples de problèmes qui pourraient être pris en compte dans un flux de configuration matérielle.
Les exemples de points de défaillance sont innombrables, et il peut être difficile de se faire une idée de tout ce qui peut mal tourner. Concevoir le flux de configuration de manière à capturer ou à prévenir des catégories entières de défaillances peut empêcher les choses de devenir incontrôlables, mais certaines défaillances doivent être capturées explicitement. Cela rend la mise en œuvre et la maintenance du flux plus coûteuses, mais cela rend également le flux de configuration plus robuste, ce qui augmentera certainement le succès auprès des utilisateurs.
La convivialité
La convivialité prend toutes les difficultés introduites par les piliers de la correction et de la fiabilité et transforme le flux en quelque chose d’agréable et de compréhensible. Un flux de configuration correct et fiable peut encore être intimidant pour les nouveaux utilisateurs, et peut être trop lourd à terminer pour certains. N’oubliez pas que le flux d’installation est souvent la première impression de l’utilisateur sur le matériel et l’une de ses premières impressions de l’application. Mettre l’accent sur la convivialité signifie concevoir le flux d’installation en cherchant à masquer la complexité et à guider activement les utilisateurs dans la bonne direction.
Vous avez peut-être déjà une compréhension intuitive de cette notion de convivialité si vous avez déjà essayé une nouvelle recette. L’objectif de la recette est clair (préparer des aliments), mais la facilité avec laquelle vous atteignez cet objectif peut dépendre en grande partie de la façon dont les instructions sont présentées. Préparer des biscuits peut être frustrant si vous devez vous précipiter d’une tâche à l’autre. À l’inverse, il est possible de préparer un repas à plusieurs plats sans trop de stress si le processus est suffisamment bien expliqué. Dans ces deux exemples, l’ordre et la qualité des étapes de la recette peuvent faire ou défaire l’expérience culinaire. Si une recette est trop compliquée, vous n’aurez peut-être pas envie de la refaire, même si le résultat est délicieux. À propos : pour une bonne recette de biscuits sans gluten, consultez celle de Google Brain.
Ce même principe s’applique à la configuration d’un matériel. Le flux de configuration a un objectif connu et comporte des étapes qui doivent avoir lieu. Le défi de la convivialité consiste à organiser ces étapes de la manière la plus simple possible pour l’utilisateur.
Au fur et à mesure que des efforts sont déployés dans ce domaine, les messages d’erreur du flux de configuration peuvent être rendus plus conviviaux et explicatifs, et le flux peut devenir plus indulgent pour les erreurs courantes. De même, des étapes visant à aider les utilisateurs à résoudre les problèmes peuvent être ajoutées. Et au fur et à mesure que l’on recueille les commentaires des utilisateurs et les résultats de la recherche UX, le flux peut être ajusté pour plus de rapidité ou de clarté.
La convivialité peut également aller au-delà de la configuration matérielle elle-même. Il est important de montrer à l’utilisateur comment utiliser son appareil vers la fin du processus d’installation, car c’est l’occasion d’anticiper les questions et d’y répondre. Cela peut rendre les utilisateurs plus confiants et plus à l’aise avec l’appareil une fois qu’il est configuré. C’était particulièrement vrai pour le contrôleur Stadia. Il fonctionne de manière très différente des autres contrôleurs et se connecte à d’autres matériels de plusieurs manières (BLE, WiFi et codes de liaison). L’équipe a mis l’accent sur l’éducation des utilisateurs, mais a dû veiller à ne pas les submerger dans le processus.
À mesure que l’exactitude et la fiabilité du flux de configuration augmentent, celui-ci devient inévitablement de plus en plus complexe. Un flux de configuration qui commence simplement peut sembler beaucoup plus compliqué une fois que certains des défis techniques ont été résolus.
Diagramme de flux simplifié
Il est très facile pour une complexité de mise en œuvre de se manifester par des étapes lourdes et souvent superflues pour les utilisateurs.
Masquer la complexité dans les domaines de la correction et de la fiabilité est la clé pour maintenir le principe de convivialité et garantir un succès durable aux utilisateurs. Cela signifie qu’il ne faut montrer à l’utilisateur que ce qui est vraiment nécessaire, ne lui poser que les questions les plus pertinentes et masquer les éléments qui pourraient être déroutants, inutiles ou redondants. Souvent, cela aggrave la complexité des deux premiers axes, car les développeurs doivent assumer une plus grande part de responsabilité dans le flux, qu’il faut alors à nouveau masquer pour favoriser la réussite de l’utilisateur.
Le succès de l’utilisateur dépend de l’équilibre à trouver entre ces différents éléments.
C’est pourquoi la configuration du matériel est si difficile. Il y a une quantité quasi infinie de travail qui pourrait être effectuée pour gérer toutes les conditions de défaillance possibles, ou pour itérer sur l’expérience utilisateur. Maximiser un aspect particulier ne conduira pas à un niveau élevé de succès pour l’utilisateur, et en fait, cela pourrait nuire sérieusement aux autres aspects.
Comme indiqué précédemment, il n’est pas possible d’atteindre le succès universel. L’objectif est plutôt de se rapprocher le plus possible du succès universel avec le temps et les efforts disponibles. La difficulté d’atteindre cet objectif réside dans la manière dont l’effort est appliqué. En faisant preuve de discernement quant aux points les plus utiles pour appliquer l’effort, l’équipe pourra trouver la voie idéale vers le succès universel.
De même, faire des choix judicieux sur la façon dont ces concepts, diagrammes et réflexions sont traduits en code, et sur la façon dont ce code est organisé, peut considérablement ajouter ou supprimer de la complexité au flux de configuration.
La traduction des écrans eux-mêmes en code n’est que la première des nombreuses étapes. Il faut ensuite naviguer entre les écrans et, comme nous l’avons vu précédemment, les chemins possibles entre les écrans dans le flux peuvent devenir extrêmement compliqués. Ensuite, l’application doit avoir un moyen de communiquer avec le contrôleur. Ajoutez à cela le fait que l’application doive stocker la progression actuelle du flux de configuration et déterminer le chemin à suivre en fonction de ce que font l’utilisateur et le contrôleur. Enfin, considérez toutes les circonstances particulières et les erreurs ou défaillances possibles qui peuvent survenir à n’importe quel moment du flux, et qui nécessitent toutes des déviations par rapport au chemin idéal.
De bonnes décisions de conception peuvent réduire considérablement l’effort nécessaire pour mettre en œuvre des améliorations au flux de configuration. Au cours du projet, cela se traduit directement par une plus grande réussite pour les utilisateurs.
Lors de l’écriture du flux de configuration du contrôleur Stadia, l’équipe a fait des choix qui nous ont permis de faire exactement cela. Nous avons été en mesure de gérer la complexité du flux à mesure qu’il prenait de l’ampleur, nous avons obtenu des gains de productivité massifs en utilisant Flutter, et nous avons investi ces avantages dans une meilleure expérience pour nos utilisateurs. Dans la suite de cette série, nous aborderons tous ces sujets. Revenez pour le prochain post la semaine prochaine pour découvrir comment nos décisions d’architecture nous ont aidés à gérer la complexité du flux de configuration.
Nick Sparks, ingénieur logiciel