Résumé

Le tactile introduit une dimension physique dans des designs qui étaient jusqu’à présent
strictement virtuels et pose un nouveau défi : comment ce design se prend-il en main ?
Web designers, il vous faut désormais penser autrement, et Josh Clark est là pour vous
guider dans le Far West des écrans tactiles. Apprenez des principes d’ergonomie, de mise
en page et de dimensionnement pour tous les écrans, découvrez une boîte à outils gestuelle
émergente, ainsi que des tactiques pour accélérer les interactions et améliorer la «
découvrabilité » des gestes. Au final, concevez des interfaces qui permettront de toucher –
étirer, froisser, déplacer, retourner – les informations elles-mêmes. Le futur est entre vos
mains…

Au sommaire Une interface physique * Mélange de design numérique et de design

industriel * Prise en main * Mises en page * Un écran peu fiable * Concevoir pour les
écrans tactiles et les curseurs * La taille idéale : 7 mm * Emplacement : mise en page et
taille des cibles * Cibles tactiles d’au moins 44 (pixels, points ou dp) * J’aime l’em * Ceci
n’est pas un pixel (la sournoiserie des viewports) * Des doigts plus rapides * Dégrossir le
scrolling * L’abus de carrousels nuit à la santé * Soyez impitoyables avec les champs de
formulaires * Le bon clavier pour la bonne tâche * La lourdeur de * Gestes * Vocabulaire
gestuel de base * Des gestes pensés comme des raccourcis clavier * Le click, c’est
magique * CSS pour faire défiler les galeries et les carrousels * Gérer le délai de 300 ms *
Rattrapage gestuel * Découverte * Design skeuomorphique * Quand le design tombe à
plat * Jouez à plus de jeux vidéo *
www.editions-eyrolles.com
Josh Clark

DESIGN
TACTILE
ÉDITIONS EYROLLES
61, bld Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com
Attention : la version originale de cet ebook est en couleur, lire ce livre numérique sur un support de lecture noir
et blanc peut en réduire la pertinence et la compréhension.
Traduction autorisée de l’ouvrage en langue anglaise intitulé Designing for touch de Josh Clark (ISBN : 978-1-9375572-
9-4), publié par A Book Apart LLC
Adapté de l’anglais par Charles Robert
© 2015 Josh Clark pour l’édition en langue anglaise
© Groupe Eyrolles, 2016, pour la présente édition, ISBN : 978-2-212-14391-1
Dans la même collection
HTML5 pour les web designers - n°1, Jeremy Keith, 2010, 96 pages.
CSS3 pour les web designers - n°2, Dan Cederholm, 2011, 128 pages.
Stratégie de contenu web - n°3, Erin Kissane, 2011, 96 pages.
Responsive web design - n°4, Ethan Marcotte, 2011, 160 pages.
Design émotionnel - n°5, Aarron Walter, 2012, 118 pages.
Mobile first - n°6, Luke Wroblewski, 2012, 144 pages.
Métier web designer - n°7, Mike Monteiro, 2012, 156 pages.
Stratégie de contenu mobile - n°8, Karen McGrane, 2013, 164 pages.
La phase de recherche en web design - n°9, Erika Hall, 2015, 176 pages.
Sass pour les web designers - n°10, Dan Cederholm, 2015, 96 pages.
Typographie web - n°11, Jason Santa Maria, 2015, 160 pages.
Web designer cherche client idéal - n°12, Mike Monteiro, 2015, 152 pages.
Design web responsive et responsable - n°13, Scott Jehl, 2015, 206 pages.
Le code de la propriété intellectuelle du 1er juillet 1992 interdit en effet expressément la photocopie à usage collectif
sans autorisation des ayants droit. Or, cette pratique s’est généralisée notamment dans les établissements
d’enseignement, provoquant une baisse brutale des achats de livres, au point que la possibilité même pour les auteurs de
créer des œuvres nouvelles et de les faire éditer correctement est aujourd’hui menacée. En application de la loi du 11
mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce
soit, sans autorisation de l’éditeur ou du Centre Français d’Exploitation du Droit de Copie, 20, rue des Grands
Augustins, 75006 Paris.
TABLE DES MATIÈRES
Avant-propos
Introduction
CHAPITRE 1
Une interface physique
CHAPITRE 2
Un écran peu fiable
CHAPITRE 3
Des doigts plus rapides
CHAPITRE 4
Gestes
CHAPITRE 5
Découverte
Ressources
Remerciements
Références
Index
Pour la Team Awesome
AVANT-PROPOS
SANS CRIER GARE, le barrage a cédé, déversant un torrent apparemment infini de rectangles
de verre de différentes tailles sur un public incrédule. Nous autres, designers de ce monde,
n’avions pas d’autre choix que d’agiter les bras pour essayer de rester à flot dans cet océan
de nouveaux appareils.
Mais nous sommes parvenus à garder la tête hors de l’eau, et nous avons lentement
mais sûrement commencé à intégrer ces nouveaux supports mobiles. Les designers natifs
ont mordu à pleines dents et se sont mis à explorer les capacités uniques de ces appareils,
créant des expériences qui ont repoussé les limites du support vers des contrées encore
plus extraordinaires. Et sur le front du Web, nous avons vu apparaître le responsive design,
qui permet aux designers de réorganiser les mises en page de sorte qu’elles s’adaptent et
fonctionnent parfaitement sur n’importe quel appareil, quelle que soit la taille de son
écran. De nos jours, ces sites malléables abondent sur le Web, et les designers ont un
arsenal d’outils à leur disposition pour s’assurer que leurs mises en page marchent sur les
téléphones, les tablettes et tous les appareils intermédiaires. Mission accomplie, non ?
Si seulement c’était aussi simple… Car voyez-vous, les mises en page adaptatives ne
sont qu’une pièce de ce puzzle géant. Le fait est que nous utilisons également ces
nouvelles interfaces avec ces » saucisses » que sont nos doigts. En tant que designers, cela
nous » pouce » (ha ha…) à créer des interfaces qui sont non seulement visualisables sur
des écrans de tailles différentes, mais également utilisables du bout du doigt.
L’ergonomie, la posture, le contexte et la nature tactile de ces interactions ont des
conséquences réelles sur la façon dont nos utilisateurs ressentent nos designs. Un design
peut s’afficher correctement sur un smartphone, mais quelle sensation procure-t-il ? Il est
d’une importance capitale de prendre en compte les interactions tactiles, car de plus en
plus d’écrans présents dans nos vies offrent des capacités tactiles, mais où peut-on
apprendre à réaliser des designs qui répondent au doigt et à l’œil ?
Vous avez de la chance, car Josh est précisément là pour apporter sa touche concernant
ces sujets.
Josh Clark est une véritable mine d’informations sur le design tactile, et il a la capacité
inouïe de pouvoir aborder les principes généraux comme les détails les plus précis avec
clarté et franchise. Dans ce livre, Josh vous aide à comprendre les principes fondamentaux
du design tactile, ainsi que les contraintes et les opportunités qu’offrent les plateformes
natives et le Web. Il vous donne des règles d’ordre général, mais également des conseils
plus pragmatiques quand il est préférable de transgresser ces règles.
Josh ne se contente pas de vous impartir ses années d’expérience pratique durement
acquise en matière de design tactile ; il vous les offre avec un esprit et un enthousiasme
pour le sujet qui est tout simplement contagieux. Je suis certain que, quand vous aurez fini
ce livre, votre cerveau foisonnera d’idées pour atteindre le nirvana du design à grand
renfort de tap, de pinch, de swipe et de scroll. Bonne lecture !
Brad Frost
INTRODUCTION
PENDANT DES DÉCENNIES, nous avons exploré le monde numérique avec des prothèses que
l’on nommait souris, clavier et curseur. Nous appuyions sur des petites briques en
plastique, assis à notre bureau. Nous déplacions des curseurs à l’écran pour activer des
boutons à distance. Nous cliquions sur des icônes. Nous pointions des pixels.
Mais soudain, nous avons eu ces pixels entre les mains. Grâce aux smartphones, des
milliards de personnes se servent d’écrans tactiles chaque jour. Aujourd’hui, nous
touchons les informations elles-mêmes : nous les élargissons, nous les réduisons, nous les
déplaçons, nous les feuilletons. Ce sentiment d’interaction directe change notre façon de
faire face au monde numérique, et il exige des designers qu’ils adoptent de nouvelles
techniques et de nouvelles perspectives. Le toucher introduit la perception physique dans
des designs qui étaient autrefois strictement virtuels ; pour la première fois, les designers
numériques doivent se poser la question : comment ce design peut-il être pris en main ?
C’est à ce sujet que ce livre est consacré. Les écrans tactiles sont partout : dans les
taxis, sur les distributeurs de boissons, les montres, les sièges d’avion, les miroirs des
vestiaires, et bien sûr tous les gadgets que nous » trimballons » dans nos poches et nos
sacs à main. Près de la moitié des Américains ont acheté une tablette à écran tactile entre
2010 et 2014 ; en 2011, Apple a vendu plus d’iPad en une seule année que de Mac au
cours des vingt-huit années précédentes (http://bkaprt.com/dft/00-01/,
http://bkaprt.com/dft/00-02/). Et le tactile est parvenu jusqu’au bureau, avec des appareils
hybrides tablette/ordinateur portable qui combinent clavier, pointeur et écran tactile.
Malgré ce déluge d’appareils tactiles, la plupart des sites web restent obstinément
optimisés pour la souris et le curseur, et il est grand temps que les designers rattrapent leur
retard en la matière. Le responsive design a provoqué une onde de choc sur le Web en
établissant cette simple vérité : le Web ne se limite pas à un seul format de sortie (l’écran
de bureau). Et maintenant, voilà une autre révélation : le Web ne se limite pas à un seul
format d’entrée. L’écran tactile n’est qu’un élément d’une chorégraphie complexe de
modes de saisie pouvant inclure le clavier, la souris, le pavé tactile, les gestes naturels à la
Kinect, la commande vocale, le stylet ou les boutons de tableau de bord, ainsi que les
capteurs embarqués tels que la caméra, le micro, le GPS et bien d’autres. Ce savant
mélange affecte non seulement la mise en page, mais également le concept fondamental de
votre design. Le design tactile ne se limite pas à créer de plus gros boutons pour les doigts
boudinés.
Ce petit volume vous donnera de solides bases pour la plupart de vos projets tactiles,
détaillant les facteurs de forme les plus populaires : téléphones, tablettes, phablettes et
ordinateurs hybrides. Je décrirai de quelle façon les impératifs de design changent en
fonction de l’environnement logiciel, et comment les designs doivent s’adapter pour
prendre en compte les modes de saisie non tactiles.
Cela nécessitera de revoir – et dans bien des cas de faire passer à la trappe – les
solutions courantes des trente dernières années de design d’interface traditionnel. Vous
découvrirez des méthodes entièrement nouvelles, notamment des modèles de design, des
indicateurs tactiles, des conseils d’ergonomie et des métaphores d’interaction que vous
pourrez utiliser dès à présent dans vos sites web et vos applications. L’héritage et les
sources de ces techniques vous surprendront peut-être. Nous emploierons des modèles de
design inspirés d’appareils vintage. Nous décortiquerons des jeux vidéo et des tableaux de
bord pour en tirer des leçons d’interaction. Au fil de ces pages, vous apprendrez à faire
connaître des gestes invisibles, vous découvrirez le pouvoir subtil de l’animation, et vous
verrez pourquoi un enfant peut potentiellement être votre meilleur bêta-testeur. Alors,
faites craquer vos doigts, retroussez vos manches, et mettons-nous au travail.
LE NOUVEAU TÉLÉPHONE était une vraie merveille, le produit d’une entreprise
technologique renommée. Il fonctionnait d’une tout autre façon que ses prédécesseurs,
mais il charmait les novices comme les technophiles. Les observateurs de l’industrie le
qualifièrent d’intuitif, d’efficace, d’amusant même. Le gadget devint rapidement un
symbole de prestige que peu de gens avaient les moyens de s’offrir. Au fil du temps, tout
le monde s’en est acheté un, et son fonctionnement est devenu si naturel que nous avons
aujourd’hui du mal à imaginer qu’un téléphone puisse marcher autrement.
Nous étions en 1963, et l’appareil en question était le téléphone à clavier de Bell
Telephone.
Une interface à boutons poussoirs remplaçait le cadran rotatif, et des millions de
personnes découvrirent les joies du clavier numérique. Il nous paraît aujourd’hui si
familier, et pourtant son agencement n’avait rien d’évident à l’époque. Pour en arriver là,
les chercheurs de Bell ont testé seize variantes du clavier, à la recherche du design qui
permettait la numérotation la plus rapide et la plus fiable.
FIG 1.1 : Les chercheurs de Bell ont testé seize agencements différents, trois par trois, répartis dans six groupes, pour
leur nouveau » poste téléphonique à boutons poussoirs ».

« Nous aimerions tout particulièrement savoir comment le concept de boutons

poussoirs influe sur la vitesse, la précision et les préférences de numérotation des
utilisateurs », écrivirent les chercheurs (http://bkaprt.com/dft/01-01/). » Dans quelle
mesure les performances s’améliorent-elles avec la pratique ? Et existe-t-il des procédures
systématiques que les utilisateurs suivent pour composer des numéros ? » Pour le
déterminer, ils ont aligné les boutons suivant différentes formes – un arc-en-ciel, une
croix, une diagonale, un cercle, et même une cible – avant d’opter pour la grille que nous
connaissons aujourd’hui (FIG 1.1). Ils ont joué sur la taille, l’espacement et la typographie
des boutons afin de réduire les erreurs et d’optimiser la vitesse de numérotation, mesurée
avec une grande précision. Ils ont demandé aux utilisateurs d’évaluer le confort du clavier
numérique afin de déterminer la tension optimale des boutons et le clic émis par chaque
pression.
Si les designers de Bell Telephone s’intéressaient à l’agencement visuel du clavier, ils
étaient bien plus préoccupés par sa perception, le contexte physique de son utilisation.
Revenons à nos jours et à notre nouvelle génération de téléphones tactiles et d’appareils
personnels, et nous voyons que les designers numériques et les chercheurs d’aujourd’hui
apprennent à nouveau des leçons similaires.
DESIGN TACTILE : UN MÉLANGE DE DESIGN NUMÉRIQUE ET DE
DESIGN INDUSTRIEL
Un téléphone ou une tablette est une dalle de verre (littéralement une ardoise vierge) qui
nous invite à lui imposer une interface de notre choix. Concevoir pour l’écran n’a rien de
nouveau pour les designers numériques ; la différence, c’est que maintenant, ces designs
doivent tenir compte de nos doigts et de nos pouces. Comment vos pixels se prennent-ils
en main ?
Cette dimension physique essentielle nous invite à aller au-delà d’un design strictement
visuel et à nous inspirer d’autres disciplines de design. Lorsque nous nous aventurons dans
le design tactile, nous touchons presque au design industriel – l’art de créer des objets
physiques. De la même façon que les objets du monde réel déçoivent lorsqu’ils sont
physiquement inadaptés, vos interfaces tactiles échoueront si leur prise en main est
inconfortable. Ce croisement entre les doigts et le numérique est au cœur du design tactile.

Comment nous tenons nos gadgets

Où les mains et les doigts tombent-ils sur l’appareil ? Cette question est la pierre angulaire
de tous les facteurs de forme abordés dans ce livre, et la réponse vous permettra de
concevoir une mise en page confortable et efficace. Comme nous tenons nos téléphones,
nos tablettes, phablettes et ordinateurs portables de manières très différentes, il n’est pas
surprenant que chaque variante de ces écrans tactiles ait ses propres besoins en matière
d’interface utilisateur.
Cependant, ces appareils ont également de nombreux points communs,
particulièrement pour ce qui est du rôle crucial des pouces. Que nous utilisions un
téléphone minuscule ou une grosse tablette, ce sont nos pouces qui font le gros du travail.
Ce fait nous permet d’établir des lignes directrices solides qui transcendent les appareils.
Ce chapitre examinera pourquoi le pouce est si important et révèlera quelques règles
d’ordre général basées sur notre façon de tenir des écrans de toutes tailles.
Le smartphone est bien sûr l’appareil que nous utilisons le plus. Nos yeux sont rivés
dessus plus de 20 % du temps, et nous le consultons 221 fois par jour en moyenne
(http://bkaprt.com/dft/01-02/). Commençons donc par le plus familier de nos gadgets.
PRISE EN MAIN DU TÉLÉPHONE
En 2013, le chercheur Steven Hoober est descendu dans la rue et a observé plus de 1 300
personnes tapoter sur leur téléphone (http://bkaprt.com/dft/01-03/). Il a découvert que la
presque totalité des gens tenait leur téléphone de trois façons différentes. La prise la plus
populaire, utilisée par 49 % des gens, était la prise à une main ; 36 % des gens tenaient
leur téléphone d’une main et se servaient de l’autre pour interagir avec l’écran ; et 15 %
adoptaient la posture de » prière » typique du BlackBerry, tapant avec les deux pouces
(FIG 1.2).

FIG 1.2 : L’usage des smartphones est défini par trois prises de base, et nous passons souvent de l’une à l’autre.

Cette étude confirme également ce que bon nombre d’entre nous peuvent déduire de
nos propres habitudes : nous changeons de prise fréquemment, en fonction du contexte et
des besoins de l’instant. Nous passons d’une prise à une main à une prise à deux mains, ou
de la main droite à la main gauche ; parfois, nous tapotons distraitement en faisant autre
chose, avant de nous arrêter pour consacrer toute notre attention à l’écran. Et par ailleurs,
nous sommes aussi habiles des deux mains. Hoober s’est aperçu que deux tiers des prises
à une main se faisaient de la main droite : c’est la majorité, mais cette proportion reste
inférieure à celle du nombre de droitiers (90 %). Cela signifie que bon nombre d’entre
nous privilégient notre main faible, tout en utilisant l’autre main pour écrire, boire du café,
tenir un bébé ou lire un livre sur le design tactile.
Ainsi, si nous sommes peu nombreux à garder tout le temps la même prise, nous avons
une claire préférence pour l’usage à une main. Et c’est là que notre pouce entre en jeu.
Quand nous tenons notre téléphone d’une seule main, le pouce est le seul doigt disponible
pour tapoter confortablement. Même lorsque nous utilisons nos deux mains, nous
préférons souvent tripatouiller notre écran avec le pouce. Chez les personnes qui tiennent
leur téléphone d’une main et touchent l’écran de l’autre, Hoober a découvert que la plupart
utilisaient leur pouce. Si l’on combine toutes ces personnes, le résultat est sans appel :
75 % des interactions sont effectuées avec le pouce (FIG 1.3).

FIG 1.3 : On parle souvent de design » finger-friendly », mais c’est le pouce qui fait l’essentiel du travail.
La zone du pouce
Si le pouce peut atteindre la quasi-totalité de l’écran sur les téléphones, sauf les plus
surdimensionnés, le territoire demandant le moins d’effort ne représente qu’un tiers de
l’écran. Par exemple, si vous tenez un téléphone dans la main droite, votre pouce tombe
naturellement dans un arc partant du coin inférieur gauche de l’écran, sans qu’il soit
nécessaire d’étirer le pouce ou d’incliner votre téléphone. Ce même arc s’applique à la
prise à deux mains, mais l’arc est plus grand car le pouce peut effectuer des mouvements
d’une plus grande amplitude.
Confort et précision ne concordent toutefois pas parfaitement. Au sein de cette zone de
confort, un deuxième arc en forme d’éventail recouvre les cibles les plus précises à portée
de pouce, comme relevé par une étude de Qian Fei d’Alibaba (http://bkaprt.com/dft/01-
04/, souscription requise). Celle-ci a également découvert que pour les utilisateurs
droitiers, le bas de l’écran et le coin inférieur droit étaient les zones les moins précises
pour un usage au pouce (FIG 1.4).

FIG 1.4 : La zone en vert est la région la plus confortable et la plus précise pour les personnes utilisant leur téléphone
d’une main. Évitez la zone en rouge, ou compensez au moins en utilisant des cibles de plus grande taille.

Et qu’en est-il des gauchers ? La zone couverte par le pouce passe de gauche à droite,
mais cette distinction n’est pas vraiment cruciale, puisque la plupart d’entre nous alternent
entre la main gauche et la main droite facilement (et fréquemment) selon le contexte. Et de
toute façon, en optimisant pour une main, on risque de pénaliser l’autre : la meilleure
solution consiste à placer les fonctionnalités principales au centre de l’écran, là où les
zones des pouces de droite et de gauche se superposent. Au final, la distinction entre le
haut et le bas est plus importante que la distinction entre la gauche et la droite. Quelle que
soit la main que vous utilisez, le bas de l’écran est plus confortable, alors que le haut
demande un effort. Cette règle vaut pour tous les écrans, petits et grands, mais sur les
téléphones de plus grande taille, la partie supérieure de l’écran est encore plus ardue.
LA PHABULEUSE PHABLETTE
La première génération d’appareils post-iPhone comportait systématiquement des écrans
de moins de quatre pouces de diagonale, une taille pratique pour un usage à une main.
Vers la mi-2014, cependant, un tiers des usages du Web mobile s’effectuait sur des écrans
de plus grande taille, avec l’arrivée de téléphones plus grands sur le marché
(http://bkaprt.com/dft/01-05/). Ces téléphones géants venaient combler le vide entre
téléphone et tablette, catégorie affublée du nom douteux de » phablette », avec des écrans
pouvant atteindre sept pouces de diagonale (FIG 1.5). Mon Dieu, qu’est-ce qu’ils
grandissent vite nos petits téléphones ! Et s’élargissent. Et s’épaississent.

FIG 1.5 : Le Galaxy W 7” de Samsung et autres portables de grande taille brouillent la démarcation entre téléphone et
tablette. Photo reproduite avec l’aimable permission de Samsung (http://bkaprt.com/dft/01-06/).

FIG 1.6 : Si aucune des prises faisant usage du pouce n’est aussi courante que l’usage de l’index sur les phablettes, elles
représentent conjointement beaucoup plus d’activité.

Malgré les proportions gargantuesques des phablettes, les gens les manipulent
généralement comme des téléphones, et les trois prises de base s’appliquent toujours.
Cependant, contrairement aux téléphones plus petits, les utilisateurs de phablettes
changent de prise bien plus souvent pour couvrir l’intégralité de l’écran, et il est presque
toujours nécessaire d’utiliser les deux mains. Dans une autre étude, Hoober et Patti Shank
ont observé que les propriétaires de phablettes utilisaient les deux mains 70 % du temps,
indépendamment de la prise utilisée (http://bkaprt.com/dft/01-07/, inscription requise). La
prise la plus populaire, utilisée 35 % du temps, consiste à tenir la phablette dans une main
tout en touchant l’écran avec l’index de l’autre main. Mais le pouce reste le pointeur
principal : 60 % du temps, les utilisateurs de phablettes touchent l’écran avec un pouce ou
avec les deux.

La zone du pouce sur la phablette

Avec un usage du pouce si répandu, la zone du pouce est aussi importante pour les écrans
de 4 à 7 pouces que pour ceux de plus petite taille – à un détail près. Les utilisateurs de
phablettes se servent plus souvent de leurs deux pouces, créant une paire de zones
symétriques et superposées en bas de l’écran, avec une bande d’espace difficile à atteindre
en haut de l’écran. En dépit de sa popularité, cette zone n’est pas celle qu’il faut optimiser.
Même si nous ne tenons nos phablettes d’une main que 25 % du temps, la prise à un seul
pouce revêt une importance disproportionnée pour les designers, car il s’agit de celle qui
couvre la moins grande surface.
Ce qui nous amène à notre premier principe pour tous les facteurs de forme : tenez
toujours compte de la prise la plus limitée, afin que les gens puissent utiliser votre
interface quelle que soit la façon dont ils choisissent de tenir leur appareil. Sur les
phablettes, cela signifie que les designers doivent cibler la prise à un seul pouce.
Mais il y a un hic : la zone couverte par un seul pouce est plus petite sur les phablettes
que sur les téléphones. À mesure que la taille du téléphone augmente, la zone couverte par
le pouce conserve à peu près la même forme et la même position – ancrée au bas de
l’écran – jusqu’à ce que la taille atteigne un point de bascule, forçant l’utilisateur à
changer de prise pour stabiliser la phablette. La plupart des gens glissent leur petit doigt
sous le téléphone pour le maintenir en place, ce qui réduit l’amplitude de mouvement du
pouce (FIG 1.7).

FIG 1.7 : La taille et la forme de la zone du pouce changent lorsque les dimensions du téléphone nécessitent le support du
petit doigt.

Même si de vastes étendues de l’écran deviennent inaccessibles à l’aide du seul pouce,

certains irréductibles continuent à se servir de leur téléphone d’une seule main et
choisissent de l’« étrangler » – glissant leur main plus haut pour augmenter l’amplitude de
leur pouce. Sur les phablettes, ce grip permet une plus grande amplitude que la prise
traditionnelle en bas de l’écran (FIG 1.8). Nous verrons quelles en sont les conséquences
dans la suite de ce chapitre.

FIG 1.8 : En agrippant la phablette plus haut, la zone du pouce s’élargit, mais la partie inférieure de l’écran devient hors
de portée.
TABLETTES : PLUS D’ÉCRAN, PLUS DE PRISES
Si les téléphones et les phablettes se limitent à trois prises de base, c’est peine perdue avec
les tablettes. Un écran plus grand implique davantage de façons de les prendre en main, ce
qui rend leur usage imprévisible. Les mêmes règles de base s’appliquent, mais avec un
casse-tête supplémentaire : la zone couverte par le pouce n’est pas constante, y compris
sur un même appareil ; elle varie selon la position et la posture.
Lorsque nous nous tenons debout, nous utilisons généralement les deux mains pour
tenir une grande tablette telle que l’iPad : nous l’agrippons sur les côtés, vers le milieu
pour une meilleure prise (si on le tient trop bas, il bascule). Certains l’enveloppent dans
leur bras comme un porte-bloc et s’en servent avec l’autre main. Mais le plus souvent,
nous l’utilisons assis : 88 % du temps, selon Hoober et Shank, contre 19 % pour le
téléphone. Lorsque nous sommes assis à une table, nous avons tendance à reposer la
tablette sur une main en soutenant le tiers inférieur, et à nous en servir de l’autre main.
Allongé sur un canapé, nous la posons généralement sur notre ventre ou la calons à l’aide
d’un coussin et nous en servons d’une seule main. Outre ces changements de prise en
main, la posture affecte également la distance à laquelle nous tenons l’appareil : nous
tenons généralement les tablettes plus près lorsque nous sommes debout, et plus loin
lorsque nous nous allongeons. L’orientation de l’appareil (portrait ou paysage) est
également très partagée, à 60 % en faveur d’une orientation verticale.
Plus l’écran est grand et plus l’appareil est lourd ; nous finissons donc souvent par le
poser, tout simplement. Hoober et Shank ont observé que les gens posaient les tablettes
plus grandes dans quasiment deux sessions sur trois : à plat sur une surface (qu’il s’agisse
d’une table ou de nos genoux) 40 % du temps, et à la verticale sur un stand dans 22 % des
cas. (Notons qu les tablettes plus petites, de 7 ou 8 pouces, sont bien plus simples à
manipuler, et nous les tenons en main dans 69 % des cas.) Ces positions suggèrent que
nous utilisons les grandes tablettes plus comme des écrans d’ordinateur traditionnels – ou
plutôt comme ces ordinateurs hybrides à clavier et écran tactile, que nous aborderons dans
un moment – que comme des appareils portatifs.

La zone du pouce de la tablette

Lorsque nous prenons effectivement nos tablettes en main, elles s’avèrent trop grosses
pour être tenues et utilisées d’une seule main, et nous sommes donc obligés d’utiliser les
deux. Là encore, les pouces jouent un rôle essentiel. Nous avons tendance à tenir les
tablettes de chaque côté, et bien que l’emplacement exact se déplace de haut en bas, les
pouces s’établissent généralement au milieu et dans le tiers supérieur de l’écran. Cette
prise permet d’atteindre plus facilement les côtés et les coins supérieurs de l’écran (FIG
1.9). En revanche, les arêtes supérieure et inférieure de l’écran sont des zones hostiles et
difficiles d’accès. La partie inférieure est particulièrement ardue, car les pouces se placent
rarement près du bas de l’écran – et parfois, cette portion de l’écran n’est même pas
visible. Dans la position la plus nonchalante, et peut-être la plus courante – allongée –, le
cadran inférieur disparaît même dans une couette, un pull-over ou un ventre dodu.
FIG 1.9 : Comme la tablette est généralement agrippée sur les côtés, la zone couverte par les pouces est complètement
différente de celle du téléphone.

Il nous arrive souvent de devoir toucher le centre de l’écran ; et à mesure que l’écran
grandit, nos mains doivent couvrir une surface de plus en plus importante. Cependant,
contrairement au curseur d’une souris qui balaye sans effort toute l’étendue de l’écran, nos
doigts sont alourdis par cette chose que l’on nomme » bras ». Ce pointeur charnu remonte
jusqu’à notre épaule, et il en coûte un effort de parcourir tout l’écran. Une interface ne doit
pas être un exercice de musculation : regroupez les commandes les plus fréquentes à
portée de pouce. Nul ne s’est jamais foulé en se tournant les pouces.
ORDINATEURS HYBRIDES ET PORTABLES : AJOUTEZ-MOI UN
CLAVIER
Si la taille de l’écran a un effet si spectaculaire sur notre façon de tenir l’appareil, il ne
devrait pas vous surprendre que l’ajout d’un clavier bouscule encore plus les choses. Nos
postures, de même que nos bras et nos mains, bougent à nouveau pour faire place au
clavier. Jusqu’à récemment, il était rare d’apercevoir cette combinaison hybride clavier-
écran tactile dans la nature. Et puis Windows 8 est arrivé.
En 2012, Windows a introduit l’interaction tactile sur les ordinateurs, révolutionnant
complètement le système d’exploitation le plus utilisé au monde. Ce bouleversement a
amené une nouvelle catégorie d’appareils tactiles – ordinateurs tactiles et combinaisons
tablette-clavier – à inonder le marché grand public… ainsi que de nouvelles exigences
pour les designers.
Le souci, c’est que les hybrides imposent à nos mains des déplacements constants entre
le clavier et l’écran tactile. Avant l’arrivée de cette génération d’appareils, de nombreuses
personnes avaient qualifié ce concept d’ergonomiquement indéfendable : le va-et-vient
constant des mains demanderait trop d’efforts, provoquant ce que l’on appelle le syndrome
du » bras de gorille » (gorilla arm). La même critique a été formulée à l’encontre des
interfaces de Minority Report et d’Iron Man : qui a envie de travailler avec les bras
constamment dans les airs ? » Les interfaces tactiles ne veulent pas être verticales », a
déclaré avec dédain Steve Jobs en 2010 (http://bkaprt.com/dft/01-08/). » C’est super à titre
de démonstration, mais ça devient très rapidement fatigant, et au bout d’un certain temps,
votre bras voudra se détacher de votre corps. »
Des études suggèrent en fait que ces inquiétudes étaient infondées. Un rapport d’Intel a
démontré que les gens avaient rapidement adopté l’interaction tactile sur ces nouveaux
appareils, optant pour l’écran tactile 77 % du temps au lieu de la souris ou du clavier
(http://bkaprt.com/dft/01-09/). En dépit de la disponibilité et de la précision du bon vieux
curseur, les utilisateurs déclaraient que l’écran tactile leur semblait plus intime et plus
direct. D’autres études ont également documenté cette résonnance émotionnelle. L’une
d’entre elles a révélé que les gens accordaient davantage de valeur aux produits
qu’ils » touchaient » sur un site web par rapport à une sélection à la souris
(http://bkaprt.com/dft/01-10/). Lorsque l’on introduit l’inter- action tactile, ces pixels
froids acquièrent la convivialité et l’investissement émotionnel d’objets physiques. Nous
examinerons cette idée plus en détail lorsque nous aborderons les interfaces gestuelles au
chapitre 4.
Outre cet attrait, l’écran tactile ne remplace pas complètement la souris, mais constitue
plutôt un ajout bienvenu, » comme d’avoir un ordinateur portable avec une vitesse
supplémentaire », a confié un testeur à Intel. Avec ces appareils hybrides, les gens
basculent facilement entre l’écran tactile, le clavier, la souris et le pavé tactile, selon le
mode de saisie qui leur semble le plus pratique. Cela représente pourtant beaucoup de va-
et-vient, et l’on pourrait penser que cela ne ferait qu’aggraver le syndrome du » bras de
gorille ». Pourquoi les gens ne perdent-ils pas l’usage de leur bras ? Il s’avère qu’ils
comprennent rapidement comment utiliser l’écran tactile sans lever le bras. Une étude du
chercheur John Whalen a permis de constater que lorsque nous utilisons des ordinateurs à
écran tactile, nous reposons nos bras le long du clavier, en tenant légèrement les coins
inférieurs de l’écran (http://bkaprt.com/dft/01-11/).

La zone du pouce sur les appareils hybrides

Cette posture consistant à poser les mains aux coins de l’écran détermine la zone couverte
par les pouces sur les appareils hybrides (FIG 1.10). Là encore, le placement des cibles
tactiles à portée des pouces facilite l’interaction et, dans ce cas, évite d’avoir à lever le
bras.

FIG 1.10 : La zone optimale pour les pouces sur les appareils hybrides se situe dans les coins inférieurs, pratiquement le
contraire de la zone optimale pour l’index.

Cependant, tout le monde n’adopte pas cette prise. D’autres (surtout les débutants)
s’expriment sous une forme libre, touchant l’écran de l’index pour parcourir toute
l’interface. Pour les designers, voilà qui est problématique : la zone optimale pour l’index
est l’exact inverse de la zone couverte par les pouces. Pour l’index, le centre de l’écran est
facile à atteindre, et les coins posent problème.
En optimisant pour les pouces, on risque d’offrir une expérience moins performante
pour l’index, et vice-versa. Un agencement doit pourtant primer sur l’autre, et comme
avec tous les autres appareils tactiles, les études tendent à donner les pouces vainqueurs.
Dès qu’ils ont acquis un minimum d’expérience, les utilisateurs d’appareils hybrides
privilégient le pouce pour toutes les interactions et reposent leurs bras sur les côtés afin
d’éviter le syndrome du » bras de gorille » (FIG 1.11).
FIG 1.11 : Les utilisateurs confirmés d’appareils hybrides privilégient l’usage au pouce, même pour atteindre des cibles
vers le centre de l’écran. Photographies d’Intel Free Press (http://bkaprt.com/dft/01-12/, http://bkaprt.com/dft/01-13/).

Et c’est là la similitude la plus frappante entre les différents facteurs de forme que nous
avons examinés : les pouces font le gros du travail, quelle que soit la taille de l’écran. Le
pouce offre la meilleure amplitude de mouvement avec le moins d’effort possible. C’est
justement cette aisance physique que les chercheurs de Bell Lab – ainsi que tous les hauts
designers industriels – ont dû prendre en compte pour concevoir leur interface. Ces
considérations ergonomiques détermineront également l’agencement de vos interfaces
numériques. Nous allons commencer par quelques principes d’ordre général valables pour
tous les designs tactiles, puis nous évoquerons des directives plus spécifiques pour chaque
appareil.
CONCEVOIR DES MISES EN PAGE POUR APPAREILS PORTABLES
Bravo ! Vous avez désormais une image claire de l’usage des doigts et des pouces sur les
gadgets de notre quotidien. Il est temps de transformer ce savoir en savoir-faire. La
position de la main – et en particulier la zone couverte par les pouces – vous indique les
meilleurs emplacements pour placer les commandes et le contenu. Quelques principes
fondamentaux valent pour tous les appareils.

Le règne du pouce
Les pouces étant les pointeurs principaux, on peut déjà déterminer une règle évidente :
regroupez les commandes les plus fréquemment utilisées dans les zones couvertes par les
pouces que nous avons identifiées précédemment. Vient ensuite un point peut-être moins
évident : il est essentiel de songer à ce que vous allez placer en dehors de cette zone.
Placez certaines cibles tactiles – par exemple les commandes qui permettent de modifier
des données – à l’abri, afin de les rendre un peu moins accessibles. Quelles actions doivent
être attractives, et lesquelles doivent être un tant soit peu difficiles d’accès ?
Au-delà de ces questions de commodité et de confort, les mains posent toutefois un
autre problème d’ordre physique : elles ne sont pas transparentes.

Les mains bloquent le champ de vision

Jusqu’à présent, nous nous sommes focalisés sur le dur labeur des mains, mais vos yeux
travaillent eux aussi ; ils doivent voir ce qui se trouve derrière vos petites mimines pendant
que vous tripotez l’écran. » Ton père n’est pas vitrier », me répétait ma mère quand je lui
bouchais la vue. Votre design doit faire face au même problème : vos mains sont
constamment en travers de votre chemin, et ce simple fait entraîne une cascade
d’implications pour votre design.

FIG 1.12 : Si les commandes de l’un de ces appareils classiques apparaissaient au-dessus du » contenu », vos pieds, votre
main ou votre bras vous empêcheraient de l’utiliser.

Le contenu au-dessus des contrôles

Jetez un œil à n’importe quelle machine conçue au cours des siècles passés, et vous verrez
les résultats d’un principe cardinal du design industriel : le contenu s’affiche toujours au-
dessus du reste. Qu’il s’agisse de l’écran d’une calculatrice, du poids affiché sur une
balance ou du papier dans une machine à écrire, le contenu doit se situer au-dessus des
commandes actionnées à la main afin que les doigts ne recouvrent pas ce qui importe
vraiment (FIG 1.12).
Jusqu’à présent, la plupart des designers numériques n’avaient pas été confrontés à ce
problème et s’étaient rarement souciés de placer le contenu au-dessus du reste. Les
logiciels de bureau placent les menus en haut de l’écran ou de la fenêtre, et les éléments de
navigation des sites web se trouvent généralement au sommet de la page. Nous avons pu
nous le permettre uniquement parce que le petit curseur de la souris tient le haut du pavé
depuis des décennies, ne bloquant que quelques pixels en traversant l’écran. Lorsque vous
introduisez un écran tactile, cependant, les doigts et les pouces deviennent le curseur,
entraînant les mains et les bras derrière eux.

FIG 1.13 : La plupart des claviers tactiles font apparaître la lettre sélectionnée au-dessus de la touche, afin de contourner
le doigt posé sur l’écran.

Partez du principe que les gens perdront de vue tout le contenu situé en dessous d’un
objet lorsqu’ils le toucheront – ainsi que l’objet lui-même. Ce principe doit affecter votre
façon d’indiquer les contrôles et de confirmer les interactions tactiles. Au pays du curseur,
un bouton peut être mis en surbrillance lorsqu’on clique dessus. Sur un écran tactile, ce
changement de couleur n’est d’aucune utilité lorsqu’il se produit dans l’ombre d’un doigt.
Présentez plutôt cette confirmation rétroactive au-dessus de l’objet. De même, les libellés
doivent être placés au-dessus des contrôles.
Le champ de vision, combiné avec les principes d’ergonomie, dicte la mise en page des
interfaces tactiles. En particulier, ces contraintes physiques repoussent le contenu vers le
milieu et le sommet de l’écran, et les contrôles vers les côtés, les coins et le bord
inférieur. » Le contenu au-dessus des contrôles » est une règle assez simple en soi, mais
elle s’avère difficile à appliquer, car ses détails varient selon la taille de l’écran et
l’environnement de la plateforme. Les systèmes d’exploitation et les navigateurs imposent
leurs limites à l’espace occupé à l’écran, et les designers doivent composer avec leurs
choix. Le reste de ce chapitre explore les réserves et les implications pour les plateformes
et les facteurs de forme les plus populaires, en commençant par le petit écran.
FIG 1.14 : Dans iOS, les barres d’outils sont ancrées en bas de l’écran, à portée de pouce.
MISE EN PAGE POUR LES TÉLÉPHONES
Les doigts et les pouces se jouent des conventions des ordinateurs de bureau, surtout
lorsqu’il s’agit des petits écrans. Les téléphones à écran tactile font passer les contrôles
principaux, tels que les menus et les barres de navigation, en bas de l’écran. Cela permet
de placer les cibles tactiles à portée de pouce, et le contenu hors de son chemin. Vous
reconnaîtrez ce principe sur l’iPhone, où les onglets et les barres d’outils sont regroupées
en bas de l’écran pour qu’on puisse y accéder rapidement (FIG 1.14).
Mais songez à ce qui ne se trouve pas dans le périmètre du pouce. Les conventions
d’iOS placent les boutons d’édition dans le coin supérieur droit de l’écran, hors de la zone
du pouce – disponibles, moyennant toutefois un léger effort supplémentaire. La raison en
est simple : les boutons d’édition permettent de modifier les données. Voilà un parfait
exemple de design défensif, qui permet d’éviter les fausses manipulations ou autres
actions que les utilisateurs risqueraient de regretter.

FIG 1.15 : Twitter pour iPhone relègue le bouton Tweeter en haut à droite de l’écran, réservant la zone du pouce à la
navigation – et permettant ainsi d’éviter tout tweet malencontreux. (Si seulement une bonne mise en page pouvait
permettre d’éviter les tweets idiots, mais malheureusement, on n’y est pas encore.)

Il n’est pas nécessaire d’exiler tous les contrôles permettant de modifier des données
vers le haut de l’écran. Lorsque l’objectif principal d’une application est d’éditer ces
données (encore et encore), ces contrôles peuvent tout à fait rester en bas. Après tout, un
bon design optimise les tâches récurrentes pour les rendre aussi ergonomiquement
efficaces que possible. Les applications pour iPhone de Swarm et d’Instagram sont des
exemples utiles : elles placent les actions principales – le check-in ou la publication d’une
photo – en bas de l’écran (FIG 1.16). En bonus : la position centrale permet d’accéder au
bouton aussi facilement de la main droite que de la main gauche.
FIG 1.16 : Swarm (à gauche) et Instagram (à droite) ont optimisé leur interface pour iPhone afin de faciliter l’accès aux
tâches principales.

Jusque là, rien de bien compliqué, mais nous avons seulement abordé des exemples sur
l’iPhone. Dans iOS, les contrôles système disparaissent complètement lorsque vous êtes
dans une application, de sorte que les designers n’ont pas à faire concurrence à la
plateforme elle-même pour l’utilisation de l’espace. Il n’en va pas de même pour d’autres
plateformes mobiles.

Faites place au système d’exploitation

Lorsque la plateforme joue des coudes pour s’approprier son propre espace à l’écran, les
designers n’ont pas d’autre choix que de s’effacer, ce qui complique notre principe
apparemment simple de » contenu au-dessus ».
Android, par exemple, occupe tout le bas de l’écran avec ses boutons système qui
épousent le rebord inférieur de chaque appareil Android. Android adhère à notre principe
de priorité au pouce, mais ces boutons entrent maintenant en concurrence avec les
contrôles de l’application. Si, en tant que designer d’application, vous suivez votre instinct
et placez les contrôles en dessous du contenu, vous finissez par les empiler au-dessus des
boutons système d’Android (FIG 1.17). Attendez-vous à des fausses manips…
FIG 1.17 : Ne coincez pas les contrôles contre les boutons système d’Android (ou d’autres contrôles placés en bas de
l’écran). Instagram (à gauche) et même l’écran d’accueil d’origine d’Android (à droite) commettent cette erreur, ce qui
risque d’entraîner de fausses manipulations dans cette zone à fort trafic.

Il n’est jamais judicieux d’empiler différents contrôles où que ce soit sur une interface
tactile ; des cibles tactiles adjacentes sont autant de tentations pour vos doigts
indisciplinés. Le fait d’empiler les contrôles au bas de l’écran ne fait qu’aggraver le
problème. D’une part, la zone du pouce, du simple fait de son volume d’utilisation,
favorise les erreurs. D’autre part, la présence du pouce au-dessus de l’écran limite la
visibilité dans cette zone ; on commet plus facilement des erreurs lorsqu’on n’y voit
goutte.
Malheureusement, la seule solution pour éviter d’encombrer les boutons système
d’Android consiste à placer les contrôles au sommet de l’écran (FIG 1.18). Ce n’est pas
idéal : vous devez tendre les doigts pour atteindre la barre de navigation, et ce faisant, vos
mains dissimulent l’intégralité de l’écran. Mais ces concessions valent mieux que
l’alternative d’empilement des contrôles et les inévitables erreurs qui en découlent. Si
vous avez le choix entre une gêne et une erreur pure et simple, la gêne est le moindre des
deux maux.
FIG 1.18 : Sur iOS, Facebook place la barre de navigation au bas de l’écran (à gauche) ; sur Android, l’application fait
passer la barre de navigation en haut de l’écran afin d’éviter toute confusion avec les boutons système d’Android. En
conséquence, les contrôles de statut/ photo/check-in sortent de la barre d’outils et intègrent le flux des actualités.

Sur les petits appareils tournant sous Android, la barre de navigation et les contrôles de
l’application doivent remonter en haut de l’écran. Voilà ce qu’indiquent les directives de
design d’Android, inversant les conventions de l’iPhone, dont le bouton Home physique
ne suscite pas les mêmes problèmes de concurrence que les boutons système d’Android.
Android encourage par ailleurs les designers à suivre ce même modèle avec la barre
d’action, un widget de navigation standard qui apparaît toujours au sommet de l’écran.
Ainsi, même si le principe du » contenu au-dessus des contrôles » s’applique toujours,
tout dépend de ce qui a la priorité. Pour Android, il s’agit du système d’exploitation, et les
applications doivent s’effacer. Sur iOS, les applications sont libres de s’approprier le bas
de l’écran… sauf s’il s’agit d’une application web.

Faites place au navigateur

La triste réalité, c’est que les sites web s’affichent dans un émulateur que nous appelons
navigateur. Autrement dit, les sites web sont des applications dans une application… qui a
en outre le défaut d’être particulièrement variable. Si tous les navigateurs remplissent la
même fonction de base, les nuances dans leur façon de présenter les pages web sont un
casse-tête bien connu de tous les web designers. Le problème ne fait qu’empirer avec le
design tactile, si l’on considère les différentes façons qu’ont les navigateurs de déverser
leurs propres contrôles à l’écran : des boutons en bas, des boutons en haut, des boutons qui
disparaissent et réapparaissent lorsque vous faites défiler l’écran ou selon l’endroit où
vous vous trouvez sur la page.
 Ce fatras incompréhensible de nos navigateurs amène à une concurrence imprévisible
entre l’interface utilisateur et les sites web qu’ils affichent. Dans le navigateur Safari de
l’iPhone, par exemple, les contrôles du navigateur s’affichent en bas de l’écran, et si vous
placez la barre de navigation de votre site au même endroit, au-dessus de la barre d’outils
du navigateur, vous risquez de rencontrer le même problème qu’avec les boutons système
d’Android.
Pour compliquer encore les choses, la barre d’outils affichée en bas de l’écran dans
Safari et d’autres navigateurs mobiles disparaît lorsque vous faites défiler la page, mais
réapparaît lorsque vous touchez le bas de l’écran. Si vous essayez de toucher un bouton ou
un lien en bas de l’écran, vous faites apparaître la barre d’outils, et votre cible remonte sur
l’écran, ce qui vous oblige à la poursuivre pour la toucher de nouveau (FIG 1.19).

FIG 1.19 : Sur iOS, lorsque vous cliquez sur un lien en bas de l’écran (à gauche), vous faites apparaître la barre d’outils
de Safari au lieu d’activer le lien. La page remonte alors pour faire de la place, et vous devez cliquer de nouveau sur le
lien pour l’ouvrir.

Voilà ce qui m’amène à définir quelques principes de design essentiels.

N’épinglez pas la barre de navigation web en bas de l’écran. Les contraintes
techniques tendent à renforcer ce principe. Les web designers ont pris l’habitude de fixer
les éléments à l’écran en utilisant la propriété CSS position:fixed. Cependant, si l’on essaie
d’appliquer ce même principe dans les navigateurs mobiles, on risque de sombrer
rapidement dans la folie, car la propriété position est prise en charge de façon inégale sur
les appareils mobiles. Dans certains navigateurs, les éléments censés être fixes vibrent et
tremblent lorsque vous faites défiler la page, d’autres remontent le long de la page avant
de revenir brusquement en place, et d’autres ne répondent tout simplement pas à la
propriété position:fixed. Les maux de tête résultants n’en valent pas la peine, et de toute
façon, c’est une mauvaise idée de fixer la barre de navigation sur les téléphones à la base.
N’épinglez pas non plus la barre de navigation au sommet de l’écran. En fait, c’est
une très mauvaise idée d’épingler une barre d’outils fixe où que ce soit sur un téléphone.
Comme les boutons du navigateur occupent déjà une portion de l’espace, abstenez-vous
d’évincer une plus grande partie du contenu en entassant vos propres boutons au sommet
de la page. Mais les téléphones sont de plus en plus grands, diront les amateurs de gadgets.
Il doit bien y avoir un moyen de rajouter une misérable barre d’outils quelque part ?
Si certains écrans ont gagné en taille, d’autres ont rapetissé. Nous sommes inondés de
smartwatchs expérimentales, à l’écran minuscule, et certains téléphones à clavier sont
toujours dotés d’écrans de la taille d’un timbre-poste. Vous ne pouvez pas prendre pour
acquis que tous les écrans présentent les dimensions généreuses des smartphones les plus
populaires.
Même les plus grands smartphones perdent de leur majesté lorsque vous les basculez
en mode paysage, réduisant certains sites web à peau de chagrin. Avant d’être remplacé
par un design responsive, le site mobile du magasin Barney’s comportait un logo et une
barre d’outils fixés au sommet de la page. Sur la plupart des téléphones, cela s’affichait
correctement en mode portrait, mais lorsque vous basculiez le téléphone en paysage, le
contenu disparaissait quasiment (FIG 1.20). Pire : si vous essayiez de faire défiler la page
en balayant le logo ou la barre d’outils, rien ne se passait, parce qu’ils étaient fixés à
l’écran. Vous ne pouviez faire défiler la page qu’en balayant une minuscule tranche de
contenu, une cible tactile à peine assez grande pour nos pouces patauds. Avec si peu
d’espace disponible en hauteur, l’ancien design de Barney était un échec total.
FIG 1.20 : Pauvre Blahnik ! Sur le vieux site mobile de Barney’s, cette sublime paire de talons hauts était complètement
écrabouillée par la barre d’outils lorsque vous orientiez l’appareil en mode paysage.

Sans même parler d’une barre d’outils fixe, le sommet de la page est un terrain hostile
pour placer une barre de navigation sur les petits écrans, même si vous la faites défiler
avec le reste de la page. Quand l’espace est restreint, ne gâchez pas la partie supérieure de
l’écran avec des contrôles de navigation ; allez droit au contenu. » Bien trop d’expériences
web mobiles […] démarrent la conversation par une liste d’options de navigation au lieu
d’afficher du contenu », met en garde Luke Wroblewski dans Mobile First
(http://bkaprt.com/dft/01-14/ ou www.editions-
eyrolles.com/Livre/9782212134063/mobile-first pour l’édition française). » Le temps est
souvent précieux sur les appareils mobiles, et les téléchargements peuvent coûter de
l’argent, alors donnez aux gens ce pour quoi ils sont venus aussi vite que vous le pouvez. »
Sur le Web, placez le contenu en premier et confinez la navigation principale au
bas de la page. Et j’ai bien dit au bas de la page, pas au bas de l’écran. S’il est mal vu
d’épingler les contrôles à un emplacement fixe sur la page, la solution consiste à les placer
dans la page elle-même. Pour ce faire, Wroblewski préconise un modèle de design utile,
que vous pouvez voir à l’œuvre sur le site web The Session (http://bkaprt.com/dft/01-
15/) : le menu de navigation semble se trouver derrière un bouton au sommet de l’écran
(FIG 1.21).

FIG 1.21 : Touchez le bouton en forme de flèche au sommet de la page (image de gauche), et les options de navigation
s’afficheront à l’écran. En réalité, le bouton vous amène au menu de navigation situé en bas de la page.

Le menu s’affiche rapidement et semble se superposer à la page ; en réalité, ce n’est

qu’un lien vers une balise d’ancrage qui vous amène à la section de navigation située en
bas de la page. Cliquez sur la flèche ou sur le bouton retour du navigateur et vous serez
renvoyé au sommet de la page. Le balisage ne pourrait être plus simple :
<a href="#navigation">Menu</a>
 ...

<ul id="navigation">
<li><a href="/one">Option un</a></li>

<li><a href="/two">Option deux</a></li>

<li><a href="/three">Option trois</a></li>
</ul>

D’après Wroblewski, cette approche présente plusieurs avantages :

Ce design utilise un minimum d’éléments de navigation (un simple lien au sommet de la
page), donne aux utilisateurs la possibilité de pivoter l’écran et d’explorer le reste du
site lorsqu’ils arrivent à la fin du contenu, ne duplique pas le contenu d’un autre menu,
et (mieux encore) ne nécessite qu’une simple balise d’ancrage. Vous avez bien lu : pas
de JavaScript compliqué, d’overlay ni de page de navigation séparée à entretenir –
juste un simple lien qui vous amène en bas de la page. C’est quasiment du HTML 0.
HTML 0 ?! Mais c’est cinq HTML de moins que ce que je veux ! Il nous arrive à tous
de nous pâmer de temps en temps devant quelque confiserie interactive à base de
JavaScript. Si je préfère la simplicité élégante d’une navigation basée sur un point
d’ancrage, qui a également le mérite d’afficher les options disponibles une fois que vous
avez fini de lire le contenu de la page, d’autres pourront trouver cette solution trop simple.
Dans ce cas, envisagez de conserver ce balisage et de faire usage d’amélioration
progressive pour enrichir le menu et offrir une expérience plus interactive. En offrant une
solution employant JavaScript et CSS aux navigateurs compatibles, vous pouvez convertir
ce menu de navigation en un overlay qui apparaît en fondu, ou en un panneau qui coulisse
depuis le rebord de la page. Dans les navigateurs moins sophistiqués (ou si JavaScript ne
parvient pas à se charger), la navigation se rabat sur le lien ancré dans le pied de page.

Et maintenant, tous ensemble

La simple règle du » contenu au-dessus des contrôles » se complique lorsque le système
d’exploitation ou le navigateur occupe l’espace primordial du téléphone. Au final
cependant, on pourrait tout résumer ainsi :
• sur l’iPhone, placez les contrôles de l’application en bas de l’écran ;
• sur Android, placez les contrôles de l’application en haut de l’écran ;
• sur le Web, placez de préférence la navigation en bas de la page (et non pas en bas de
l’écran).
Le matériel, de même que les plateformes logicielles, affecte les principes de mise en
page. Nous savons que la prise en main s’adapte en fonction de la forme, de la taille et du
poids de l’appareil. Alors, qu’advient-il de la mise en page de votre interface lorsque
l’écran s’agrandit ?
MISE EN PAGE POUR LES PHABLETTES
Lorsque la taille de l’écran dépasse les cinq pouces, votre mise en page doit prendre en
compte l’espace disponible au-delà de la portée du pouce. Les utilisateurs de phablettes
sont peut-être prêts à changer de prise pour atteindre votre contenu, mais il est de votre
devoir de limiter autant que possible tout effort supplémentaire. La meilleure façon de
procéder consiste à placer les cibles les plus fréquemment actionnées dans la zone
couverte par le pouce en tenant l’appareil à une main (le grip le plus restreint). Les
lecteurs attentifs – oui, vous ! – se souviendront que même cette zone se déplace le long
de l’appareil à mesure que la taille de l’écran augmente. Même si vous ne pouvez pas vous
contenter de redimensionner votre mise en page pour téléphones afin de l’adapter aux
phablettes, certains principes de base s’appliquent toujours.
Pour les applications sur phablette, placez les éléments de navigation et les
contrôles fréquents au bas de l’écran. Quelle que soit la prise en main utilisée, le haut
de l’écran est toujours difficile à atteindre sur les phablettes. Comme sur les téléphones de
plus petite taille, suivez la règle du » contenu au-dessus des contrôles » pour conserver les
cibles tactiles courantes à portée de pouce et hors du chemin du contenu. Android fait
toutefois exception. Au lieu d’empiler tous les contrôles au sommet de l’écran comme
vous le feriez sur les petits écrans, placez certains des contrôles les plus fréquents dans
une barre d’outils située en bas de l’écran (FIG 1.22). Il s’agit du modèle de design de la
barre d’action scindée, développée à l’origine pour les petits écrans, mais qui s’avère
aujourd’hui utile pour les gadgets de plus grande taille.

FIG 1.22 : Par défaut, la barre d’action d’Android regroupe tous les éléments de navigation et les options au sommet de
l’écran (image de gauche). La barre d’action scindée (à droite) déplace les icônes d’action en bas de l’écran, simplifiant
l’accès au pouce sur les phablettes.

Ce n’est toujours pas idéal. En empilant les contrôles sur les phablettes, on favorise le
même genre de fausses manips que sur les téléphones. Comme il est pratiquement
impossible d’atteindre les contrôles placés au sommet de l’écran d’une seule main,
cependant, déplacer les contrôles à portée de pouce en vaut le risque. Au moins, les
utilisateurs se servant de leur pouce sont en mesure d’atteindre les boutons. Comme nous
l’avons remarqué précédemment, les contraintes liées aux plateformes forcent
constamment les designers à faire des compromis. En cas de doute, le moindre mal est
toujours l’option qui permet au moins un accès basique aux fonctions.
Le bouton de déclenchement flottant est un palliatif pratique. Ces boutons se nichent
dans le coin inférieur de l’écran et restent en place alors que le reste de la page défile.
Vous pouvez utiliser un bouton de déclenchement pour exécuter l’action principale d’un
écran – » ajouter une photo », » check-in », » nouveau message » – ou le transformer en
mini-barre d’outils ou en menu circulaire d’actions associées (vous en apprendrez
davantage sur les menus circulaires au chapitre 4.) Lorsque je me suis occupé du design
du site mobile responsive d’Entertainment Weekly, nous avons utilisé un bouton de
déclenchement flottant pour offrir un accès rapide aux outils de partage sur les écrans de
toutes tailles (FIG 1.23). Touchez le bouton et vous verrez apparaître une liste d’options.

FIG 1.23 : Sur le site mobile d’Entertainment Weekly (http://m.ew.com), un bouton de déclenchement flottant (à gauche)
se déroule pour afficher les options de partage (à droite).

Mais, ne devait-on pas éviter d’empiler des contrôles en bas de l’écran ? Absolument,
voilà encore un compromis permettant de placer les contrôles à portée de main sur les
phablettes. La bonne nouvelle : un bouton de petite taille qui se développe n’est pas aussi
pénalisant qu’une barre d’outils complète. Dans le jargon de développement d’Android,
un bouton de déclenchement s’appelle un bouton d’action flottant (FIG 1.24) ; consultez
les directives de design d’Android pour plus d’informations sur l’espacement des boutons
(http://bkaprt.com/dft/01-16/).

FIG 1.24 : Un bouton de déclenchement flottant, tel que ce bouton d’action dans le coin inférieur droit, vous permet
d’inclure une ou plusieurs actions principales en bas de l’écran sans que celles-ci n’entrent en conflit avec les boutons
système d’Android.

Autre solution : afficher les contrôles visuels au sommet de l’écran et placer une
interaction de secours en dessous. Une deuxième option facilitant l’usage au pouce sur
les phablettes consiste à conserver le contrôle des onglets au sommet, mais à les compléter
par une navigation par balayage dans le corps de la page (FIG 1.25). Ce modèle fonctionne
bien pour le contenu de navigation organisé en onglets. Les utilisateurs peuvent accéder
aux onglets en cliquant dessus, mais sur les écrans plus grands, il est plus pratique de
balayer directement le contenu. Le geste classique » tirer vers le bas pour actualiser » offre
des avantages similaires, vous permettant d’actualiser le contenu de l’écran sans avoir à
toucher un bouton.
FIG 1.25 : L’application Contacts d’Android permet de basculer entre les onglets en balayant l’écran. Touchez l’onglet
Favoris ou Tous les contacts au sommet de l’écran, ou bien balayez l’écran à n’importe quel endroit pour basculer entre
les onglets. (Les onglets sont un composant standard dans le système d’exploitation Android, et la fonction de balayage
est intégrée pour être facilement utilisée par les designers.)

Pour la navigation web, tenez-vous-en au modèle de menu avec balise d’ancrage.

Les limitations techniques et la concurrence avec les contrôles du navigateur qui entrent
en jeu sur les petits écrans s’appliquent également aux phablettes. La meilleure solution
consiste à placer au sommet de la page un lien conduisant à un menu de navigation en bas
de page. Certes, le lien vers le menu, placé dans le coin supérieur de l’écran, est bien hors
de portée du pouce, mais c’est moins gênant que ce que vous pourriez imaginer. Je le
constate tout le temps dans la recherche utilisateur : les gens se tournent vers la navigation
principale en dernier recours, lorsqu’ils ne parviennent pas à trouver ce qu’ils veulent dans
le corps de la page. Ce qui signifie qu’en plaçant la navigation au bas de la page, celle-ci
apparaît lorsque les utilisateurs en ont le plus besoin (sans se fouler le pouce).
Évitez de placer des cibles tactiles dans le coin opposé de la phablette. Nous autres
simples mortels ne sommes pas dotés d’un pouce capable d’atteindre le côté opposé d’une
phablette : le côté gauche de l’écran est hors d’atteinte du pouce droit lorsque la phablette
est tenue d’une main. Évitez les cibles tactiles qui épousent le bord droit ou gauche de trop
près. Dans le corps principal de la page, favorisez les cibles qui s’étendent au moins sur un
tiers de l’écran – ou mieux, sur toute la largeur de l’écran.
Mais n’agrandissez pas la taille des gestes en fonction de la taille de l’écran. Disons
par exemple qu’une interface vous permet de balayer un menu pour afficher des actions.
Utilisez la même distance de balayage que vous utiliseriez sur un téléphone – ne forcez
pas les gens à balayer toute la surface de la phablette pour activer une fonction. Ce n’est
pas parce que vous maniez un téléphone géant que vous avez des mains géantes ; adaptez
la taille des gestes à la main et non à l’écran.
Déplacez des montagnes. La plupart des interfaces sont des paysages fixes que nous
parcourons du doigt. Nous nous déplaçons vers les boutons ; ils ne viennent jamais à nous.
Mais il ne doit pas forcément en être ainsi. Samsung a créé un mode de fonctionnement à
une main spécial pour ses téléphones Android de grande taille (FIG 1.26). Lorsque vous
activez cette fonction, l’interface rétrécit pour prendre la taille d’un téléphone normal,
plaçant tous les éléments à portée de pouce avec une prise à une main. Dans les faits, vous
transformez temporairement votre gros téléphone en petit téléphone. Malheureusement, ce
superbe écran géant devient complètement inutile, contredisant la raison pour laquelle
vous avez acheté une phablette.

FIG 1.26 : Le mode à une main de Samsung (à gauche) réduit les interfaces utilisateur sur phablette pour qu’elles soient
plus maniables, tandis que la fonction » Reachability » d’Apple (à droite) fait glisser le sommet de l’écran vers le bas
pour le rendre plus accessible. Photographie de gauche prise par Kārlis Dambrāns (http://bkaprt.com/dft/01-17/) ;
photographie de droite utilisée avec l’aimable permission d’Apple (http://bkaprt.com/dft/01-18/).

Apple a emprunté une approche différente dans iOS avec une fonction
appelée » reachability » (FIG 1.26). Touchez le bouton Home deux fois, et l’interface
glisse vers le bas de sorte que le sommet de l’application arrive à la moitié de l’écran, à
portée de pouce, et remonte lorsque vous avez fini. Les contrôles placés en haut de l’écran
deviennent aussi faciles à atteindre que si vous aviez remonté votre main le long du
téléphone, sans l’effort associé. Autre avantage : contrairement à l’approche employée par
Samsung, celle-ci n’altère pas la taille ni la disposition des cibles tactiles.
Si ces solutions d’Apple et de Samsung fonctionnent au niveau du système
d’exploitation, les sites web peuvent eux aussi employer des panneaux coulissants. Au lieu
de faire glisser l’interface vers le haut ou vers le bas, cependant, un angle d’approche plus
pratique sur les pages web consiste à faire apparaître un menu du bord de l’écran. Un petit
bouton ou un onglet placé dans la zone du pouce permet d’invoquer le menu, avec des
options pratiques à utiliser d’une seule main (FIG 1.27).
FIG 1.27 : Le site du Time (http://time.com) comporte un onglet latéral qui ouvre un tiroir rempli d’articles récents
lorsque vous le touchez.

Une mise en garde toutefois : sur une phablette, les côtés de l’écran sont difficiles
d’accès pour les pouces, quoique plus simples à atteindre que le sommet. (Vous pouvez
contourner ce problème en permettant également aux utilisateurs de balayer l’écran pour
ouvrir l’onglet avec une interaction de secours.) En général, les contrôles latéraux sont
mieux adaptés à un usage à deux mains, et c’est pourquoi ils fonctionnent mieux sur les
tablettes plus larges. Voilà donc venu le moment de parler de la grande sœur de la
phablette.
MISE EN PAGE POUR LES TABLETTES
Le design pour tablettes contraste fortement avec les petits écrans. Alors que les
téléphones et les phablettes privilégient le bas de l’écran pour les cibles tactiles les plus
fréquentes, les zones couvertes par les pouces sur les tablettes bougent de haut en bas,
privilégiant les côtés et les coins supérieurs (FIG 1.28). Si le sommet de l’écran devient
plus important pour l’expérience tactile, c’est également le cas de l’expérience visuelle.
Plus l’écran est grand, et plus il est difficile de parcourir tout l’écran d’un seul coup d’œil,
comme nous pouvons le faire sur le téléphone ; ainsi nos yeux – de même que nos pouces
– viennent se poser naturellement sur la moitié supérieure de la tablette. La hiérarchie des
informations du design doit refléter ce facteur.

FIG 1.28 : Sur l’iPad, les applications Instapaper (à gauche) et Twitter (à droite) offrent de bons exemples de placement
alternatif des contrôles dans la zone des pouces.

Si les coins supérieurs sont un emplacement idéal pour les cibles tactiles fréquentes, la
partie centrale du sommet de l’écran est tout bonnement hostile. Sans même parler de
l’effort requis pour atteindre cette zone, celle-ci vous oblige à couvrir l’écran et tout son
contenu. Le défunt magazine pour iPad The Daily offrait une barre de défilement en haut
et au centre de l’écran pour parcourir les pages du numéro (FIG 1.29), mais les miniatures
étaient couvertes par la main lors de son utilisation. Il fallait donc se contorsionner en
faisant défiler le curseur pour voir la couverture du numéro.
FIG 1.29 : La barre de défilement du Daily révèle des miniatures des pages qui finissent masquées par votre doigt.
Comme pour la plupart des interfaces tactiles, la partie centrale du sommet de l’écran est un mauvais endroit pour placer
des contrôles.

Cette maladresse du Daily nous amène à édicter une exception à la règle du coin
supérieur pour les contrôles sur tablette. Dans certains cas, il vaut mieux placer les
contrôles en bas de l’écran, même s’il s’agit de la région la moins accueillante des
tablettes pour les interactions tactiles comme pour l’expérience visuelle. Cette exception
s’impose lorsque les effets de ces contrôles sur le corps de la page doivent être visibles.
Lorsque les contrôles permettent de parcourir ou de modifier le contenu, placez-les en
dessous ou à côté du contenu, jamais au-dessus.
L’application pour iPad du Sydney Morning Herald, par exemple, offre un moyen
original de parcourir tous les articles du numéro du jour en faisant défiler un curseur
affichant le numéro des pages au bas de l’écran (FIG 1.30). Ce contrôle révèle une liste des
titres des articles ; c’est donc un compromis acceptable que de placer ces contrôles au bas
de l’écran. Si les contrôles se trouvaient en haut, votre main couvrirait toute la liste
lorsque vous les activeriez.
FIG 1.30 : L’application pour iPad du Sydney Morning Herald liste les titres de la page lorsque vous touchez le curseur
au bas de l’écran. La position du contrôle permet de garder les titres bien en vue.

Alors, faut-il placer les contrôles pour tablette en haut ou en bas ? Coupons la poire en
deux.
• Les coins supérieurs sont idéaux pour la navigation et les outils ne nécessitant qu’une
seule action comme le partage, l’ajout aux favoris ou la suppression.
• Le bord inférieur est acceptable pour les contrôles permettant de parcourir ou de
prévisualiser le contenu sur la page au-dessus. (Si l’espace le permet, toutefois, il vaut
encore mieux placer les outils sur les côtés afin qu’ils ne disparaissent pas sous les
mains et les doigts.)
MISE EN PAGE POUR ORDINATEURS PORTABLES ET HYBRIDES
Le bord inférieur de l’écran est tout de suite beaucoup plus pratique lorsque votre écran
tactile est vertical et se voit adjoint d’un clavier. Sur les ordinateurs portables/hybrides, les
pouces tendent à privilégier le rebord et les coins inférieurs, et votre mise en page doit en
tenir compte.
Regroupez les contrôles et les gestes principaux dans les coins inférieurs et sur les
côtés. Ce n’est généralement pas comme cela que l’on procède, me direz-vous. La plupart
des designs pour grands écrans fixent traditionnellement les contrôles principaux comme
la navigation et les barres d’outils au sommet ou au milieu de l’écran, hors de la sacro-
sainte zone du pouce. L’écran tactile nous oblige à réévaluer notre position. Les meilleures
applications Windows optimisées pour les écrans tactiles, par exemple, font passer les
contrôles fréquents du centre de l’écran aux rebords : balayez l’écran depuis la droite pour
ouvrir la barre d’action Windows, et faites glisser l’écran de haut en bas pour faire
apparaître la barre des tâches (FIG 1.31).

FIG 1.31 : Les gestes système de Windows sont optimisés pour des mains qui reposent dans les coins inférieurs de
l’écran. Dans Windows, faites glisser votre doigt depuis le bord droit de l’écran (en haut) pour faire apparaître la barre
des charmes – remplacée par la barre d’actions dans Windows 10 – ou balayez l’écran de haut en bas pour afficher la
barre des tâches (en bas).

Lorsqu’elles n’organisent pas les contrôles principaux dans des tiroirs en dehors de
l’écran, les applications Windows bien élevées alignent ces contrôles sur le côté gauche ou
droit, ou le long du rebord inférieur. Facebook pour Windows dispose les options de
navigation principales le long du rebord gauche et la barre de discussion à droite.
L’application de musique pour Xbox place ses contrôles de lecture au bas de l’écran. Dans
chaque cas, les contrôles principaux peuvent facilement être actionnés par les pouces qui
reposent aux coins de l’écran (FIG 1.32).

FIG 1.32 : Les contrôles placés sur les bords de l’écran permettent de placer les cibles tactiles fréquentes à portée de
pouce en position de repos. L’application Musique de la Xbox (en haut) fixe la navigation sur le bord gauche et les
contrôles du lecteur en bas de l’écran. Facebook (en bas) vous permet de parcourir les catégories avec votre pouce
gauche et la barre de discussion avec le droit.
 Les applications natives peuvent se permettre de placer les contrôles au bas de l’écran,
mais sur le Web, c’est plus compliqué. Les navigateurs sont aujourd’hui incapables de
détecter à quel type d’appareil ils ont affaire. Il n’existe aucun moyen fiable de déterminer
si un appareil dispose d’un écran tactile, d’un clavier, d’une souris ou d’une combinaison
des trois. En d’autres termes, le navigateur n’a aucun moyen de savoir s’il tourne sur une
tablette, un ordinateur portable ou un appareil hybride. Les logiciels natifs disposent de
beaucoup plus d’informations sur l’appareil, de sorte que les designers d’applications
natives peuvent plus facilement concevoir une expérience tactile sur mesure.
Nous avons besoin de nouvelles techniques de web design pour couvrir tous les types
d’appareils à grand écran. On ne peut que faire des progrès dans ce sens : la plupart des
designs de sites web pour grands écrans ne sont pas encore optimisés pour les interactions
tactiles sur ces appareils. Cela s’explique par le fait que bon nombre d’entre nous
s’imaginent toujours que grand écran signifie ordinateur de bureau, et donc clavier et
souris. Ces suppositions ne tenaient déjà pas debout à l’origine, mais avec les tablettes et
les ordinateurs hybrides, elles s’écroulent tout simplement. À l’heure qu’il est, les sites
web pour grands écrans posent problème à nos gros doigts patauds, avec des cibles tactiles
trop petites pour les liens et des menus de type <select>, ou ils s’appuient sur des
interactions de survol qui ne sont tout simplement pas déclenchées sur les écrans tactiles.
Nous devons changer notre façon de penser le design pour grands écrans. En fait, nous
devons tout simplement changer notre façon de considérer les écrans, car ceux-ci ne
cessent de nous induire en erreur. Nos préjugés sur les écrans nous amènent à concevoir
dans la mauvaise direction. Il s’avère que les pixels ne fonctionnent pas de la façon que
nous imaginons, que la taille de l’écran ne détermine pas s’il est tactile, et que les
navigateurs ne sont même pas capables de savoir quels gadgets y sont raccordés. De ce
fait, il est difficile de s’adapter de manière fiable aux exigences physiques qui ont fait
l’objet de ce chapitre. Pour les designers, le problème des écrans tactiles réside moins dans
cette mécanique que dans le mécanisme lui-même : l’écran.
L’ÉCRAN NOUS A LONGTEMPS PARU comme une toile de fond fidèle pour nos interfaces
visuelles. Au fil de la courte histoire du web design, les écrans ont toujours su être fiables
et rassurants. Ils ont gardé le même format pendant des décennies, et bien qu’ils aient
progressivement grandi, ils l’ont fait à un rythme régulier. Le secteur du web design a
établi des largeurs standard – en commençant par 600 pixels dans les années 1990, puis
800 pixels autour des années 2000, puis 980, et enfin 1 200. Et puis soudain, cette illusion
de largeur fixe a explosé avec la révolution mobile et son déluge d’écrans de tailles et de
formes différentes.
Le responsive design est la nouvelle norme, et grâce aux media queries CSS, nous
avons pu adapter nos designs à ces contenants de poche. Mais les écrans tactiles et les
autres modes de saisie émergents nous posent de nouveaux défis tenaces, tels que les
énormes variations de densité de pixels et la prise en charge inégale des interactions
tactiles, que les media queries ne sont pas (encore) en mesure de gérer. Les écrans ne sont
plus cette base solide pour le design qu’ils semblaient être auparavant.
Notre mission consiste à construire des interactions physiques solides par-dessus ces
fondations virtuelles branlantes. Ce chapitre vous expliquera comment mettre un peu
d’ordre sur ces écrans peu fiables. Nous découvrirons des interactions universelles qui
fonctionnent avec ou sans écran tactile. Nous explorerons le monde des viewports
dynamiques qui permettent d’agrandir l’écran d’un simple pincement de doigts, et nous
apprendrons à dimensionner des cibles tactiles même lorsque vous ne connaissez pas la
densité de pixels de l’écran. Mais surtout, nous verrons ce que vous pouvez ou non savoir
sur les écrans – et ce que vous pouvez supposer sans trop vous avancer : très peu de
choses.
Même la simple question » cet appareil dispose-t-il d’un écran tactile ? » ne trouve pas
de réponse définitive. Les navigateurs n’offrent aucun moyen de le déterminer avec
certitude. Idéalement, il faudrait coder notre CSS de sorte qu’il s’adapte à différents
modes de saisie, de la même façon que le responsive design prend en compte plusieurs
types d’affichage (c’est-à-dire de tailles d’écrans). Malheureusement, nous ne disposons
encore d’aucun outil infaillible permettant de détecter les modes de saisie d’un appareil.
Clavier, écran tactile, souris, reconnaissance vocale ou gestes naturels de style Kinect –
nous n’avons aucun moyen de deviner comment l’utilisateur pilote son navigateur.
LA TAILLE EST UN PIÈTRE MOYEN DE DÉTECTER LES ÉCRANS
TACTILES
N’ayant pas de meilleurs outils à notre disposition, nous nous sommes reposés sur
l’hypothèse douteuse que la taille de l’écran nous donnait une indication sur son mode de
saisie. » Si c’est un petit écran, il est tactile. Si c’est un grand écran, il est piloté par une
souris. » Cette distinction était déjà mise à mal par les grandes tablettes comme l’iPad, et
les ordinateurs hybrides l’ont achevée avec leurs écrans tactiles de grande taille. En marge
de ce phénomène, d’énormes tablettes tactiles font également leur apparition, avec des
écrans qui dépassent les 20 pouces de diagonale. Pourtant, les designers parlent encore de
mises en page » mobiles » et » bureau » (tactile vs. souris), alors qu’ils devraient plutôt
parler de petits et de grands écrans. Il serait temps que nous cessions de confondre taille de
l’écran et mode de saisie, mais comment faire ?
Si les media queries ne ciblent pas encore les appareils tactiles, cela devrait changer
avec CSS4. La nouvelle media query pointer cible les gadgets dotés d’outils de pointage
fins (fine) ou épais (coarse) – ou même d’aucun pointeur, comme les interfaces utilisant
uniquement la reconnaissance vocale ou un clavier (http://bkaprt.com/dft/02-01/). Une
souris, un pavé tactile, un stylet ou tout autre » bidule » précis compte comme un pointeur
fin, tandis que les doigts sont un pointeur épais. Cela nous permet de créer des règles
spécifiques mieux adaptées aux doigts et aux pouces. Par exemple, pour agrandir une zone
de saisie, vous pourriez utiliser la propriété pointer ainsi :
/* Agrandir les champs de saisie pour les écrans tactiles */
@media (pointer:coarse) {

input[type="text"] {
min-height:44px;
}

Si la propriété pointer est une nette amélioration, son approche binaire » fin vs. épais »
est trop réductrice. Comme les ordinateurs hybrides nous l’ont déjà démontré, un même
appareil peut disposer de plusieurs modes de saisie différents. Lorsque vous avez un
mélange de pointeurs fins et épais, la media query pointer se fie à ce que le navigateur
considère comme étant le mode de saisie » principal ». Une tablette adjointe d’un clavier
Bluetooth considèrerait sans doute son écran tactile comme le mode de saisie principal –
et la propriété pointer indiquerait alors coarse –, mais un ordinateur à écran tactile pourrait
décider que son mode de saisie principal est son pavé tactile, et pointer renverrait alors
l’attribut fine.
La propriété pointer nous serait plus utile si nous pouvions cibler des combinaisons
spécifiques. Comme nous l’avons appris au chapitre 1, la mise en page sur un ordinateur
hybride disposant d’un écran tactile et d’un clavier devra être différente de celle destinée à
une tablette tactile, car l’ergonomie est différente sur les deux appareils. C’est pourquoi il
est important d’identifier à la fois la présence d’un écran tactile et sa possible association à
d’autres modes de saisie. Tant que nous y sommes, ce serait super d’avoir des en-têtes
HTTP qui annoncent au serveur backend à quel type d’appareil il a affaire :
« Hello, je suis un écran tactile ! »
 « Bien le bonjour, je suis un hybride écran tactile-clavier. »
« Salut, je n’ai pas d’écran du tout… »
Il est prévu que cette fonction soit implémentée à l’avenir mais en attendant, nous
devons nous contenter de ce que nous avons. Nous avons presque la possibilité de détecter
les écrans tactiles en utilisant JavaScript pour repérer les événements tactiles et en ajoutant
une classe » touch » dans l’élément document du DOM. Pour effectuer un test rapide, mais
relativement naïf, vous pouvez vérifier la présence de ontouchstart ou de MaxTouchPoints
(msMaxTouchPoints dans Internet Explorer) :
<script>
// si le navigateur prend en charge les interactions tactiles, ajouter la classe 'touch' dans
l’élément body
if ( 'ontouchstart' in window ||

window.navigator.MaxTouchPoints ||
window.navigator.msMaxTouchPoints )

{
document.getElementsByTagName('body')[0].className
+= ' touch';

}
</script>

Et à partir de là, vous pouvez ajouter ces quelques lignes dans votre CSS pour
augmenter la taille des cibles tactiles :
/* Agrandir les champs de saisie sur les écrans tactiles */
.touch input[type="text"] {

min-height:44px;
}

Cette solution n’est pas parfaite. Pour commencer, cette approche teste le navigateur
pour voir si le logiciel prend en charge les interactions tactiles, mais néglige le côté
matériel. Ce n’est pas parce qu’un navigateur comprend les interactions tactiles que
l’appareil les prend en charge. Il arrive parfois que des navigateurs prenant en charge les
interactions tactiles, mais tournant sur des gadgets sans écran tactile, rapportent que les
événements tactiles sont disponibles, ce qui produit des faux positifs. Après tout, vous
demandez au logiciel s’il prend en charge les interactions tactiles, et certains navigateurs
vous répondront sincèrement que c’est le cas, même s’ils tournent sur un appareil
incompatible. Ensuite, tous les navigateurs tactiles ne rendent pas les événements
disponibles en JavaScript, ce qui produit des faux négatifs (c’est notamment le cas
d’Opera Mini et des appareils plus anciens tournant sous Symbian et Windows Phone 7).
Le tableau est sombre : nous n’avons aucun moyen de savoir avec certitude si nous
avons affaire à un écran tactile, du moins pour le moment. La seule véritable option qui
s’offre à nous est de deviner au mieux. Et au fond, il n’y a qu’un seul choix possible.
PARTEZ DU PRINCIPE QUE TOUS LES ÉCRANS SONT TACTILES
Puisque n’importe quel appareil est susceptible de comporter un écran tactile, nous avons
intérêt à considérer que c’est toujours le cas. Face à ces incertitudes, il est de notre devoir
de nous assurer que nos designs seront accessibles pour les curseurs comme pour les
doigts. Tous vos sites web – et il en va de même pour les applications de bureau natives –
doivent être conçus pour permettre les interactions tactiles.
Ce n’est pourtant pas ce que nous faisons à l’heure actuelle. Nos stratégies de
design » établies » ne prennent pas en compte le curseur et l’écran tactile. Un nouveau
langage de design doit s’imposer et remplacer les traditionnelles interactions par curseur
par des conventions suffisamment flexibles pour gérer plusieurs modes de saisie
potentiels. En fin de compte, il s’avèrera peut-être impossible de prendre en charge tous
les modes de saisie – en combinaison ou séparément – avec une seule interface. Nous
devrons peut-être offrir plusieurs modes, sélectionnables par l’utilisateur en fonction de
ses habitudes. (Le site Vimeo, par exemple, offre un mode » canapé », interface alternative
mieux adaptée à un grand écran de télévision.) Ce que nous ne devons pas faire, c’est
botter en touche. Après tout, l’idéal du Web est d’être une plateforme accessible depuis
n’importe quel appareil, quel que soit le mode de saisie ou le type d’affichage. Pour
l’instant, cela implique de rendre toutes nos mises en page de bureau accessibles aux
doigts, ce qui n’est pas un défi insurmontable.
CONCEVOIR POUR LES ÉCRANS TACTILES ET LES CURSEURS
Si la taille de l’écran n’est pas un bon moyen de détecter les interactions tactiles, celles-ci
sont toutefois influencées par la taille et la forme de l’écran – c’est pour cette raison que
les pouces couvrent une surface différente sur les téléphones, les tablettes et les PC
hybrides. Dès lors que nous considérons que tous les écrans sont tactiles, la taille de
l’écran indique où se trouve la zone couverte par les pouces. Il est assez simple de cibler
les téléphones et les phablettes, puisque cette zone est similaire sur tous ces écrans. Mais
cela devient plus délicat pour les tablettes et les PC hybrides ; comme leurs écrans sont de
même taille, nous ne pouvons pas nous reposer sur des media queries basées sur la taille
de l’écran pour appliquer des mises en page spécifiques à chaque type d’appareil. Au lieu
de ça, nous devons prendre des décisions (et faire certains compromis) pour créer des
mises en page qui privilégient les pouces sur les deux types d’appareils, tout en prévoyant
des interactions qui fonctionnent à la main comme avec un curseur.

Ciblez la zone de contact commune : les rebords gauche et droit

Les zones couvertes par les pouces diffèrent sur les tablettes et les PC hybrides, mais elles
s’entrecoupent. Cette zone de contact commune converge sur les bords gauche et droit de
l’écran, ce qui permet d’établir une zone tactile ergonomique pour les deux facteurs de
forme (FIG 2.1). C’est là que vous placerez les cibles tactiles les plus fréquentes.

FIG 2.1 : Si vous superposez la zone des pouces sur la tablette (en jaune) à celle du PC hybride (en bleu), celles-ci
s’entrecoupent dans une zone qui épouse les rebords gauche et droit (en vert) ; concrètement, la moitié inférieure de la
zone couverte par les pouces sur une tablette.

Privilégiez tout particulièrement le bord gauche pour les contrôles principaux. Steven
Hoober et Patti Shank ont constaté que 84 % des utilisateurs utilisant leur index pointaient
avec leur main droite (http://bkaprt.com/dft/01-07/). Dans la plupart des cas, la main
gauche soutient l’écran, ce qui permet d’atteindre facilement les éléments de navigation
situés sur le bord gauche à l’aide du pouce. Quand je dis » contrôles principaux », je ne
veux pas nécessairement parler de la barre de navigation principale d’un site. Souvenez-
vous que la plupart des gens utilisent le traditionnel menu de navigation en dernier recours
– uniquement s’ils ne trouvent pas ce qu’ils cherchent dans le corps de la page. Il est
toujours important de proposer des menus de navigation clairs pour indiquer quel est
l’objet du site, mais ceux-ci ne doivent pas occuper l’espace principal. Les contrôles
principaux sont plutôt ceux que les gens utilisent effectivement sur votre site. Pour un
média, il peut s’agir de partager des liens (FIG 2.2). Pour un site de commerce, cela pourra
être » Ajouter au panier » et » Commander ». Les boutons que vous placerez sur le bord
gauche de l’écran devront être ceux sur lesquels les gens appuient le plus souvent.
FIG 2.2 : UserTesting (http://bkaprt.com/dft/02-02/) ajoute des boutons de partage dans la gouttière de gauche sur les
grands écrans (comme les tablettes et les ordinateurs). Les boutons peuvent facilement être actionnés du pouce pour
partager le contenu.

Réduisez le nombre d’interactions nécessaires

Utiliser une interface physique demande un effort. Plus l’écran tactile est grand, plus il
demande d’effort et de précision. Faites gagner du temps et de l’huile de coude à vos
utilisateurs en réduisant le nombre de clics et d’interactions nécessaires pour parcourir
votre design. Les menus de sélection, les zones de saisie, les carrousels et autres widgets
peuvent s’avérer pratiques si vous avez un clavier et une souris, mais cauchemardesques
sur les écrans tactiles. (Le chapitre 3 aborde les alternatives pour des interactions plus
rapides.)

Les interactions de survol sont un bonus

Prenez un iPad et faites flotter votre doigt au-dessus de l’écran pour voir ce qu’il se passe.
Pas grand-chose. Les interactions de survol peuvent être utiles si vous disposez d’un
curseur, mais sont parfaitement inutiles sur la plupart des écrans tactiles. (Certaines
interfaces pour stylet font exception : le stylet S Pen de Samsung déclenche les
événements de survol lorsque vous le tenez juste au-dessus de l’écran.) Comme ces
interactions ne sont pas universellement disponibles, notamment sur les navigateurs
textuels ou à reconnaissance vocale, traitez-les comme des améliorations. Vous pouvez
utiliser les interactions de survol pour proposer des raccourcis et des aperçus de contenu
sur les navigateurs et les appareils qui les prennent en charge, mais assurez-vous qu’elles
ne sont pas le seul moyen d’accès.
Il est toutefois possible d’utiliser l’écran tactile pour offrir un aperçu du contenu
comme avec les interactions de survol. Les interfaces de carte vous permettent
généralement de toucher un lieu une première fois pour afficher un résumé des
informations, puis une deuxième fois pour ouvrir les détails complets (FIG 2.3). C’est ainsi
que la plupart des navigateurs web gèrent les événements mouseover et les états CSS :hover,
en déclenchant les interactions mouseover/hover au premier contact et en effectuant un
véritable clic lors du second.

FIG 2.3 : Dans l’application Maps de l’iPhone, lorsque vous touchez un lieu une fois, vous affichez une bulle
d’informations préliminaires ; touchez-le de nouveau pour obtenir les informations complètes sur le lieu.

La future norme pour les media queries CSS4 introduira une nouvelle media query
pour les interactions de survol qui contrôlera les styles en fonction de la compatibilité de
l’appareil (http://bkaprt.com/dft/02-03/). Cette fonction vous permettra de masquer et
d’afficher le contenu sur les appareils prenant en charge les interactions de survol par
exemple, mais gardera le contenu visible sur les appareils non compatibles (tels qu’un
iPad uniquement équipé d’un écran tactile) :
@media (hover) {

/* CSS pour les appareils avec survol ; afficher et

masquer au survol */
.metadata { display: none }

.metadata:hover { display: block }

}
@media (hover: none) {

/* CSS pour les appareils sans survol ;

toujours visible */
.metadata { display: block }

Les choses se compliquent sur les appareils qui disposent de plusieurs modes de saisie.
Admettons que vous ayez une tablette tactile à laquelle vous avez connecté une souris.
Dans ce cas, la propriété hover fonctionnera comme la media query pointer décrite
précédemment : elle se conformera au mode de saisie principal déterminé par le
navigateur. Comme le mode de saisie principal de notre tablette est l’écran tactile (la
souris est un accessoire), le navigateur déclarera qu’il ne prend pas en charge les
interactions de survol – même si la souris est connectée. Si vous voulez créer des règles
qui s’appliqueront dans le cas où l’un des modes de saisie (principal ou non) prend en
charge les interactions de survol, vous pourrez utiliser la nouvelle media query any-hover :
@media (any-hover: hover) {
/* au moins l’un des modes de saisie raccordés

dispose du survol */

De même, il existe une règle permettant de détecter les navigateurs dont aucun des
modes de saisie ne prend en charge les interactions de survol :
@media (any-hover: none) {

/* au moins l’un des modes de saisie raccordés

ne dispose pas du survol */

}

Est-il préférable d’utiliser hover ou any-hover ? Tout dépend de ce qui est le plus pratique.
hover est déclenché lorsque l’interface de saisie principale du support permet de survoler le
contenu sans effort. any-hover, en revanche, est déclenché dès lors que le survol est
possible, même s’il nécessite un dispositif de saisie secondaire ou un effort supplémentaire
(certains navigateurs déclenchent les événements de survol avec une longue pression, par
exemple). Les choses peuvent s’embrouiller encore plus : alors que le navigateur de notre
exemple de gadget suivra la règle CSS de la media query hover:none, il honorera également
la pseudo-classe :hover lorsque vous utiliserez la souris pour survoler un élément. Ainsi,
même si cela peut sembler surprenant, cette règle CSS sera effectivement déclenchée :
@media (hover: none) {
/* le mode de saisie principal de l’appareil ne

comporte pas le survol */

a:hover {
/*, mais un mode de saisie secondaire sera capable
de survol, alors prévoyez cet usage */

color: red;

}
}

Ici, le navigateur respecte le souhait du designer d’offrir la meilleure mise en page

possible au mode de saisie principal (l’écran tactile), tout en respectant le mode de saisie
secondaire (la souris). Bienvenue dans le monde sauvage et extravagant du design pour
modes de saisie multiples.

Voyez grand sinon rien

La taille de votre écran peut varier, mais vos doigts restent les mêmes. Du plus petit
téléphone au plus grand ordinateur de bureau, les cibles tactiles doivent être assez grandes
pour être actionnées à la main. D’après une étude réalisée par Google en 2013, une
écrasante majorité (83 %) des sites web empêchent les utilisateurs de naviguer à cause de
cibles tactiles trop petites (http://bkaprt.com/dft/02-04/). Nos cibles tactiles doivent être
suffisamment grandes pour être infaillibles, de sorte que les gens puissent les utiliser sans
loucher ni marteler l’écran. Les petits menus <select>, les légendes minuscules dans les
barres d’outils et les pieds de page doivent être redimensionnés pour être utilisables.
Quelle taille faut-il viser ? La réponse passe par une question plus fondamentale :
quelle est la taille d’un doigt ? La largeur d’un doigt humain varie de 8 mm pour un enfant
à 18 mm pour l’incroyable Hulk, un écart considérable. Par chance, la largeur du doigt
importe moins que la surface du doigt qui entre en contact avec l’écran. Que vos doigts
soient menus ou trapus, cette surface est remarquablement uniforme.
LA TAILLE IDÉALE : 7 MM
Une cible tactile de 7 mm est optimale sur tous les appareils. Dans une étude portant sur
les écrans tactiles des téléphones et des ordinateurs de bureau, des chercheurs de
Microsoft ont testé la capacité des gens à toucher des cibles tactiles de différentes tailles
(http://bkaprt.com/dft/02-05/). Pas de surprise : plus le bouton est petit et plus les gens le
ratent fréquemment. À 5 mm, les utilisateurs rataient la cible une fois sur trente – un taux
d’erreur inacceptable. À 7 mm, ce taux chutait à un sur cent – pas mal – et à 9 mm, à un
sur deux cents. Au-delà de 9 mm, on ne constatait que de maigres améliorations (FIG 2.4).

FIG 2.4 : Une étude réalisée par Microsoft sur la précision des écrans tactiles a conclu que 7 mm était la taille minimale
pour une cible tactile.

Sur la plupart des écrans, 7 mm donne un résultat satisfaisant pour la plupart des
applications. Pour les situations critiques où une erreur pourrait susciter de sérieux regrets
(le bouton » libérez le kraken ! »), il peut être judicieux d’augmenter cette taille à 9, voire
11 mm. Vous pouvez également faire de même pour les boutons fermer, supprimer ou
d’autres actions destructives qui demandent » plus de deux gestes, cinq secondes ou un
changement de contexte important pour être corrigées », comme indiqué dans les
directives relatives aux interfaces utilisateur de Microsoft (http://bkaprt.com/dft/02-06/).
Sur les écrans de tablettes et d’ordinateurs plus spacieux, il est acceptable d’agrandir
toutes les cibles tactiles à 9 mm – taille qui offre une plus grande sécurité pour un coût
minime. Mais même dans ces cas, une taille plus petite donne des résultats précis. Pour la
plupart des cibles tactiles, considérez 7 mm comme votre minimum absolu.
EMPLACEMENT : MISE EN PAGE ET TAILLE DES CIBLES
Toutes les cibles tactiles ne sont pas égales. Sur les téléphones, la zone couverte par les
pouces en forme d’éventail est beaucoup plus précise que les autres parties de l’écran. En
clair : plus elles s’écartent de la zone des pouces, plus les cibles tactiles doivent être
grandes. Pensez notamment à élargir les cibles placées aux coins de l’écran à 11 mm, voire
plus, afin d’en améliorer la précision (FIG 2.5).

FIG 2.5 : Si 7 mm est une taille adéquate pour le centre de l’écran, il peut être judicieux de porter cette taille à 9 ou 11
mm dans les emplacements difficiles à atteindre, tels que les coins ou les rebords du haut et du bas. Données fournies par
Steven Hoober et Patti Shank (http://bkaprt.com/ dft/01-07/).

Comme toujours, les besoins spécifiques du public ciblé l’emportent sur toutes les
autres considérations. Si vous concevez pour des personnes à motricité réduite, comme les
très jeunes ou les très âgés, il peut être préférable d’offrir des cibles tactiles plus grandes,
entre 10 et 15 mm.
Super ! Mais… des millimètres ? Les millimètres ne sont pas franchement nos unités de
prédilection lorsque nous codons du CSS ou développons des applications mobiles. Que
représentent ces chiffres dans des unités plus familières ? Gravez ce nombre dans votre
caboche : 44.
CRÉEZ DES CIBLES TACTILES D’AU MOINS 44 (PIXELS, POINTS
OU DP)
Quarante-quatre est le nombre magique, la taille qui produit des cibles tactiles de 7 mm
sur toutes les plateformes. Sur le web, utilisez 44 pixels. Pour les applications natives,
utilisez les unités spécifiques à la plateforme : iOS utilise des points, tandis qu’Android
utilise des pixels indépendants de la densité, ou dp. Ces trois unités ne diffèrent que par
leur nom ; le point et le dp sont calibrés à 160 dpi, tout comme le pixel classique sur le
web. Vous pouvez donc utiliser les mêmes chiffres, quelle que soit la plateforme. À 160
dpi, 44 pixels représentent 7 mm – et voilà !
(Mais attendez, tous les écrans n’offrent pas une résolution de 160 dpi, non ? Comme la
densité de pixels varie énormément d’un appareil à un autre, les pixels eux-mêmes ne
changent-ils pas de taille ? Réponse courte : non. Réponse plus longue : voir à la fin de ce
chapitre. En attendant, fiez-vous au nombre 44.)
Si 44 est le strict minimum, vous pouvez utiliser une valeur plus élevée – surtout sur les
grands écrans – pour offrir des cibles tactiles simples et infaillibles. Si nous appliquons
notre calcul avec 160 dpi, 9 mm se traduit par 57 pixels, 10 mm par 63 pixels et 11 mm
par 69 pixels.
D’un autre côté, vous serez parfois forcé de choisir des dimensions plus petites.
Idéalement, toutes les cibles tactiles devraient être au minimum un carré de 7 mm de côté
– 44 pixels par 44 – mais les petits écrans demandent parfois des compromis. Le clavier de
l’iPhone, par exemple, comporte des touches qui font 44 pixels de haut, mais 30 de large –
de même, en orientation paysage, les boutons mesurent 44 pixels de large, mais 38 de
haut, afin de faire tenir tout le clavier AZERTY à l’écran.
Si les contraintes d’espace vous obligent à rétrécir les cibles tactiles, voici ce qui
fonctionne le mieux selon moi : du moment que la cible mesure au moins 44 pixels dans
sa longueur, vous pouvez, si c’est absolument indispensable, réduire sa largeur à 30 pixels,
soit un peu plus de 4,75 mm. Ce qui signifie que la taille pratique minimale pour
n’importe quelle cible tactile est de 44 × 30 (ou 30 × 44).
J’AIME L’EM
Problème, il est plutôt mal vu d’utiliser des pixels comme unités de longueur. En
responsive design, la bonne pratique consiste à utiliser des cadratins (em) pour les
dimensions et la mise en page (http://bkaprt.com/dft/02-03/). Les cadratins sont des unités
relatives basées sur la taille du texte ; un cadratin correspond à la hauteur de la police
actuelle. Il peut sembler contradictoire de vouloir fixer une taille physique minimale pour
nos cibles tactiles et d’utiliser des unités relatives pour ce faire, mais nous avons de la
chance. Pratiquement tous les navigateurs utilisent la même taille de police par défaut, 16
pixels, qui se traduit par un chiffre minimum magique de 2,75 em :
2,75 em = 44 px = 7 mm
3,5625 em = 57 px = 9 mm

Les cadratins posent toutefois rapidement problème parce qu’ils sont relatifs à la taille
de la police de l’élément parent. Ainsi, si vous créez un bouton de 2.75em dans un bloc de
texte de 12px, le bouton mesurera 33px, et non 44px. Voilà tous nos précieux calculs anéantis.

FIG 2.6 : Le design du pavé numérique de Skype place les boutons les uns à côté des autres, mais évite les erreurs en leur
donnant une taille bien supérieure à 44 pixels.

Lancez la musique héroïque, car rem arrive à la rescousse. Rem est l’abréviation de
root em, ou la taille de la police de l’élément racine – l’élément <html> dans le DOM.
Même si la police change de taille au cours du document, cette valeur rem fondamentale
est constante, car elle désigne toujours la taille de cet élément racine unique. La plupart
des navigateurs définissent une font-size racine de 16px, de sorte que 2.75rem équivaut à 44px.
Les rems ont été intégrés dans CSS3, et les navigateurs plus anciens ne les
comprendront pas (oui, c’est de toi que je parle, IE8). Pour venir en aide à ces navigateurs,
commencez par spécifier la taille en pixels, puis définissez-la à nouveau en rems :
html { font-size: 16px; } /* fixer la taille de police
standard à 16 pixels */

.touch { height: 44px; height: 2.75rem } /* 7 mm */

.touch-big { height: 57px; height: 3.5625rem }

/* 9 mm */

Et aussi simplement que ça, nous avons une règle cohérente pour les cibles tactiles dans
tous les navigateurs, en utilisant une unité relative qui se redimensionnera à l’échelle avec
tout le mojo responsive dont vous disposez.
NE M’ENTASSEZ PAS
L’espacement des cibles tactiles est aussi important que leur dimensionnement pour éviter
les erreurs. Plus les cibles sont proches, plus elles doivent être grandes. De même, plus les
cibles sont petites et plus vous devez les espacer.
Les directives de design de Microsoft donnent une norme fiable : espacez les cibles
tactiles de 7 mm d’au moins 2 mm (13 pixels ou 0,8125 rems). Si vous souhaitez
juxtaposer vos cibles tactiles, donnez-leur une taille minimale de 9 mm (57 pixels ou
3,5625 rems).
Pfiou. Nous avons donc parlé des dimensions, de l’espacement et de l’importance
d’utiliser le rem comme unité de longueur. Revenons à des considérations d’ordre
physique – avec les pixels. Puisque nous traitons avec des unités relatives et des écrans
dont la densité de pixels peut varier, comment un simple » 44 » peut-il garantir une
dimension physique spécifique ? Accrochez vos ceintures, mes amis : la route va devenir
un peu cahoteuse, mais ça en vaut la peine. Pour concevoir une interface physique, il est
essentiel de comprendre le rapport entre les pixels et les dimensions physiques. En fait, il
s’avère que les pixels ne sont probablement pas ce que vous imaginez.
CECI N’EST PAS UN PIXEL (LA SOURNOISERIE DES VIEWPORTS)
Les pixels ne sont plus ce qu’ils étaient. Vous vous souvenez sans doute qu’un pixel était à
l’origine défini comme un point physique sur l’écran. Nous appelons ces pixels des pixels
physiques, et aux premiers jours d’Internet, ces points faisaient la même taille sur tous les
écrans (96 dpi), car ces derniers – et la densité de pixels – présentaient peu de variations.
Aujourd’hui, les affichages vont des écrans à très faible densité sur les appareils plus
anciens aux écrans Retina super-denses et tous leurs semblables. Cette diversité pose un
problème pour les vieilles pages web conçues en pixels : le rendu physique d’un même
site est beaucoup plus petit sur un écran haute résolution que sur un écran basse résolution
(FIG 2.7).

FIG 2.7 : Les variations de résolution sur les écrans ont introduit un problème d’échelle : le même contenu, par exemple
un fichier image, présente des dimensions physiques différentes sur les écrans haute résolution (à gauche) et les écrans
basse résolution (à droite). Un pixel ne correspond plus à la même taille sur des appareils différents. Photographie de
Veronika Sky Kindred (http://bkaprt.com/dft/02-07/).

Pour ne rien arranger, le W3C a redéfini le pixel en 2011 avec CSS 2.1. Le nouveau
pixel n’était plus ce petit point de lumière dépendant du matériel, mais désignait plutôt une
distance physique particulière. En d’autres termes, nous avons quitté le monde des pixels
matériels pour entrer le monde des pixels virtuels, parfois appelés pixels de référence,
pixels CSS ou pixels web. Ces pixels virtuels ont une taille spécifique, de même qu’un
pouce ou un centimètre, taille qui reste identique sur tous les écrans, quelle que soit la
densité de pixels de l’affichage.
Le W3C a fixé le pixel à 96 dpi, l’ancienne taille de vos vieux moniteurs de bureau –
soit 1/96e de pouce. Cette approche aurait pu simplifier nos affaires… si les navigateurs
avaient effectivement suivi la norme. Le problème, c’est que les navigateurs sur les écrans
tactiles n’emploient pas ce pixel virtuel de 96 dpi. D’ailleurs, si les navigateurs
fonctionnent aussi bien sur les téléphones et les tablettes, c’est justement parce qu’ils
ignorent délibérément cette règle.

Les viewports dynamiques exigent des pixels dynamiques

Le responsable est le viewport dynamique, ce tour de passe-passe qui vous permet de
zoomer sur les pages web en pinçant l’écran. Sur ces gadgets, les sites web (et donc les
pixels) n’ont pas de taille physique spécifique. En ce moment même, je regarde le site du
New York Times, qui fait 972 pixels de large à l’heure où j’écris ces lignes. Conformément
à la spécification CSS, pour laquelle 96 pixels équivaut à un pouce, le site devrait mesurer
plus de 10 pouces de large :
972 px ÷ 96 dpi = 10,13 pouces

Et pourtant, quand je visionne le site sur mon téléphone, il tient dans moins de 3
pouces. Et c’est tant mieux, car c’est la seule façon d’afficher la page entière sur un petit
écran. À partir de là, je peux zoomer sur la page pour lire le contenu qui apparaît
soudainement bien plus grand (FIG 2.8). C’est ce qui permet de rendre les sites
de » bureau » utilisables sur les petits écrans. Par leur nature, les viewports dynamiques
démantèlent la notion selon laquelle le pixel correspond à une dimension physique fixe.

FIG 2.8 : L’idée d’un pixel de taille fixe est dynamitée lorsque vous zoomez sur un site web.

La solution consiste à indiquer au viewport qu’il ne doit pas être dynamique. Si un

viewport dynamique est nécessaire pour agrandir et rétrécir un site qui n’existe que dans
sa version de bureau, il est encore préférable de redimensionner le site de façon réactive,
de sorte qu’il soit rarement nécessaire de zoomer.
Utilisez device-width pour définir la taille du viewport
Un site responsive bien conçu utilise la largeur de l’appareil pour fixer la taille du
viewport en ajoutant la ligne suivante dans la balise <head> de la page :
<meta name="viewport" content="width=device-width,

initial-scale=1.0" />

Cette balise permet de dire au navigateur » choisis ta propre largeur fixe pour mon site
web, je te fais confiance ». Considérez device-width comme la taille » naturelle » d’un
appareil, définie en pixels virtuels. Sur les téléphones et les tablettes, cela correspond à la
largeur entière de l’écran ; sur un ordinateur de bureau, il s’agit de la largeur de la fenêtre
du navigateur.
(Comme vous l’aurez peut-être deviné, width=device-width définit la largeur du viewport.
initial-scale=1.0 demande au navigateur de ne pas agrandir ni rétrécir la page lors du
chargement. Cela a pour effet d’empêcher Safari mobile d’agrandir la page en mode
paysage. Au lieu de cela, le navigateur reformate la mise en page pour l’adapter à un écran
plus large.)
Jetons un œil à l’iPhone 6 pour voir comment cela fonctionne dans la pratique. Le
device-width du téléphone est de 375 pixels. (Là encore, il s’agit de pixels virtuels et non
matériels ; la résolution matérielle de l’iPhone 6 est de 750 pixels de large.) Lorsque vous
utilisez la balise <meta> présentée plus haut, la taille du viewport est fixée à 375 pixels
web » naturels ». C’est également sur cette taille que les media queries du viewport
s’appuieront. Dans notre exemple de l’iPhone 6, une fois cette balise <meta> en place, toute
media query qui comporte une propriété max-width ou min-width correspondant à un viewport
de 375px de large appliquera ses règles CSS au téléphone.
Ainsi, du moins sur des appareils individuels, les pixels web peuvent prendre une
largeur fixe, à supposer que vous ayez fixé la largeur du viewport comme indiqué ci-
dessus. Mais ce ne sera presque jamais la taille de 96 dpi définie par la spécification
originale. En 2007, quand Apple a pris la décision de fixer le device-width du premier
iPhone à 320px, ses pixels web ont pris une taille d’environ 160 dpi, et ce choix a affecté
tous les navigateurs mobiles qui ont suivi : Apple a eu beaucoup de succès avec son
viewport dynamique et a également introduit la balise <meta name="viewport"> ; tout le monde
a suivi le mouvement. Aujourd’hui, pratiquement tous les navigateurs mobiles rapportent
un device-width qui donne à peu près la même densité aux pixels virtuels : 160 dpi est
devenu la norme de facto des pixels web sur les écrans tactiles.
Et c’est pour cela que la règle des 44 pixels fonctionne.
Vous me suivez toujours ? Nous avons redéfini le sens du mot » pixel » plusieurs fois
dans ces quelques pages, mais cette gymnastique nous a permis de déterminer des
dimensions fiables pour les cibles tactiles, basées sur cette convention de 160 dpi pour les
navigateurs tactiles. Après tout, peut-être les écrans sont-ils plus fiables que ce que l’on
pensait… si l’on change de perspective. Le prochain chapitre appelle à un ajustement
similaire mais aborde les interactions courantes. Nous allons devoir repenser nos modèles
de design afin de les rendre plus efficaces pour nos doigts et nos pouces lents. Démarrez le
moteur, il est temps d’étancher notre soif de vitesse.
LES MEILLEURES INTERFACES semblent traduire les intentions en actions instantanément, en
un seul clic. Il peut paraître insignifiant de gagner quelques millisecondes par-ci et par-là,
mais ces instants s’additionnent et s’accumulent. Ce gain d’efficacité imprègne votre
interface d’une sorte de fluidité zen. » On n’imagine pas qu’un gain d’une seconde, d’un
clic ou d’un instant de réflexion puisse avoir de l’importance, mais c’est le cas », écrit le
designer John McWade. » Cela rend l’appareil plus transparent ; celui-ci n’est plus tant
une machine qu’une extension du cerveau et de la main. Faites un vœu, et pouf, il est
exaucé, comme si l’appareil était vivant, comme s’il respirait » (http://bkaprt.com/dft/03-
01/).
Quel est le secret de cette interface sans peine ? Elle est conçue pour être confortable et
rapide. Jusqu’à présent, nous nous sommes intéressés au confort : une bonne ergonomie et
des cibles tactiles généreuses. Mais comment rendre votre interface plus rapide ?
Habituellement, lorsqu’on parle de vitesse, on évoque les performances techniques –
combien de temps prend le téléchargement et le rendu d’une page web ou de l’écran d’une
application. Cet aspect est important, bien sûr, mais en s’évertuant à optimiser les bits et
les octets, on en oublie d’optimiser pour les doigts et les pouces. Les bonnes pratiques que
nous avons héritées de l’ère des ordinateurs de bureau sont pour une bonne part
déconnectées des réalités de l’écran tactile. Ce chapitre vous apprendra à optimiser ces
solutions de design familières pour accélérer les interactions tactiles.
INFORMATIONS ET CONTRÔLES JUSTE À TEMPS
Vous connaissez ces séries télé médicales, celles où le chirurgien est épaulé par une équipe
héroïque d’assistants intuitifs qui anticipent chacun de ses besoins et lui donnent toujours
le bon instrument au bon moment ? Voilà le modèle que doit suivre votre interface : elle
doit se tenir discrètement à l’écart tant que l’utilisateur n’a pas besoin de son aide, et
réapparaître exactement avec l’outil nécessaire. Le facteur essentiel pour offrir une
interface rapide est de fournir juste ce qu’il faut et précisément au bon moment.

Permettre les tâches principales directement à partir des vues en liste

Nous réalisons les tâches plus rapidement lorsque nous avons moins d’interfaces à
parcourir : nous absorbons une page rapidement lorsqu’elle se concentre seulement sur
quelques tâches ou types d’informations essentiels, et nous assimilons une seule page plus
vite que plusieurs pages. Une page qui liste des produits, par exemple, doit permettre
d’ajouter facilement ces produits au panier à partir du même écran (FIG 3.1). Offrez un
accès facile aux actions qui ne demandent qu’un seul clic pour permettre aux gens de
parcourir une liste et de sélectionner des articles sans avoir à changer de vue.

FIG 3.1 : Une envie irrepressible de hamburger ? L’application de courses en ligne FreshDirect offre un lien direct pour
ajouter un produit à votre panier. En touchant la ligne à un autre endroit, vous êtes amené vers une page décrivant votre
viande en boîte préférée dans les moindres détails.

Il n’est pas non plus nécessaire de gaspiller de l’espace pour ajouter ces actions. Vous
pouvez traiter ces raccourcis comme des options avancées en les dissimulant derrière des
panneaux cachés et en les révélant d’un geste (FIG 3.2). De nombreuses applications, y
compris des navigateurs, affichent de même un menu contextuel lorsque vous appuyez
longuement sur un élément. L’inconvénient, c’est que ces raccourcis sont véritablement
invisibles tant qu’ils n’ont pas été découverts. Nous verrons comment indiquer la présence
de ces gestes au chapitre 5.

FIG 3.2 : L’application Mail d’iOS (à gauche) révèle un menu d’options lorsque vous balayez un message de droite à
gauche. De même, l’application Vimeo pour iPhone (à droite) vous permet de partager ou d’ajouter une vidéo à vos
favoris en la balayant de gauche à droite. Ces deux actions vous évitent d’avoir à passer par un écran distinct.

Offrez un résumé concis des informations

Le principe consistant à offrir un accès aux tâches principales à partir des vues en liste
s’applique également aux informations clés. Par exemple, dans une vue affichant une liste,
intégrez les données les plus importantes de chaque élément dans cette vue, au lieu
d’obliger les gens à parcourir une série de pages détaillées distinctes. (Comme le nom
l’indique : réservez les informations » intéressantes » – ou plus simplement, les détails –
pour la vue détaillée.) Placez les informations essentielles dans la liste générale, et vous
court-circuiterez le besoin d’en savoir plus. C’est pour cette raison que les applications de
messagerie électronique incluent les premiers mots de chaque message dans l’affichage de
la boîte de réception, pour vous permettre d’écumer la liste. Ou prenez les applications de
météo, qui représentent les conditions météorologiques par heure ou par jour à l’aide
d’une combinaison familière de température et d’icônes . La plupart des gens qui
souhaitent connaître les prévisions se contenteront de cette présentation compacte. Les
précipitations, la pression barométrique et autres détails pratiques peuvent – et doivent –
être dissimulés à un clic de distance pour les plus curieux, mais le cas d’utilisation
principal est traité dans la représentation en liste (FIG 3.3).
FIG 3.3 : Cette vue heure par heure de la météo vous donne un aperçu des prévisions d’un seul coup d’œil. Vous pouvez
appuyer sur une heure pour obtenir plus de détails, mais dans la plupart des cas, vous avez uniquement besoin de la
température et de l’icône qui l’accompagne.

Cette approche, appelée dévoilement progressif (progressive enhancement), donne juste

assez d’informations au moment opportun et ne fournit de renseignements
supplémentaires que sur demande. Le dévoilement progressif, lorsqu’il est bien appliqué,
vous permet de conserver une expérience immédiate claire et focalisée, tout en offrant
l’accès à des données plus complexes au besoin. Pour poursuivre notre exemple
d’application météo, les meilleurs sites et applications du genre permettent aux amateurs
de météorologie de se délecter des statistiques barométriques, tandis le reste d’entre nous
pouvons vérifier rapidement si nous avons besoin de prendre un parapluie.
Le dévoilement progressif préfère la clarté à la densité, et le compromis consiste à
ajouter quelques interactions supplémentaires pour accéder aux informations les plus
détaillées. Rien de bien grave. Créer des interfaces plus rapides ne consiste pas toujours à
réduire le nombre d’interactions ; c’est la qualité qui compte.

Distinguez les interactions de qualité des interactions inutiles

Nous répugnons toujours à ajouter quelques clics supplémentaires, et avec raison ; aux
débuts du Web, les réseaux étaient si lents qu’il pouvait s’écouler une éternité avant que
l’on parvienne à accéder à un lien. Ce problème a refait son apparition avec la lenteur des
réseaux mobiles, mais nous avons beaucoup appris depuis cette triste époque. Les pages
web peuvent aujourd’hui rapatrier le contenu avant de l’afficher, et les applications ont
souvent du contenu prêt dans une base de données locale. Lorsque les téléchargements ne
sont pas un problème, il est souvent souhaitable d’ajouter des interactions intermédiaires
afin de résumer chaque écran à un message ou une tâche clé.
La qualité de ces interactions est beaucoup plus importante que la quantité. Du moment
que chaque interaction apporte quelque chose – une nouvelle information, la réalisation
d’une tâche, ou même un simple sourire, c’est une interaction de qualité qui préserve la
dynamique du site ou de l’application. L’ennemi, ce sont les interactions inutiles, ou celles
que vous pourriez éviter avec un affichage plus intelligent du contenu ou un geste plus
efficace. Prenez ce bulletin météo. Si le sélecteur des heures n’affichait que les heures,
sans la température ni l’icône de la météo, il vous faudrait sélectionner chaque heure
séparément pour voir l’évolution de la météo du jour – autant d’interactions inutiles. Il
suffit d’ajouter juste assez d’informations pour éviter à vos utilisateurs de faire les
poubelles.

Laissez les actions de l’utilisateur déclencher l’affichage des contrôles

Créez des interfaces qui observent en silence (et réagissent à) la façon dont les gens les
utilisent ; faites en sorte que votre application débarque au bon moment pour présenter les
options pertinentes sur un plateau d’argent. Ce genre d’interaction prédictive ne demande
aucun talent de divination. Dans bien des cas, certaines commandes ne sont utiles que
dans des contextes précis. Par exemple, les interfaces tactiles font apparaître des outils de
copier/coller uniquement lorsque vous sélectionnez du texte. D’autres indices
comportementaux peuvent indiquer des désirs courants : dans Instagram, le flux de photos
défile vers le bas de l’écran, et les gens visionnent presque toujours les images dans cet
ordre ; un défilement vers le haut indique un changement d’objectif. Lorsque cela se
produit, Instagram devine que vous cherchez peut-être les contrôles du sommet de la page
et les fait apparaître à l’écran (FIG 3.4).
FIG 3.4 : Une fois que vous avez fait défiler la page vers le bas (à gauche), la barre d’outils d’Instagram réapparaît
lorsque vous remontez (à droite), anticipant que vous puissiez avoir besoin d’accéder au menu de l’application.

L’exemple d’Instagram témoigne d’un service rapide et prévenant, mais c’est

également un raccourci pour l’une des interactions qui fait perdre le plus de temps : le
scrolling tant redouté. Instagram nous épargne le voyage vers le sommet d’une longue
page, mais une autre solution consiste à raccourcir cette longueur dès le départ.
DÉGROSSIR LE SCROLLING
Le scrolling en lui-même n’est pas une mauvaise chose – il fait partie du charme des
écrans tactiles –, mais les pages très longues présentent le double inconvénient de fatiguer
vos pouces et d’éprouver votre patience. Des pages compactes sont des pages agréables à
parcourir.
Le scrolling à rallonge est courant sur les petits écrans, là où les designers ont tendance
à empiler le contenu dans une seule colonne interminable. C’est une approche
compréhensible, mais fondamentalement paresseuse du responsive design : qu’est-ce que
je fais de cette mise en page en trois colonnes ? Facile, je les empile toutes en une seule
colonne absolument gigantesque, et voilà ! Même si vos visiteurs parviennent au contenu
qu’ils cherchent après avoir fait défiler votre page mal ficelée, il n’est pas dit qu’ils aient
la force de l’ouvrir après tous ces efforts.
Gérer une grande quantité de contenu demande plus de nuance. Une stratégie consiste à
déployer des mises en page hors canvas (http://bkaprt.com/dft/03-02/). Ces dernières
placent des colonnes ou des panneaux de contenu en dehors de l’écran jusqu’à ce que
l’utilisateur les appelle – une autre forme de dévoilement progressif (FIG 3.5). Quelques
exemples :

FIG 3.5 : Un écran large (en haut) permet de présenter toutes les colonnes en même temps, alors qu’un plus petit offre la
possibilité de les afficher hors champ, affichant le contenu conceptuellement adjacent lorsqu’il est pertinent ou demandé.

• un menu de navigation qui apparaît en haut ou sur le côté de l’écran ;

• un encadré qui s’affiche avec des informations supplémentaires ;
• un long formulaire scindé en plusieurs sections (les grands écrans pourront afficher le
formulaire entier, tandis que les petits écrans l’afficheront section par section, chacune
d’entre elles occupant la totalité de l’écran).
L’approche de design hors canvas vous permet de préserver une fonction essentielle des
colonnes : afficher des morceaux de contenu associés côte à côte. Placez un encadré en
dehors de l’écran jusqu’à ce qu’il devienne pertinent ou qu’il soit demandé, et vous
éviterez un long scrolling tout en conservant ce contenu à portée de main. Les accordéons,
les toggles et autres schémas de design qui condensent le contenu secondaire tiennent un
rôle similaire.
Une approche de mise en page hors canvas populaire mais souvent mal utilisée est celle
du carrousel. Un carrousel est un widget semblable à un diaporama qui découpe le contenu
en différents panneaux qui défilent et s’affichent un par un (FIG 3.6). Son intérêt principal
est de réduire la hauteur d’une page en concentrant le contenu important en un îlot de
panneaux horizontaux. En dépit de ses bonnes intentions, les carrousels sont souvent
employés à tort et à travers.

FIG 3.6 : De nombreux sites utilisent un carrousel pour afficher un assortiment de fonctions diverses. Malheureusement,
cette approche tend souvent à dissimuler le contenu qu’elle cherche à mettre en évidence.
L’ABUS DE CARROUSELS NUIT À LA SANTÉ
Les carrousels peuvent être formidables dans le bon contexte – nous verrons lesquels par
la suite – mais ils peuvent facilement mal tourner, surtout lorsqu’ils sont utilisés sur une
page d’accueil. Les designers adorent en mettre en page d’accueil, parce qu’ils donnent
l’impression de résoudre de nombreux problèmes en ayant un fort impact visuel sans
sacrifier trop d’espace. Les sites médiatiques déversent leurs articles à la une dans des
carrousels, et hop, tous les gros titres occupent par magie la même position de premier
choix au sommet de la page. Les sites de vente en ligne font la même chose avec leurs
promotions. Les carrousels font même miroiter la promesse d’éliminer le pire ennemi du
designer, le positionnement organisationnel : sur le site marketing d’une entreprise, chaque
service veut obtenir un emplacement privilégié sur la page d’accueil. Balancez-les tous
dans un carrousel et voilà, mission accomplie.
Si les carrousels permettaient un affichage compact avec un fort impact visuel tout en
résolvant les conflits de politique interne, je veux monter sur ce manège tout de suite,
non ? Malheureusement, les carrousels tiennent plus de l’or des fous que de la balle
d’argent, car ils exigent des denrées des plus précieuses : de la patience et de l’attention.

Un parcours du combattant
Lorsque le but est d’optimiser les taux de clics ou de parcourir rapidement le contenu, les
carrousels ont tendance à nous décevoir. Prenons par exemple un carrousel qui présente
dix articles sur un site d’actualité ; avant de tomber sur ce dixième article, vous devrez
vous donner la peine de passer les neuf autres – neuf interactions avant de pouvoir ne
serait-ce que lire le titre. L’article est clairement l’un des plus intéressants du jour, mais il
est enterré sous une pile d’interactions. Un outil destiné à mettre en évidence du contenu
ne doit pas le dissimuler ou vous obliger à vous fouler le pouce pour le trouver. Le
problème empire quand le carrousel est un amas de fonctions ou de produits. Lorsque la
collection n’est pas organisée, les gens n’ont aucun moyen de savoir ce qui se trouve dans
la suite du carrousel et s’en désintéressent rapidement.
Une étude a démontré que 84 % des clics effectués sur le carrousel d’une page
d’accueil se font sur la première diapositive ; les diapos suivantes ne sont pratiquement
jamais actionnées (http://bkaprt.com/dft/03-03/). À ce sujet, lisez » Carrousels à
redirection automatique, les accordéons agacent les utilisateurs et réduisent la visibilité »
(http://bkaprt.com/dft/03-04/) et » Les carrousels sur les pages d’accueil sont-ils
efficaces ? » (http://bkaprt.com/dft/03-05/). Il doit bien exister un moyen de diriger plus de
trafic vers les pages prioritaires.
Et la fonction de progression automatique ? Si les gens ne veulent pas parcourir
toutes les diapositives, faites-le à leur place. Mais l’idée qu’on puisse avoir envie de rester
assis à regarder le carrousel défiler est, au mieux, optimiste – surtout dans un contexte
mobile. La dure vérité, c’est que vous demandez à l’utilisateur d’endosser une décision et
un effort qui vous reviennent.
Forcez une décision éditoriale. À en écouter les sirènes du carrousel, plus besoin de
sélectionner le meilleur article ou le produit phare à afficher sur la page d’accueil. Ils sont
tous à la une ! En pratique, ça ne tient pas la route. Si l’écrasante majorité des utilisateurs
consultent uniquement le premier article du carrousel, vous ne pouvez pas prétendre qu’ils
sont tous sur un pied d’égalité. Mieux vaut faire un choix éditorial et mettre en évidence
cet article d’une façon offrant facilement accès aux articles secondaires.
Privilégiez les interactions accessibles d’un seul clic. Au lieu de dissimuler le contenu
derrière une flopée de balayages, offrez un seul bouton permettant de tout révéler à la fois.
La page d’accueil mobile d’Entertainment Weekly affiche un article principal et deux
articles secondaires. Appuyez sur le bouton » More », et vous obtenez douze titres de plus
(FIG 3.7). Cette approche permet d’esquiver les quatorze (quatorze !) balayages dont vous
auriez besoin pour atteindre ce dernier article dans un carrousel, et vous y amène
directement en un clic. Ces douze articles sont toujours masqués derrière le bouton, mais
les trois articles visibles donnent une idée de ce que vous trouverez de l’autre côté. Cette
approche remplace l’odeur fétide du ragoût mystère par le parfum rassurant de
l’information, l’assurance que vous êtes sur la bonne voie pour atteindre votre objectif.
FIG 3.7 : Le site mobile d’Entertainment Weekly révèle ses quinze articles principaux en une seule interaction (en
appuyant sur le bouton More Featured News), au lieu des quatorze balayages que demanderait un carrousel.

Remplissez ces panneaux. L’exemple d’Entertainment Weekly fonctionne parce qu’il

donne aux gens juste assez d’information pour qu’ils devinent ce qui se trouve derrière le
bouton » More », ce qui est la clé de n’importe quelle stratégie de dévoilement progressif.
Lorsque vous présentez plusieurs articles sur un seul panneau d’un carrousel, la densité de
contenu résultante donne une idée de ce qui se trouve vraisemblablement sur le panneau
suivant : un thème commence à émerger (FIG 3.8). Cette densité entraîne également un
gain de temps en demandant moins d’interactions que les panneaux qui comportent un
seul élément.

FIG 3.8 : Les pages d’accueil de sites d’actualité tels que TechCrunch et le New York Times déploient en milieu de page
un carrousel qui présente plusieurs articles à la une avant de vous inviter à faire défiler les articles suivants.

Quand les carrousels ont du génie

Nous nous sommes intéressés au cas le plus flagrant – les carrousels présentant du contenu
divers sur une page d’accueil, mais avant cela, je vous ai promis d’aborder les bons
contextes pour déployer un carrousel.
Les carrousels sont parfaits pour les données linéaires. Revenons à notre bulletin
météo heure par heure. La présentation horizontale du carrousel cadre parfaitement avec
une visualisation chronologique classique, et comme l’ordre des données est évident et
prévisible, l’odeur de l’information est puissante. Vous savez ce que vous obtiendrez en
faisant défiler le carrousel : les prévisions des heures suivantes. Mais les données linéaires
ne doivent pas forcément être strictement mathématiques. Les carrousels fonctionnent
également bien pour les diaporamas de style PowerPoint qui racontent une histoire,
présentent un argumentaire ou offrent un aperçu des fonctionnalités d’un produit ; toute
progression logique de ce genre est une source de données linéaires et peut faire l’objet
d’un carrousel (FIG 3.9).
FIG 3.9 : Le site Should I Use a Carousel? (http://bkaprt.com/dft/03-06/) soutient que les carrousels sont un fléau.
Ironiquement, son diaporama de style PowerPoint est une excellente utilisation d’un carrousel comme trame narrative.

Les carrousels sont utiles pour parcourir simplement des articles apparentés. Il
s’agit d’un format approprié pour les galeries de photos et les diaporamas, créant un
environnement idéal pour découvrir du contenu au hasard. Comme toujours, les carrousels
fonctionnent mieux lorsque les gens ont une bonne idée de ce qu’ils y trouveront – ce qui
signifie que les diaporamas les plus efficaces se focalisent sur un sujet spécifique (des
photos sur tapis rouge ! des chats avec des chapeaux rigolos !). Dans ce contexte, vous
n’optimisez pas pour plus de vitesse mais pour une balade langoureuse à travers les
images, de sorte que le défilement du carrousel ne soit plus un inconvénient mais une
fonctionnalité.
SOYEZ IMPITOYABLES AVEC LES CHAMPS DE FORMULAIRES
Les formulaires web sont ces abominables formalités administratives que nous
remplissons pour parvenir à l’objet de nos rêves : un service à recevoir, un produit à
acheter. Les formulaires sont des obstacles nécessaires, mais plus l’obstacle est grand, et
moins la chose qui se trouve de l’autre côté nous fait rêver. Vingt-et-un pour cent des
achats abandonnés le sont parce que les clients ont trouvé le processus trop long
(http://bkaprt.com/dft/03-07/). Chaque champ compte : une étude a démontré qu’en
réduisant le nombre de champs d’un formulaire de contact de quatre à trois, on améliorait
le taux de conversion de près de moitié (http://bkaprt.com/dft/03-08/). Et s’il s’agit d’une
bonne pratique sur n’importe quelle plateforme, c’est essentiel sur les écrans tactiles. Ces
derniers présentent de nombreux avantages, mais les interactions précises telles que la
saisie de texte et le remplissage de formulaires n’en font pas partie.
Le site mobile de Kay Jewelers demande aux clients de remplir quarante champs pour
finaliser un achat (FIG 3.10). (« Elle n’en vaut pas la peine ! », m’a crié quelqu’un alors
que je présentais ce formulaire au cours d’un atelier de design.) Je ne m’en prends pas
spécialement à Kay Jewelers ; quarante (ou plus !) est malheureusement un nombre
courant. Alors, élaguons un peu ces formulaires.
FIG 3.10 : Rien de tel que de remplir quarante champs de formulaire pour finaliser un achat…

Condensez les données à champs multiples. Le formulaire scinde le nom du client en

trois champs : premier prénom, deuxième prénom et nom de famille. Il en fait de même
avec les numéros de téléphone et l’adresse postale (FIG 3.11).

FIG 3.11 : Arrêtez de vous disperser. Vous n’avez pas besoin de trois champs pour demander un nom – et encore moins
de neuf champs pour un numéro de téléphone.

Dans ces trois cas, il est préférable de combiner les champs. De trop nombreux
formulaires concordent précisément avec la base de données du site. Si celle-ci comporte
trois champs pour le nom, le designer les retranscrit consciencieusement dans trois champs
sur le formulaire. Mais ce n’est pas à votre client de remplir votre base de données ; c’est à
vous de faire ce travail pour eux. Passer d’un champ à l’autre demande une interaction de
plus et interrompt le déroulement du processus. Simplifiez la vie de vos utilisateurs en
combinant ces données dans un seul champ, puis formatez les informations en arrière-plan
pour les insérer dans votre base de données.
Ne demandez pas d’informations superflues. Tout champ supplémentaire est un
fardeau de plus pour votre client. Notre formulaire d’exemple ne demande non pas un,
mais trois numéros de téléphone. Demander un seul numéro de téléphone présente déjà
peu d’intérêt pour des achats en ligne ; avez-vous vraiment besoin de deux numéros de
plus ? Avez-vous besoin d’une adresse de facturation complète, alors que la plupart des
services de traitement de carte de crédit ne requièrent que le code postal ? Soyez
impitoyable quant à la quantité d’informations que vous demandez.

FIG 3.12 : Pas besoin de demander au client quel type de carte de crédit il possède ; cela se déduit du numéro de sa carte.

Répondez à vos propres questions. De même, ne posez pas au client de questions

auxquelles vous pouvez répondre vous-même. Pas besoin de demander la ville et la région
si vous avez le code postal. Pas besoin de demander quel type de carte de crédit il possède,
puisque c’est inscrit dans le numéro de compte. (Les cartes American Express
commencent par 34 ou 37, par exemple ; les MasterCard commencent par 51 à 55.) Là
encore, ne forcez pas votre client à remplir votre base de données à votre place.
Simplifiez les paiements par carte de crédit. La plupart des services de traitement de
cartes de crédit demandent très peu d’éléments à titre d’authentification : numéro de
compte, date d’expiration, code de sécurité (CVV, ou cryptogramme visuel) et code postal.
Uniquement des données numériques. Le service de paiement mobile Square a développé
une solution intelligente qui condense toutes ces informations en un seul champ, et fournit
un clavier numérique pour saisir les données rapidement (FIG 3.13).
FIG 3.13 : Square vous permet de fournir les informations de votre carte de crédit dans un seul champ en utilisant un
simple clavier numérique. À mesure que vous saisissez les données, l’icône du champ se transforme pour confirmer le
type de carte (en haut à droite) et vous indiquer où trouver le cryptogramme visuel, ou CVV (coin inférieur droit).

Vous commencez par saisir votre numéro de carte ; après avoir saisi les premiers
chiffres, l’icône change en fonction du type de carte détecté. Lorsque vous avez fini de
saisir le numéro, la chaîne de caractères est raccourcie pour ne conserver que les quatre
derniers chiffres, puis le champ de saisie se transforme pour afficher les trois informations
requises restantes : la date d’expiration, le cryptogramme et le code postal. Pas besoin de
passer d’un champ à l’autre, il suffit de saisir toutes les données à la suite sur le clavier
numérique. Lorsque vous arrivez au CVV, l’image de la carte de crédit se retourne pour
vous indiquer où se trouve le code. Ce schéma permet un gain de temps et d’espace et
réduit le nombre d’interactions tout en guidant l’utilisateur et en vérifiant les informations
au fur et à mesure.
S’inspirant de l’approche de Square, le développeur Zachary Forrest a conçu un
prototype HTML qu’il a rendu accessible sur le web (http://bkaprt.com/dft/03-09/).
AVEZ-VOUS VRAIMENT BESOIN DE CE CLAVIER ?
La raison implicite pour laquelle il est impératif d’alléger les formulaires, c’est que la
saisie de texte sur un écran tactile est… extrêmement… lente. Ne vous méprenez pas :
nous le faisons de bon gré avec la bonne motivation. Selon un mythe populaire, nous
rechignons à taper sur nos écrans tactiles, mais nous envoyons et recevons en moyenne 35
messages par jour (http://bkaprt.com/dft/03-10/) – et plus d’une centaine chez les
adolescents (http://bkaprt.com/dft/03-11/). Pour autant, nous ne le faisons pas de façon très
efficace, et nous commettons encore beaucoup d’erreurs en tapant. Lorsque vous êtes tenté
d’afficher le clavier, commencez par envisager des alternatives.
Complétez les zones de saisie par des alternatives à cliquer. S’il y a fort à parier que
le terme saisi par l’utilisateur appartienne à un champ restreint de possibilités, offrez les
boutons cliquables correspondants à côté du champ. Par exemple, un site de voyage pourra
utiliser l’historique d’achat du client ou sa localisation GPS pour suggérer des aéroports de
départ (FIG 3.14).

FIG 3.14 : Offrez des suggestions pour alléger la saisie de données.

Prenez en charge le remplissage automatique. La plupart des navigateurs comportent

une fonction de remplissage automatique, ou autofill, permettant de remplir un formulaire
avec des informations courantes telles que le nom, l’adresse, le numéro de téléphone,
l’adresse électronique, etc. Aidez les navigateurs à récupérer les champs appropriés en
utilisant des valeurs spécifiques dans le nom et les attributs de saisie automatique de ces
champs (FIG 3.15), comme ceci :

FIG 3.15 : Valeurs recommandées pour les attributs name et autocomplete

<form method="post" autocomplete="on">

Nom : <input type="text" name="name"

autocomplete="name">
 Adresse électronique : <input type="email" name="email"

autocomplete="email">
Téléphone : <input type="tel" name="phone"

autocomplete="tel">
Adresse : <input type="text" name="address"
autocomplete="address">

</form>

Vous pouvez activer le remplissage automatique en ajoutant l’attribut autocomplete="on"

dans le formulaire ou les champs de saisie (le remplissage automatique fonctionne
uniquement lorsque l’attribut method du formulaire est réglé sur post). Par défaut, les
formulaires acceptent toujours le remplissage automatique, mais les utilisateurs devront
parfois activer la fonction dans les préférences de leur navigateur.
Utilisez des données provenant d’autres applications. Il se peut que les informations
que vous demandez se trouvent déjà sur l’appareil. Si vous concevez une application ayant
accès au répertoire, permettez à l’utilisateur de choisir un contact pour remplir
automatique l’adresse, le téléphone et l’adresse électronique. Dans l’exemple de
l’application de voyage, le champ » Destination » peut offrir de sélectionner un contact
pour obtenir l’adresse de votre destination, déterminer quel est l’aéroport le plus proche et,
le cas échéant, quelles sont les options de transport locales pour vous rendre jusqu’à votre
destination (voiture de location, train ou bus).
LE BON CLAVIER POUR LA BONNE TÂCHE
Quand vous ne pouvez pas vous passer d’un clavier, offrez au moins le clavier approprié
en spécifiant l’attribut type des éléments input de la page. La plupart des navigateurs offrent
des claviers optimisés pour ces types de champs afin de remplir facilement les
formulaires.
<input type=•email•>

<input type=•url•>
<input type=•tel•>

<input type=•number•>

Dans la plupart des navigateurs, ces attributs type font apparaître exactement le clavier
dont vous avez besoin. Dans Safari mobile, cependant, le clavier affiché pour type="number"
comprend à la fois des numéros et des signes de ponctuation (FIG 3.16). Si vous souhaitez
obtenir un clavier numérique, vous pouvez le forcer en spécifiant un attribut pattern et en
ajoutant inputtype pour faire bonne mesure :

FIG 3.16 : Demandez à Safari mobile un simple champ type="number" et vous obtiendrez un clavier bourré de signes de
ponctuation (à gauche). Ajoutez les attributs pattern et inputtype, et vous obtiendrez un clavier entièrement numérique
(à droite).
<input type="number• pattern=•[0-9]*•
inputtype="numeric•>

De nombreux navigateurs tactiles utilisent également type pour se passer tout

simplement de clavier lorsqu’il s’agit de saisir une date ou une heure. Utilisez l’un de ces
types de champ pour obtenir un sélecteur de date ou d’heure natif (FIG 3.17).
FIG 3.17 : Android Chrome (à gauche) affiche une interface de calendrier en plein écran lorsque vous sélectionnez un
champ <input type="date">, tandis que Safari mobile (à droite) affiche un sélecteur de date à trois roulettes plutôt
convivial.
<input type=•date•>
<input type=•time•>

<input type=•datetime•>

<input type=•month•>

Les sélecteurs de date conviennent si vous devez saisir une date arbitraire comprise
dans une large fourchette (comme une date de naissance), mais il existe des options plus
pratiques et plus rapides si vous souhaitez saisir une date dans un intervalle plus restreint.
Nous verrons un exemple dans un instant, mais s’il y a une raison d’être sceptique à
l’égard des sélecteurs de date à roulette, c’est qu’ils sont difficiles à utiliser sur les écrans
tactiles. C’est d’ailleurs pour cette raison que l’élément select est le suivant dans notre liste
de cibles à abattre.
LA LOURDEUR DE <SELECT>
Dans les interfaces de bureau, le menu déroulant select est un pilier de la densité
d’information, regroupant potentiellement des centaines d’options préformatées dans un
seul contrôle compact. Il permet certes de faire des économies d’espace, mais sur les
écrans tactiles, un menu select tend à faire perdre du temps et à demander de nombreuses
interactions. Il faut non seulement appuyer deux fois sur le menu pour l’afficher et le
fermer, mais aussi le faire défiler, d’abord rapidement puis plus lentement pour préciser
son choix. C’est donc une expérience franchement hostile sur ce type d’écrans.
Remplacez les longs menus par une fonction de suggestion automatique. Prenons
un menu déroulant contenant les cinquante états des États-Unis. Ce pauvre Wyoming se
retrouve bien esseulé à la fin de cette liste alphabétique, et il faut balayer l’écran à de
nombreuses reprises pour y parvenir sur un écran tactile. (Le Wisconsin, l’avant-dernier
sur la liste, est encore plus difficile à sélectionner ; avec le Wyoming, vous pouvez au
moins faire défiler la roulette rapidement jusqu’au bout. Pour sélectionner le Wisconsin,
vous devez donner un petit coup de pouce supplémentaire.) Il est beaucoup plus rapide
d’ouvrir un champ de saisie et de commencer à taper le nom de l’état, en laissant
l’interface donner des suggestions à mesure que vous écrivez (FIG 3.18). Quatre frappes
suffisent pour trouver le Wyoming : sélectionnez le champ, tapez W, tapez Y, touchez la
suggestion Wyoming, et voilà !
FIG 3.18 : Le site web Expedia offre des suggestions de saisie tactiles lorsque vous saisissez votre ville de départ et
d’arrivée.

En théorie, l’élément datalist d’HTML5 permet d’incorporer facilement des

suggestions de saisie ; sur la page, datalist ressemble à un champ de saisie ordinaire, mais
il permet au site web d’afficher des suggestions (FIG 3.19). Pour cela, vous devez associer
le champ de saisie à un élément datalist via l’attribut list :

FIG 3.19 : datalist vous donne des suggestions de saisie instantanées.

<input id="state" list="state-list">

<datalist id="state-list">

<option value="Vermont">

<option value="Virginia">
<option value="Washington">

<option value="West Virginia">

<option value="Wisconsin">
 <option value="Wyoming">

</datalist>

À l’heure où j’écris ces lignes, cependant, peu de navigateurs mobiles prennent en

charge l’élément datalist ; les autres le remplacent par un champ de saisie de texte
ordinaire sans pouvoir magique de suggestion. En attendant que tous les navigateurs
implémentent cette fonction, vous pouvez obtenir le même effet avec une pincée de
JavaScript. Voyez la bibliothèque Awesomplete de Lea Verou (http://bkaprt.com/dft/03-
12/) et le plugin jQuery Datalist de Mike Taylor (http://bkaprt.com/dft/03-13/) à titre
d’exemple.
Remplacez les menus courts par une série de boutons. Lorsque vous avez seulement
quelques options, ne les entassez pas dans un menu ; exposez-les toutes pour pouvoir les
sélectionner en un clic (FIG 3.20). Cette approche permet une expérience beaucoup plus
rapide que le sélecteur de date natif dont nous avons parlé précédemment pour les plages
de date courtes.

FIG 3.20 : Fandango vend généralement des billets de cinéma quelques jours seulement avant la séance, ce qui réduit la
plage de dates possibles. Le site web expose ces dates (à gauche) pour faciliter leur sélection au lieu de les cacher dans
un menu. Les horaires du film subissent un traitement similaire (à droite).

Utilisez des sélecteurs » plus-moins » pour les plages de sélection restreintes. Si

vous devez saisir un nombre compris dans un intervalle relativement réduit (par exemple
des billets d’avion ou de cinéma), utilisez des sélecteurs » plus-moins » (ou boutons
stepper) pour permettre aux utilisateurs d’augmenter ou de diminuer la valeur d’un seul
clic (FIG 3.21). Les steppers sont idéaux lorsque les valeurs sont susceptibles de n’être
ajustées que légèrement.
FIG 3.21 : Fandango utilise des sélecteurs » plus-moins » pour réduire le nombre d’interactions lorsque vous
sélectionnez un nombre de tickets à acheter.

Nous avons optimisé plusieurs cas afin de simplifier l’usage des formulaires à
l’intention de vos visiteurs. Il y a cependant un cas où les formulaires sont conçus pour
ralentir les gens – pour une bonne raison.
FIGHT ! JIU-JITSU GESTUEL VS. OK | ANNULER
Souhaitez-vous vraiment supprimer ce message ?
OK | Annuler
Souhaitez-vous enregistrer les modifications ?
OK | Annuler
Êtes-vous sûr de vouloir manger ce burrito ?
OK | Annuler
Malgré leur usage répandu, les boîtes de dialogue de confirmation sont rarement
efficaces. Ces alertes sont censées nous ralentir pour réfléchir un instant, mais nous y
avons développé une immunité. Trop faciles à ignorer, elles sont comme des dos d’âne
agaçants qui ne ralentissent personne.
Des gestes bien placés offrent cette protection de façon bien plus efficace et rapide.
Appelez cela le jiu-jitsu gestuel : un art martial qui se pratique du bout des doigts. Le
swipe est un champion en la matière : faites glisser votre doigt sur l’écran pour
déverrouiller, répondre à un appel, éteindre l’appareil, supprimer un message. Ce geste est
juste suffisamment difficile pour indiquer une intention certaine, mais assez simple pour
ne pas perturber le déroulement de votre activité. Au lieu d’une boîte de confirmation,
ajoutez une petite défense gestuelle pour protéger vos utilisateurs des actions qu’ils
pourraient regretter. (Doublez cela d’une tactique encore meilleure, un bouton annuler.
Dans la mesure du possible, permettez aux utilisateurs d’annuler leur dernière action.
Pardonnez-leur leurs fautes et laissez-les se sortir du pétrin avec grâce et aisance.)
Si vous souhaitez que l’utilisateur vous accorde encore plus d’attention, utilisez un
geste plus compliqué. C’est ainsi que l’application de réservation d’hôtel Hotel Tonight
présente ses conditions d’utilisation. Comme le service se spécialise dans les réservations
de dernière minute, celles-ci ne sont pas remboursables, une condition que les utilisateurs
doivent absolument comprendre. Pour s’en assurer, l’application vous demande de réaliser
un geste simple – tracer le logo en forme de lit de l’entreprise – pour confirmer la
réservation (FIG 3.22).
FIG 3.22 : Hotel Tonight demande aux utilisateurs de tracer le logo pour accepter les conditions d’utilisation.
L’INTERFACE MAINS LIBRES
À l’exception de notre jiu-jitsu gestuel, la plupart des améliorations que nous avons
abordées visent à réduire les interactions à l’essentiel, afin de créer des interfaces tactiles
qui demandent moins d’actions. Malgré tous les bienfaits des écrans tactiles, ceux-ci sont
mal conçus, lents ou imprécis pour certaines tâches, et aucune optimisation d’interface ne
réglera complètement ce problème. Mieux vaut dans ce cas opter pour une alternative non
tactile, une leçon que l’entreprise Ford a apprise lorsqu’elle a voulu remplacer son tableau
de bord physique par une interface tactile. Les clients se sont plaints – à juste titre – qu’il
était devenu trop difficile, voire dangereux de changer de station de radio ou de régler le
volume en conduisant.
La conduite est l’un des nombreux contextes dans lesquels un écran tactile est une
mauvaise solution interactive – parce que vos yeux sont trop occupés pour regarder
l’écran. Contrairement à des commandes mécaniques, une dalle de verre ne peut pas être
utilisée à tâtons. Donner un écran tactile à un conducteur, c’est surtout lui donner une
excellente raison d’avoir un accident. Ford aurait pu s’en douter ; pour finir, le tableau de
bord traditionnel à boutons a été réintégré (http://bkaprt.com/dft/03-14/).
Les contrôles physiques sont une solution potentielle mais d’autres options ont fait leur
apparition. Les appareils bardés de capteurs nous donnent la possibilité de nous passer
entièrement de saisies tactiles en sortant les interactions de l’écran pour les placer au sein
de notre environnement. Les capteurs de positionnement GPS ont inspiré la première
vague de designs de ce type, permettant l’émergence de sites web et d’applications
capables de dire où se trouve le café le plus proche ou à quelle heure part le prochain train
de la gare locale. L’exploitation des informations de localisation a révolutionné la
technologie mobile. Mais aujourd’hui, les capteurs peuvent faire quelque chose d’encore
plus puissant : voir ce qui est juste devant vous.
C’est tout le concept du bon vieux code-barre et de son jeune (et moins populaire)
cousin, le code QR. Lorsque vous encodez des données telles qu’une URL dans ces lignes
et ces points, puis que vous laissez la caméra la lire à votre place, vous éliminez tout le
travail pour vos doigts et vos pouces. Mais l’usage des appareils photo est devenu bien
plus sophistiqué, offrant de puissants raccourcis.
• Lorsque vous créez un compte avec l’application eBay, vous pouvez éviter de saisir
votre nom et votre adresse en scannant votre permis de conduire avec votre appareil
photo ; l’application lit vos renseignements et remplit le formulaire à votre place.
• Safari mobile sur iOS remplit les informations de paiement à votre place lorsque vous
prenez une photo de votre carte de crédit.
• Avec l’application Google Translate, pointez votre caméra sur du texte écrit dans une
langue, et il sera automatiquement traduit dans une autre (FIG 3.23). L’application
affiche la traduction en temps réel, dans la même police et la même couleur, comme si
vous regardiez à travers une fenêtre multilingue magique.
FIG 3.23 : La fonction » word lens » de Google Translate traduit le texte à la volée en utilisant la caméra et un bon vieil
algorithme de reconnaissance des caractères. Il vous évite de devoir saisir du texte dans une langue étrangère. Image
extraite d’une vidéo de Google (http://bkaprt.com/dft/03-16/).

• Layar est un service web et une application mobile qui permet aux éditeurs d’intégrer
du contenu multimédia numérique dans des pages imprimées. Prenez une photo du
magazine, et la page prend vie avec de la vidéo et des liens connexes.
• Les personnes malvoyantes peuvent utiliser l’application LookTel Money Reader pour
identifier la valeur des billets. Aux États-Unis, il est impossible de différentier les
billets au toucher ; les téléphones peuvent donc devenir une aide précieuse. Lorsque les
capteurs sont accompagnés d’un écran tactile, les appareils peuvent offrir des interfaces
exceptionnellement utiles pour les personnes malvoyantes ou autrement handicapées.
Pour plus d’exemples, lisez l’article » Les malvoyants se tournent vers les smartphones
pour voir leur monde » (http://bkaprt.com/dft/03-15/).
Et ce n’est que la caméra. Les gadgets d’aujourd’hui sont pleins à craquer de capteurs
dotés de superpouvoirs.
• Le micro est l’oreille de votre appareil. Étudiez l’API Web Audio
(http://bkaprt.com/dft/03-17/) pour découvrir comment les navigateurs peuvent émettre
et reconnaître des sons. De même, l’API Web Speech (http://bkaprt.com/dft/03-18/)
permet aux navigateurs de comprendre la parole et de reproduire des mots.
• Le GPS note votre emplacement, et mieux encore, les lieux à proximité. L’API
Geolocation (http://bkaprt.com/dft/03-19/) permet au navigateur de faire office
d’annuaire.
• Le lecteur d’empreintes digitales permet une identification instantanée.
• L’accéléromètre, le gyroscope et la boussole permettent de suivre vos mouvements et
votre activité. L’API Device Orientation (http://bkaprt.com/dft/03-20/) permet aux
navigateurs de savoir dans quel sens l’appareil est orienté.
• Le capteur de lumière indique au navigateur le niveau de luminosité ambiante via l’API
Ambient Light (http://bkaprt.com/dft/03-21/).
 Si vous ajoutez à cela les protocoles de réseau standard via Wi-Fi, service cellulaire,
Bluetooth et NFC, nos appareils se mettent tout à coup à échanger, à » socialiser », comme
sources de données ou comme interfaces pilotées à distance. À mesure que de plus en plus
d’objets, lieux et appareils se verront adjoints de minuscules ordinateurs connectés au
réseau, la quantité de données environnantes exploitables par nos appareils personnels
décuplera. Posez-vous toujours la question : comment pourrait-on recueillir et utiliser ces
données de manière à faire économiser du temps et des efforts aux gens – ou à leur
épargner la pénible tâche de saisir des données ?
En d’autres termes : comment offrir des résultats optimaux pour un effort minimal ?
Ces exemples employant les capteurs de nos appareils ne sont pas uniquement des
raccourcis ; le plus important, et le plus intéressant, c’est qu’ils réagissent directement à
l’environnement de l’utilisateur. Lorsque nous concevons pour des capteurs et pas
seulement des écrans, le monde entier devient une toile numérique. En tant qu’utilisateurs,
cela nous donne la possibilité d’interagir plus directement avec les gens et les lieux qui
nous sont chers, en leur redonnant une partie de l’attention que nous avons cédée aux
écrans.
Mais les écrans ont encore de l’avenir. Notre industrie commence tout juste à explorer
le potentiel des interfaces tactiles et les multiples gestes permettant de parcourir les
informations. L’interaction tactile directe nous permet de manipuler les informations
comme si elles étaient des objets physiques. En adoptant les gestes tactiles, votre interface
devient non seulement plus rapide mais aussi plus naturelle, évidente et intuitive.
LES MAINS SONT FABULEUSEMENT EXPRESSIVES. Nous parlons tout le temps avec nos mains ;
elles posent des questions, trahissent nos intentions, demandent de l’attention, révèlent des
émotions. Un geste du revers de la main rejette une idée ; un doigt pointé accuse ; un
pouce levé s’enthousiasme. Si les mains sont excellentes pour communiquer avec les gens,
elles sont encore plus efficaces pour communiquer avec des objets. De la délicate
opération du nouage de lacets à la force brute employée pour ouvrir un bocal de
cornichons, nos mains et nos doigts improvisent constamment en termes de prise, de
pression, de position et de sensibilité.
Comment pouvons-nous transposer cette expression à la manipulation d’informations
numériques ? Les écrans tactiles placent littéralement les données entre les mains de
l’utilisateur, et c’est au designer qu’il revient de permettre (et d’interpréter) cette
interaction. Malheureusement, si nos mains ont un vocabulaire poussé pour parler aux
gens et aux objets, le langage gestuel destiné aux écrans tactiles en est encore à ses
rudiments. Un lexique plus riche nous attend, mais il faudra du temps avant qu’un
ensemble de gestes tactiles plus sophistiqués soit plus répandu.
Ce chapitre explore les possibilités des gestes tactiles. Nous commencerons par
examiner la poignée de gestes que nous avons déjà bien assimilés. Nous verrons pourquoi
les éléments d’interface traditionnels tels que les boutons et les onglets sont bien en deçà
du potentiel expressif des interactions tactiles – et quelles sont de meilleures alternatives.
Au fil du chemin, nous contournerons les pièges du design gestuel et nous conclurons en
abordant les techniques permettant de coder des gestes dans le navigateur (et leurs
difficultés). Mais tout d’abord, voyons les bases.
LE VOCABULAIRE GESTUEL DE BASE
Quelques gestes fondamentaux sont communs à toutes les plateformes. Ce sont des gestes
que la plupart des gens comprennent et peuvent découvrir par eux-mêmes. Il s’agit de vos
composants gestuels de base.

Tap
Le tap est le clic de l’univers tactile, l’action universelle permettant d’interagir avec tous
les éléments à l’écran. Le tap indique » je veux en savoir plus » ou » je veux activer
ceci ». Comme nous l’avons vu au chapitre 1, le tap est également la meilleure alternative
aux interactions de survol dans un environnement tactile : utilisez un tap pour obtenir un
aperçu d’un objet, prévisualiser les informations sans ouvrir une vue détaillée ; utilisez un
second tap pour l’activer.

Swipe
Comme le tap, le swipe (balayage) est devenu si familier que ses usages semblent à la fois
évidents et limités : faites glisser votre doigt pour faire défiler la page ou basculer entre
différentes vues. Mais des usages plus subtils ont fait leur apparition. Le swipe peut
révéler des panneaux cachés, par exemple, comme la fonction commune à de nombreuses
plateformes qui consiste à faire glisser votre doigt depuis le haut de l’écran pour faire
apparaître la barre d’état et les notifications, ou les nouveaux gestes de Windows révélant
des panneaux de commande. Comme nous l’avons vu au chapitre précédent, le swipe est
également un mouvement essentiel pour le design défensif, évitant aux utilisateurs de
déclencher des actions qu’ils pourraient regretter par la suite : faites glisser votre doigt sur
l’écran pour débloquer le téléphone, répondre à un appel ou supprimer un message.

Pression longue
Similaire au clic de droite, la pression longue fait apparaître un menu contextuel contenant
des actions associées ou des informations sur l’élément touché. On retrouve la même
approche sur toutes les plateformes tactiles, mais les détails peuvent varier.
• Windows. Une pression longue agit comme un clic droit à la souris ; elle ouvre un
menu contextuel. (Dans Windows, vous pouvez également ouvrir ce menu à l’aide d’un
tap à deux doigts : appuyez avec un doigt et effectuez un tap rapide avec un autre.)
• Android. Une pression longue sur un élément d’une liste fait apparaître la barre
d’action contextuelle d’Android, qui vous permet de sélectionner des éléments
supplémentaires dans la liste, puis de manipuler tous ces éléments en même temps
(supprimer, déplacer, etc.).
• Web. La plupart des navigateurs tactiles utilisent la pression longue afin d’ouvrir des
menus contextuels relatifs aux liens et aux images (pour des actions comme
sauvegarder, copier, partager, etc.). Cela signifie que si une application web veut
utiliser ce geste, elle doit outrepasser le comportement par défaut du navigateur – ce
qui risque bien souvent de poser des problèmes d’utilisabilité.
• iOS. Les applications iOS emploient la pression longue de façon moins systématique
 que les autres plateformes, même si elle appelle tout de même un menu ou un résumé
du contenu. Son usage inégal, cependant, signifie que la pression longue est
généralement uniquement découverte par les utilisateurs experts ou curieux ; mieux
vaut donc la traiter comme un raccourci alternatif permettant de consulter un écran
détaillé.

FIG 4.1 : Pincez la vue de navigation de l’application Zappos afin de déclencher un zoom sémantique sous Windows,
pour un aperçu plus visuel des sections du magasin.

Pression longue et glissement

Sur toutes les plateformes, ce geste déclenche un comportement de glisser-déplacer. Une
pression longue sur un élément déplaçable signale que vous avez l’intention de le
déplacer, et le glissement permet de l’amener à destination.

Pincement et étirement
Ce duo de gestes permet généralement d’agrandir et de rétrécir les images, les cartes et les
pages web. C’est une interaction immédiate et satisfaisante qui vous permet d’attraper un
objet et de le redimensionner à l’envi.
Cet effet de zoom littéral est complété dans de plus en plus d’applications par une
version plus métaphorique appelée zoom sémantique – une convention émergente grâce à
son usage qui s’est généralisé dans Windows. Dans ce contexte, le zoom sémantique
permet de basculer entre deux vues : un gros plan et une vue d’ensemble de l’organisation.
Par exemple, dans l’application de shopping Zappos pour Windows, la vue zoomée
présente toutes les sections avec leurs catégories de produits : chapeaux, gants, etc., dans
Accessoires (FIG 4.1). Afin de parcourir plus rapidement les produits, pincez cette vue
pour revenir à une liste simplifiée des mêmes sections, sans les catégories. Étirez ou
appuyez sur une section pour l’agrandir.
D’autres approches développent le zoom sémantique afin de naviguer plus
profondément dans la hiérarchie des informations. Par exemple, l’application Photos de
l’iPad utilise le pincement et l’étirement comme moyen alternatif pour basculer entre la
vue de l’album complet et les photos individuelles (FIG 4.2). Lorsque vous êtes en train
d’admirer l’une de vos photos, vous pouvez appuyer sur le bouton retour pour revenir à la
vue miniature des photos de l’album, mais vous pouvez aussi pincer l’écran pour revenir à
cette vue de l’album. Ici, le zoom sémantique est déployé de façon à vous permettre de
monter et de descendre dans la structure organisationnelle de l’application. Pincez une vue
détaillée (la photo) pour la fermer et revenir au niveau supérieur (l’album), ou depuis la
vue de l’album, étirez une miniature pour l’ouvrir en vue détaillée.

FIG 4.2 : Pincez une photo dans l’application Photos de l’iPad pour la fermer et revenir à la vue miniature de l’album
parent. Ce geste offre une alternative au bouton retour placé dans le coin supérieur gauche de l’écran.

Double tap
Comme le geste pincer-étirer, le double tap permet de zoomer et de dézoomer. (Android
ajoute une nuance avec le double tap + glissement. Lorsque vous faites glisser votre doigt
vers le haut ou le bas après un double tap dans Android, vous pouvez contrôler le niveau
de zoom exact ; en faisant glisser votre doigt vers le haut, vous dézoomez, vers le bas et
vous zoomez.) Le double tap trouve peu d’utilisations conventionnelles au-delà du zoom
cependant, ce qui le rend idéal pour expérimenter dans d’autres contextes.
BostonGlobe.com, par exemple, permet à ses abonnés d’effectuer un double tap sur un
titre pour sauvegarder un article à lire plus tard.
Vous pouvez compter sur votre public pour comprendre ces six gestes sans aide
supplémentaire. Néanmoins, bien qu’il soit fiable, ce kit reste primitif – il ne fait que
transposer à l’écran tactile les interactions que l’on connaît à la souris. Ces gestes sont
exactement aussi expressifs qu’un curseur de souris, réduisant toute la subtilité de la main
à un seul doigt qui pointe. Ainsi, ces gestes ont tendance à renforcer les vieilles
métaphores de bureau.
LE PROBLÈME DES BOUTONS
Les boutons nous ont toujours bien servi dans le monde physique comme dans le monde
numérique, mais leur interprétation sur les écrans tactiles est un peu plus difficile à
maîtriser : les boutons demandent un effort, ajoutent de la complexité et insèrent une
couche d’abstraction entre vous et le contenu. Les écrans tactiles ont le potentiel de
balayer cette abondance de boutons, menus, dossiers, onglets et autres débris
administratifs que nous avons accumulés au cours de décennies de bureautique. Une
nouvelle chorégraphie de gestes peut et doit remplacer ces contrôles obsolètes pour nous
permettre de travailler directement sur le contenu.

Les boutons demandent des efforts

Les interfaces physiques demandent un effort physique. Sur les petits écrans tactiles, cet
effort est modeste, généralement un simple mouvement du pouce. Plus l’écran s’agrandit,
cependant, et plus l’effort se fait sentir. En parcourant l’écran, vous devez déplacer votre
main, voire votre bras pour manipuler les contrôles. Je sais, je sais – ça n’est pourtant pas
si compliqué de bouger sa main au-dessus d’un écran, si ? Mais la fatigue s’installe avec le
temps et la répétition. Il y a quelques années, pour juger un concours de magazines
numériques, j’ai dû examiner des centaines d’applications pour iPad. Après plusieurs
heures de mauvaise ergonomie, j’en avais des crampes aux bras. Appelons ça l’iPad
elbow.
Prenez par exemple le bouton Retour dans le coin supérieur gauche de nombreuses
applications pour iPad. Il faut l’actionner tout le temps – pour revenir en arrière, pour
parcourir la hiérarchie de l’application, etc. Le bouton se trouve dans la zone du pouce,
mais l’atteindre demande tout de même un instant de concentration et un effort. Malgré
l’étendue de l’écran d’une tablette, ce minuscule lopin de pixels exige une attention
constante.
Sur les écrans plus grands comme ceux des tablettes, privilégiez les gestes grossiers
aux gestes fins. Permettez aux gens de tripoter l’écran tout entier pour effectuer des
actions de base, comme la navigation simple. Dans l’application Mail de l’iPad, par
exemple, le bouton retour de la boîte de réception ouvre le tiroir de messages, mais vous
pouvez également l’ouvrir en faisant glisser votre doigt de gauche à droite n’importe où
sur l’écran (FIG 4.3). L’écran tout entier devient le contrôle – pas besoin d’atteindre le
bouton retour.
FIG 4.3 : Le bouton retour dans l’application Mail pour iPad demande un léger effort (à gauche), mais le geste de
glissement (à droite) vous permet d’accéder au même contenu où que se trouvent vos mains.

Les gestes grossiers contribuent à réduire les erreurs et à améliorer l’accessibilité.

Quand des designers de chez Boeing m’ont demandé comment faire pour que leurs
interfaces tactiles soient plus tolérantes vis-à-vis des errances des doigts des pilotes en cas
de turbulence, je leur ai suggéré d’utiliser des gestes grossiers (un balayage, un pincement
de la main entière, etc.) pour permettre aux pilotes de manœuvrer sans avoir à appuyer
délicatement sur des boutons. Le même conseil vaut pour les personnes âgées, les enfants
ou les personnes à motricité réduite. Enfin, ces gestes permettent un contrôle à l’aveugle
pour ceux qui ont une vision limitée de l’écran – comme les conducteurs et les cyclistes.
Les gestes larges ont également tendance à devenir des réflexes. Les interfaces
traditionnelles s’appuient sur la mémoire visuelle, elles nous demandent d’observer des
boutons et des libellés pour en absorber le sens. Les interfaces tactiles demandent un peu
la même chose, mais y mêlent la mémoire musculaire – une connaissance subconsciente
de l’interface qui semble jaillir tout droit de nos mains et de nos doigts. Comme lorsque
vous jouez d’un instrument ou tapez sur un clavier, les actions répétitives employées sur
un écran tactile finissent par devenir instinctives. Cependant, les écrans tactiles présentent
une différence de poids par rapport aux interfaces physiques : leurs surfaces de verre
n’offrent pas le même ressenti physique que les cordes d’une guitare ou les touches d’un
clavier. Les contrôles fins nous ralentissent et nous forcent à regarder l’écran. Les gestes
grossiers, en revanche, sont rapidement intégrés dans la mémoire musculaire et demandent
peu de perception visuelle ; les utilisateurs d’ordinateurs portables n’ont aucune difficulté
à utiliser deux doigts pour faire défiler une page sur leur pavé tactile, par exemple. Les
actions expressives larges rapprochent les meilleures interfaces tactiles des instruments de
musique et les éloignent d’autant des simples panneaux à boutons poussoirs.

Les boutons ajoutent de la complexité

Nous avons tous été déroutés par l’abondance de boutons que comportent nos voitures,
notre électroménager, nos télécommandes et autres appareils de tous les jours.
Récemment, lors de nos vacances d’été, ma famille a dénombré plus de 80 boutons sur
notre Citroën de location ; il nous a fallu dix minutes avant de comprendre comment la
démarrer. (Le volant de la Citroën C4 comporte treize boutons et quatre molettes – des
molettes !) La complexité de ces interfaces courantes reflète la complexité croissante des
appareils qu’elles servent, lançant au designer un défi bien connu : la multiplication des
fonctions semble appeler la multiplication des contrôles. Mais si vous n’y faites pas
attention, les boutons se mettent à pousser comme du chiendent sur votre interface.
Tirez une leçon des consoles de jeux. Ce qui n’était au départ qu’un joystick à un
bouton sur les premières consoles Atari a évolué pour devenir une manette complexe
recouverte de boutons. Une manette de Xbox One ordinaire comporte onze boutons, deux
gâchettes, deux joysticks et un pavé directionnel. La première génération de jeux sur
iPhone en 2008 a tenté de transposer ce système de boutons, avec des résultats
embarrassants (FIG 4.4). Les boutons affichés à l’écran occupaient un espace précieux,
affectaient la jouabilité et immobilisaient les doigts et les pouces. Ils étaient également
difficiles à utiliser : comme les doigts glissaient sur le verre, les boutons virtuels
n’offraient pas le même ressenti rassurant que leurs homologues physiques. Les boutons
n’ont pas fait long feu.

FIG 4.4 : Comme beaucoup d’autres jeux, Earthworm Jim a été porté sur téléphone avec des contrôles de console, ce qui
le rend pratiquement injouable.

Les designers de jeux avaient besoin d’un nouveau modèle : ils ont donc abandonné les
boutons. En proposant moins de commandes, les designers ont épuré leurs jeux. Des jeux
simples mais satisfaisants comme Angry Bird sont devenus les rois des écrans tactiles en
ne faisant appel qu’à un ou deux gestes. La nature du jeu s’est adaptée à la nature de
l’appareil. À mesure que les jeux tactiles ont gagné en popularité, des jeux plus
sophistiqués ont été développés pour rivaliser avec les jeux cinématiques des consoles.
Certains, comme le jeu d’action-fantaisie Infinity Blade, transposent les interactions
tactiles au genre du hack-and-slash. D’autres jeux emploient une approche encore plus
novatrice, créant un gameplay conçu sur mesure pour l’écran tactile. Des jeux comme
République (FIG 4.5) ou Monument Valley vous invitent à déplacer le héros en touchant
l’environnement de jeu. Au lieu de s’appuyer sur un système de marionnettes complexe
basé sur des boutons, ces jeux vous immergent par une interaction directe avec le monde
du jeu. C’est un changement de perspective qui offre l’expérience complexe d’un jeu de
console sans avoir besoin des contrôles correspondants.

FIG 4.5 : Dans République, vous êtes un hacker qui guide le héros pour l’aider à s’échapper d’un mystérieux bâtiment.
Vous voyez le monde par le biais de caméras de surveillance et vous lui dites où aller et à quel moment. La plupart des
actions consistent à toucher des caméras pour en prendre le contrôle, puis à toucher des emplacements pour indiquer au
fugitif où il doit se rendre. Le monde lui-même devient l’interface, aucun bouton n’est nécessaire.

Les logiciels de tous genres devraient explorer un changement de perspective similaire,

adopter plus d’interactions directes et moins de boutons et de contrôles. On pourrait arguer
que toucher un bouton est une sorte d’interaction directe. Le problème, c’est que cette
connexion se fait avec un bouton, pas avec les informations que vous cherchez à
manipuler. Bref, pour le dire autrement…

Les boutons relèvent du bricolage

Comprenez-moi bien : les bricolages – et les boutons – ne sont pas tous mauvais. Nous
avons inventé les interrupteurs électriques et les boutons il y a plus d’un siècle pour
contrôler des objets à distance. Ces interrupteurs étaient conçus comme des messagers
chargés de communiquer notre volonté (allumer la lumière) à sa destination (l’ampoule).
Cette interaction est peut-être pratique, mais elle est également indirecte, complètement
déconnectée de la chose que nous souhaitons affecter. Il n’est pas évident au premier
abord que tel interrupteur est destiné à allumer telle ampoule ; il faut le découvrir et
apprendre à l’utiliser. Lorsque je suis dans une nouvelle chambre d’hôtel, il me faut
toujours une minute ou deux pour essayer tous les interrupteurs et trouver celui qui allume
la lampe que je veux. Mais c’est bien mieux que de tâtonner dans une chambre obscure et
de monter sur une échelle pour visser une ampoule. L’interrupteur est un bricolage inspiré.
Lorsqu’il n’est pas pratique d’interagir avec l’objet principal, il peut être ingénieux
d’ajouter un contrôle pour l’actionner à distance.
Les boutons sont en somme des solutions de secours pour les cas où une interaction
directe est impossible. L’histoire des interfaces virtuelles est la même. Nous avons créé
des boutons, des onglets et des curseurs à titre d’intermédiaires skeuomorphiques pour
manipuler des informations numériques et des actions qui sont hors de portée ou qui ne
peuvent être représentées facilement. Les boutons ont toujours leur place, leurs libellés
évidents et leurs appels à l’action clairs les rendent particulièrement utiles. Utilisez-les tant
que vous en avez besoin, mais reconnaissez qu’ils ne sont que des solutions de secours.
Chaque fois que vous ajoutez un bouton dans votre design, posez-vous la question : y a-t-
il un moyen de manipuler le contenu plus directement ?

L’information comme objet physique

Chaque interface numérique est une illusion, une fine couche de magie recouvrant un
bouillon d’uns et de zéros. Pour la première fois, cependant, les écrans tactiles donnent la
possibilité de créer l’illusion qu’il n’y a pas d’illusion, qu’il n’y a rien entre vous et le
contenu. Ce livre souligne l’importance de l’inter- action physique ; pour compléter
l’illusion, appliquons maintenant ce même raisonnement aux données elles-mêmes.
Repensez vos informations comme des objets physiques. Pour chaque élément de votre
interface, demandez-vous : » Qu’est-ce que je pourrais faire avec cette donnée si je
pouvais la faire glisser, l’étirer et la toucher sur un écran en verre ? » Le zoom sémantique
– qui transpose le caractère physique du pincer pour zoomer à l’architecture de
l’information sous-jacente – en est un exemple. Imaginez maintenant comment vous
pourriez sélectionner un intervalle de dates. Un design classique utilise deux sélecteurs de
date sous forme de calendrier, une solution qui fait effectivement emploi d’une métaphore
physique en parodiant les calendriers papier. Mais cette approche n’imprègne pas les
données de propriétés physiques et d’interaction directe. Au lieu de cela, imaginez
l’intervalle de dates lui-même comme un objet avec une masse et une élasticité – étirez ou
pressez ses extrémités pour lui donner la taille de votre choix (FIG 4.6).
FIG 4.6 : Imaginez un intervalle de dates comme un élastique que vous pouvez étirer à volonté.

Faites du contenu le contrôle

Cette réinterprétation permet de libérer autant d’interface que possible entre l’utilisateur et
le contenu. Toutes les interfaces utilisateur sont des conventions sociales, et ces
conventions rencontrent des problèmes lorsqu’elles sont comprises inégalement. Dans son
livre Living with Complexity, le designer Don Norman évoque les trous qui distinguent les
salières des poivrières – et note que personne ne s’accorde quant au fait que ce soit la
salière ou la poivrière qui ne doive comporter qu’un seul trou. Norman fait remarquer
qu’il importe peu de savoir qui a » raison ». Ce qui importe, c’est ce que croit la personne
qui les remplit. Cela ne poserait pas de problème si tout le monde comprenait le système
de la même façon, mais ce n’est pas le cas. Même si je suis certain que la salière doit être
celle qui ne comporte qu’un trou, je ne peux pas compter sur le fait que tout le monde
partage cette opinion ; quand je suis au restaurant, j’en verse toujours un peu sur ma main
pour vérifier. Je ne fais pas confiance au système.
En tant que designers, c’est à nous de remplir la salière. Notre rôle est de donner
confiance aux utilisateurs. Pour cela, nous finissons souvent par apposer des étiquettes
explicites pour désigner le sel et le poivre. Mais déchiffrer les étiquettes demande encore
un certain degré de traitement visuel (et de connaissance du français). Vous savez ce qui
est encore mieux ? Des bouteilles transparentes qui laissent voir le sel et le poivre qu’elles
contiennent. Pas besoin de lire les étiquettes pour trouver ce que l’on cherche (FIG 4.7).
FIG 4.7 : Devinez quel est le jeu de salière et de poivrière le plus facile à utiliser ? Photographie de gauche de Joe King
(http://bkaprt.com/dft/04-01/) ; photographie de droite de Black Country Museums (http://bkaprt.com/dft/04-02/).

Les galeries de photos pour écrans tactiles sont des exemples presque parfaits de cette
approche. Ce sont des interfaces très denses qui ne comportent pourtant quasiment aucun
contrôle. Il n’y a que du contenu : touchez une photo pour l’agrandir, puis faites défiler la
collection du bout du doigt. L’interaction est entièrement liée au contenu ; les informations
elles-mêmes sont l’interface. Marshall McLuhan a prononcé cette phrase célèbre : » Le
message, c’est le médium. » Quand nous créons l’illusion d’une interaction directe avec
les informations, nous pouvons enfin dire que le médium est le message.
Alors, à quoi ressemble l’interaction lorsque nous pressons ce message sous une dalle
en verre à deux dimensions ? Dans le monde physique, nous avons un mot qui désigne un
morceau de contenu plat et unique : nous appelons cela une carte. C’est pour cela que tous
les grands systèmes d’exploitation tactiles utilisent les cartes (ou carreaux, panneaux…)
comme métaphore fondamentale pour représenter le contenu à interaction directe.

Le pouvoir de la métaphore de la carte

Les cartes sont devenues un moyen populaire de représenter des objets de données
individuels : une photo sur Facebook, un vol sur TripIt, un contact, un coupon, un avis sur
Yelp, un rappel Google Now, un niveau de jeu vidéo, etc. (FIG 4.8). Jusqu’à récemment,
nous nous contentions de partager ces informations en envoyant des URL par email ou
SMS. Aujourd’hui, les cartes de données constituent un format portable, petit et pratique
qui peut aussi bien venir s’emboîter avec d’autres modules sur un site responsive pour
grands écrans, ou faire office d’événement principal dans une application pour petits
écrans. En plus, les cartes sont ludiques : lorsque nous représentons des objets de données
comme des cartes de collection, des cartes de visite ou des coupons, nous ressentons le
besoin naturel et même nostalgique de les partager et les échanger de la même façon –
attrapez-les toutes !
FIG 4.8 : Pinterest et ses épingles (à gauche), TripIt (à droite), Google Now, cartes Twitter… de nombreux services
incorporent des cartes comme de minuscules supports multimédias dans des applications, des pages web, des flux
sociaux, des fenêtres de notification, etc.

Les cartes suggèrent également beaucoup d’interactions physiques. L’interaction la plus

familière, bien entendu, consiste à retourner la carte. Sur les téléphones, les écrans
s’empilent comme un jeu de cartes. Vous faites défiler l’historique de votre navigateur en
balayant l’écran comme si vous distribuiez des cartes à la belote du samedi soir – c’est une
geste large et sans effort, un geste magnifique.
Remplacez les » cartes » par des » pages » et vous obtenez la plus vieille métaphore du
web. Pourtant, les premières générations de navigateurs tactiles vous forçaient à tourner
ces pages en appuyant sur un bouton, ce qui embrouillait la métaphore. Vous est-il souvent
arrivé de vous servir d’un bouton pour tourner les pages d’un journal ? Aujourd’hui, la
plupart des navigateurs tactiles font bien leur travail et vous permettent de parcourir votre
historique d’un simple glissement de doigt. Après avoir utilisé une métaphore physique –
la page – pendant plusieurs décennies pour décrire le Web, nous sommes finalement
parvenus à lui associer une interaction physique appropriée.
Cette réconciliation est le produit essentiel du design d’interaction pour écrans tactiles.
Adoptez les verbes qui correspondent manifestement aux noms de votre interface. Pensez
à tout ce que vous pourriez faire avec des cartes dans le monde réel : les retourner, les
plier, les mélanger, les empiler, les étirer, les trier, les froisser, les corner, les mettre de
côté. Toutes ces actions physiques peuvent servir de tremplin à la métaphore de votre
interface. Que signifie de retourner un objet de données, de l’étirer, de le froisser ?
Facebook a créé une application nommée Paper qui joue sur cette analogie physique,
permettant d’explorer la timeline de Facebook d’une façon fabuleusement tactile. Tout est
représenté sous forme de cartes. L’application est organisée en flux, chaque flux étant
représenté par un jeu de cartes que vous pouvez trier, battre ou jeter pour créer de
nouvelles collections. Chaque élément d’un flux est une carte que vous pouvez feuilleter.
Lorsqu’une carte comprend un article web, vous faites glisser celui-ci vers le haut pour le
déplier comme un journal et vous commencez la lecture (FIG 4.9).

FIG 4.9 : Facebook Paper imagine ses données comme des cartes physiques où chaque action physique produit une
action correspondante sur les données. Les cartes représentant un article web se déplient pour révéler leur contenu
interactif.

Les gestes employés dans Facebook Paper suivent une logique naturelle une fois que
vous les avez découverts, mais ils ne sont pas toujours évidents pour le néophyte.
Permettre à votre public de trouver, d’apprendre et de s’adapter à ces nouveaux gestes est
un défi majeur – un défi que nous abordons dans le prochain chapitre. Cela étant, lorsque
les gestes reposent sur des interactions simples basées sur le monde physique, il n’y a pas
forcément beaucoup d’instructions à donner. Alors que nous nous apprêtons à concevoir
des interactions plus poussées, commençons par regarder autour de nous pour trouver
l’inspiration.
LAISSEZ-VOUS GUIDER PAR LE MONDE RÉEL
Pour comprendre le monde qui nous entoure, nous faisons confiance à un mélange de lois
physiques et de conventions humaines. La gravité s’est avérée être extrêmement fiable, de
même que bon nombre de nos propres constructions sociales (à l’exception de la salière et
de la poivrière). Les vis s’enfoncent dans le sens des aiguilles d’une montre, les pages des
livres occidentaux se déroulent de gauche à droite, une coche indique une tâche effectuée,
et la couleur rouge veut dire » stop ». Ces choses définissent nos attentes et façonnent nos
comportements à mesure que nous évoluons dans le monde physique. Appliquez ces
attentes et ces comportements à votre interface tactile, et vous offrirez à vos utilisateurs
une expérience familière et prévisible. Voici quelques stratégies pour y parvenir.

Empruntez des interactions directes

L’approche la plus rationnelle consiste à interagir avec l’écran exactement comme nous
interagirions avec un autre objet du monde réel. Les carnets de croquis sont un exemple
simple, créant l’illusion (encore !) qu’écran tactile et papier sont interchangeables (ce n’est
pas pour rien que nous appelons ces appareils pads et tablettes). Prenez Paper (une
application de dessin pour iPad à ne pas confondre avec l’application de Facebook), qui a
déployé des efforts techniques importants pour recréer l’effet de l’encre sur le papier.
Choisissez un crayon, un stylo ou une plume et dessinez avec un stylet ou du bout du
doigt. La peinture libre devient la principale interaction gestuelle de l’application –
l’action qui fonctionne dans le monde réel fonctionne également sur la tablette. C’est
simple.
Bien souvent, cependant, vous pouvez emprunter une interaction physique familière
sans copier l’artefact d’origine en entier. Vous savez comment fonctionne un bouton rotatif
ou un cadran : tournez le bouton dans le sens des aiguilles d’une montre pour augmenter
ou avancer, dans le sens inverse pour réduire ou reculer. Mais si vous souhaitez utiliser ce
mouvement de rotation, vous n’avez pas besoin d’ajouter un bouton visible sur votre
interface. Vous pouvez plutôt vous servir de cette action comme inspiration pour un
équivalent gestuel. L’application Paper fait cela très bien : en faisant tourner deux doigts
dans le sens inverse des aiguilles d’une montre, où que ce soit sur l’écran, vous annulez la
dernière opération et remontez dans le temps pour enlever les derniers traits de votre
dessin. Vous changez d’avis ? Faites tourner vos doigts dans le sens des aiguilles d’une
montre pour faire réapparaître vos traits (FIG 4.10). Quand vous empruntez un geste du
monde réel, souvenez-vous que c’est l’action physique que vous cherchez à importer, pas
l’objet original ; vous voulez utiliser la rotation, pas le bouton rotatif.
FIG 4.10 : Vous voulez annuler la dernière opération ? Paper vous permet de revenir en arrière avec un simple geste de
rotation.

Appuyez-vous sur des symboles ou des notations établis

En traduisant des mouvements de rotation physiques en gestes tactiles, nous transformons
ceux-ci en notations, c’est-à-dire en abréviations signifiantes. Ces symboles sont des
inventions humaines – les gribouillages de rotation dans un sens ou dans l’autre n’ont pas
de sens intrinsèque. Mais là encore, toutes les interfaces utilisateur sont des constructions
sociales ; en vous inspirant de conventions bien établies, votre interface paraîtra
immédiatement familière et intuitive.
Parfois, des systèmes de notation peuvent être empruntés dans leur intégralité. Cet
ensemble de signes de correction spécialisés, par exemple, est en mesure d’exprimer des
idées complexes tout en étant universellement compris par les correcteurs (FIG 4.11). Une
application destinée à ce public pourra adapter cette notation sous forme de gestes abrégés
pour supprimer, déplacer ou insérer de nouveaux paragraphes.
FIG 4.11 : La collection de signes de correction du Chicago Manual of Style (http://bkaprt.com/ dft/04-03/).

Adobe Comp est une application de représentation filaire et de mise en page pour iPad
dont l’interface tactile s’appuie sur les symboles courants du wireframing (FIG 4.12).
Ajoutez une image en traçant un gros X, placez une colonne de texte en griffonnant une
pile de lignes, effacez un élément en le raturant. L’application convertit ces symboles en
composants de wireframe et, une fois que vous avez fini, exporte vos maquettes au format
InDesign, Illustrator ou Photoshop – une ébauche informelle sur tableau blanc transformée
en un wireframe formel. Bien sûr, ça ne vous paraît peut-être pas plus efficace que de
produire un wireframe avec Microsoft Visio ou OmniGraffle sur un ordinateur de bureau,
mais c’est la façon la plus rapide de le faire sur un écran tactile. Ces gestes fluides
évoquant l’esquisse permettent de créer des mises en page beaucoup plus rapidement
qu’avec des panneaux de commande conçus pour les ordinateurs de bureau.
FIG 4.12 : Adobe Comp emprunte la nomenclature des wireframes. Ici, en dessinant un X, vous insérez un espace
réservé pour une image, et en traçant une série de lignes, vous insérez du texte.

Appliquer des lois physiques aux objets numériques

Adobe Comp s’inspire directement de notre façon de travailler sur une interface familière
– le papier, mais il n’est pas nécessaire d’être aussi littéral. Vous pouvez également
appliquer des notions de physique aux objets numériques en leur donnant une impression
de masse, de présence physique. Par exemple, le geste pincer pour zoomer apporte une
perception physique d’étirement-compression aux photos ou aux cartes. La façon qu’a un
écran de rebondir lorsque vous vous heurtez à la fin du contenu en faisant défiler la page
ajoute une forme de solidité à des données intangibles. L’application Clear pour iPhone
traite les éléments des listes de tâches comme des composants physiques que vous pouvez
comprimer, faire glisser ou pousser sur le côté, et ces actions ont une correspondance
sémantique pour les données (FIG 4.13).
FIG 4.13 : L’interface entièrement gestuelle de Clear s’appuie sur de simples conventions physiques. Pour insérer un
élément dans la liste, écartez deux éléments afin de lui faire de la place.

• Insérez un nouvel élément dans la liste en écartant vos doigts entre deux autres
éléments pour lui faire une place.
• Marquez un élément comme terminé en le faisant glisser sur le côté.
• Pincez une liste pour la fermer.
Ce sont là des gestes simples pour des actions physiques simples, correspondant
naturellement aux gestes que vous effectueriez pour réorganiser votre liste si les éléments
étaient arrangés physiquement sur votre bureau. Lorsque des éléments virtuels se
comportent avec une présence physique si familière, notre cerveau se fond naturellement
dans l’interaction.

Honorez les contraintes physiques

Si les possibilités du monde physique inspirent des interactions gestuelles, c’est également
le cas des impossibilités. TouchUp est une application pour iPad qui permet d’ajouter des
filtres ou des effets sur des photos. L’exemple le plus simple consiste à peindre une
couleur sur la photo, en vous servant de votre doigt comme d’un pinceau. Mais comment
faire pour changer la taille du pinceau ? Ça ne devrait pas être bien compliqué, non ?
Après tout, les applications de bureau abordent toujours ce problème en offrant un curseur
ou une palette permettant de choisir la taille du pinceau. Le problème, c’est que vous avez
déjà un pinceau – votre doigt – et qu’il ne peut pas changer de taille. Changer la taille de
l’empreinte de votre doigt sur l’écran introduit une incertitude. Vous n’avez aucune idée
de la taille de l’empreinte que vous laisserez. Vous passez d’une interaction directe à une
approximation abstraite.
Alors TouchUp ne permet pas de changer la taille du pinceau. À la place, vous changez
la taille de la toile : pincez pour rétrécir, étirez pour agrandir. Votre pinceau fait toujours la
même taille à l’écran, mais comme vous dessinez sur une photo très agrandie, le résultat
produit sur l’image sera un trait fin.
C’est une solution qui semble évidente quand vous la voyez en action, mais elle
renverse complètement l’approche de bureau traditionnelle. Quand vous devez prendre en
compte l’aspect physique du toucher, vous devez repenser des solutions familières. Pour
chaque solution, demandez-vous : l’ancien modèle est-il encore valable ou faut-il
employer une nouvelle approche pour une interaction plus directe ?
Lorsque vous vous laissez guider par le monde réel, vous créez des interfaces qui sont
facilement compréhensibles. Certaines actions, cependant, sont trop chargées de sens ou
trop complexes pour être réduites à une simple action physique ; elles peuvent nécessiter
des gestes plus abstraits. Ces gestes avancés trouvent un parallèle dans l’informatique
traditionnelle.
DES GESTES PENSÉS COMME DES RACCOURCIS CLAVIER
Des gestes faciles à découvrir, combinés à des contrôles traditionnels indiqués de façon
explicite, devront toujours former la base de votre interface. Veillez toujours à ce que les
actions de base de votre application soient faciles à comprendre. Mais n’ayez pas peur de
déployer des raccourcis gestuels plus abstraits comme alternatives parallèles aux contrôles
ordinaires, à l’instar des raccourcis clavier sur les ordinateurs de bureau. Précédemment,
j’ai par exemple mentionné que l’application Mail de l’iPad complétait le bouton retour
par un geste de balayage. Au chapitre 3, nous avons évoqué Vimeo, qui permet d’utiliser
certains gestes dans la vue en liste pour éviter d’avoir à ouvrir la page détaillée : faites
glisser une vidéo vers la gauche ou vers la droite pour la partager ou l’ajouter aux favoris.
Dans ces deux cas, la » manière lente » est toujours disponible, et les gestes sont des
contrôles avancés à l’intention des utilisateurs experts.
Ces raccourcis rapides ne se limitent pas aux swipes et aux taps. Plus de doigts offrent
plus de possibilités. Un tap à cinq doigts peut permettre d’alterner entre la vue des
messages envoyés et la boîte de réception. Dans une application de journal, un balayage à
deux doigts pourrait vous faire passer à la section suivante plutôt qu’à la page suivante. À
l’avenir, les gestes utilisant plusieurs doigts permettront de développer un langage
d’interaction plus riche, dans lequel des gestes abstraits aideront à réaliser des actions
complexes.

Le potentiel inexploité des gestes multidoigts

L’application Uzu pour iPad est un » visualiseur de particules cinétiques », mais la
première impression que vous en aurez sera peut-être plutôt celle d’un jouet visant à
hypnotiser les fumeurs de joints, une sorte de lava-lamp interactive. Touchez l’écran avec
un doigt et des étincelles jaillissent comme des feux d’artifice (FIG 4.14). Ajoutez un
deuxième doigt, et les étincelles tourbillonnent entre les deux doigts, alors qu’un troisième
doigt crée un vortex entre les trois. Changez la teinte et la taille des particules en touchant
l’écran avec les dix doigts et en le balayant de haut en bas et de gauche à droite. Quand
vous vous serez familiarisé avec l’application, vos doigts auront l’air de voler et de danser
à l’écran, comme si vous jouiez d’une sorte de clavier visuel en technicolor – d’un
instrument plutôt que d’un outil.
FIG 4.14 : Dans Uzu, les animations et les actions varient en fonction du nombre de doigts utilisés.

Au premier abord, cela ne vous semblera peut-être pas pertinent pour cette application
de services financiers intranet que vous devez développer, mais Uzu offre des leçons utiles
pour tous types d’interfaces tactiles. Notamment, cette approche multi- doigts rappelle le
rôle des touches Alt, Control ou Fonction ; dix doigts permettent dix modes d’action. Les
doigts deviennent des touches fonction. Tout comme les dactylos professionnels
parcourent les mots à toute vitesse, ou comme les utilisateurs experts utilisent des
raccourcis clavier pour réaliser des tâches en une fraction de seconde, les gestes
multitouch nous aident également à naviguer sans effort dans nos interfaces tactiles. Ces
gestes, bien qu’abstraits, permettent aux utilisateurs avancés d’accomplir des tâches de
façon plus économique.
Si les commandes multidoigts possèdent un tel potentiel, pourquoi n’en utilisons-nous
pas plus ? Les téléphones prennent en charge le multitouch depuis des années, mais de
façon assez médiocre. Les prises à une main et les petits écrans nous ont plutôt incités à
taper d’un seul doigt. Les écrans plus grands sont plus prometteurs. La taille et le poids
des tablettes plus grandes exigent que vous utilisiez vos deux mains ou que vous posiez la
tablette sur vos genoux, de sorte à toujours avoir au moins une main libre – avec un écran
assez grand pour utiliser plusieurs doigts à la fois. Il en va de même pour les ordinateurs
hybrides et portables.
Il existe cependant quelques obstacles, à commencer par l’accessibilité : tout le monde
n’est pas doté de mains et de doigts complètement mobiles – ni même de dix doigts,
d’ailleurs. Pour certains handicaps, un pincement à cinq doigts est proprement impossible.
La découvrabilité est une autre pierre d’achop- pement. Comment sommes-nous censés
savoir que des actions abstraites comme un balayage à trois doigts ou un tap à cinq doigts
sont disponibles ? Nous aborderons des stratégies permettant de révéler des gestes au
chapitre 5, mais considérez qu’il est préférable de traiter ces gestes mutitouch plus
abstraits comme des alternatives – des compléments expressifs aux boutons et aux autres
interactions traditionnelles. Les utilisateurs doivent tout de même être en mesure
d’accomplir toutes ces actions avec des gestes simples, même si cela demande plus de
temps.
EMBOUTEILLAGE DE GESTES
À mesure que vous ajouterez de plus en plus de gestes dans votre interface pour compléter
ou remplacer des contrôles traditionnels, ces gestes risquent de devenir encombrants.
D’une part, comme les systèmes d’exploitation et les navigateurs s’approprient la plupart
des gestes clés, votre application ou votre site web doit se débrouiller avec les restes ;
d’autre part, les gestes – en particulier les gestes grossiers – consomment beaucoup
d’espace et jouent des coudes pour se faire une place à l’écran.

Faites de la place pour les gestes du système et du navigateur

En tant que designer, vous devez négocier avec les navigateurs et les systèmes
d’exploitation pour utiliser les gestes clés – et si le système se les approprie en premier,
c’est lui qui a la priorité. Vous vous souvenez des boutons système d’Android placés en
bas de l’écran que nous avons évoqués au chapitre 1 ? Le système d’exploitation a la
priorité, donc les designers d’applications doivent leur laisser la place et placer leurs
contrôles au sommet de l’écran. Il en va de même pour les gestes du système ; les
designers d’applications doivent composer avec l’environnement d’exploitation pour
éviter les gestes conflictuels.
Par exemple, iOS sur iPad requiert des gestes grossiers pour basculer entre les
applications. Balayez l’écran vers la gauche ou la droite avec quatre ou cinq doigts pour
alterner entre les applications récentes, ou pincez l’écran avec quatre ou cinq doigts pour
fermer une application et revenir à l’écran d’accueil. Vous pouvez de fait gifler votre écran
pour parcourir les applications – exactement le genre de gestes grossiers qu’un système
d’exploitation de tablette devrait adopter. J’adore l’esprit de ces gestes, mais je ne suis pas
fou de leur exécution. J’aurais préféré qu’Apple emploie les interactions déjà adoptées par
d’autres plateformes, comme Windows et un certain nombre de systèmes d’exploitation
tactiles défunts comme Symbian, BlackBerry PlayBook et webOS de Palm. Ceux-ci
utilisent tous des gestes de rebord, technique qui est à la fois plus cohérente intérieurement
et plus respectueuse des différentes applications. Les gestes de rebord partent du bord, ou
du cadre de l’appareil, et se prolongent dans l’écran. Lorsqu’ils sont utilisés pour basculer
entre plusieurs applications, ils donnent l’impression que l’on met les écrans de côté en les
poussant par le bord.
Ces gestes font correspondre l’action physique à la métaphore conceptuelle de l’OS. Si
vous considérez les applications comme la toile centrale de l’appareil, le système
d’exploitation est le cadre qui supporte cette toile. Lorsque les gestes de l’OS partent du
cadre de l’appareil, l’action correspond à l’attente : ce geste s’exerce en dehors de
l’application actuelle. Vous travaillez sur le cadre – le système d’exploitation – à la fois
physiquement et métaphoriquement.
À l’opposé, les actions permettant de basculer entre les applications sur l’iPad
s’effectuent sur la toile elle-même, un territoire qui devrait être réservé à l’application
ouverte. Cela crée une concurrence avec les interactions de l’application qui peut être
déconcertante : ce geste s’appliquera-t-il au niveau de l’application ou du système
d’exploitation ? Apple aurait pu éviter cette ambiguïté en arrimant ses gestes au rebord de
l’appareil. En les plaçant à l’intérieur de l’écran, Apple a éliminé plusieurs gestes très
pratiques de l’arsenal du designer.
Les navigateurs se sont aussi accaparé une bonne part des gestes utiles pour leur propre
usage. Pincement, double tap, glissement, pression longue… Ces gestes fondamentaux ont
déjà une signification pour les navigateurs et sont donc hors de portée des designers web.
Vous pourriez remplacer ces gestes en capturant leurs événements tactiles et en les
détournant à vos fins personnelles – par exemple pour qu’une pression longue déclenche
un comportement personnalisé au lieu d’afficher un menu contextuel. Mais il est rarement
judicieux de casser une fonction du navigateur. Si les gestes d’un navigateur ne produisent
pas le même effet sur différents sites web, nous risquons de saper la confiance des
utilisateurs à un moment où nous cherchons à consolider les interactions gestuelles et à
établir des normes. Laissez les navigateurs garder leurs gestes et travaillez avec ce qu’il
vous reste.

Donnez de la marge à vos gestes

Gérer la densité gestuelle ne demande pas seulement d’éviter les conflits avec les
navigateurs et les OS ; vous devez également prendre en compte l’espace physique que
ces gestes occupent, sans quoi ils commenceront à se chevaucher et entreront en collision.
Lorsque les gestes s’empilent, les erreurs de l’utilisateur suivent le même chemin. Prenons
par exemple une galerie de photos qui permet de faire défiler les images sur une même
page web. Sur les petits écrans, ces glissements peuvent facilement entrer en conflit avec
les gestes de rebord du navigateur ; Safari mobile, par exemple, réserve le balayage depuis
les bords gauche et droit de l’écran pour parcourir votre historique de navigation. Dans
notre exemple de galerie photo, un balayage accidentellement trop large pendant que vous
parcourez la galerie vous ferait complètement sortir de l’expérience, en vous lâchant sur
une autre page de votre historique. Les précédentes versions de Chrome pour Android ont
contourné ce problème en limitant l’espace alloué aux gestes. Avant, un balayage depuis le
bord gauche ou droit permettait de changer d’onglet, mais les utilisateurs n’arrêtaient pas
d’activer cette fonction par accident en essayant de faire défiler la page. Les développeurs
de Chrome ont donc limité le geste permettant de basculer entre les onglets à un balayage
sur la barre d’adresse, plutôt que n’importe où sur la page. Ce geste a rendu plus d’espace
et de liberté aux designers web qui souhaitaient utiliser des gestes tactiles. (Chrome a
finalement abandonné tout simplement les onglets dans la version d’Android 5.0
Lollipop.)
Réduisez les risques liés à la densité gestuelle en les anticipant. Cette galerie tactile
pourrait utiliser l’API d’historique HTML5 pour actualiser l’historique du navigateur à
chaque balayage. Dans ce scénario, un balayage accidentel depuis le rebord droit vous
ramènerait à l’image précédente ; le même résultat qu’un balayage normal dans la galerie.

Les menus circulaires permettent de réduire la densité gestuelle

Parfois, de vieilles techniques refont surface pour résoudre de nouveaux problèmes. Le
menu circulaire (ou menu radial) est apparu il y a un demi-siècle, mais il va peut-être enfin
avoir son heure de gloire en nous permettant d’éviter des conflits gestuels. Un menu
circulaire est un ensemble d’options qui apparaissent autour du pointeur comme les rayons
d’une roue. L’application de prise de notes OneNote de Microsoft, par exemple, offre un
menu circulaire faisant office de menu contextuel comme le ferait un clic droit (FIG 4.15).
Appuyez sur l’icône omniprésente du menu de l’application, et une roue d’actions à
appliquer à votre sélection actuelle apparaît. Faites glisser votre doigt sur celle que vous
souhaitez et relâchez la pression.

FIG 4.15 : Le menu circulaire contextuel de

À première vue, ces menus peuvent sembler plus compliqués qu’une simple barre
d’outils et remplis d’informations à assimiler. Cependant, les menus circulaires sont
tactiles par nature : toucher-glisser-relâcher. C’est pour cette raison que les anglophones
appellent parfois ces menus » marking menus » : cela s’apparente à tracer une marque sur
l’écran. Un balayage vers deux heures sur le cadran signifie une chose, un balayage vers
six heures, une autre. Vous devenez progressivement plus rapide, car les menus circulaires
exploitent la mémoire musculaire là où les menus à liste ne le peuvent pas. Dans
l’application Messages sur iOS, par exemple, vous pouvez ouvrir un menu circulaire pour
envoyer un clip audio, une photo ou une vidéo à quelqu’un (FIG 4.16). C’est un
mouvement fluide qui se transforme rapidement en habitude.
FIG 4.16 : Maintenez l’icône de micro enfoncée et un menu circulaire s’affiche alors que l’application démarre
l’enregistrement ; glissez vers le haut pour envoyer le fichier audio, vers la gauche pour le supprimer, ou relâchez le
bouton pour mettre en pause.

Autre avantage des menus circulaires, leurs gestes restent très compacts. Ils partent
d’un point spécifique à l’écran – idéalement sur le contenu que vous cherchez à manipuler,
même s’il s’agit souvent d’un bouton de menu ou d’un autre emplacement. Ce point
d’ancrage fixe réduit les erreurs, car il exige une attention supplémentaire ; il vous
demande d’appuyer sur l’élément que vous souhaitez affecter avant de démarrer le geste.
Les menus circulaires sont plus précis et permettent de mettre de l’ordre dans des
interfaces gestuelles autrement congestionnées.
Les menus circulaires existent depuis la fin des années 1960, mais ils n’ont jusqu’à
présent jamais rencontré beaucoup de succès dans les interfaces grand public
traditionnelles, à une exception près : les jeux. Les jeux de combat utilisent des menus
circulaires pour accéder rapidement à l’inventaire ou aux options de combat (FIG 4.17). Il
est tout à fait logique que les jeux de gâchette aient adopté le menu circulaire plutôt
qu’une liste plus classique. Dans ces jeux, il est essentiel de limiter les interruptions de
l’expérience, et les menus circulaires sont beaucoup plus efficaces que d’autres outils de
sélection.
FIG 4.17 : Le jeu au titre évocateur Game of Thrones: The Game utilise un menu circulaire pour contrôler l’action.

L’étude qui en a apporté la preuve est dans un tiroir depuis plus de vingt-cinq ans. Une
étude de 1988 a effectué la comparaison et a déterminé qu’avec une liste de huit éléments
spécifiques, les utilisateurs étaient plus rapides avec des menus circulaires qu’avec des
listes linéaires (http://bkaprt.com/dft/04-04/). Et il s’avère que la vitesse ne fait que
s’accroître. Cet effet a été confirmé par une étude réalisée en 1994 par Bill Buxton et
Gordon Kurtenbach, qui ont testé la vitesse d’utilisation des menus circulaires avec un
stylet. Au fil du temps, ils ont noté que les utilisateurs experts cessaient de regarder le
menu et marquaient l’écran à l’aveugle. Une fois cette transition effectuée, la sélection
devenait trois fois plus rapide (http://bkaprt.com/dft/04-05/).
Comme toute technique, les menus circulaires ont toutefois leurs limites. Gardez les
réserves suivantes à l’esprit.
• Ils demandent de la précision. Si le point d’ancrage fixe d’un menu circulaire permet de
réduire la densité gestuelle, cela va à l’encontre des avantages des gestes grossiers
parcourant tout l’écran. Les gestes grossiers sont idéaux pour la navigation et les
contrôles de base, tandis que les menus circulaires sont plus adaptés aux actions et aux
outils rapides.
• Ils ne sont pas agrandissables à volonté. On ne peut faire rentrer qu’un certain nombre
d’options autour d’un cercle. Huit semble être le maximum raisonnable. Sur les petits
écrans comme ceux des téléphones, un menu circulaire engloutit une part non
négligeable des pixels de l’écran, et il est donc généralement limité à trois ou quatre
options.
• La première utilisation peut être difficile. Malgré le gain de vitesse qui vient avec
l’expérience, nous sommes plus à l’aise pour parcourir une liste linéaire qu’un menu
circulaire. Mais ce degré de confort n’est pas si important lorsque vous vous intéressez
à l’usage réel. » Les effets de l’organisation disparaissent avec la pratique », a
découvert Buxton en 1994. » Même lorsque les options du menu sont ordonnées d’une
façon linéaire ordinaire, la sélection à l’aide d’un menu circulaire est toujours plus
rapide et moins susceptible d’entraîner des erreurs qu’avec un menu linéaire. » Ce fait,
cependant, dépend de cette dernière contrainte.
 • Les menus circulaires doivent être constants. Si vous changez l’ordre ou le contenu
d’un menu circulaire de façon dynamique, les utilisateurs devront se replier sur un
mode de sélection visuel, et vous perdrez tout gain de temps lié à la mémoire
musculaire.
Globalement, ces limitations sont modestes et contribuent d’ailleurs à modeler de bons
cas d’utilisation, tels qu’une navigation principale ou des menus contextuels cohérents.
C’est exactement le rôle qu’ils ont été amenés à jouer dans certaines parties d’Android, de
Windows et d’iOS, ou encore comme menus de navigation dans de nombreuses
applications populaires (FIG 4.18).

FIG 4.18 : Les applications Yelp (gauche) et My Fitness Pal (droite) pour iPhone utilisent des menus circulaires dans leur
navigation.

Les menus circulaires ont mis plus de temps à arriver sur le web que dans ces
environnements d’OS et d’applications alors qu’ils sont pourtant bien adaptés au support
ainsi qu’aux capacités des navigateurs. Parmi des exemples web existants, on trouve le
sporadique plugin jQuery (http://bkaprt.com/dft/04-06/) ou un clone CSS3 du menu
circulaire de l’application Path (http://bkaprt.com/dft/04-07/). Pourquoi ne voyons-nous
pas plus d’expériences de ce genre ? La vérité, c’est qu’il est encore pénible de développer
des gestes dans le navigateur. Voyons pourquoi.
LE DÉSESPOIR DES GESTES SUR LE WEB
Certains problèmes structurels rendent la conception de gestes sur navigateur fastidieuse,
mais pas impossible. Les navigateurs ne sont pas très doués pour répondre aux attentes en
matière d’interaction que les appareils à écran tactile ont créées, pour deux raisons en
particulier.
Tout d’abord, comme nous l’avons vu précédemment, les navigateurs se sont déjà
approprié de nombreux gestes utiles. Ces conflits gestuels laissent peu d’options au
designer au-delà du tap et du balayage. (C’est également pour cela que les menus
circulaires sont parfaitement adaptés au web : leur interaction tap-balayage utilise
précisément cette combinaison.)
Ensuite, JavaScript n’offre aux développeurs d’interface que les événements tactiles les
plus basiques : touchstart, touchend et touchmove. Il est relativement facile de détecter un tap ou
peut-être un balayage, mais le reste devient rapidement compliqué. Amusez-vous bien à
coder un geste de rotation ou un balayage à plusieurs doigts. Idéalement, nous devrions
avoir des événements pour tous les gestes courants sur n’importe quel élément du DOM :
pincement, pression longue, balayage, rotation, etc. (Microsoft modèle cette approche
dans son framework de conception d’applications Windows natives avec HTML5,
suggérant peut-être la voie à suivre.) Pour le moment, nous devons les construire nous-
mêmes en partant de zéro – ou mieux, utiliser une bibliothèque telle que l’excellente
Hammer.js (http://hammerjs.github.io), qui offre des événements pour le tap, le double
tap, le balayage, le glissement, le pincement et la rotation.
Des outils et des techniques commencent à émerger pour aider les designers à faire
face. Les balayages sont un geste idéal pour débuter. Ils sont (relativement) faciles à
implémenter, et de nombreux sites ont déjà adopté le balayage pour passer à l’écran
suivant/précédent. Par exemple, vous pouvez parcourir les galeries photo de Flickr, les
articles du New York Times, les résultats de recherche d’image de Google, et bien plus.
Vous pouvez vous aventurer au-delà du balayage, bien sûr, mais cela demande plus de
travail. Voyons un peu ce que cela implique. Le reste de ce chapitre présente la façon dont
les navigateurs gèrent les événements tactiles et comment vous pouvez utiliser JavaScript
et/ou CSS pour construire quelques gestes simples. Nous ne nous embourberons pas dans
les détails pratiques – ce n’est pas un livre sur JavaScript – mais il est important pour les
designers de savoir ce qui est réaliste en termes de programmation sur les écrans tactiles.
Comme programmer des événements tactiles n’est jamais chose aisée, commençons par
voir dans quelles situations vous n’en avez pas besoin.
LE CLICK, C’EST MAGIQUE
Comme nous l’avons remarqué, la plupart des navigateurs tactiles offrent les événements
touchstart, touchmove et touchend. En touchant l’écran, on déclenche également l’événement
click, qui permet à tous les vieux sites conçus pour la souris de faire leur boulot dans un
environnement tactile. Vous pouvez conserver votre santé mentale en vous focalisant sur
ce simple modèle d’interaction.
Quand vous le pouvez, tenez-vous en au clic. Malgré la disponibilité d’événements
tactiles plus complexes, il n’est pas nécessaire de remplacer les événements click dans
votre JavaScript, à moins que vous ne souhaitiez programmer quelque chose de plus
poussé qu’un tap. Bien que nous associions couramment click à la souris, ce n’est pas
strictement un événement de souris. Considérez plutôt que c’est une action
générique : » Je veux activer cet élément. » Dans la plupart des cas, si vous souhaitez
déclencher quelque chose lorsqu’un utilisateur touche l’écran, il suffit de capturer
l’événement click. Oubliez les événements tactiles et faites comme si vous codiez pour la
souris.
Le clic présente en outre l’avantage de fonctionner avec tous les modes de saisie.
Malgré son nom dérivé de la souris, click restera probablement l’action clé pour les
navigateurs web, qu’ils soient utilisés à l’aide du clavier, de la reconnaissance vocale, de
gestes de style Kinect, ou même d’un casque de réalité virtuelle. Le clic n’est pas
seulement compatible avec le passé ; il est aussi compatible avec le futur.
Mais click n’est pas parfait. Dans ce chapitre, j’ai fait valoir que les interactions tactiles
demandaient de nouvelles approches. Elles diffèrent des événements de souris et de pavé
tactile d’une façon évidente et subtile à la fois. Une différence qui n’est pas des moindres
est le nombre de pointeurs à prendre en charge. Les interfaces pour souris n’ont jamais
plus d’un curseur à la fois ; sur un écran tactile, vous pouvez utiliser vos dix doigts (ou
même plus avec l’aide de vos amis – ou de vos orteils). Si vous devez suivre plus d’un
doigt à la fois, click ne suffira pas. Utilisez click quand vous le pouvez, mais passez aux
événements tactiles lorsque vous devez faire l’une des choses suivantes :
• suivre plusieurs doigts (pincement, rotation ou balayage à deux doigts) ;
• effectuer une action lorsque le doigt est appuyé contre l’écran (un mouseover à la sauce
tactile) ;
• suivre le mouvement d’un doigt (balayage ou glissement).
Pour ce dernier élément, vous avez parfois plus de marge de manœuvre. CSS suffira
pour le cas d’utilisation le plus courant d’un balayage – les galeries et carrousels – alors
commençons par là.
UTILISEZ CSS POUR FAIRE DÉFILER LES GALERIES ET LES
CARROUSELS
Les sites s’appuient souvent sur un code JavaScript complexe pour créer des carrousels et
les gestes associés, mais il existe en fait une solution étonnamment simple. Si vous utilisez
overflow:scroll en CSS à la place, tous les navigateurs tactiles modernes vous donneront un
panoramique accéléré au niveau matériel ; le balayage est en prime, le tout sans
JavaScript.
Prenez une liste d’images :
<ul class="carousel">

<li>
<img src="image1.png" alt="unicorn">

</li>
<li>
<img src="image2.png" alt="rainbow">

</li>
<li>
<img src="image3.png" alt="sparkles">

</li>
</ul>

Utilisez CSS pour afficher les éléments de la liste en ligne dans une bande horizontale,
tous fixés à une taille spécifique :
.carousel {
white-space:nowrap;
}

.carousel li {
display: inline-block;

padding: 0;
margin: 0;

.carousel img {
width: 400px;

height: 300px;

Voilà maintenant le tour de magie. Définissez la hauteur et la largeur de la liste ul

contenant les images, et attribuez la valeur scroll à sa propriété de débordement horizontal
(overflow-x). Cette ligne demande aux navigateurs de faire défiler les images lorsqu’elles
dépassent la largeur disponible. Résultat : les navigateurs tactiles affichent un carrousel
d’images pouvant être balayées horizontalement (FIG 4.19).
FIG 4.19 : Pourquoi utiliser JavaScript ? CSS et HTML suffisent à créer un carrousel tactile.

.carousel {

white-space:nowrap;
overflow-x: scroll;

overflow-y: hidden;
width: 100%;
height: 300px;

/* défilement inertiel pour Safari mobile */

-webkit-overflow-scrolling: touch;
}

La dernière règle des styles .carousel indique à iOS d’appliquer son fameux défilement
inertiel.
-webkit-overflow-scrolling: touch;

Désormais, une simple pichenette du doigt fait défiler la page et celle-ci continue sous
le fait de sa propre inertie avant de s’arrêter en douceur, pour un effet qui imite un
comportement physique naturel. Sans la propriété -webkit-overflow-scrolling, le carrousel
avancerait uniquement lorsque vous le déplacez et s’arrêterait brusquement, produisant
une interaction austère et artificielle. D’autres navigateurs tactiles modernes n’ont pas
besoin de cette propriété et incluent le défilement inertiel sans aide supplémentaire.
Une mise en garde toutefois : de nombreux navigateurs mobiles plus anciens ne gèrent
pas la propriété overflow:scroll correctement et la traitent comme overflow:hidden, qui ampute
le contenu débordant de la page. Au lieu d’un carrousel qui défile, vous vous retrouvez
avec un carrousel qui ne veut pas bouger, empêchant d’accéder au contenu situé hors de
l’écran. Heureusement, le Filament Group propose un correctif : Overthrow est une
bibliothèque JavaScript qui résout le problème sur ces navigateurs, et ajoute même le
défilement inertiel en prime (http://bkaprt.com/dft/04-08/).
Ajoutez des points d’accrochage au carrousel
Nous avons maintenant un carrousel qui tourne librement ; c’est super, sauf qu’il peut
s’arrêter pile entre deux images. Faites en sorte que le carrousel vienne s’aligner avec l’un
de ses panneaux lorsqu’il arrête de défiler en ajoutant des règles scroll-snap :
.carousel {
white-space:nowrap;

overflow-x: scroll;
overflow-y: hidden;

width: 100%;

height: 300px;

/* défilement inertiel pour Safari mobile */

-webkit-overflow-scrolling: touch;

/* alignement avec les panneaux lors de la fin

du défilement*/
-ms-scroll-snap-type: mandatory;

scroll-snap-type: mandatory;
-ms-scroll-snap-points-x: snapInterval(0px,

400px);
scroll-snap-points-x: snapInterval(0px, 400px);
}

La règle scroll-snap-points-x demande au carrousel de s’aligner au début de la première

image (à 0px de la largeur du carrousel), puis de venir s’aligner tous les 400px à partir de là,
soit la largeur de chaque image. À l’heure actuelle, seul Internet Explorer 10+ prend en
charge scroll-snap, et les autres navigateurs l’ignorent, défilant rapidement et librement
sans s’arrêter au bon endroit. Cependant, scroll-snap est en voie de standardisation et
d’autres navigateurs devraient l’adopter à l’avenir (http://bkaprt.com/dft/04-09/).

Ordonnez l’expérience de bureau avec l’amélioration progressive

Sur les navigateurs de smartphones et de tablettes, les éléments comportant la propriété
overflow:scroll sont visuellement épurés. Sur les ordinateurs de bureau, cependant, ces
éléments s’accompagnent de barres de défilement. Les barres de défilement sont un bon
point de départ ; elles permettent aux gens d’accéder à votre contenu, offrant une
indication visuelle claire qu’il y a plus de contenu à découvrir. Par contre, une barre de
défilement sur un carrousel en plein milieu d’une page n’est pas franchement esthétique.
Appliquez un peu de JavaScript bien ficelé pour améliorer l’expérience. Utilisez
JavaScript pour détecter si le navigateur a accès à un écran tactile ou dispose d’objets de
pointage, et dans le cas contraire, réglez le carrousel sur overflow:hidden et ajoutez des
boutons précédent/suivant pour déplacer le contenu du style .carousel vers la gauche ou la
droite. Je laisse les détails de la programmation de ce carrousel comme exercice au lecteur,
mais tout d’abord, quelques remarques. Comme nous l’avons évoqué au chapitre 1, il
n’existe aucun moyen infaillible de détecter les écrans tactiles. Pour ce widget particulier,
cependant, cette règle suffira pour une amélioration strictement esthétique.
if ( ! 'ontouchstart' in window ||
 ! window.navigator.MaxTouchPoints ||

! window.navigator.msMaxTouchPoints )
{

// pas d’écran tactile, placer des boutons précédent/

suivant pour le bureau
}

Comme cette méthode de détection n’est pas complètement infaillible, cette approche
donnera inévitablement à certains navigateurs tactiles les boutons précédent/suivant au
lieu de l’interaction de balayage. Peu importe. Cela ne représentera qu’une minorité des
navigateurs, votre contenu sera toujours accessible, et avec des boutons suffisamment
gros, votre carrousel restera facilement accessible sur les écrans tactiles.
ÉVÉNEMENTS TACTILES DANS LE NAVIGATEUR
Comme nous l’avons vu, un judicieux mélange de CSS et d’événements JavaScript click
peuvent gérer le tap et le balayage. Si c’est tout ce dont vous avez besoin, notre travail est
fini ; n’hésitez pas à passer au chapitre suivant. Mais si vous avez besoin de gestes plus
complexes – multi-touch, glisser-déplacer, manivelle, rotation, etc. –, alors bouclez votre
ceinture, mettez votre casque, nous allons programmer des événements tactiles. Nous
n’approfondirons pas trop l’aspect code, mais voici un aperçu général du fonctionnement
des événements tactiles.
L’iPhone a été la première plateforme populaire à intégrer les événements tactiles
JavaScript dans son navigateur, et d’autres navigateurs lui ont rapidement emboîté le pas
pour être compatibles avec iOS. Cette approche est devenue une norme du W3C
(http://bkaprt.com/dft/04-10/) et elle est désormais prise en charge par quasiment tous les
navigateurs tactiles modernes (sauf Internet Explorer, qui dispose de son propre modèle de
pointeur concurrent qui deviendra peut-être lui-même une norme distincte – nous verrons
cela dans un instant).
Le modèle d’événements tactiles prédominant permet aux développeurs de détecter
trois événements : touchstart, touchend et touchmove. Vous connaissez peut-être déjà leurs
cousins de bureau mousedown, mouseup et mousemove, et ces événements tactiles fonctionnent de
façon similaire : les développeurs peuvent détecter lorsqu’une interaction tactile débute,
finit ou change, puis déclencher des actions correspondantes sur la page. Ces événements,
comme tous les événements JavaScript, créent un objet de données auquel les
développeurs peuvent accéder pour obtenir plus d’informations sur l’interaction tactile.
Les objets d’événements tactiles incluent trois listes de touches, des objets de données qui
désignent chacun un doigt ou un stylet qui touche actuellement l’écran :
• : une liste de tous les objets tactiles sur l’écran, pas seulement l’élément du
event.touches
DOM pour cet événement.
• : une liste concentrée d’objets tactiles qui inclue uniquement les
event.targetTouches
touches sur l’élément du DOM actuel.
• : une liste des objets tactiles impliqués dans l’événement actuel.
event.changedTouches
Dans touchmove, par exemple, cette liste vous dit quelles touches ont effectivement
bougé. Admettons que vous pinciez l’écran avec votre doigt et votre pouce, mais que
seul votre pouce bouge : c’est seulement ce dernier geste qui sera inclus.
Chacun des objets tactiles de ces trois listes contient à son tour des informations sur les
coordonnées du toucher et l’élément cible qui a déclenché l’événement. (Si vous touchez
un lien, par exemple, l’élément cible sera l’élément DOM <a> de ce lien.) Ces objets
d’événement et de toucher permettent aux développeurs de suivre la présence, la position
et le mouvement des doigts sur l’écran. Pour une introduction, lisez le tutoriel de Boris
Smus intitulé » Développer pour les navigateurs web multi- touch »
(http://bkaprt.com/dft/04-11/).

Démêler les événements de souris et les événements tactiles

Précédemment, nous avons évoqué le fait que le toucher déclenche un événement click
pour une meilleure rétrocompatibilité, mais ce toucher déclenche également tout un tas
d’autres événements de souris. Chaque fois que vous touchez l’écran et levez votre doigt,
le navigateur déclenche tous ces événements, dans cet ordre : touchstart, touchmove (le cas
échéant), touchend, mouseover, mousemove (le cas échéant), mousedown, mouseup, click. Ce
comportement est conçu pour veiller à ce que les sites codés pour les interactions à la
souris et au curseur continuent à fonctionner sur les écrans tactiles, ce qui est une bonne
chose. Cependant, cela soulève quelques problèmes potentiels.
• Les événements de souris se produisent tous à la suite après que le doigt a quitté
l’écran. Ainsi, touchmove ne se produit pas au même moment que mousemove, et mouseover se
déclenche lorsque le doigt n’est même plus sur l’écran. En d’autres termes, si les
événements de souris restent disponibles, ils ne correspondent pas exactement au
comportement des événements tactiles.
• Comme une interaction tactile déclenche à la fois des événements tactiles et des
événements de souris, faites attention, lorsque vous définissez des actions distinctes
pour ces deux types d’événements, à ne pas les définir en double. Utilisez
event.preventDefault() à l’intérieur des gestionnaires d’événements tactiles pour empêcher
le navigateur de déclencher également les événements de souris correspondants. (Cela
aura quelques répercussions, que nous allons aborder.) Par exemple, si vous voulez
déclencher une action pour touchstart et mousedown, vous devrez demander au navigateur
de ne pas traiter d’autre événement tactile au déclenchement de touchstart, sans quoi il
exécutera également l’action définie pour mousedown.
document.body.addEventListener('touchstart',

function(event) {
event.preventDefault(); // don’t trigger more
events for this touch

// placez ici votre code pour l’événement touchstart

}, false);

• Il s’écoule un délai de 300 millisecondes après touchend, de sorte que click et tous les
autres événements de souris simulés se déclenchent un tiers de seconde après que vous
avez ôté votre doigt de l’écran. (Cela signifie également qu’un seul événement mousemove
se produit pour toute interaction tactile donnée, tandis que touchmove s’actualise à mesure
que vous déplacez votre doigt.) Nous verrons pourquoi ce retard existe et comment
vous pouvez l’éliminer dans un instant.
• Vous perdez la correspondance sémantique des événements de souris tels que mouseout,
qui se déclenche sur l’élément touché seulement après qu’un autre élément de la page
est touché, et pas quand vous levez votre doigt comme vous pourriez vous y attendre.
Dans bien des cas, les différences entre le toucher et la souris exigent que vous
développiez des styles d’interaction séparés pour chacun, afin de prendre en charge
indépendamment chaque mode de saisie. Pour agrandir un élément, par exemple, vous
pourriez ajouter une détection du pincement et de l’étirement pour les événements tactiles,
tout en basculant sur un zoom actionné par un bouton pour les événements de souris. Mais
les choses se compliquent lorsque vous prenez en considération le nombre croissant
d’appareils et de navigateurs qui vous permettent de basculer entre la souris, le clavier et
l’écran tactile. Vous interface doit être prête à accepter n’importe quel style de mode de
saisie et d’interaction disponible. Si vous êtes un développeur JavaScript, prenez
l’habitude d’écrire des blocs de code séparés pour les clics et les interactions tactiles – cela
devient rapidement laborieux.

Assumez la prise en charge des événements tactiles

Comme mentionné ci-dessus, vous devez utiliser prevent- Default() dans les gestionnaires
d’événements tactiles pour empêcher le navigateur de déclencher les événements de souris
correspondants dans la foulée. C’est plutôt simple, mais cette solution présente un effet
secondaire important : en plus d’annuler les événements de souris pour cette interaction
tactile, elle indique au navigateur de ne pas appliquer son comportement ordinaire par
défaut sur l’élément – pas de scrolling, pas de clic, et ainsi de suite. Lorsque vous capturez
un événement tactile avec preventDefault(), vous dites concrètement au navigateur que vous
allez vous en occuper à partir de là et gérer tout ce qui est lié à cette interaction.
L’utilisateur essaie-t-il d’effectuer un tap, un défilement, un balayage, un double tap ? Ce
sera à vous de vous en assurer et de fournir ce comportement vous-même. Par exemple,
lorsque vous utilisez preventDefault() dans un gestionnaire d’événement touchstart ou
touchmove, vous annulez le scrolling pour cette interaction tactile. Soit vous codez votre
propre comportement de scrolling, soit cette partie de la page devient impossible à faire
défiler.
La gestion d’interactions détaillées comme celles-ci devient rapidement compliquée et
vous n’avez pas intérêt à vous avancer sur cette voie légèrement. Si vous décidez de partir
à l’aventure (et vous devrez le faire si vous souhaitez offrir des gestes complexes à vos
utilisateurs), envisagez de limiter vos gestionnaires touchend personnalisés à un petit
nombre de boutons ou de liens. Évitez notamment d’ajouter des gestionnaires tactiles à
des éléments qui doivent défiler, afin de ne pas désactiver accidentellement le
comportement de scrolling ordinaire du navigateur.
Là encore, si vous pouvez vous contenter de l’événement click, vous vous épargnez
toutes sortes de souffrances. Malheureusement, même notre fidèle ami click perd la boule
lorsqu’il s’agit d’interactions tactiles. Le problème le plus flagrant, c’est le délai qui
s’écoule entre le moment où vous touchez l’écran, et le moment où l’événement tactile est
déclenché.
GÉRER LE DÉLAI DE 300 MILLISECONDES
Jusqu’à très récemment, tous les navigateurs mobiles tactiles imposaient un délai de 300
ms avant d’enregistrer un » clic » après avoir touché l’écran. Quasiment un tiers de
seconde, un délai suffisant pour que les sites web tactiles semblent léthargiques par
rapport aux applications natives. Le coupable, c’est le double tap que les navigateurs
tactiles utilisent pour agrandir et réduire une page. Lorsque vous touchez l’écran une
première fois, le navigateur attend un instant – 300 ms ! – avant de répondre, pour
s’assurer que vous n’êtes pas en train d’effectuer un double tap. Sans cela, les navigateurs
pourraient poursuivre l’action sans attendre.
La plupart des navigateurs réservent le double tap au zoom, alors Chrome et Firefox
pour Android ont essayé une solution astucieuse : ils n’attendent pas le double tap si le
designer désactive le zoom sur sa page dès le départ. Le problème, c’est que cette
approche n’élimine pas seulement le double tap, mais également le pincer pour zoomer,
une fonction donc beaucoup de personnes peuvent avoir besoin pour être en mesure de lire
votre site. Pour eux, désactiver le zoom a pour effet de casser votre site – un choix
minable pour l’accessibilité.
En 2013, Chrome a pris une mesure plus utile, éliminant le zoom par double tap
lorsqu’une page fixe sa largeur sur device- width, comme ceci :
<meta name="viewport" content="width=device-width,

initial-scale=1.0">

Si vous concevez un site responsive ou mobile uniquement, vous devriez utiliser cette
balise de toute façon ; c’est donc une solution facile qui contourne le délai de 300 ms sans
effort supplémentaire. En prime, il est toujours possible de pincer pour zoomer. Les autres
navigateurs suivront peut-être l’exemple de Chrome à l’avenir, mais certains ne pourront
pas. Safari mobile, par exemple, fait défiler la page lorsque vous effectuez un double tap
au sommet ou en bas de l’écran. Il est peu vraisemblable qu’il désactive ce geste un jour,
car le double tap ne fait pas que zoomer.
Internet Explorer vous permet de désactiver le zoom par double tap avec CSS. En
utilisant la propriété touch-action (http://bkaprt.com/dft/04-12/), vous pouvez indiquer à IE
10+ d’autoriser le comportement tactile par défaut sur des éléments individuels. Par
exemple, pour désactiver les double taps sur un élément tout en permettant le zoom par
pincement, ajoutez cette règle CSS :
-ms-touch-action: manipulation;

touch-action: manipulation;

Un jeu d’enfant. Pour résumer, voici comment supprimer le délai dans Chrome et
Internet Explorer.
• Réglez la taille du viewport sur device-width.
• Utilisez la règle CSS touch-action.
Les autres navigateurs continueront à traîner des pieds, mais si vous tenez vraiment à
accélérer l’expérience, une paire de bibliothèques JavaScript pourront vous venir en aide.
FastClick de FT Labs (http://bkaprt.com/dft/04-13/) utilise les événements tactiles pour
déclencher des clics rapides et élimine le double tap. Il se charge également de différencier
les scrolls, balayages et taps pour vous. Tappy, écrit par Scott Jehl du Filament Group
(http://bkaprt.com/dft/04-14/), masque les différences entre les événements click tactiles,
de souris et de clavier en créant un événement tap unique qui marche pour les trois,
éliminant le délai de 300 ms dans la foulée.
DOULEURS ET PROMESSES DES ÉVÉNEMENTS DE POINTEUR
Voilà donc que je vous suggère d’utiliser une bibliothèque JavaScript pour unifier les clics
et les interactions tactiles dans un seul événement. Ou d’utiliser click autant que possible.
J’ai beau tourner autour du pot, très cher lecteur, vous avez sans doute compris que je
souhaitais vivement avoir une seule codebase valable à la fois pour la souris et les écrans
tactiles – au moins pour les interactions simples. Différents modes de saisie demanderont
toujours différentes interactions, et un code séparé est parfois indispensable. Mais pour les
interactions de base (clics, scrolling, glisser-déplacer, etc.), les interactions sont si
similaires que nous ne devrions pas avoir besoin de les traiter séparément. C’est là le
principe des événements de pointeur.
Microsoft a introduit les événements de pointeur dans Internet Explorer comme
alternative concurrente aux événements tactiles. Les événements de pointeur combinent
les événements pour la souris, l’interaction tactile et le stylet, voire d’autres modes de
saisie tels que les gestes de style Kinect – tout ce qui peut être considéré comme un
pointeur. Ils sont prometteurs mais, malheureusement, ils ne fonctionnent que dans
Internet Explorer. Cela changera peut-être : le W3C a créé une norme pour les événements
de pointeur (http://bkaprt.com/dft/04-15/), que d’autres navigateurs seront susceptibles
d’adopter (à l’heure où j’écris, Chrome et Firefox ont annoncé qu’ils le feront et Safari,
qu’il ne le fera pas). En attendant que cette intrigue évolue, des bibliothèques JavaScript
telles que Hand.js de Microsoft (http://bkaprt.com/dft/04-16/) comblent le vide et vous
permettent d’utiliser les événements de pointeur immédiatement pour une gestion unifiée
des événements dans tous les navigateurs. Dans tous les cas, les designers sont obligés de
prendre en charge les événements tactiles, les événements de pointeur et les événements
de souris. Pfiou.
Voici un bref aperçu du fonctionnement du système de pointeurs. Ces derniers
déclenchent divers événements et, contrairement aux actions de la souris, peuvent se
produire simultanément (par exemple lorsque vous posez plusieurs doigts sur l’écran).
Pour des raisons de compatibilité, les événements de souris sont toujours déclenchés ;
donc, comme avec les événements tactiles, assurez-vous que vous ne traitez pas à la fois
les événements de pointeur et les événements de souris – event.preventDefault() est votre
ami, avec les mises en garde évoquées précédemment.
Comme Microsoft a publié Internet Explorer 10 en avance par rapport à la norme du
W3C, l’entreprise a utilisé des préfixes de navigateur pour nommer ses propres
événements de pointeur. Maintenant que la norme est établie, ces noms préfixés ne sont
plus pris en charge à partir d’IE 11. En clair, pour couvrir toutes les versions, vous devez
attacher les noms avec et sans préfixe des événements et des objets de pointeur. Cela
commence à devenir verbeux. Les événements de pointeur clés sont :
• (ou MSPointerDown pour IE 10) : un bouton de la souris est pressé, ou un
pointerdown
doigt/stylet entre en contact avec l’écran. Similaire à mousedown et touchstart.
• (ou MSPointerUp) : un bouton de la souris est relâché, ou un doigt/stylet est levé
pointerup
de l’écran. Similaire à mouseup et touchend.
• pointermove (ou MSPointerMove) : un pointeur actif est en mouvement. Similaire à mousemove et
touchmove.
 • (ou MSPointerOver) : début du survol ; pour les appareils qui ne prennent pas en
pointerover
charge le survol, cet événement est déclenché immédiatement avant pointerdown.
Similaire à mouseover.
• (ou MSPointerOut) : fin du survol ; pour les gadgets ne prenant pas en charge le
pointerout
survol, cet événement est déclenché immédiatement après pointerup. Similaire à mouseout.
Cet objet d’événement de pointeur vous donne toutes les informations qu’un
événement de souris vous donnerait (event.clientX et event.clientY pour les coordonnées à
l’écran, event.target pour l’élément cible, etc.). Mais l’objet révèle également quel type de
pointeur vous avez reçu (event.pointerType), ou même le niveau de pression exercé par un
stylet (event.pressure). Pour plus de détails sur les objets d’événement de pointeur,
consultez la documentation de Microsoft sur les événements de pointeur
(http://bkaprt.com/dft/04-17/).

Tous ensemble : prendre en charge les pointeurs, les interactions tactiles et

les clics
Nous devons maintenant jongler avec un tas de types d’événement : clavier, souris, écran
tactile, pointeur, ainsi que les noms de pointeur préfixés de Microsoft. Comment tirer au
clair votre JavaScript ? Pour commencer, définissez les événements de pointeur pour les
navigateurs qui les prennent en charge et, pour le reste, définissez des événements de
souris et des événements tactiles séparément. Ensuite, offrez à tous les navigateurs des
événements de clavier et des événements click. Voici le résumé :
if ('PointerEvent' in window) {
// lier aux événements de pointeur

}
else if ('MSPointerEvent' in window) {
// lier aux événements de pointeur avec préfixe MS

}
else {

// lier aux événements de souris

if ('ontouchstart' in window) {
// lier aux événements tactiles ;

// utilise event.preventDefault() pour éviter de

// traiter à la fois les événements tactiles

// et les événements de souris

// lier aux événements de clavier

// lier aux événements click

Les événements de pointeur ont le potentiel exceptionnel de réunir tous les événements
d’interaction sous une même enseigne, mais dans l’intervalle, ils ne font qu’ajouter un
autre scénario à gérer pour les designers – sans compter le surplus de code associé et le
coût que cela représente en termes de performances. Quelle est la meilleure tactique à
adopter ? Simplifiez là où vous le pouvez et reposez-vous sur l’événement click autant que
possible (ou tap de la bibliothèque Tappy).
RATTRAPAGE GESTUEL
Les écrans tactiles créent des attentes en matière d’interaction que les navigateurs ont
encore du mal à suivre. Pour le pire et pour le meilleur, qu’ils soient simples ou
complexes, c’est ainsi que nous construisons des gestes sur le Web. Le modèle de
l’interaction tactile dans les navigateurs est un désordre tel que les applications natives
resteront sans doute le principal terrain d’expérimentation en la matière dans un futur
proche. C’est dans ces environnements propriétaires que l’essentiel de l’innovation se fera
jusqu’à ce que les standards rattrapent le retard, ce qui finira inévitablement par arriver.
Entre temps, même avec ces imbroglios d’événements tactiles, cela vaut la peine de
s’efforcer de faire fonctionner les gestes et les interactions tactiles dans le navigateur. Vous
connaissez la chanson : un nouveau médium demande de nouvelles interactions, et ce
chapitre s’est attaché à vous montrer à quoi elles pourraient ressembler. Mais concevoir et
construire des gestes n’est que la moitié de l’équation.
Maintenant que vous avez déterminé quels gestes utiliser pour votre interface, il va
falloir que les gens puissent les découvrir. C’est ce que nous allons voir au prochain
chapitre.
HOURRA, VOUS AVEZ DES GESTES ! Mais, euh, vos utilisateurs le savent-ils ? Les gestes ne
sont utiles que si les gens peuvent les trouver. Autrement ils ne sont que des œufs de
Pâques, des confiseries cachées pour les chanceux ou les plus déterminés – et vos
utilisateurs ne sont ni l’un, ni l’autre. Le défi, bien sûr, c’est que les gestes sont invisibles,
contrairement aux boutons avec leurs appels à l’action dûment étiquetés. Si l’interface ne
suggère pas clairement un geste, vous devez aider les gens à le découvrir. Ce chapitre
explore l’art subtil de rendre les gestes apparemment intuitifs, même lorsqu’ils ne sont pas
intrinsèquement évidents. Nous allons découvrir les fondamentaux d’une interface
explicite et intuitive dans des sources aussi diverses que des magazines, des manuscrits
anciens et des jeux vidéo. Ceux-ci démontrent tous la norme de référence pour une
interface découvrable : des instructions qui se révèlent en contexte et en temps opportun,
sans nécessiter de manuel.
FIG 5.1 : Lorsque Vanity Fair a sorti une application pour iPad, ses instructions complexes semblaient suggérer que
l’application était tout sauf l’expérience » intuitive » qui était promise.
LES INSTRUCTIONS EXPLICITES NE SONT PAS LA SOLUTION
Les designers se reposent trop souvent sur des manuels, des FAQ et des aide-mémoires
élaborés pour expliquer les subtilités des balayages à trois doigts et des pincements à cinq
doigts. Si ces guides peuvent être des références utiles, ils sont de piètres outils
d’apprentissage. Lorsque vous présentez trop d’informations trop vite, vous accablez
l’utilisateur et vous lui donnez l’impression que votre application ou votre site web est
beaucoup plus compliqué qu’il ne l’est vraiment (FIG 5.1).
Ce n’est pas seulement le volume des instructions qui rebute les gens, c’est le fait qu’il
y ait des instructions tout court. Les nouveaux venus sur votre site ou votre application
sont là pour faire quelque chose, et les instructions semblent les en divertir. Effectivement,
en lisant ces instructions, nous pourrions parvenir à nos fins plus rapidement, mais nous
sommes trop impatients pour en prendre la peine. Nous disposons, pour la plupart, de
connaissances incomplètes des outils que nous utilisons tous les jours, parce que nous ne
lisons jamais le fichu manuel – c’est pour cette raison qu’il est moins utile de faire
précéder votre expérience utilisateur d’un tutoriel ou d’une vidéo que de permettre aux
gens de plonger directement dans le cœur du sujet et d’expérimenter. Nous examinerons
quelques techniques d’orientation efficaces par la suite. Mais d’abord, sachez une chose :
parfois, la seule instruction dont les gens ont besoin pour utiliser votre interface, c’est une
bonne métaphore.
DESIGN SKEUOMORPHIQUE : » JE SAIS DÉJÀ COMMENT ÇA
MARCHE »
Comme nous l’avons vu au chapitre précédent, si un élément d’une interface ressemble ou
se comporte comme un objet physique, les gens essaieront d’interagir avec de la même
façon. Et moins une geste ressemble à une action physique, plus il est difficile à deviner.
Ces principes expliquent l’efficacité du design skeuomorphique, approche qui consiste à
maquiller les interfaces numériques pour les faire ressembler (et avec un peu de chance, se
comporter) comme des objets physiques. Si une interface ressemble à un livre, elle nous
pousse aussitôt à l’utiliser comme tel, en feuilletant les pages pour parcourir le contenu.
La métaphore informe l’utilisateur en faisant simplement correspondre le design visuel à
l’interaction sous-jacente. » Hé, c’est un bouton rotatif [ou un livre, un microphone ou une
fronde lance-oiseaux]. Je sais déjà m’en servir. »
Cependant, un design skeuomorphique pose problème en tant qu’outil pédagogique
lorsque le designer n’applique pas la métaphore jusqu’au bout. Pendant les dix-huit
premiers mois de l’iPad, l’application Calendrier, qui ressemblait pourtant à un agenda en
cuir, ne se comportait pas comme tel : lorsque vous essayiez de tourner les pages, rien ne
se passait. L’application Contacts originale présentait le même défaut, mais pire encore :
lorsque vous tentiez de feuilleter les pages du carnet d’adresses, vous supprimiez
carrément le contenu (FIG 5.3).

FIG 5.2 : Et si les magazines physiques comportaient les mêmes instructions que les magazines pour iPad ? Cette parodie
du designer Khoi Vinh démontre à quel point nos interfaces élégantes deviennent compliquées lorsque nous les
surchargeons d’informations.
FIG 5.3 : L’application Contacts d’origine pour iPad ressemblait à un carnet d’adresses, mais ne fonctionnait pas de la
même façon. Quand vous essayiez de tourner la page en feuilletant le carnet, vous supprimiez les coordonnées du
contact. Oups !

Vous voyez bien à quel point il peut être dommageable de proposer un design visuel
qui ne correspond pas au design de l’interaction. Ayez conscience des possibilités
interactives qu’offre votre métaphore d’interface, mais également des possibilités qu’elle
promet. Si votre design semble promettre que l’on puisse feuilleter les pages, alors il doit
le permettre. N’essayez pas de copier un objet physique si votre interface ne peut pas agir
comme tel.
Cette correspondance » apparence-comportement » s’éloigne de ce que les artistes et
designers ont pratiqué de façon ludique pendant des siècles. Les moines gravaient des
effets de trompe-l’œil tridimensionnels sur leurs manuscrits enluminés pour créer
l’illusion d’un parchemin, d’un papier tuilé ou de feuilles de papier empilées (FIG 5.4).
Plus récemment, les designers interactifs des années 1980 ont fidèlement reproduit des
calculatrices, des calendriers et des livres en tant qu’éléments d’interface pour le
Macintosh et d’autres interfaces graphiques (FIG 5.5). Historiquement, nous considérions
ces fioritures comme des ornements ; nous savions qu’une interface de bureau qui
ressemblait à un livre serait malgré tout utilisée à l’aide de boutons classiques. Mais
lorsque cette plaisanterie visuelle arrive sur l’écran tactile, nous nous faisons prendre au
piège. Souvenez-vous : la nature physique de l’interaction tactile donne l’illusion qu’il n’y
a pas d’illusion. Les interfaces tactiles qui ressemblent à des objets physiques vous
tromperont et vous mettront sur la mauvaise voie si elles ne se comportent pas comme ces
objets.
FIG 5.4 : Le concepteur de ce livre d’heures du XVe siècle a enluminé ses pages pour donner l’impression qu’elles
étaient rédigées sur des rouleaux de parchemin – rappel fantaisiste d’une technologie de lecture plus ancienne. On
imagine que personne n’est tombé dans le panneau en essayant de dérouler la page comme un parchemin. La donne
change lorsque vous introduisez un écran tactile. Image tirée des bibliothèques de l’Université de Liège.

FIG 5.5 : Nous jouons au jeu du sosie sur les ordinateurs de bureau depuis les années 1980.
QUAND LE DESIGN TOMBE À PLAT
Si un design ne peut pas ressembler à un objet physique sans se comporter comme tel,
qu’en est-il de la proposition inverse ? Une interface peut-elle fonctionner si elle se
comporte comme un élément physique, mais n’y ressemble pas ? Certains designers
rechignent à singer l’apparence d’objets réels pour des raisons esthétiques, et le design
skeuomorphique peut facilement virer au kitsch. Mais en éliminant tous les indices qui
indiquent cette ressemblance, on risque d’aplatir bien plus que l’apparence. Une anecdote
au sujet d’iOS peut servir de mise en garde.
En 2013, Apple a sorti iOS 7, un nouveau design reprenant l’esthétique plate
popularisée par Windows. L’entreprise a éradiqué sans pitié les éléments
skeuomorphiques : les boutons se sont transformés en texte épuré, les curseurs sont
devenus des blocs plats et les cartes ont perdu leurs bordures et leurs ombres. Ce faisant,
les designers plaidaient pour un recentrage sur le contenu et l’efficacité visuelle, renonçant
aux décorations » frivoles », telles que les ombres, les surfaces lustrées ou les effets de
lumière – les attributs du monde physique. Si l’objectif était louable, la mise en œuvre a
été difficile à suivre. Les utilisateurs d’Apple avertis savaient comment ces widgets aplatis
fonctionnaient grâce aux versions précédentes, mais les néophytes disposaient de bien peu
d’indices visuels. Les widgets se comportaient toujours comme des objets physiques – les
curseurs glissaient, les cartes se retournaient, mais les utilisateurs devaient tâtonner pour
comprendre qu’il s’agissait de curseurs ou de cartes. Pire, l’aplatissement de l’interface
avait également mis à mal la découvrabilité des éléments de base, boutons inclus.
Si vous éliminez les indices skeuomorphiques, comblez le vide avec d’autres
instructions. Il peut s’agir de suggestions subtiles, telles que des indices visuels ou des
animations. Dans Windows, le système d’exploitation indique qu’il est possible de balayer
ou de faire défiler les panoramas, ses grilles de panneaux horizontales, en plaçant des
tuiles partiellement visibles à l’écran (FIG 5.6). Dans iOS, le curseur » faites glisser votre
doigt sur l’écran pour déverrouiller » indique le geste à effectuer à l’aide d’une animation
qui balaie le texte de gauche à droite. Quant au design aplati d’Apple, l’entreprise a par la
suite rajouté une option permettant de rétablir les contours de ses boutons autrement nus.
FIG 5.6 : Les tuiles sectionnées sur le bord droit des panoramas de Windows indiquent qu’il est possible de les faire
défiler.

Ces interventions esthétiques et ces indications de mouvement laissent entrevoir le rôle

interactif d’un élément, afin qu’il ne soit pas nécessaire qu’il ressemble à un véritable
objet. Le panorama coulissant de Windows, les listes de tâches dans l’application Clear, le
rebond élastique dans iOS lorsque vous arrivez à la fin d’une liste – aucun de ces éléments
numériques ne prétend ressembler à une chose réelle, mais ils se comportent
conformément aux lois de la physique. L’illusion d’existence physique ne s’appuie pas sur
le fait que ces éléments paraissent réels, mais qu’ils se comportent comme tel. En fait, il
peut être risqué de donner aux choses une apparence trop réelle.
NE SOYEZ PAS SI LITTÉRAL
Lorsqu’un design devient trop attaché à la » vérité » physique de son interface, il risque de
perdre des opportunités numériques. Les applications pour tablettes de première
génération de l’industrie du magazine, par exemple, étaient si proches du comportement
d’un magazine papier qu’elles n’offraient pas grand-chose de plus qu’un PDF. Elles
étaient tout ce qu’il y a de plus simple à utiliser – il suffisait de feuilleter les pages –, mais
elles ne tiraient pas parti du superpouvoir numérique le plus essentiel : l’accès direct au
contenu. Dans de nombreuses applications, la table des matières était inutilisable et vous
ne pouviez pas simplement sauter vers le contenu qui vous intéressait. L’emploi trop
littéral de la métaphore physique était comme une régression.

Améliorez les métaphores physiques grâce au numérique

Donnez à vos interfaces le pouvoir faire des choses dont les objets physiques ordinaires
sont incapables. En remplaçant leurs boutons physiques par un écran tactile, nos appareils
sont devenus des métamorphes, défiant la physique traditionnelle du design industriel. À
première vue, l’application pour iPad du Sydney Morning Herald ressemble et se
comporte comme la version papier. Mais touchez l’indicateur de la page en bas de l’écran,
et vous verrez apparaître une liste abrégée de tous les titres de cette page. Faites glisser
votre doigt le long du bas de l’écran et vous pourrez parcourir tous les articles du jour et y
accéder instantanément sans avoir à feuilleter tout le magazine (FIG 5.7). L’application
associe la familiarité du journal papier à l’efficacité numérique d’un contenu libéré des
entraves d’une expérience analogique » page par page ».
FIG 5.7 : L’application pour iPad du Sydney Morning Herald place une expérience de navigation paginée au premier
plan, mais vous permet de parcourir rapidement les titres en faisant défiler l’indicateur en bas de l’écran.

L’application du Herald démontre qu’une interface naturelle peut puiser son inspiration
ailleurs que dans le simple savoir-faire physique. Les interactions à la souris façonnent
elles aussi les attentes. Dans Maps pour iOS, les novices comprennent facilement qu’un
double tap permet de zoomer – une interaction qu’ils ont acquise en double-cliquant dans
Google Maps. Mais lorsque vous rencontrez un geste sans contexte ni histoire, vous
manquez d’un point de référence. Personne n’imagine que vous pouvez effectuer un tap à
deux doigts dans Maps pour dézoomer (essayez, ça marche vraiment). Aucune interaction
préalable avec une carte physique ou numérique ne permet de le deviner. Lorsque les
gestes ne concordent pas avec une expérience passée, ils deviennent abstraits et
demandent une aide explicite pour être découverts.
Il n’y a pas de problème à fournir une aide explicite, d’ailleurs. J’ai déjà entendu des
designers dire » si votre interface a besoin d’une explication, vous faites fausse route ». Ce
n’est pas vrai. Si les fonctions de base doivent être faciles et évidentes dès le départ, les
fonctions avancées nécessitent toujours quelques instructions, même dans l’interface la
mieux pensée. Cependant, le meilleur apprentissage se fait par l’expérimentation, et c’est
pourquoi les écrans d’aide et les FAQ nous déçoivent souvent. Une meilleure approche
consiste à former les utilisateurs progressivement et contextuellement, et par chance, nous
avons à notre disposition un excellent moyen d’apprendre.
JOUEZ À PLUS DE JEUX VIDÉO
Quand il s’agit d’apprendre aux gens à utiliser des interfaces inconnues, les concepteurs
de jeux vidéo sont des experts. Dans de nombreux jeux, vous ne savez même pas quel est
votre objectif, et vous connaissez encore moins vos capacités ou les obstacles que vous
risquez de rencontrer. Comment apprenez-vous tout cela en tant que joueur ? Certainement
pas en lisant un manuel ou en regardant un tutoriel vidéo. Vous apprenez en jouant. Le jeu
lui-même vous apprend à jouer ; il vous entraîne et vous apprend les mouvements avancés
jusqu’à ce que vous maîtrisiez les bases. Entre autres techniques, les jeux s’appuient sur
trois outils pour y parvenir : le coaching, les niveaux et les bonus.

Coaching
Vous connaissez peut-être le vieil adage : » Show, don’t tell. » En français, on pourrait
dire » prêchez par l’exemple ». Lire un livre n’est pas la meilleure façon d’apprendre à
jouer d’un instrument ou à frapper une balle de tennis. Généralement, quelqu’un vous
montre comment faire, vous l’imitez puis vous vous entraînez. Toutes les théories
d’apprentissage modernes mettent l’accent sur l’importance de la participation active,
complétée par un encadrement. En d’autres termes, nous apprenons en faisant, et nous
apprenons le mieux dans l’instant. C’est ce que l’on appelle le coaching, et c’est ce que
font les meilleures interfaces intuitives. Le coaching consiste à accompagner le joueur (ou
l’utilisateur de votre site web) en illustrant des techniques utiles aux moments opportuns.
Dans la version pour iPad du jeu Dead Space, le premier écran vous apprend à vous
déplacer en appliquant un calque transparent qui vous montre ce qu’il faut faire, puis vous
invite à essayer vous-même (FIG 5.8). Une fois que vous avez crapahuté à travers la pièce,
le calque disparaît. L’un des éléments les plus essentiels du coaching consiste à savoir
quand une compétence a été apprise et quand passer à quelque chose de nouveau.
FIG 5.8 : Avant de courir, il faut apprendre à marcher : dans Dead Space, un calque transparent offre un coaching simple
qui vous apprend à vous déplacer dans le premier écran du jeu. La main animée trace la forme de croix, vous invitant à
faire de même.

Encore mieux que » show, don’t tell » : » do, don’t read ». Dead Space associe les
instructions à des actions ; vous mettez la compé- tence en pratique au moment où elle
vous est enseignée. Compa- rez cela au traditionnel tutoriel employé par tant
d’applications mobiles. Ces tutoriels sont généralement des écrans statiques qui illustrent
les fonctions, contrôles ou gestes principaux, isolés du contenu ou de l’usage réel de
l’application (FIG 5.9).
FIG 5.9 : Dans l’application de réveil Rise, un simple tutoriel présente des images statiques des gestes permettant de
définir des alarmes.

Les tutoriels vous demandent de retenir des gestes dans votre mémoire visuelle. En
vous forçant à effectuer l’action, Dead Space vous aide à stocker le geste dans votre
mémoire musculaire, ce qui est beaucoup plus efficace. Là encore, l’apprentissage
d’actions physiques repose sur la répétition : une boucle de démonstration et de mise en
pratique. Lorsque vous enseignez des gestes, faites-les répéter à vos utilisateurs dès le
début et souvent. C’est ce que font les tutoriels de Mailbox (FIG 5.10) et de Dots (FIG 5.11)
en vous obligeant à effectuer chaque geste pour continuer.
FIG 5.10 : Il n’y a aucun bouton » continuer » dans le tutoriel de l’application Mailbox d’iOS ; vous devez effectuer le
geste décrit pour continuer.

FIG 5.11 : Le tutoriel du jeu Dots présente le mécanisme essentiel : relier des points. Pour poursuivre le tutoriel, vous
devenez réaliser chaque tâche en reliant les points.

Une démonstration vaut mieux qu’un tutoriel. Bien que les tutoriels de Mailbox et de
Dots soient efficaces pour apprendre les contrôles, ils sont aussi un peu protocolaires, car
ils imposent une série d’obstacles à franchir avant de pouvoir utiliser l’application pour de
vrai. Dead Space surpasse les deux avec sa démonstration contextuelle, une présentation
des fonctions strictement chorégraphiée dans l’environnement de travail réel d’une
application ou d’un site. C’est comme les petites roues sur un vélo : vous avancez tout
seul, mais avec quelques supports qui vous empêchent de tomber. L’application de prise
de notes Noted, par exemple, vous guide à travers des étapes déterminées vous permettant
de créer et d’éditer votre première note (FIG 5.12).

FIG 5.12 : La démonstration de Noted vous emmène sur un chemin prédéterminé à travers l’application, et vous créez
votre premier document au fur et à mesure. Le point s’anime pour vous indiquer les gestes à effectuer.

Facebook Paper vous offre une liberté totale à partir d’un chemin déjà tracé ; vous
explorez l’application à votre rythme, et Paper explique les interactions clés à mesure que
vous les rencontrez (FIG 5.13). Les gestes sont illustrés à l’écran par des animations qui
vous encouragent à les reproduire (démonstration et mise en pratique !). Vous êtes libre de
suivre ou non les conseils de l’application – vous restez aux commandes. Il s’agit du style
de démonstration le plus efficace, et c’est celui que les jeux vidéo emploient souvent.

FIG 5.13 : Paper vous donne des instructions à l’aide d’animations, de texte et d’enregistrements vocaux pour décrire les
fonctions à mesure que vous les découvrez.

Tous ces exemples de coaching expliquent leurs gestes via du texte et des libellés, mais
vous pouvez également faire allusion à des fonctionnalités à l’aide de moyens plus subtils,
comme l’animation. Lorsque la toute première application USA Today pour iPad est sortie,
un ruban placé au sommet de l’écran permettait de parcourir les chaînes éditoriales. Mais
beaucoup de gens n’ont pas compris qu’ils pouvaient faire défiler le ruban, et pensaient
que l’application ne contenait qu’une poignée de sections.
Les designers ont alors ajouté une animation : à chaque fois que vous consultiez l’écran
principal, le ruban apparaissait en défilant depuis la droite (FIG 5.14). » Hé, ça bouge,
peut-être que je peux le faire bouger aussi ? » Et ça a marché. Maintenant que
l’application illustrait le mouvement du contrôle, la confusion était levée et les visiteurs se
sont mis à utiliser le ruban comme prévu. Une fois le ruban déplacé par l’utilisateur –
preuve que le geste avait bien été compris, l’animation cessait de se déclencher.

FIG 5.14 : Lorsque le site de USA Today a ajouté une animation au ruban de navigation, un grand nombre d’utilisateurs
ont enfin compris à quoi il servait.

Les erreurs sont l’occasion d’apprendre. Le coaching ne consiste pas seulement à

observer ce que les gens font, mais également ce qu’ils ne parviennent pas à faire. Des
couches d’apprentissage intelligentes détectent les erreurs et arrivent à la rescousse pour
offrir des instructions. Citia est une plateforme en ligne qui organise son contenu sous
forme de cartes. Pour parcourir la pile de contenu, vous devez retourner les cartes vers la
droite. Si vous essayez de déplacer la carte dans la mauvaise direction, l’application
signale l’erreur et offre simultanément une correction : la carte suit le déplacement dans
la » mauvaise » direction, puis repart dans la bonne. L’application honore l’intention de
l’utilisateur tout en redressant le cap.
Lorsque quelqu’un arrête d’interagir, c’est potentiellement le signe qu’il rencontre une
difficulté – ou du moins qu’il ne sait pas quoi faire ensuite. Dans l’application de livres
jeunesse The Fantastic Flying Books of Mr. Morris Lessmore, vous commencez la
navigation en ouvrant la couverture du livre d’un balayage (FIG 5.15). Si vous n’avez pas
ouvert le livre au bout de quelques secondes, une image animée apparaît et vous indique le
mouvement à effectuer. Les interfaces les plus didactiques surveillent votre activité, votre
inactivité et votre progrès général, et adaptent leurs instructions en conséquence. Ce qui
nous amène aux niveaux.

FIG 5.15 : Lorsqu’une pause indique la perplexité : si vous ne balayez pas l’écran pour ouvrir le livre sur le premier
écran, au bout de quelques secondes, une main fantomatique apparaît pour vous montrer ce que vous devez faire.

Niveaux
N’enseignez pas tout d’un coup. La théorie de l’éducation moderne recommande
d’apprendre par petites doses, de s’appuyer sur les bases et de dévoiler plus
d’informations à mesure que l’étudiant progresse. Les jeux font souvent ça littéralement,
en divisant l’avancement en niveaux explicites qui se focalisent sur une nouvelle
compétence. Bien que la plupart des applications et des sites web ne soient pas aussi
linéaires que les jeux, les courbes d’apprentissage sont similaires. Commencez par
enseigner les interactions de base au moment où les utilisateurs les rencontrent, avant
d’introduire des gestes plus complexes ou abstraits. (Laissez les gens utiliser ces gestes
avancés s’ils les découvrent par eux-mêmes. Le système de niveaux ne consiste pas à
retenir les informations, mais plutôt à décider du moment où vous les annoncerez.)
Nous sommes toujours plus motivés à apprendre une nouvelle compétence au moment
précis où nous en avons besoin – comme quand nous courons tête baissée vers un géant
terrifiant qui manie une énorme épée. Infinity Blade est un jeu sur iOS dont le système de
combat est incroyablement sophistiqué, mais facile à apprendre pas à pas, en détaillant
chaque élément. Alors que le géant s’apprête à vous passer dessus, le jeu gèle l’action et
démontre le geste que vous devez connaître pour survivre à la crise du moment (FIG 5.16).
FIG 5.16 : Une compétence à la fois : Infinity Blade met le jeu en pause à des moments bienvenus afin de former le
joueur à utiliser une compétence particulière. Une fois que vous avez maîtrisé la parade (en haut), vous êtes prêt à
apprendre l’esquive, etc.

Là encore, l’accent est mis sur la démonstration et la pratique. Le jeu vous montre le
geste ou le contrôle à utiliser puis attend votre réponse ; lorsque vous utilisez le nouveau
geste, l’action reprend… et votre première interaction est réussie. Lorsqu’une interaction
est suffisamment importante, il n’y a pas de mal à interrompre l’activité et à forcer
l’utilisateur à essayer le geste pour poursuivre.
Apple a employé cette approche lors du lancement d’OSX Lion, une mise à jour qui
changeait le fonctionnement du scrolling. Ils ont retourné la gravité virtuelle, de sorte que
la souris ou le pavé tactile fonctionnait dans le sens inverse du sens auquel les utilisateurs
de Mac avaient été habitués pendant des décennies. Pour apprendre ce geste, Apple
affichait une boîte de dialogue dès l’installation du logiciel afin d’expliquer la différence
et vous inviter à essayer le scroll. En fait, vous étiez obligé de scroller parce que c’était le
seul moyen de trouver le bouton Continuer. Faites défiler la page, cliquez sur le bouton et
BOUM : vous venez de battre le niveau un du système d’exploitation d’Apple.
Vous êtes maintenant prêt à l’essayer par vos propres moyens ; continuez à utiliser
votre nouvelle compétence dans le » niveau » actuel jusqu’à ce que vous rencontriez un
nouveau défi et que vous ayez besoin de nouvelles instructions. Pensez votre application
comme si elle comportait des niveaux. Vous devez motiver les utilisateurs et leur
permettre de passer les niveaux de difficulté, du mode novice jusqu’au mode expert.
Comment leur apprendre les bases puis, une fois que c’est fait, les manœuvres avancées ?
Trop souvent, nous traitons nos applications et nos sites web comme un niveau unique.
Nous faisons une brève introduction et nous lâchons nos utilisateurs dans la nature. En
adoptant un système de niveaux, vous accompagnez et instruisez les gens au fil du
parcours qui les mènera à la maîtrise. Et de temps en temps, vous devez les récompenser
pour leurs progrès.

Bonus
Dans les jeux vidéo, à mesure que vous progressez, vous gagnez des bonus, des petits
turbos qui vous confèrent plus de vitesse ou des capacités spéciales. Si les gestes sont les
raccourcis de l’interaction tactile, alors les bonus sont les raccourcis des jeux vidéo –
utilisables par tout le monde, mais surtout efficaces entre les mains des experts. Non
seulement les bonus débloquent de nouvelles capacités, mais ils sont également des
récompenses, marquant vos progrès à mesure que vous avancez dans les niveaux du jeu.
Enseigner un geste avancé ou abstrait s’apparente à offrir un bonus et donne aux
utilisateurs un sentiment de satisfaction similaire.
Lorsque Twitter a remanié son application pour iPhone vers la fin 2011, il a manqué
une occasion de révéler un geste abstrait. Le nouveau design avait déplacé l’accès aux
messages directs (DM) hors de la navigation principale, l’enterrant plus profondément
dans l’onglet Moi. Pour les utilisateurs qui se servaient beaucoup des DM, cela signifiait
deux taps à chaque fois qu’ils voulaient y accéder. Afin de leur faciliter la tâche, Twitter
avait généreusement ajouté un geste pour y accéder plus rapidement : balayer l’écran vers
le haut depuis l’onglet Moi pour aller directement à vos messages. Le problème, c’est que
personne n’avait été informé et que la plupart des gens ignoraient l’existence de l’option.
Il est judicieux de permettre aux gens d’apprendre la manière lente avant de leur
enseigner les raccourcis. Dans le cas de Twitter, apprendre à ouvrir l’onglet Moi puis à
toucher le bouton Messages directs renforçait le modèle mental de l’application,
enseignant aux gens où se trouvaient les DM. Mais après avoir effectué cette action cinq
ou dix fois, vous aviez démontré que vous aviez appris le chemin. Ce que l’interface aurait
dû faire à ce stade aurait été de dispenser un bonus – dévoiler le raccourci gestuel à l’aide
d’une démonstration animée, puis vous demander de reproduire le geste pour poursuivre
(FIG 5.17).
FIG 5.17 : Cette simple maquette montre comment Twitter aurait pu améliorer la découverte de son raccourci gestuel
permettant d’accéder aux messages directs. Après avoir appuyé sur le bouton DM dix fois, l’application aurait affiché un
message d’instruction avec une animation du geste à effectuer.
ON NE FAIT QUE COMMENCER
Le fait que nous ayons besoin d’enseigner les gestes indique seulement que nous n’avons
pas encore beaucoup de normes établies. Pour cette raison, c’est à la fois une époque
excitante et étourdissante pour les designers comme pour les consommateurs. En tant que
designers, nous devons échanger, examiner le travail des autres, partager des idées de
conventions gestuelles et nous engager à les codifier. Nous avons notre propre travail de
coaching et de mise à niveau à faire.
Notre travail est de plus en plus compliqué. Nous devons concevoir pour un tas de
plateformes et jongler entre une infinité de modes de saisie pour ce faire. Mais des défis
complexes cachent souvent des opportunités remarquables. Nous avons aujourd’hui la
chance d’inventer des façons plus humaines d’interagir avec les informations qui nous
entourent. C’est en partie le moment d’étudier et de raffiner notre savoir-faire technique
(44 pixels, les cibles tactiles !). Mais surtout, il est peut-être plus urgent de prendre du
recul vis-à-vis de nos bonnes pratiques obsolètes et de nous autoriser à imaginer des
possibilités innovantes sur ce support en voie de développement. Prenez le contrôle de vos
écrans tactiles, voyez grand, et concevez quelque chose d’extraordinaire.
RESSOURCES
Inspiration provenant du design industriel
Une grande partie de ce livre est axée sur les aspects physiques du design tactile,
établissant des liens avec les siècles de design industriel qui ont précédé l’écran. Les livres
suivants vous apporteront des bases solides s’inscrivant dans cette tradition.
• Designing for People, Henry Dreyfuss. Considéré comme le fondateur du design
industriel moderne, Dreyfuss a conçu le téléphone de Bell, le thermostat Honeywell,
l’aspirateur Hoover et d’autres grands classiques du XXe siècle. Son ouvrage de
référence paru en 1955 est toujours autant d’actualité.
• The Design of Everyday Things, Don Norman. Farce amusante et instructive sur le
design de notre environnement, ce livre essentiel étudie pourquoi le design de certains
objets physiques marche (et pourquoi d’autres, non).
• Designing Devices, Dan Saffer. Ce petit livre électronique explore les éléments qui
définissent les interfaces d’appareils bien conçus depuis les temps anciens.

Les facteurs humains et l’écran tactile

Le champ des facteurs humains vise à adapter les technologies aux capacités et aux limites
du corps humain. Cela peut se résumer à une question de confort – concevoir des
interfaces qui sont physiquement et cognitivement faciles à maîtriser. Ces ressources
traitent des facteurs humains vis-à-vis des écrans tactiles.
• « Multi-touch Systems That I Have Known and Loved », Bill Buxton. Un
merveilleux traité sur le bon et le mauvais design tactile écrit spontanément par un
précurseur de l’UX qui a également coinventé l’écran tactile capacitif
(http://bkaprt.com/dft/06-01/).
• « How Do Users Really Hold Mobile Devices ? », Steven Hoober. Se penche sur
l’ergonomie et la précision de diverses prises en main de smartphones
(http://bkaprt.com/dft/01-03/).
• « Making Learning Usable: How We Use Mobile Devices », Steven Hoober et Patti
Shank. Développe l’étude précédente de Hoober pour l’appliquer aux tablettes et aux
phablettes (http://bkaprt.com/dft/01-07/).
• « Designing for a Thumb: An Ideal Mobile Touchscreen Interface for Chinese
Users », Qian Fei. Une analyse méticuleuse de la précision des pouces sur les écrans
tactiles des mobiles, qui a proposé la zone en forme d’éventail sur les smartphones
(http://bkaprt.com/dft/01-04/).
• « User Learning and Performance with Marking Menus », Gordon Kurtenbach et
Bill Buxton. S’intéresse au gain de temps exceptionnel des menus circulaires par
rapport aux menus linéaires traditionnels sur les écrans tactiles
(http://bkaprt.com/dft/04-05/).

Directives de design par plateforme

Chaque plateforme a ses propres règles. Explorez les directives de design pour les
systèmes d’exploitation tactiles les plus populaires.
• iOS Human Interface Guidelines. La philosophie d’une bonne expérience sur iPhone
et iPad par Apple, allant des principes de design généraux à l’usage détaillé de chaque
contrôle (http://bkaprt.com/dft/06-02/).
• Material Design. Le langage visuel qu’utilise Google sur toutes les plateformes, y
compris Android ; ce site explique sa philosophie et les détails de sa mise en œuvre
(http://bkaprt.com/dft/06-03/).
• Windows Design. Directives pour créer des applications pour Windows 10 sur des
appareils allant du téléphone à l’ordinateur à écran géant (http://bkaprt.com/dft/06-04/).

Directives pour smartwatch

Les directives de design tactile générales de ce livre s’appliquent également à la
nouvelle cuvée de smartwatches, mais avec quelques contraintes supplémentaires. Apple
et Google donnent chacun leurs propres conseils.
• Apple Watch Human Interface Guidelines (http://bkaprt.com/dft/06-05/)
• Android Wear (http://bkaprt.com/dft/06-06/)

Coder des gestes pour le web

• « Multi-touch Web Developement », Boris Smus. Présente les techniques (et les
pièges) de la programmation de gestes avec des événements tactiles
(http://bkaprt.com/dft/04-11/).
• « Touch and Mouse », Chris Wilson et Paul Kinlan. Comment coder des interactions
qui marchent bien avec les interfaces tactiles et les interfaces à curseur
(http://bkaprt.com/dft/06-07/) ?
• « Unifying Touch and Mouse: How Pointer Events Will Make Cross-Browsers
Touch Support Easy », David Rousset. Coder des événements de pointeur pour une
intercompatibilité optimale entre les navigateurs (http://bkaprt.com/dft/06-08/).
Une poignée de bibliothèques JavaScript vous aideront à réduire les souffrances de la
programmation de gestes pour le web en éliminant les divergences entre les événements
de souris, d’écran tactile et de pointeur.
• Hammer.js. Détecte plusieurs gestes dans les navigateurs modernes (y compris IE
9+) : tap, double tap, pression longue, balayage, pincement et rotation
(http://bkaprt.com/dft/06-09/).
• Hand.js. Une bibliothèque de polyfills de Microsoft qui vous permet d’utiliser des
événements de pointeur dans tous les navigateurs (http://bkaprt.com/dft/04-16/).
• Tappy, de Scott Jehl du Filament Group. Pallie les différences entre les événements
click sur écran tactile, souris et clavier en créant un seul événement tap qui fonctionne
pour les trois (http://bkaprt.com/dft/04-14/).
Outils de notation tactiles
L’encre et le papier sont mes meilleurs outils de planification. Je commence toujours par
là, en griffonnant mes idées à la main, puis je passe à des esquisses d’écrans et de widgets.
Cette boîte à outils présente cependant un gros inconvénient : elle ne bouge pas. Cela rend
difficile l’illustration de gestes en mouvement. Quelques petits malins sont toutefois venus
à mon aide en proposant des notations détaillées pour représenter les gestes tactiles :
• « Touch Notation », Matt Gemmell. Un système simple permettant de représenter des
gestes complexes (http://bkaprt.com/dft/06-10/).
• Cue, P.J. Onori. Un ensemble d’icônes de gestes compactes disponibles au format
SVG, PNG, OmniGraffle et InDesign, à utiliser dans vos wireframes et autres
documents (http://bkaprt.com/dft/06-11/).
• Pochoirs de gestes tactiles, Dan Saffer et RachelGlves. Un jeu de dessins de mains
effectuant des gestes courants, disponible dans de nombreux formats numériques. Ces
pochoirs offrent des représentations claires et littérales de chaque geste
(http://bkaprt.com/dft/06-12/).
REMERCIEMENTS
Ça me chagrine de me retrouver seul sur la couverture de ce livre alors que tant de gens y
ont contribué. Je remercie tout spécialement ma partenaire dans ce fandango, ma
merveilleuse éditrice Tina Lee, qui a révélé le livre tapi dans une masse d’idées. Elle a
démêlé ma prose, m’a aidé à trouver mon chemin quand j’étais perdu et à fait taire une
flopée de tics d’écriture dont je n’avais même pas remarqué l’existence. Comme Tina,
Katel LeDû de A Book Apart m’a patiemment aidé à rester sur la bonne voie, d’une main
parfois sévère mais souvent généreuse en high fives.
Merci à Mandy Brown de m’avoir incité à écrire ce livre, à Jeffrey Zeldman de m’avoir
poussé à persévérer et à Jason Santa Maria et Rob Weychert de lui avoir donné un look
d’enfer. Merci à Caren Litherland, véritable sniper de la ponctuation errante et de la
grammaire maladroite.
Les idées de ce livre ont été développées et testées au cours du design de nombreux
sites web et applications. Des notions vagues sont devenues des principes de design
parfaitement clairs grâce aux nerfs d’acier de mes collaborateurs, qui confirment la règle
selon laquelle vous avez toujours intérêt à travailler avec des gens plus intelligents que
vous. Parmi eux, un merci tout particulier à mon acolyte Brad Frost, qui a également
rédigé l’avant-propos de ce livre (s’appropriant ainsi plusieurs jeux de mots tactiles avant
que je n’aie le temps de m’en servir). Merci à mes complices Dan Mall, Jennifer Brook,
TJ Pitre, Jonathan Stark, Ethan Marcotte, Kevin Hoffman, Melissa Frost, Kelli Shaver,
Robert Gorell, Robert Jolly et Kristina Frantz. Merci également à mes clients, qui ont
accepté de repousser les limites avec nous et d’essayer de nouvelles techniques. Je pense
notamment à Abby McInerney, Teri Everett et David Fine de Time Inc. ; Sara Winge et
Edie Freedman d’O’Reilly Media ; Chad Schlegel et Bill Gannon d’Entertainment
Weekly ; Tony Brancato de People Magazine ; Ned Desmond et Christine Ying de
TechCrunch ; Cathy Ferrara de Scholastic ; et Samantha Katz, Joel Smernoff et Peter
Meyers de Citia.
J’ai la chance de compter parmi mes amis des gens que je considère aussi comme des
héros. Il m’arrive souvent de me pincer quand je vois en quelle compagnie je me trouve,
d’autant plus qu’ils sont tous si généreux avec leurs idées et leurs suggestions. Mon
compagnon de route Luke Wroblewski ne cesse de m’apprendre des choses sur les
mobiles, particulièrement le soir autour d’un verre ou deux. C’est également lui qui a
organisé l’équipe de Mobilewood, dont l’influence et l’innovation se reflètent à travers
tout ce livre. Merci aux cerveaux de Mobilewood, j’ai nommé Brad Frost (à nouveau),
Lyza Danger Gardner, Jason Grigsby, Scott Jehl, Scott Jenson, Tim Kadlec, Jeremy Keith,
Brian LeRoux, Bryan Rieger, Stephanie Rieger et Andrea Trasatti. Merci à mon équipe de
Providence : Jennifer Robbins, Jason Pamental, Bil Herron et Coryndon Luxmoore d’avoir
confronté mes premières idées sur le design tactile à la réalité. Je suis reconnaissant de
mes longues conversations avec mes brillants amis Rachel Hinman, David VanEsselstyn,
Carla Diana, Rusty Mitchell, Loren Brichter, John Gruber et mon partenaire de hacking (et
chéri de Brooklyn), Larry Legend. Merci également à Bill Buxton pour ses mots
d’encouragement, ainsi qu’à Steven Hoober et Patti Shank pour leurs efforts de recherche
inlassables en matière de design mobile.
 Mon courage est renouvelé chaque jour par l’enthousiasme et la créativité de mes
compagnons de studio à Brooklyn. Merci à vous tous, et particulièrement à la Suissesse
Tiny Roth Eisenberg d’avoir créé une communauté si remarquable chez Friends, ainsi qu’à
Jessi Arrington et Creighton Mershon d’apporter tant d’esprit (et de couleur !) chez
Studiomates.
Pour finir, je suis infiniment reconnaissant envers les deux amours de ma vie : ma
femme Liza, et notre fille, Nika. L’optimisme et l’émerveillement inépuisables de Nika ne
cessent de recharger les miens, et son usage perpétuellement inventif des téléphones et des
tablettes me rappellent que nous n’avons fait qu’effleurer la question de l’interaction avec
les informations – et entre nous. Et bon sang, Liza, grâce à toi, tout est possible. Chaque
jour, tu m’apprends de nouvelles choses, tu me pousses à me dépasser, tu m’encourages, tu
me réjouis. Tu m’aides à être le meilleur Josh Clark que je puisse être, et tu as
certainement fait de moi l’homme le plus chanceux du monde. Merci de partager cette vie
magnifique avec moi.
RÉFÉRENCES
Introduction
00-01 http://www.pewinternet.org/2015/04/01/us-smartphone-use-in-2015
00-02 http://www.cnbc.com/id/39501308
00-03 http://pewinternet.org/Reports/2014/E-Reading-Update/Tablet-and-Ereader-Ownership/Half-of-American-
adults-now-own-a-tablet-or-ereader.aspx
00-04 http://www.asymco.com/2012/02/16/ios-devices-in-2011-vs-macs-sold-it-in-28-years

Chapitre 1
01-01 https://archive.org/details/bstj39-4-995
01-02 http://www.tecmark.co.uk/smartphone-usage-data-uk-2014/
01-03 http://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php
01-04 http://link.springer.com/chapter/10.1007/978-3-642-39241-2_6
01-05
http://www.cmo.com/content/dam/CMO_Other/ADI/ADI_Mobile_Report_2014/2014_US_Mobile_Benchmark_Rep
01-06 http://samsungtomorrow.com/사용자의-눈과-손에-딱-맞는-대화면-갤럭시-w-출시
01-07 http://www.elearningguild.com/research/archives/index.cfm?id=174&action=viewonly
01-08 http://www.sfgate.com/news/article/Steve-Jobs-Touchscreen-Laptops-Don-t-Work-AAPL-2477126.php
01-09 http://www.intelfreepress.com/news/do-people-want-touch-on-laptop-screens/
01-10 http://www.sciencedirect.com/science/article/pii/S1057740813000934
01-11 http://www.slideshare.net/uxpa-dc/the-hybrids-are-coming-john-whalen
01-12 https://www.flickr.com/photos/intelfreepress/6837427202
01-13 https://www.flickr.com/photos/intelfreepress/6983554875
01-14 http://www.abookapart.com/products/mobile-first
01-15 http://thesession.org
01-16 http://www.google.com/design/spec/components/buttons.html#buttons-floating-action-button
01-17 https://www.flickr.com/photos/janitors/10065590424
01-18 http://www.apple.com/

Chapitre 2
02-01 http://dev.w3.org/csswg/mediaqueries-4/#pointer
02-02 https://www.usertesting.com
02-03 http://www.w3.org/WAI/GL/css2em.htm
02-04 http://mobile-ux.appspot.com/#8
02-05 http://go.microsoft.com/fwlink/p/?linkid=242592
02-06 https://msdn.microsoft.com/en-us/library/windows/desktop/Dn742468(v=VS.85).aspx
02-07 https://instagram.com/p/q89q9djBkq/

Chapitre 3
03-01 http://www.mcwade.com/DesignTalk/2013/09/flat-is-cool-but-be-consistent
03-02 http://www.lukew.com/ff/entry.asp?1569
 03-03 http://erikrunyon.com/2013/01/carousel-stats/
03-04 http://www.nngroup.com/articles/auto-forwarding/
03-05 http://yorkwebteam.blogspot.com/2013/03/are-homepage-carousels-effective-aka.html
03-06 http://shouldiuseacarousel.com
03-07 http://www.statista.com/statistics/232285/reasons-for-online-shopping-cart-abandonment
03-08 http://blog.hubspot.com/blog/tabid/6307/bid/6746/Which-Types-of-Form-Fields-Lower-Landing-Page-
Conversions.aspx
03-09 http://zdfs.github.io/toscani/paymentInfo
03-10 http://blogs.forrester.com/michael_ogrady/12-06-19-
sms_usage_remains_strong_in_the_us_6_billion_sms_messages_are_sent_each_day
03-11 http://www.pewinternet.org/2012/03/19/teens-smartphones-texting
03-12 http://leaverou.github.io/awesomplete/
03-13 https://github.com/miketaylr/jquery.datalist.js
03-14 http://www.wsj.com/articles/SB10001424127887323566804578549351972660468
03-15 http://bits.blogs.nytimes.com/2013/09/29/disruptions-guided-by-touch-screens-blind-turn-to-smartphones-
for-sight
03-16 https://www.youtube.com/watch?v=h2OfQdYrHRs
03-17 http://www.w3.org/TR/webaudio
03-18 http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html
03-19 http://www.w3.org/TR/geolocation-API
03-20 http://w3c.github.io/deviceorientation/spec-source-orientation.html
03-21 http://www.w3.org/TR/ambient-light

Chapitre 4
04-01 https://www.flickr.com/photos/jking89/4572668303
04-02 https://www.flickr.com/photos/blackcountrymuseums/4385115536
04-03 http://www.chicagomanualofstyle.org/tools_proof.html
04-04 http://www.donhopkins.com/drupal/node/100
04-05 http://www.billbuxton.com/MMUserLearn.html
04-06 http://tikku.com/jquery-radmenu-plugin
04-07 http://lab.victorcoulon.fr/css/path-menu
04-08 https://github.com/filamentgroup/Overthrow
04-09 https://drafts.csswg.org/css-snappoints/
04-10 http://www.w3.org/TR/touch-events/
04-11 http://www.html5rocks.com/en/mobile/touch
04-12 https://msdn.microsoft.com/en-us/library/windows/apps/Hh767313.aspx
04-13 https://github.com/ftlabs/fastclick
04-14 https://github.com/filamentgroup/tappy
04-15 http://www.w3.org/TR/pointerevents/
04-16 http://handjs.codeplex.com
04-17 https://msdn.microsoft.com/library/dn433244.aspx

Ressources
06-01 http://www.billbuxton.com/multitouchOverview.html
06-02 https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG
06-03 https://www.google.com/design/spec/material-design/introduction.html
06-04 https://dev.windows.com/en-us/design
06-06 https://developer.apple.com/watch/human-interface-guidelines
06-07 http://www.html5rocks.com/en/mobile/touchandmouse
06-08 http://blogs.msdn.com/b/davrous/archive/2015/08/10/handling-touch-in-your-html5-apps-thanks-to-the-
pointer-events-of-ie10-and-windows-8.aspx
06-09 http://hammerjs.github.io
06-10 http://mattgemmell.com/touch-notation
06-11 http://somerandomdude.com/work/cue
06-12 http://www.kickerstudio.com/2008/12/touchscreen-stencils
INDEX
A
Adobe Comp 129, 130
Android 32, 41
API Web
Audio 108
Speech 108

B
barre d’action scindée 42
barre d’outils fixe 37
bibliothèque Awesomplete 103
boîtes de dialogue de confirmation 105
bouton 116, 118, 120
de déclenchement flottant 43
stepper 103
bras de gorille 23
Buxton, Bill 141

C
capteurs 107
carrousels 87
cartes 124
champs de formulaire 92
Chicago Manual of Style 129
claviers 99
Clear (application) 131
coder des événements tactiles 143
contrôles de rebord 53, 61

D
démonstrations 172
design
iOS 7 166
skeuomorphique 162
device-width 75
dévoilement progressif 81
directives de design
d’Android 34, 45
de Microsoft 72
données linéaires 91
double tap 115

E
emplacement des cibles tactiles 68
ems 70
Entertainment Weekly 88
espacement des cibles tactiles 72
événements de pointeur 156

F
Facebook Paper 174
fatigue 116
Fei, Qian 16
fonction Reachability 46
Forrest, Zachary 96

G
gestes
dans les navigateurs Web 143
de rebord 136
grossiers 116
multidoigts 133
glisser-déposer 113
Google Translate 107

H
Hoober, Steven 14, 19, 21, 62, 69

I
Instagram (application) 32, 83
Intel 23
interaction prédictive 83

J
Jehl, Scott 183
jiu-jitsu gestuel 105
Jobs, Steve 23

K
Kurtenbach, Gordon 141

L
Layar 107
lois physiques 130
LookTel Money Reader 107

M
McLuhan, Marshall 123
McWade, John 78
media queries CSS4 58
media query pointer 58
mémoire musculaire 117
menus
circulaires 138
déroulants 101
métaphores physiques 168
mise en page
hors canvas 85
pour ordinateurs portables et hybrides 51
pour phablettes 41
pour tablettes 48
pour téléphones 30
mode à une main 46

N
New York Times 74
Norman, Don 122
norme W3C pour les événements de pointeur 156

O
objets de données 150

P
phablettes 17
pincement et étirement 113
pixels virtuels 73
pression longue 112
prise en charge des événements tactiles, détecter 153
prise en main 14

Q
qualité des interactions 82

R
remplissage automatique 97
rems 71

S
Safari 35
scrolling 84
sélecteur de date 99
Shank, Patti 19, 21, 62, 69
Smus, Boris 151
survol 63
Swarm (application) 32
swipe 111
Sydney Morning Herald 168

T
taille des cibles tactiles 69
tap 111
sans délai 154
Taylor, Mike 103
téléphone
à clavier 11
Bell 11
The Daily 49
The Session 39
TouchUp 132
tutoriels 172

U
Uzu (application) 133

V
Verou, Lea 103
viewport dynamique 74

W
W3C 74
Whalen, John 24
Windows 8 23
Wroblewski, Luke 38

Z
zone du pouce 16
zoom 113, 115
sémantique 113
À PROPOS DE A BOOK APART
Nous couvrons les sujets émergents et essentiels du design et du développement web avec
style, clarté et surtout brièveté – car les professionnels du design et du développement
n’ont pas de temps à perdre !
À PROPOS DE L’AUTEUR

Josh Clark est le fondateur de Big Medium, agence de design spécialisée dans les objets
connectés, l’expérience mobile et le responsive web design, et qui offre ses services aux
entreprises les plus innovantes. Josh a écrit quatre autres livres, notamment Tapworthy:
Designing Great iPhone Apps (O’Reilly, 2010), et donne des conférences sur le futur des
interfaces numériques dans le monde entier. En 1996, Josh a créé un type d’interface
utilisateur unique : le programme d’entraînement Couch-to-5K (C25K), qui a aidé des
millions d’allergiques au sport à se mettre au jogging. (Sa devise est la même pour le
fitness que pour l’UX : no pain, no pain.)
Pour suivre toutes les nouveautés numériques du Groupe Eyrolles, retrouvez-nous sur Twitter et Facebook

@ebookEyrolles

EbooksEyrolles
Et retrouvez toutes les nouveautés papier sur

@Eyrolles

Eyrolles