Trois paramètres que nous avons délibérément choisi de ne pas inclure

Chaque application accumule des paramètres comme une maison s'encombre de bric-à-brac : lentement, imperceptiblement, petit à petit, à chaque ajout bien intentionné. Il en résulte un écran « Paramètres » que personne ne lit et un produit dont la signification varie légèrement d'un utilisateur à l'autre.

Chaque paramètre semble anodin pris isolément. Il s’agit d’un simple commutateur, désactivé par défaut, que personne n’est obligé de modifier. Mais chaque commutateur double le nombre de comportements possibles de l’application, et quelqu’un doit tous les tester, sur chaque plateforme, dans chaque langue. Pour une petite équipe qui déploie ses applications sur iPhone, Android, Windows et le navigateur, cette multiplication fait toute la différence entre une mise en production prudente et une mise en production hasardeuse.

Trois options que nous avons toujours refusé d'ajouter, même lorsqu'on nous l'a demandé :

1. Le choix entre deux processus d'intégration

Si nous n'arrivons pas à déterminer lequel est le meilleur, c'est qu'aucun des deux n'est assez bon pour être commercialisé.

La demande émane généralement de l'équipe elle-même plutôt que des utilisateurs : deux personnes préfèrent deux versions différentes, et un paramètre semble être une solution diplomatique. Ce n'est pas le cas. Un nouvel utilisateur ne connaît pas suffisamment l'application pour choisir la manière dont il souhaite la découvrir. Nous continuons donc à travailler jusqu'à ce qu'un parcours se révèle clairement meilleur, et c'est celui-là que nous lançons.

2. Un bouton bascule pour le nouveau design

Soit la nouvelle version constitue une amélioration et l'ancienne est supprimée, soit elle n'est pas encore prête. Un bouton bascule permet d'éviter de prendre cette décision — mais cela double indéfiniment notre charge de travail en matière d'assurance qualité.

Nous comprenons pourquoi les gens se posent cette question. Une refonte modifie la mémoire musculaire, ce qui est véritablement perturbant. Notre réponse consiste à rendre la transition plus en douceur plutôt que de la laisser au choix de l’utilisateur : conserver les éléments à leur emplacement d’origine lorsque c’est possible, expliquer ce qui a été déplacé et laisser le temps à la nouvelle version de faire ses preuves avant de la juger. Si, après cela, la refonte s’avère toujours moins bien adaptée à la plupart des utilisateurs, la solution la plus honnête est de la corriger ou de revenir à la version précédente — et non de maintenir deux applications au sein d’une seule.

3. Une option “ Réduire les animations ”

iOS en propose déjà une, à l'échelle du système, que nous respectons. En ajouter une deuxième dans nos réglages reviendrait à faire double emploi et à admettre tacitement que nos animations par défaut sont agaçantes. Mieux vaut corriger ces animations.

Il en va de même pour nos autres plateformes. Android, Windows et les navigateurs disposent chacun de leurs propres paramètres système permettant de réduire les animations, et notre rôle est de les respecter plutôt que d’en créer un autre en parallèle. Une personne qui a désactivé les animations une seule fois, pour l'ensemble de son appareil, ne devrait pas avoir à le refaire dans chaque application qu'elle installe.

Ce que nous ajoutons

Il ne s'agit pas d'une règle contre les paramètres de configuration. Nous en ajoutons un lorsque les utilisateurs ont réellement besoin d'un comportement différent pour des raisons que nous ne pouvons pas anticiper dans notre conception : les unités de mesure, le premier jour de la semaine, la disposition du clavier sur laquelle quelqu'un apprend à taper. La question que nous nous posons est de savoir si un paramètre reflète une réelle différence entre les utilisateurs, ou s'il s'agit simplement d'une décision que nous n'avons pas encore prise.

Nos points faibles

Nous n’avons pas toujours su rester cohérents. Nous avons intégré des paramètres qui, au départ, n’étaient qu’une réponse rapide à une demande ponctuelle, mais qui sont restés bien après que tout le monde ait oublié pourquoi ils avaient été créés. Il est plus difficile de les supprimer par la suite que de ne pas les ajouter, car à ce moment-là, chacun compte déjà sur chacun d’entre eux.

Refuser des modifications, c'est un travail à part entière. C'est juste que ça n'apparaît dans aucun message de commit.