À nouveau ensemble pour la première fois
Introduction
Depuis près de 30 ans, l'expérience de l'informatique de bureau est axée sur le clavier et la souris ou le pavé tactile comme principaux périphériques d'entrée pour les utilisateurs. Toutefois, ces dix dernières années, les smartphones et les tablettes ont introduit un nouveau paradigme d'interaction: le toucher. Avec le lancement des machines Windows 8 à écran tactile, et avec le lancement de l'incroyable Chromebook Pixel à écran tactile, l'écran tactile fait désormais partie de l'expérience de bureau attendue. L'un des plus grands défis consiste à créer des expériences qui fonctionnent non seulement sur les appareils tactiles et les souris, mais aussi sur les appareils sur lesquels l'utilisateur peut utiliser les deux modes de saisie, parfois simultanément.
Cet article vous explique comment les fonctionnalités tactiles sont intégrées au navigateur, comment vous pouvez intégrer ce nouveau mécanisme d'interface dans vos applications existantes et comment utiliser la saisie tactile avec la souris.
L'état du toucher sur la plate-forme Web
L'iPhone a été la première plate-forme populaire à intégrer des API tactiles dédiées dans le navigateur Web. Plusieurs autres fournisseurs de navigateurs ont créé des interfaces d'API similaires, conçues pour être compatibles avec l'implémentation iOS, désormais décrite dans la spécification "Événements tactiles version 1". Les événements tactiles sont compatibles avec Chrome et Firefox sur ordinateur, et avec Safari sur iOS et Chrome et le navigateur Android sur Android, ainsi qu'avec d'autres navigateurs mobiles tels que le navigateur BlackBerry.
Mon collègue Boris Smus a écrit un excellent tutoriel HTML5Rocks sur les événements tactiles. Il constitue un bon point de départ si vous ne vous êtes encore jamais intéressé aux événements tactiles. Si vous n'avez jamais travaillé avec des événements tactiles, lisez cet article avant de continuer. Allez, j'attends.
Vous avez terminé ? Maintenant que vous maîtrisez les événements tactiles, sachez que les interactions tactiles peuvent être légèrement différentes de celles avec la souris (et le pavé tactile qui émule la souris et le trackball). Bien que les interfaces tactiles tentent généralement d'émuler la souris, l'émulation n'est ni parfaite, ni complète. Vous devez vraiment utiliser les deux styles d'interaction et les gérer indépendamment les uns des autres.
Point important à ne pas oublier: l'utilisateur peut avoir toucher et avoir une souris
De nombreux développeurs ont créé des sites qui détectent de manière statique si un environnement prend en charge les événements tactiles, puis partent du principe qu'ils doivent uniquement prendre en charge les événements tactiles (et non ceux de la souris). Il s'agit désormais d'une hypothèse erronée : ce n'est pas parce que des événements tactiles sont présents que l'utilisateur utilise principalement ce périphérique de saisie tactile. Certains appareils, comme le Chromebook Pixel et certains ordinateurs portables Windows 8, sont désormais compatibles avec les modes de saisie "Souris" et "Tactile", et d'autres le seront bientôt. Sur ces appareils, il est assez naturel que les utilisateurs se servent à la fois de la souris et de l'écran tactile pour interagir avec les applications. Par conséquent, "compatible avec les commandes tactiles" n'est pas la même que "n'a pas besoin de la souris". Vous ne pouvez pas considérer le problème comme « Je dois écrire deux styles d'interaction différents et basculer entre eux », vous devez réfléchir à la façon dont les deux interactions vont fonctionner ensemble et indépendamment. Sur mon Chromebook Pixel, j'utilise souvent le pavé tactile, mais j'appuie aussi vers le haut et j'appuie sur l'écran. Sur la même application ou sur la même page, je fais ce qui me semble le plus naturel à ce moment-là. En revanche, certains utilisateurs d'ordinateurs portables à écran tactile n'utilisent que rarement, voire jamais, l'écran tactile. Par conséquent, la présence de la saisie tactile ne devrait pas désactiver ni gêner le contrôle de la souris.
Malheureusement, il peut être difficile de savoir si l'environnement de navigateur d'un utilisateur est compatible avec la saisie tactile. Idéalement, un navigateur sur un ordinateur de bureau indiquerait toujours la compatibilité avec les événements tactiles afin qu'un écran tactile puisse être connecté à tout moment (par exemple, si un écran tactile connecté via un KVM devient disponible). Pour toutes ces raisons, vos applications ne doivent pas tenter de basculer entre l'écran tactile et la souris : elles sont simplement compatibles avec les deux.
Soutenir conjointement la souris et le toucher
1 – Clic et appui : l'ordre "naturel" des choses
Le premier problème est que les interfaces tactiles tentent généralement d'émuler les clics de souris, évidemment, car elles doivent fonctionner sur les applications qui n'ont interagi qu'avec des événements de souris auparavant. Vous pouvez l'utiliser comme raccourci, car les événements de type "clic" continueront d'être déclenchés, que l'utilisateur clique avec la souris ou appuie sur l'écran. Ce raccourci pose toutefois quelques problèmes.
Tout d'abord, vous devez être prudent lorsque vous concevez des interactions tactiles plus avancées: lorsque l'utilisateur utilise une souris, il répond par un événement de clic, mais lorsqu'il touche l'écran, des événements tactiles et des événements de clic se produisent. Pour un clic simple, les événements sont organisés dans l'ordre suivant:
- CANNOT TRANSLATE
- Touchmove
- Touchend
- survol avec la souris
- mousemove
- souris
- souris
- click
Autrement dit, si vous traitez des événements tactiles tels que "touchstart", vous devez vous assurer de ne pas traiter également l'événement de clic et/ou de survol correspondant. Si vous pouvez annuler les événements tactiles (appel preventDefault() dans le gestionnaire d'événements), aucun événement de souris n'est généré pour l'appui. L'une des règles les plus importantes pour les gestionnaires tactiles est la suivante:
Toutefois, cela empêche également d'autres comportements par défaut du navigateur (comme le défilement). En règle générale, vous gérez entièrement l'événement tactile dans votre gestionnaire, et vous VOULEZ désactiver les actions par défaut. En général, il est préférable de gérer et d'annuler tous les événements tactiles, ou d'éviter d'avoir un gestionnaire pour ces événements.
Deuxièmement, lorsqu'un utilisateur appuie sur un élément d'une page Web sur un appareil mobile, les pages qui n'ont pas été conçues pour l'interaction mobile présentent un délai d'au moins 300 millisecondes entre l'événement "touchstart" et le traitement des événements de la souris (mousedown). Pour ce faire, vous pouvez utiliser Chrome. Vous pouvez activer l'option Émuler les événements tactiles dans les outils pour les développeurs Chrome afin de tester les interfaces tactiles sur un système non tactile.
Ce délai permet au navigateur de déterminer si l'utilisateur effectue un autre geste, en particulier s'il s'agit d'un double appui. Évidemment, cela peut être problématique si vous souhaitez obtenir une réponse instantanée à un contact du doigt. Des tâches sont en cours pour essayer de limiter les scénarios dans lesquels ce retard se produit automatiquement.
La première façon, et la plus simple, d'éviter ce délai, consiste à "indiquer" au navigateur mobile que vous n'aurez pas besoin de zoomer sur votre page. Pour ce faire, utilisez une fenêtre d'affichage fixe, par exemple en l'insérant dans votre page:
<meta name="viewport" content="width=device-width,user-scalable=no">
Bien entendu, ce n'est pas toujours approprié. Cela permet de désactiver le zoom par pincement, qui peut être requis pour des raisons d'accessibilité. Par conséquent, utilisez-le avec parcimonie, voire pas du tout (si vous désactivez la mise à l'échelle utilisateur, il peut être utile de fournir un autre moyen d'améliorer la lisibilité du texte dans votre application). De plus, ce délai ne s'applique pas dans Chrome sur les appareils de bureau compatibles avec l'écran tactile, ainsi que dans les autres navigateurs des plates-formes mobiles lorsque la page comporte des fenêtres d'affichage non évolutives.
Raison 2: Les événements de mouvements avec la souris ne sont pas déclenchés par commande tactile
À ce stade, il est important de noter que l'émulation des événements de souris dans une interface tactile ne s'étend généralement pas à l'émulation des événements de déplacement de la souris. Par conséquent, si vous créez une commande de déplacement de la souris qui utilise des événements de mouvement de souris, elle ne fonctionnera probablement pas avec un appareil tactile, sauf si vous ajoutez spécifiquement des gestionnaires tactiles.
Généralement, les navigateurs implémentent automatiquement l'interaction appropriée pour les interactions tactiles sur les commandes HTML. Par exemple, les commandes HTML5 Range ne fonctionnent que lorsque vous utilisez des interactions tactiles. Toutefois, si vous avez implémenté vos propres commandes, elles ne fonctionneront probablement pas sur les interactions de type clic-glisser. En fait, certaines bibliothèques couramment utilisées (telles que jQueryUI) ne prennent pas encore en charge les interactions tactiles de cette manière (bien que pour jQueryUI, plusieurs correctifs de monkey-patch existent pour ce problème). C'est l'un des premiers problèmes que j'ai rencontrés lors de la mise à niveau de mon application Web Audio Playground pour l'écran tactile. Les curseurs étant basés sur jQueryUI, ils ne fonctionnaient pas avec les interactions cliquer-glisser. J'ai opté pour les commandes de plage HTML5 et ça a marché. Ou bien, j'aurais pu simplement ajouter des gestionnaires touchmove pour mettre à jour les curseurs, mais cela pose problème...
Raison 3: Les commandes tactiles et les mouvements de souris ne sont pas la même chose
L'un des pièges dans lesquels j'ai vu quelques développeurs sont tombés est de faire en sorte que les gestionnaires "touchmove" et "mousemove" appellent dans les mêmes chemins de code. Le comportement de ces événements est très proche, mais légèrement différent. En particulier, les événements tactiles ciblent toujours l'élément à l'endroit où l'utilisateur appuie sur DÉMARRÉ, tandis que les événements de souris ciblent l'élément qui se trouve actuellement sous le curseur de la souris. C'est pourquoi il existe des événements de survol et de sortie de la souris, mais il n'y a pas d'événements de toucher et de contact correspondants, seulement le toucher.
La manière la plus courante de mordre est si vous supprimez (ou déplacez) l'élément que l'utilisateur a commencé à toucher. Par exemple, imaginez un carrousel d'images avec un gestionnaire tactile sur l'ensemble du carrousel afin de prendre en charge un comportement de défilement personnalisé. À mesure que les images disponibles changent, supprimez certains éléments <img> et ajoutez-en d'autres. Si l'utilisateur commence à appuyer sur l'une de ces images, puis que vous la supprimez, votre gestionnaire (qui se trouve sur un ancêtre de l'élément img) cessera simplement de recevoir des événements tactiles (car ils sont envoyés vers une cible qui n'est plus dans l'arborescence). L'utilisateur aura l'impression que l'utilisateur tient le doigt à un endroit, même s'il a peut-être déplacé et finalement supprimé l'image.
Vous pouvez bien sûr éviter ce problème en évitant de supprimer les éléments qui possèdent (ou ont des ancêtres qui disposent) de gestionnaires tactiles alors qu'un écran tactile est actif. Il est également préférable d'enregistrer des gestionnaires touchstart/touchmove statiques, d'attendre d'avoir reçu un événement touchstart, puis d'ajouter les gestionnaires touchmove/touchend/touchcancel à la target de l'événement touchstart (et de les supprimer à la fin ou à l'annulation). Ainsi, vous continuerez à recevoir des événements pour les actions tactiles, même si l'élément cible est déplacé ou supprimé. Vous pouvez jouer sur cette page. Appuyez sur le cadre rouge tout en appuyant sur la touche Échap pour la supprimer du DOM.
N° 4 : Saisie tactile et pointage
La métaphore du pointeur de la souris séparait la position du curseur de la sélection active, ce qui permettait aux développeurs d'utiliser les états de survol pour masquer et afficher des informations susceptibles d'être pertinentes pour les utilisateurs. Cependant, à l'heure actuelle, la plupart des interfaces tactiles ne détectent pas qu'un doigt passe la souris sur une cible. Par conséquent, fournir des informations sémantiquement importantes (par exemple, une fenêtre pop-up "Qu'est-ce que cette commande ?") en passant la souris est interdite, sauf si vous proposez également un moyen tactile d'accéder à ces informations. Vous devez faire attention à la façon dont vous utilisez le survol pour transmettre des informations aux utilisateurs.
Il est intéressant de noter que, dans certains cas, la pseudo-classe CSS :hover PEUT être déclenchée par des interfaces tactiles. Le fait d'appuyer sur un élément rend l'action :active lorsque le doigt est baissé et elle acquiert également l'état :hover. (Dans Internet Explorer, l'indication :pointage s'applique uniquement lorsque le doigt de l'utilisateur est baissé, tandis que d'autres navigateurs la maintiennent activé jusqu'au prochain clic ou déplacement de la souris.) Il s'agit d'une bonne approche pour faire fonctionner les menus pop-up sur les interfaces tactiles. L'activation d'un élément présente un effet secondaire : l'état :hover est également appliqué. Exemple :
<style>
img ~ .content {
display:none;
}
img:hover ~ .content {
display:block;
}
</style>
<img src="/awesome.png">
<div class="content">This is an awesome picture of me</div>
Lorsqu'un utilisateur appuie sur un autre élément, celui-ci n'est plus actif et l'état de survol disparaît, comme si l'utilisateur avait déplacé le pointeur de la souris hors de l'élément. Vous pouvez encapsuler le contenu dans un élément <a> afin d'en faire également un tabstop. Ainsi, l'utilisateur peut activer/désactiver les informations supplémentaires lors d'un survol ou d'un clic de souris, d'une pression tactile ou d'une pression sur une touche, sans avoir besoin de JavaScript. J'ai été agréablement surpris lorsque j'ai commencé à faire en sorte que mon Web Audio Playground fonctionne bien avec les interfaces tactiles que mes menus contextuels fonctionnaient déjà bien, car j'avais utilisé ce type de structure.
La méthode ci-dessus fonctionne bien pour les interfaces basées sur le pointeur de la souris, ainsi que pour les interfaces tactiles. Cela diffère de l'utilisation d'attributs "titre" lors du survol de la souris, qui ne s'affichent PAS lorsque l'élément est activé:
<img src="/awesome.png" title="this doesn't show up in touch">
N° 5: Précision du toucher et de la souris
Bien que les souris présentent une dissociation conceptuelle de la réalité, il s'avère qu'elles sont extrêmement précises, car le système d'exploitation sous-jacent suit généralement la précision exacte des pixels pour le curseur. D'autre part, les développeurs d'applications mobiles ont découvert que toucher les doigts sur un écran tactile n'était pas aussi précis, principalement en raison de la taille de la surface du doigt lorsqu'il est en contact avec l'écran (et en partie parce que les doigts masquent l'écran).
De nombreux individus et entreprises ont effectué des recherches approfondies sur l'expérience utilisateur pour concevoir des applications et des sites qui s'adaptent à l'interaction des doigts. De nombreux ouvrages ont été rédigés sur ce sujet. Le conseil de base est d'augmenter la taille des zones cibles tactiles en augmentant la marge intérieure et de réduire le risque d'appuis incorrects en augmentant la marge entre les éléments. Les marges ne sont pas incluses dans le traitement de la détection des appels des événements tactiles et de clic, contrairement aux marges. L'une des principales corrections que j'ai apportées à Web Audio Playground a été d'augmenter la taille des points de connexion afin qu'ils soient plus faciles à toucher avec précision.
De nombreux fournisseurs de navigateurs qui gèrent des interfaces tactiles ont également introduit une logique dans le navigateur pour aider à cibler l'élément approprié lorsqu'un utilisateur touche l'écran et réduire le risque de clics incorrects. Bien que cela ne corrige généralement que les événements de clic, pas les mouvements (bien qu'Internet Explorer semble également modifier les événements de type "mousedown", "mousemove" ou "mouseup").
N° 6: Limitez le contenu des gestionnaires tactiles pour éviter les à-coups
Il est également important de limiter les gestionnaires tactiles aux éléments là où vous en avez besoin. Les éléments tactiles peuvent avoir une bande passante très élevée. Il est donc important d'éviter les gestionnaires tactiles sur les éléments de défilement (car votre traitement peut interférer avec les optimisations du navigateur pour un défilement tactile rapide sans à-coups. Les navigateurs récents essaient de faire défiler un thread GPU, mais cela est impossible s'ils doivent d'abord vérifier avec JavaScript pour voir si chaque événement tactile est géré par l'application). Vous pouvez consulter un exemple de ce comportement.
Pour éviter ce problème, vous devez vous assurer que si vous ne gérez des événements tactiles que dans une petite partie de votre interface utilisateur, vous n'y associez que des gestionnaires tactiles (pas, par exemple, sur la <body> de la page). Pour résumer, limitez autant que possible le champ d'application de vos gestionnaires tactiles.
N° 7: Technologie multipoint
Le dernier défi intéressant est que, même si nous l'appelons "interface utilisateur tactile", la prise en charge presque universelle est en fait pour l'écran tactile multipoint. En d'autres termes, les API fournissent plusieurs entrées tactiles à la fois. Lorsque vous commencez à prendre en charge l'interaction tactile dans vos applications, vous devez réfléchir à l'impact qu'elles peuvent avoir sur celles-ci.
Si vous créez des applications principalement pilotées par la souris, vous avez l'habitude d'utiliser un seul point de curseur. En effet, les systèmes ne sont généralement pas compatibles avec plusieurs curseurs de souris. Pour de nombreuses applications, il vous suffit de mapper les événements tactiles sur une seule interface de curseur. Toutefois, la plupart du matériel que nous avons vu pour la saisie tactile sur ordinateur peut gérer au moins deux entrées simultanées, et la plupart des nouveaux matériels semblent accepter au moins cinq entrées simultanées. Bien entendu, si vous développez un clavier de piano à l'écran, vous devez être en mesure d'accepter plusieurs saisies tactiles simultanées.
Les API W3C Touch actuellement implémentées n'ont pas d'API permettant de déterminer le nombre de points de contact compatibles avec le matériel. Vous devrez donc utiliser votre meilleure estimation du nombre de points de contact que vos utilisateurs voudront ou, bien sûr, faire attention au nombre de points de contact que vous voyez dans la pratique et adapter. Par exemple, dans une application de piano, si vous ne voyez jamais plus de deux points de contact, vous pouvez ajouter des éléments d'interface utilisateur "accords". L'API PointerEvents dispose d'une API permettant de déterminer les fonctionnalités de l'appareil.
Retouche
Nous espérons que cet article vous a fourni des conseils sur les problèmes courants liés à l'implémentation de commandes tactiles parallèlement aux interactions avec la souris. Bien sûr, il est plus important que tout autre conseil : vous devez tester votre application sur un appareil mobile, une tablette, ainsi que sur un ordinateur de bureau combiné à une souris et à un écran tactile. Si vous n'avez pas de matériel permettant de passer en mode tactile et de la souris, utilisez l'option Émuler les événements tactiles de Chrome pour tester les différents scénarios.
Il est non seulement possible, mais relativement facile de suivre ces conseils, de créer des expériences interactives attrayantes qui fonctionnent bien avec la saisie tactile, la saisie à la souris et même les deux styles d'interaction en même temps.