La plupart des conseils sur les polices de caractères sont écrits pour la prose — de longues lignes de bas-de-casse lues à loisir. Les applications à hautes performances vivent dans un autre régime : des nombres balayés en colonnes, des identifiants lus une seule fois d'un coup d'œil, des étiquettes de onze pixels sur des écrans que quelqu'un surveille pendant huit heures. Une police ravissante dans un essai peut être activement dangereuse sur un écran de trading. Voici ce qu'il faut interroger à la place.
Les chiffres d'abord, les lettres ensuite
Dans une interface dense en données, ce sont les chiffres qui font l'essentiel du travail, alors auditez-les avant toute autre chose :
- Les chiffres tabulaires sont non négociables. Chaque chiffre à la même chasse, pour que les colonnes tiennent et qu'une valeur qui défile ne fasse pas trembler ses voisines. Le CSS tient en une ligne —
font-variant-numeric: tabular-nums lining-nums— mais seulement si la police possède la fonctionnalité. Beaucoup de polices à la mode ne l'ont pas. - Des chiffres modernes, pas elzéviriens. Les chiffres elzéviriens, avec leurs ascendantes et leurs descendantes, sont magnifiques dans la prose et chaotiques dans un tableau.
- Des chasses stables d'une graisse à l'autre. Si les chiffres gras sont plus larges que les romains, chaque cellule mise en valeur casse sa colonne. Les meilleures polices d'interface dessinent toutes les graisses sur une même chasse — et l'axe de grade d'une fonte variable (la graisse sans changement de chasse) est la solution la plus propre de toutes, comme le montre le chapitre d'Universal Web sur les fontes variables.
L'alphabet de l'interface
Les interfaces regorgent de chaînes qui doivent être lues correctement exactement une fois : numéros de commande, hachés git, clés d'API, montants. Pour celles-là, le jeu de caractères confusibles est tout l'enjeu — 0/O, 1/l/I, 5/S, 8/B. Testez-les au corps de production avant de regarder la moindre page de spécimen. Les polices qui réussissent le test ont tendance à l'afficher : zéros barrés ou pointés, l à queue, ouvertures élargies. C'est le même argument d'anatomie de la lisibilité que l'Universal Web avance pour les lecteurs malvoyants — une interface à 11px place chaque utilisateur en condition de basse acuité.
La liste de contrôle
Ce que je fais réellement subir à une police candidate avant qu'elle ne soit livrée dans une application :
1. Composez un vrai tableau — données réelles, tabular-nums activé — et regardez une valeur défiler. Rien ne doit bouger, sauf les chiffres.
2. Le test de l'alphabet : 0O 1lI 5S 8B rn/m au plus petit corps de production, sur les deux thèmes.
3. La hauteur d'x à 11–13px. Les polices à petite hauteur d'x s'effondrent exactement là où vivent les interfaces. Une hauteur d'x généreuse achète du corps effectif gratuitement.
4. La graisse en thème sombre. Le clair sur sombre se lit une demi-graisse plus gras ; si la police n'a ni axe de grade ni version plus légère pour compenser, chaque étiquette devient molle. (Le chapitre sur le mode sombre en explique la physique.)
5. Le grep des fonctionnalités : tnum, lnum, zero, case — vérifiez les fonctionnalités OpenType réellement présentes, pas celles que la page marketing laisse entendre.
6. La classe de poids en performance. Tout cela doit arriver dans un ou deux fichiers WOFF2 assez petits pour ne pas faire barrage aux données qu'ils étiquettent — le sujet du prochain essai.
Le motif de cette liste de contrôle est le motif de toute cette discipline : dans les applications, la typographie se mesure en erreurs évitées par pixel, pas en beauté par spécimen. Choisissez la police qui échoue à se faire remarquer dix mille lectures d'affilée.