Fonctionnalité «bouton Retour», quelle est son importance?

Il est de plus en plus courant que les applications "riches" cassent le bouton de retour. J'ai toujours soutenu que c'était une mauvaise forme mais peut-être que cette vue est dépassée?

Est-il jamais OK de casser le bouton de retour? Et si oui, quels sont les critères?

Ne cassez le bouton de retour que si cela est prévu (s'il est logique de ne pas revenir en arrière après un événement sur votre site Web).

Mozilla a fait une étude sur la façon dont les gens utilisent son navigateur et les résultats pour le bouton de retour sont impressionnants:

Le bouton Précédent est utilisé beaucoup plus souvent que tout autre élément de navigation (nous entendons les boutons Précédent, Suivant, Recharger, Arrêter et Accueil). 93,1% des participants à l'étude ont utilisé le bouton Retour au moins une fois, et en moyenne, chaque utilisateur a cliqué 66,2 fois sur les 5 jours - soit 3 fois plus de clics que le bouton Recharger, 10 fois plus que le bouton Accueil et plus de 30 fois plus que le bouton Boutons Avancer et Arrêter!

la source

J'utilise beaucoup le bouton de retour et je déteste quand je ne peux pas l'utiliser.

Briser le bouton arrière, c'est comme casser la pédale de frein dans une voiture. Les utilisateurs s'attendent à ce qu'il fonctionne toujours et quand cela ne se produit pas soudainement, le chaos s'ensuit. Le bouton de retour peut être la fonctionnalité d'interface utilisateur la plus utilisée dans un navigateur, donc modifier son comportement de quelque manière que ce soit peut, au mieux, ne pas servir, et, au pire, entraîner la confusion et l'abandon des utilisateurs (ou augmenter les coûts de support client). Même si cela ramène l'utilisateur là où il était, ce n'est pas ce qu'il attendait .

Il faut éviter de casser le bouton de retour.

Dans certains cas, casser le bouton de retour peut être OK, mais il est presque toujours inutile. Je l'ai vu beaucoup avec des formulaires en plusieurs étapes où vous postez d'une page à l'autre. Ce que vous devez faire dans ce cas, c'est à partir de votre page de formulaire (1), publier sur une autre page (2) qui (par exemple) stocke des éléments dans la session, puis rediriger vers une autre page (3). Lorsque l'utilisateur appuie sur le bouton de retour, il passe de (3) à (1).

Même avec les RIA, vous pouvez utiliser des hachages / ancres d'URL (c'est-à-dire page.html#section) et les surveiller pour les changements. Gmail le fait pour les différentes «pages» comme la boîte de réception, la composition, les paramètres, etc. Cette question sur Stack Overflow vous aidera si vous souhaitez l'implémenter.

Il est important de casser le bouton de retour sur les sites où l'utilisateur répond à un quiz, certains sites bancaires. En général, ce n'est pas une bonne idée.

La raison principale pour laquelle il est "de plus en plus courant" est que certains frameworks RIA ne prennent pas en charge le bouton de retour ou vous obligent à réfléchir activement à la façon d'intégrer son utilisation dans votre application. La plupart des frameworks offrent cependant un support pour la navigation, comme le support de Silverlight 3 pour les cadres et les contrôles de page , il vous suffit de savoir comment l'utiliser efficacement. Le même cadre de navigation est utilisé dans les applications Windows Phone 7.

Des études ont montré que près du tiers des clics lors de l'utilisation du navigateur se trouvent sur le bouton de retour (de Don't Make Me Think). Honnêtement, je ne crois pas qu'il y ait jamais une bonne raison d'arrêter le bouton de retour de fonctionner. les gens devraient pouvoir naviguer sur votre site comme bon leur semble.

D'après mon expérience, à moins que vous n'utilisiez un cadre confiné tel qu'une application DANS le contexte d'un navigateur (comme Silverlight mentionné ci-dessus), et que vous ayez une navigation claire et appropriée en place, ce n'est tout simplement pas une bonne idée de commencer à faire des singes avec fonctionnalité par défaut. Dans les cas où je l'ai vu utilisé, il y a presque toujours eu des problèmes avec un autre navigateur incompatible avec le javascript ou une session qui n'était pas toujours enregistrée correctement, et quand quelqu'un frappe "accidentellement" le bouton, les choses ont tendance à ne pas continuer comme prévu.

Je pense que je peux résumer les réponses comme

Vous ne devriez jamais faire cela à moins que vous ne puissiez absolument pas l'éviter. Même alors, vous ne devriez pas.

Parait à peu près juste.

Pour ne pas négliger la façon dont les utilisateurs "fréquents" appuient sur le bouton de retour, ou que ce n'est tout simplement pas une "bonne idée" de le "casser", je proposerais une suggestion différente: le bouton de retour devrait amener l'utilisateur quelque part avant l'utilisateur. arrivé là où ils sont maintenant. Dans de nombreux cas, cela a plus de sens et est plus utilisable pour ne pas les reprendre en un clic (et peut être beaucoup plus facile à mettre en œuvre). Par exemple, parcourez un album photo. L'utilisateur fait un clic pour sélectionner l'album, est présenté avec des vignettes. Un autre clic sur une miniature montre cette image avec les liens suivants / précédents. À ce stade, l'utilisateur navigue dans l'album. Quand ils ont fini, ils cliquent en arrière. À ce stade, il est plus pratique et intuitif de revenir à la vignette qu'à l'image précédente.

En bref, le bouton de retour devrait faire quelque chose, mais exactement ce qu'il devrait faire dépend de l'application.