Bonne idée d'avoir un bouton retour pour fermer une fenêtre modale?
J'ai une demande pour que le bouton de retour du navigateur ferme une fenêtre modale.
Je pense que c'est probablement une bonne idée, car je pense que la plupart du temps, lorsqu'un utilisateur regarde une fenêtre modale (et celle-ci domine la page et contient des informations, pas seulement une fenêtre d'alerte), s'il presse, il veut pour aller à l'information qu'ils regardaient auparavant.
Ma seule préoccupation est que cela pourrait entraîner les utilisateurs du site à s'attendre à cela avec des fenêtres modales, ce qui les rendra plus frustrés sur d'autres sites.
Y a-t-il d'autres considérations que je devrais garder à l'esprit?
D'après mon expérience, les fenêtres modales sont mieux utilisées pour présenter des interactions claires que l'utilisateur soit:
- besoins à faire (par exemple, résoudre une alerte)
- a choisi de faire (par exemple, ouvrir une galerie de photos).
La résolution de cette interaction devrait fermer le modal, et il devrait déjà y avoir un contrôle en place qui le fait.
En effet, les fenêtres modales interrompent le flux utilisateur et cassent les contrôles et idiomes standard du navigateur; vous ne pouvez pas créer de lien profond dans un modal, vous ne pouvez pas vous retirer d'un modal, les araignées Web ne peuvent pas lire les modaux, ils ne sont tout simplement pas un bon endroit pour mettre du contenu réel.
Avec cela à l'écart, je ne vois aucun problème avec le changement du comportement du bouton de retour du navigateur. De nombreux sites Web modifient le bouton de retour pour revenir à la dernière "page" sémantique sur laquelle l'utilisateur se trouvait (c.f. gmail). Dans ce cas, le modal est un espace séparé qui contient du contenu qui n'est pas dans la page principale, c'est certainement une page sémantique qui lui est propre, il est donc logique que le bouton de retour en revienne.
Dans le pire des cas, tout ce que vous allez faire, c'est obliger l'utilisateur à cliquer deux fois en arrière pour obtenir son comportement attendu, et dans le meilleur des cas, vous allez empêcher un utilisateur d'appuyer sur le bouton de retour et de se retrouver sur un site Web inattendu et complètement différent (c'est-à-dire de retour à google).
Les arguments de l'opportunité des fenêtres modales mis à part (parce que je ne pense pas que nous ayons suffisamment de contexte pour cela dans votre question), je pense que votre raisonnement pour expliquer pourquoi c'est une bonne idée est sain. Certains utilisateurs comptent beaucoup sur le bouton de retour:
Le bouton Retour est la bouée de sauvetage de l'internaute et la deuxième fonctionnalité de navigation la plus utilisée (après avoir suivi les liens hypertextes). Les utilisateurs savent avec bonheur qu'ils peuvent essayer n'importe quoi sur le Web et être toujours enregistrés par un ou deux clics sur Retour pour les ramener en territoire familier.
Nielsen Norman Group - Les 10 principales erreurs de conception Web
L'utilisation des boutons arrière évolue également. Plus précisément dans les interfaces utilisateur de téléphonie mobile.
Un exemple de cela est que cliquer sur un lien dans une application comme Facebook peut lancer un navigateur, mais vous pouvez cliquer sur le bouton de retour de votre téléphone pour revenir à l'application Facebook à partir de cette fenêtre de navigateur. Ce comportement suit le parcours des utilisateurs où qu'il aille dans le système d'exploitation, plutôt que de fournir un comportement spécifique au contexte pour différentes applications et actions.
Évidemment, nous ne parlons pas ici d'un comportement global du système d'exploitation, mais je pense qu'il y a un parallèle. Sur mon mobile, je veux toujours que le bouton de retour me ramène à la dernière chose que je regardais. Actuellement, le comportement modal standard est que le fait d'appuyer sur le bouton de retour ne vous ramènera pas à la dernière chose que vous avez regardée, mais la page précédente que vous avez chargée dans votre navigateur. Je dirais que même si certains utilisateurs peuvent être habitués au comportement modal actuel, c'est un comportement non standard pour commencer.
Si vous implémentez cette fonctionnalité, la clé pour rendre tous les utilisateurs confortables sera de s'assurer que le comportement standard des fenêtres modales est toujours pris en charge; un bouton [X] pour le fermer, par exemple. Cela signifie que si les utilisateurs ont des attentes spécifiques, ils ne seront pas confus. Comme l'a souligné Racheet, le pire qui se produira est qu'un utilisateur très familier avec les fenêtres modales devra cliquer deux fois sur le bouton de retour pour revenir à la page précédente.
"Les superpositions et les visionneuses sont conçues pour transmettre une nouvelle page qui se trouve en haut de la page précédente. Il n'est donc pas surprenant que les utilisateurs les perçoivent comme des pages distinctes et s'attendent à ce que le bouton de retour du navigateur les ramène à l'original. Hélas, pendant les tests, la grande majorité des superpositions initiées par les utilisateurs sur le site testé ne se sont pas fermées lorsque les sujets ont cliqué sur le bouton de retour du navigateur, et les ont renvoyés à la place après la page superposée. "
La fermeture d'une fenêtre modale à l'aide du bouton de retour dans le navigateur n'est pas une pratique courante. Les pratiques courantes incluent: cliquer sur le "X" dans le coin supérieur droit, cliquer à l'extérieur de la fenêtre modale ou appuyer sur la touche "Echap" du clavier.
Le problème de la mise en œuvre d'une pratique non standard est que la plupart des gens ne savent pas qu'elle est là pour l'utiliser.
Cliquer sur le bouton "Retour" dans un environnement de navigateur devrait ramener l'utilisateur à la précédente page.
Si vous activez le bouton "Précédent" pour fermer la fenêtre modale, que se passera-t-il lorsque l'utilisateur cliquera sur le bouton "Suivant" après avoir fermé la fenêtre modale?
Les messages modaux et les fenêtres contextuelles indiquent généralement que quelque chose ne va pas avec le concept d'interface utilisateur. Souvent, ils peuvent être évités. Ce ne sont pas des bonnes pratiques en général car cela conduit exactement au problème que vous avez mentionné: les utilisateurs devront commencer à deviner:
"Que se passera-t-il si je clique sur ce bouton de retour ici? Humm ...."
Les utilisateurs ne sauront pas avec certitude. À moins que vous ne montriez une capture d'écran de l'interface utilisateur, il est vraiment difficile de répondre à ces questions car cela dépend considérablement du contexte dans lequel il est utilisé et du langage de conception visuelle global. Gmail est un tout autre cas, car il s'agit d'une application dédiée qui ressemble non seulement à une application, mais qui le ressent également. Sur un site Web traditionnel, le modèle mental des utilisateurs est différent.