La télécommande comme seul périphérique d'entrée

Sur le web, le pointeur fait énormément de travail invisible. Il permet d'atteindre n'importe quel point de l'écran en un geste, il révèle des informations au survol, il rend le défilement continu et naturel. Retirez-le et il ne reste que quatre flèches, une touche OK et une touche retour. Toute la conception d'interface change.

Le focus devient l'architecture

Sur un décodeur, exactement un élément a le focus à tout instant, et toute la navigation consiste à déplacer ce focus. Il n'y a pas d'état intermédiaire, pas de position de pointeur indépendante de la sélection, pas de survol. Ce qui est un détail d'accessibilité sur le web devient ici la structure centrale de l'application.

Ça a des conséquences immédiates. Chaque élément interactif doit savoir dire s'il peut recevoir le focus — un bouton désactivé doit être sauté, pas seulement grisé. Chaque écran doit déclarer où va le focus quand on y arrive, et où il retourne quand on en repart: revenir dans une liste et retrouver le focus au premier élément plutôt qu'à celui d'où on était parti est l'un des irritants les plus universellement détestés. Et le focus ne doit jamais disparaître: un écran sans élément focalisé est un écran où la télécommande ne fait plus rien, et l'abonné conclut que le boîtier est gelé.

Décider où va le focus

Quand l'abonné appuie sur Droite, quelque chose doit choisir le prochain élément. Deux approches coexistent, et le choix entre les deux structure le reste du code.

L'approche géométrique calcule. On prend la position de l'élément actuel, on projette un cône dans la direction demandée, on garde les candidats qui s'y trouvent et on choisit le plus proche selon une pondération qui privilégie l'alignement sur l'axe. C'est élégant, ça ne demande aucune déclaration, et ça s'adapte tout seul quand la mise en page change.

Ça se dégrade aussi de façon imprévisible. Sur une grille irrégulière — des vignettes de tailles différentes, une rangée mise en vedette plus haute que les autres, un élément qui déborde — le candidat géométriquement le plus proche n'est pas toujours celui que l'abonné visait. Le pire est que ces anomalies ne se reproduisent pas: elles dépendent des données réelles, donc elles apparaissent en production sur un catalogue que personne n'avait en développement.

L'approche par graphe explicite déclare les liens: depuis cet élément, Droite mène à celui-là. C'est verbeux, c'est du travail de maintenance à chaque changement de mise en page, et ça devient rapidement pénible sur du contenu dynamique. Mais c'est déterministe, testable, et ça ne surprend jamais.

En pratique, la solution qui tient la route est hybride: le calcul géométrique par défaut à l'intérieur d'une zone homogène — une rangée, une grille régulière — et des liens explicites aux frontières entre zones, là où la géométrie se trompe. On paie le coût de la déclaration seulement là où elle rapporte.

Les touches qui ne vous appartiennent pas

Une application de décodeur ne reçoit pas tout ce que l'abonné appuie. Le volume, la sourdine, l'alimentation, la touche d'accueil, souvent le changement de chaîne: le middleware les intercepte et n'en transmet rien. C'est voulu — l'abonné doit pouvoir couper le son ou revenir à l'accueil quoi qu'il arrive, y compris si l'application est bloquée.

Il faut donc concevoir en supposant qu'on peut être quitté à tout moment sans préavis, et ne jamais construire un flux dont on ne sort qu'en allant jusqu'au bout.

Deuxième piège: les codes de touches varient. Un même bouton peut arriver avec des valeurs différentes selon le modèle de télécommande, la génération de boîtier ou le fournisseur. Une application qui compare directement des codes numériques dispersés dans le code fonctionnera sur le boîtier de développement et échouera ailleurs. La discipline à imposer tôt est de traduire les codes en intentions — «haut», «valider», «retour» — en un seul endroit, et de ne jamais laisser un code brut se répandre dans la logique applicative.

La règle des trois mètres

Une interface de téléviseur est lue à deux ou trois mètres, souvent le soir, dans une pièce sombre, par quelqu'un qui n'a pas envie de faire un effort. Tout doit grossir: les tailles de police, les zones cliquables, les espacements.

L'indicateur de focus mérite une attention particulière, parce que c'est là que les maquettes échouent le plus souvent. Un contour fin et discret peut être magnifique sur un écran de conception à cinquante centimètres et parfaitement invisible depuis un divan. Sur un décodeur, le focus est la seule information qui dit à l'abonné où il se trouve: il doit se voir en un dixième de seconde, en périphérie du regard, et sur toutes les images de fond possibles. Une bordure lumineuse doublée d'un changement d'échelle fonctionne mieux qu'une nuance de couleur, qui disparaît sur les affiches sombres.

Le coût de la profondeur

Sur le web, ajouter un niveau de menu coûte un clic, et le clic est presque gratuit puisqu'on atteint n'importe quoi directement. Avec une télécommande, atteindre le troisième élément d'un sous-menu situé au deuxième niveau peut demander huit ou dix appuis, chacun avec sa petite latence d'animation.

C'est pourquoi le nombre d'appuis est la mesure d'ergonomie la plus utile sur un décodeur, plus que le nombre de clics ou le temps passé. Une fonction qui se rejoint en trois appuis est utilisée; la même à neuf appuis ne l'est pas, quelle que soit sa qualité. Compter les appuis sur les cinq parcours les plus fréquents, avant d'écrire du code, révèle plus de problèmes de conception que n'importe quelle revue de maquette.

C'est l'exercice que je recommande à toute équipe qui aborde le téléviseur pour la première fois. Prendre sa maquette, prendre les cinq choses que l'abonné fait vraiment tous les jours, et compter. Le résultat est presque toujours inconfortable, et c'est exactement l'information qu'on voulait.