Faut-il d'abord concevoir pour le toucher?
L'interaction tactile devient de plus en plus omniprésente et souvent l'option seulement. Devrions-nous concevoir pour le toucher d'abord ou même pour le toucher uniquement?
Quelles sont les ramifications de cette approche?
En tant que personne qui pense toujours à l'UX et au HCI, j'ai trouvé la discussion sur alternatives au "survol" sur les appareils tactiles et sur d'autres articles similaires très intéressante. Cependant, il a estimé que cela essayait beaucoup de chausse-pied une analogie de curseur dans une situation tactile et était tout simplement un mauvais travail.
Devrions-nous éviter des choix de conception qui s'appuient sur une interaction guidée par le curseur? Par exemple, survoler les états des boutons et les info-bulles (informations de rétroaction) ou `` survoler les options '', comme survoler une ligne du tableau pour afficher le bouton modifier, supprimer, etc. (éléments d'action) ou même des choses comme les menus déroulants (ne devrions-nous changer que les cliquer et ne pas les survoler ou les deux).
Même sur ce site, je remarque qu'une fois que vous retirez les états de vol stationnaire de l'équation, une quantité énorme de fonctionnalités/informations est supprimée (essayez de voir à quel point le contenu de cette page dépend d'un état de vol stationnaire).
Une meilleure approche serait-elle un type d '"amélioration progressive" où certaines fonctionnalités de base sont présentées, applicables au toucher et au curseur, et des fonctionnalités supplémentaires sont ajoutées lorsqu'un appareil tactile est détecté (permettant un pincement pour zoomer, des points de contact multiples ou même multi utilisateur) ou un curseur est détecté (survol, info-bulles, précision supplémentaire).
Il est important de noter que cela s'applique non seulement à la conception Web, mais à la conception d'applications, à la conception de systèmes d'exploitation et à HCI en général. C'est aussi pas une question sur 'mobile first' mais plutôt 'touch first'.
Donc, devrions-nous concevoir pour le toucher d'abord ou même pour le toucher uniquement et quelles sont les ramifications de le faire?
Je pense que la conception pour le toucher d'abord pourrait être une bonne stratégie générale pour les sites Web. Il semble que de nombreux concepteurs, moi y compris, trouvent plus facile d'ajouter des fonctionnalités à un design existant que de les supprimer. Donc, concevoir une application sans assumer de pointeur (la version tactile), puis ajouter des embellissements de pointeur pour la version informatique traditionnelle semble être une approche réussie ( c'est nouveau donc je ne fais que deviner).
Il est important de noter que la conception sans pointeur n'est généralement pas très compromettante. Les changements de pointeur fournissent une rétroaction. Des effets de survol mineurs (par exemple, les liens changeant d'apparence lors du survol) sont couramment utilisés, mais nous nous en sommes bien sortis jusqu'au début des années 90. Il n'y a pas de véritable substitut aux effets de survol brut (par exemple, les menus déroulants de survol), mais ceux-ci ont une utilisation douteuse.
Mais toucher uniquement les conceptions ne devraient pas se retrouver sur des interfaces utilisateur de pointeur traditionnelles, l'effort relativement petit pour ajouter les réactions du pointeur en vaut la peine.
Devriez-vous concevoir pour le toucher en premier? Vous devriez choisir celui qui a le plus d'audience, AKA la version principale. Par exemple, pour un site comme stackoverflow, il n'est pas logique que la version Web mobile soit la version principale, car la plupart des gens utilisent des ordinateurs pour accéder au site.
Devriez-vous concevoir uniquement pour le toucher? Ce n'est pas la décision d'un concepteur. Si votre entreprise va développer une application ainsi qu'un site, qui êtes-vous pour dire qu'elle ne devrait développer qu'une application? Mais si vous êtes le patron, vous devriez penser à "les gens utiliseraient-ils mon application via un ordinateur?"
Je conçois du plus simple et général au plus puissant et spécifique.
Je prends du recul par rapport à la première conception pour mobile ou tactile, en commençant par une conception qui semble acceptable sur le navigateur de texte lynx. Il ne s'agit pas d'un snob de ligne de commande, mais plutôt de garantir que le contenu est présenté de manière optimale pour les robots d'indexation Web, les concepteurs d'applications maillées et les personnes handicapées ou ayant des besoins spéciaux.
Après avoir conçu cette base solide, en m'assurant que tout est bien structuré et sémantiquement cohérent, j'essaie de concevoir les interfaces nécessaires plus ou moins en parallèle. Cela me permet de veiller à ce que tout ce que je fais pour la version de navigateur traditionnelle ne le rende pas inutilisable sur l'édition mobile ou ne soit pas terrible sur un écran large.
Cela peut sembler un peu gênant, et ça l'est. Mais je pense que le chagrin d'essayer de faire fonctionner nos présentations sur une variété de plates-formes et dans une variété de contextes va souffrir à un certain stade du processus de conception.
Vous devez concevoir non pas pour l'appareil, mais pour la tâche à accomplir. N'oubliez pas que tout ce que vous faites doit être d'aider l'utilisateur à accomplir une tâche. Si la conception tactile permet cela, alors faites-le. Par-dessus tout, concentrez-vous sur ce que fera l'utilisateur.
Étant donné qu'il existe une vaste gamme de ce que nous concevons, il est difficile de donner des conseils plus spécifiques que cela. Par exemple, ce que vous faites pour une application Facebook est considérablement différent de celui d'une application conçue pour être utilisée comme système de contrôle sur un bateau, ou pour un logiciel conçu pour être utilisé par des personnes ayant une faible motricité fine.