Une interface utilisateur Web doit-elle s'appuyer sur le bouton de retour du navigateur?
Le bouton de retour est une excellente option "sortir de l'impasse d'un flux" offerte par les navigateurs. Une interface utilisateur doit-elle s'appuyer sur le bouton de retour comme seule méthode pour permettre à un utilisateur d'accéder à la page précédente ou l'interface utilisateur doit-elle fournir un bouton supplémentaire spécifique au site pour revenir à l'écran précédent?
Un scénario courant qui vient à l'esprit avec ceci est un site de commerce électronique qui a une liste de produits. Un utilisateur clique sur l'un des produits pour afficher une page de détails. Ensuite, après avoir consulté les détails, ils aimeraient revenir à la liste pour cliquer sur un autre produit et afficher ses détails. L'interface utilisateur devrait-elle supposer qu'un utilisateur utilisera le bouton de retour du navigateur ou le site Web devrait-il fournir un lien ou un bouton qui permet aux utilisateurs de "revenir à vos résultats", en laissant le bouton de retour du navigateur comme une alternative?
Une application Web devrait toujours s'efforcer d'être compatible avec le bouton de retour du navigateur. Autrement dit, l'utilisation du bouton de retour devrait avoir des résultats déterministes dans cette application qui correspondent au comportement attendu (cohérence globale).
Un scénario courant qui vient à l'esprit avec ceci est un site de commerce électronique qui a une liste de produits. Un utilisateur clique sur l'un des produits pour afficher une page de détails. Ensuite, après avoir consulté les détails, ils aimeraient revenir à la liste pour cliquer sur un autre produit et afficher ses détails. L'interface utilisateur devrait-elle supposer qu'un utilisateur utilisera le bouton de retour du navigateur ou le site Web devrait-il fournir un lien ou un bouton qui permet aux utilisateurs de "revenir à vos résultats", en laissant le bouton de retour du navigateur comme une alternative?
Cependant, une application Web ne doit généralement pas s'appuyer uniquement sur le bouton de retour du navigateur pour toute la navigation qui pourrait être considérée comme liée.
Malheureusement, l'une des principales raisons en est que certaines personnes ont peur de frapper leur bouton de retour dans certaines applications Web en raison d'un comportement de contrôle/état du navigateur cassé ou incohérent trouvé dans de nombreux AJAX web lourd applications, où l'utilisation du bouton de retour peut ne pas entraîner l'effet escompté par la personne l'utilisant.
Deuxièmement, si la page a été générée à partir d'un nouvel onglet (ou d'un signet!), Il ne peut pas y avoir de bouton de retour. Bien que la personne utilisant l'application devrait idéalement avoir toujours l'onglet d'origine ouvert, si vous voulez qu'elle puisse accéder à la page dont elle est originaire, assurez-vous de lui donner un moyen de le faire à partir du contexte de la page sur laquelle ils se trouvent actuellement.
En utilisant votre exemple, supposons que la liste était une page de vente statique (au lieu d'une recherche dynamique). Que se passe-t-il si la personne parcourant le site met en signet un produit individuel, puis ferme cette session. Lorsqu'ils chargent ce signet, quelles options de navigation souhaitez-vous mettre à leur disposition? Quelles options de navigation pensez-vous qu'ils voudront à portée de main? C'est une bonne idée de les rendre cohérentes composant de votre interface utilisateur, donc pas la peine de compter uniquement sur le bouton de retour dans d'autres cas.
Pour développer légèrement cela, fournir des options de navigation arrière dans votre interface utilisateur vous permet de contrôler leur présentation: cela signifie que vous pouvez apaiser l'anxiété quant au résultat d'une action en délimitant clairement ce que l'utilisation du contrôle fera.
Par exemple, demandez-vous si quelqu'un aurait une incertitude sur ce que pourraient faire les actions suivantes:
Back(Retour à où ? s'applique également au bouton de retour du navigateur, car nous savons tous qu'il ne fait pas toujours ce que nous attendons) , en fonction de l'application Web, et les gens ne savent pas ce que votre application fera jusqu'à ce qu'ils essaient, ce qui peut être un point d'hésitation)Back to listings(quelles listes? si je viens ici d'un signet, ai-je la moindre idée de ce que je faisais qui m'a amené ici?)Back to [associated product category](Eh bien, c'est bien, c'est fonctionnel et ce n'est pas un souci de ne pas être déterministe, mais devrait probablement être représenté ailleurs)Back to the January Sale Event(hé! c'est ce que je regardais quand je suis venu ici! il est suffisamment précis pour que je puisse m'attendre… où je m'attendrais à aller) (aka cela correspond à la carte de contexte de navigation qui m'a amené à cette page)
(et vous voudrez probablement utiliser un libellé tel que "Plus de" plutôt que "Retour à", selon le contexte dans lequel vous finissez par utiliser un tel contrôle, et lorsque la navigation à partir de celui-ci est clairement liée à des résultats spécifiquement liés)
Ce dernier exemple vous donne ce que vous souhaitez viser: une réduction de l'anxiété pour les personnes utilisant votre application en précisant clairement quel sera le résultat associé.
De plus, cela vous donne un comportement supplémentaire au-delà de ce qui est nécessairement disponible dans le bouton précédent. Alors que le bouton de retour devrait simplement fonctionner, ce contrôle est alors présent si quelqu'un ouvre la page deux mois plus tard. S'ils cliquent dessus, vous pouvez présenter la page associée à "l'événement de vente de janvier", mais avec un message en haut indiquant que l'événement est maintenant terminé, nous sommes désolés que vous ayez raté les offres incroyables que nous avions, mais voir [ ces nouveaux événements/produits/etc].
Ces points de navigation sont une opportunité non seulement d'avoir un contrôle de back-navigation de sauvegarde avec lequel vous savez que la personne utilisant l'application se sentira à l'aise d'interagir avec, mais aussi un endroit où vous contrôlez où il va, et qui vous offre la possibilité de communiquer avec le utilisateur dans un contexte assez étroitement géré. Ils peuvent, s'ils sont gérés correctement, fournir plus de fonctionnalités que le bouton de retour du navigateur seul, améliorant l'expérience plutôt que d'encombrer simplement l'écran avec des commandes/fonctionnalités directement dupliquées.
Si vous prévoyez d'implémenter des contrôles de navigation arrière, rendez-les clairs, cohérents et toujours disponibles (au moins sur les types de page où ils ont du sens). Essayez de fournir une valeur supplémentaire par rapport à ce que le bouton Précédent seul représente, à la fois pour vous-même et pour les personnes utilisant votre application.
Si vous voulez simplement dupliquer littéralement la fonctionnalité du bouton de retour du navigateur avec un contrôle qui dit en arrière ou a une icône similaire représentative ... ne vous embêtez pas. Assurez-vous simplement que le comportement du bouton de retour du navigateur fonctionne correctement. (ce que vous devriez toujours faire de toute façon)
Oui. Vous devez vous fier au bouton de retour du navigateur.
Les utilisateurs s'attendent à ce que le bouton soit là, alors assurez-vous qu'il est fonctionnel.
Mais devriez-vous imiter le même bouton avec ses fonctionnalités?
Si votre application ou votre site Web en a besoin, oui, mais pas toujours exactement la même chose.
Dans certains cas, comme votre exemple de boutique en ligne, un bouton qui dit simplement retour ou une flèche peut ne pas suffire. Dans cet exemple, une navigation dans le fil d'Ariane est en ordre, ou un bouton ou un lien qui dit "retour aux résultats" (un peu plus de contexte pour le bien de l'utilisateur).
Se fier est le mauvais mot
Vous demandez si vous devez vous fier au bouton, ce que vous ne devriez pas. Vous demandez également si vous devez proposer une autre option. Ce que vous pourriez, et dans certaines situations, devriez.
Voici donc la chose:
bouton Retour
Vous ne devriez jamais, jamais, casser le comportement du bouton de retour. À tout moment, vous devez vous efforcer de garder ses fonctionnalités intactes, car cela fait partie du comportement de chaque navigateur. C'est la prise en main d'un utilisateur sur la situation, son aide en cas d'erreur.
C'est un gilet de sauvetage que vous ne devriez pas retirer.
Votre propre interface utilisateur
Dans de nombreux cas, des choses comme une miette ou un bouton "retour" pourraient être utiles. Peut-être parce que le bouton de retour du navigateur est caché sur un certain système d'exploitation, peut-être parce qu'il est légèrement moins sophistiqué, ou peut-être simplement pour que les utilisateurs regardent votre application au lieu du navigateur.
En général, vous ne pouvez pas vraiment vous tromper en ajoutant une navigation de courtoisie.
Conclusion
Devriez-vous vous y fier? Vous pouvez, tant que vous vous assurez de ne pas le casser lorsque vous ne le faites pas. Devriez-vous ajouter le vôtre? Si cela vous semble pratique, si vous l'utilisez, oui.
Et enfin: mesurer. Voyez si les gens l'utilisent si vous l'ajoutez.
J'essaie généralement de fournir à la fois le bouton de retour à l'écran et la prise en charge du bouton de retour du navigateur.
Les raisons:
Si l'utilisateur est immergé dans le flux de l'application, un bouton de retour à l'écran peut aider à garder le focus dans le flux et éviter de perdre son attention.
La prise en charge du bouton de retour du navigateur est importante pour moi, même à un coût élevé , car il est présomptueux de supposer que l'utilisateur utilisera simplement le bouton à l'écran plutôt que le bouton de retour du navigateur.
Notez qu'il existe de rares exceptions où vous souhaitez intentionnellement éviter ou casser le comportement du bouton de retour (par exemple, les formulaires de sécurité).
Personne ne devrait pas se fier uniquement au bouton de retour du navigateur.
Pourquoi?
Parce que les téléphones intelligents augmentent en moyenne à un rythme plus rapide que la taille des mains des humains. Regardez où se trouvent généralement ces boutons arrière.
En haut à droite (général) 
Vue standard de l'iPhone (en bas à gauche) 
Vue horizontale de l'iPhone 6 (en haut à gauche) 
Voyons maintenant comment les utilisateurs tiennent leurs appareils 
Parfois, il est difficile d'atteindre ce bouton arrière car les mains des utilisateurs ne sont pas assez grandes pour appuyer facilement sur le bouton arrière par défaut dans toutes les positions. Ainsi, s'il est possible de fournir un moyen plus facile de traverser, faites-le.
Voir cette tendance en ce qui concerne la taille de l'écran 
ne autre raison de ne pas compter sur le bouton de retour est qu'il peut y avoir des scripts empêchant un utilisateur de revenir en arrière et d'obtenir le résultat attendu en raison de la conception du site Web
- le bouton de retour du navigateur DOIT fonctionner comme prévu.
- votre bouton de retour de l'interface utilisateur Web NE DOIT PAS fournir de bouton de retour à moins qu'il ne fasse la même chose que le bouton de retour du navigateur
- exemple: vue de catégorie filtrée dans le commerce électronique - si le bouton de retour revient à la vue de catégorie non filtrée, il NE DOIT PAS ressembler à un bouton de retour, mais plutôt à un fil d'Ariane.
- vous DEVEZ fournir des liens de navigation contextuels, mais ils NE DOIVENT PAS ressembler à des boutons de retour
Le principal raisonnement derrière l'argument du comportement du bouton de retour - prenez cet exemple de scénario:
- Je filtre nos produits avec un prix <1000
- Je clique sur un produit pour accéder à la page de détails
- Je clique sur le bouton de retour "ui"
- Je vois la page de catégorie avec tous les articles
- en tant que client, je pense "J'ai cliqué sur le bouton retour et les filtres sont perdus" (et donc il n'y a aucune raison d'essayer le bouton retour du navigateur)
- Je jure proportionnellement à la complexité du filtrage que j'avais mis en place
- S'il n'y avait pas de bouton de retour "ui", j'utiliserais très probablement le bouton de retour du navigateur comme je suis habitué.
Je pense que vous ne devez pas vous fier exclusivement au bouton de retour du navigateur.
- Si l'utilisateur interagit avec votre site pour se rendre quelque part, je pense qu'il est raisonnable de s'attendre à pouvoir revenir de la même manière.
- Il est important d'afficher où l'utilisateur se trouve dans le contexte du site Web afin que l'utilisateur dispose d'un cadre de référence où il se trouve dans le site global.
* modifier pour plus de précision: vous devez également prendre en charge le bouton de retour du navigateur. Je veux juste m'assurer que c'était clair. J'ajoutais simplement les raisons pour lesquelles vous ne voudriez pas vous fier exclusivement au bouton de retour du navigateur.
Non, vous ne devriez pas compter sur le bouton de retour du navigateur.
Bien qu'il soit facile de dire que vous pouvez vous attendre à ce qu'il soit présent et que vous puissiez vous attendre à ce qu'il fonctionne toujours d'une certaine manière, ce n'est tout simplement pas le cas.
Étant donné que le bouton de retour existe dans une application en dehors de la vôtre, vous ne pouvez pas raisonnablement vous attendre à ce qu'il soit présent ou fonctionne d'une manière spécifique. S'il y a quelque chose que la révolution du Responsive Design nous a appris, c'est que vous ne pouvez rien prédire sur le contexte de la navigation d'un utilisateur.
Et si, en 2017, Google décidait de ne plus vouloir prendre en charge le bouton de retour dans Chrome?
Nous pouvons pleurer l'hérésie tout ce que nous voulons pour le moment, mais Google pourrait le faire pour un certain nombre de raisons qui nous ne pouvons pas prédire. Tout comme M $, Apple, Mozilla ou tout autre fournisseur de navigateur. Vous vous retrouvez alors à compter sur une fonctionnalité qui n'existe plus.
Il y a beaucoup de choses ici sur le fait de ne pas supprimer ou interférer avec le bouton de retour du navigateur, mais je ne pense pas que c'est ce que le questionneur demande.
Le bouton de retour du navigateur est là pour l'utilisateur et ne doit donc pas faire partie de vos voyages utilisateur projetés. L'utilisateur peut avoir personnalisé son navigateur afin que le bouton de retour ne s'affiche pas - Si vous vous en remettez à cela, vous vous retrouverez avec un parcours utilisateur interrompu.
Je ne m'appuierais pas sur tout ce qui est susceptible d'utiliser la fonction JavaScript "history.back" (en fait une pression sur le bouton de retour).
Si votre parcours utilisateur montre qu'un utilisateur est susceptible de vouloir revenir à une page de résultats de recherche ou ailleurs, vous devez lui fournir une méthode explicite pour ce faire - "Revenez à vos résultats"
Je ne l'utiliserais pas exclusivement.
Le premier exemple qui me vient à l'esprit est Google Chrome pour Android. Chaque "onglet" est une nouvelle instance, donc ouvrir une nouvelle fenêtre revient à démarrer une toute nouvelle session. Dans ces cas, le bouton de retour ramènera simplement l'utilisateur à l'écran d'accueil au lieu de revenir en arrière. La même chose se produira si un utilisateur choisit "Ouvrir le lien dans un nouvel onglet".
En raison de cette fonctionnalité, avoir une fonction de navigation sur le site Web permettrait à l'utilisateur de continuer sans interrompre le flux des choses.
En remarque: j'ai entre 40 et 100 onglets dans Chrome à cause de cela. Il est vraiment assez facile d'accumuler des onglets en utilisant le navigateur normalement, et tous les utilisateurs ne sauront pas vraiment comment pour faire face à ce comportement.
Parlant non pas en tant que designer mais en tant qu'utilisateur; chaque fois que je dois par défaut sur le bouton de retour de mon navigateur pour continuer naviguer sur un site, je ne peux pas m'empêcher de le considérer comme un échec de l'UX du site. Plus je dois l'utiliser, plus je suis frustré. Les seules exceptions sont des exemples tels que "Quelle était l'adresse de ce vendeur sur la dernière page?" ou "Qu'est-ce que j'ai de nouveau mis dans ce champ de formulaire sur la dernière page?", avec l'intention de revenir directement à la page sur laquelle je suis déjà.
À mon humble avis, le bouton de retour natif ne devrait jamais être le seul moyen pour l'utilisateur de sortir d'une page, même s'il essaie de revenir à une page de liste précédente. Il existe une myriade d'options simples, testées et efficaces pour fournir une navigation à vos utilisateurs - un < back to listing le lien en haut d'une page, le fil d'Ariane ou toute autre suggestion de réponse fonctionne bien.