L'ouverture d'une boîte modale devrait-elle modifier l'historique du navigateur?
J'affiche des images qui peuvent être cliquées pour être ouvertes dans une boîte modale (comme ce plugin le fait) et zoomées lorsqu'elles sont pincées sur des appareils tactiles (comme cette démo ).
La modalbox réelle est la suivante:
Il affiche l'image et une navigation simple en haut à droite de l'écran. La navigation a des boutons gauche, droit et fermer.
Lors de la visualisation du site sur un appareil mobile, j'ai remarqué que certains utilisateurs appuyaient sur le bouton de retour du navigateur lorsqu'ils souhaitaient fermer la modalbox. Cela fait sortir le navigateur du site. J'ai déjà changé la couleur d'arrière-plan de la navigation du blanc (qui devait être moins intrusif) au foncé.
Du point de vue de l'expérience utilisateur, est-il recommandé de pousser un état d'historique de navigateur supplémentaire (lors de l'ouverture de la boîte modale) au cas où les utilisateurs appuieraient sur le bouton de retour?
(quelque chose comme: www.example.com/#img1)
Y a-t-il une pensée ou une manière courante d'approcher les boîtes modales?
OUI EN EFFET
Pour la plupart des utilisateurs, ce ne sera qu'une autre page. Et conceptuellement, ils auront raison, ils n'ont aucune idée de la partie technique, ils savent seulement qu'en cliquant ou en faisant quelque chose on leur présente un contenu différent. C'est une situation très courante (et assez étudiée), bien sûr.
De NNG Surutilisation des superpositions
Vous devez également considérer ce qui se passera si l'utilisateur décide de ne réaliser aucune de vos actions cibles. Bien sûr, vous devez inclure un moyen explicite de fermer la visionneuse, mais une autre stratégie courante des utilisateurs consiste à cliquer sur le bouton Précédent du navigateur pour revenir à l'écran sous-jacent. Par défaut, les navigateurs Web ne traitent pas les superpositions comme des pages distinctes. Le bouton Précédent amène les utilisateurs non pas à l'écran sous-jacent, mais à la page précédant cet écran. Si vos analyses montrent que les utilisateurs cliquent sur Précédent après avoir atteint une superposition, envisagez d'ajuster le bouton Précédent de sorte que lorsqu'une superposition s'affiche, le bouton Précédent ferme la lightbox au lieu de naviguer vers la page précédente de l'historique du navigateur.
4 modèles de conception qui violent les attentes du bouton arrière
Les superpositions et les lightboxes sont conçues pour transmettre une nouvelle page placée 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 à la page d'origine. 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 au-delà de la page superposée.
Les lightboxes sont-elles une bonne UX?
Confusion du bouton Précédent - Les utilisateurs qui cliquent sur le bouton Précédent du navigateur pour revenir à la page parent sont un problème. D'après mon expérience personnelle, le problème est plus fréquent sur les pages où la page parent est fortement grisée, donnant à l'utilisateur le sentiment qu'il y a échappé. Utilisez des superpositions légères ou transparentes pour vous aider.
En bref: la plupart des personnes qui ont testé le problème du bouton de retour ont trouvé ce comportement courant: les utilisateurs utilisent le bouton de retour pour revenir à un état précédent, et c'est une donnée.
Certains sites sont si horriblement réalisés qu'ils ont du contenu dans des modaux (ou même AJAX pages chargées) et lorsque l'utilisateur est au milieu d'un voyage, comme une galerie de photos avec navigation et l'utilisateur clique en arrière, elle est envoyée au ... début. Pensez à ceci: l'utilisateur est à l'élément 51 et elle veut voir l'élément 50 ... et elle est envoyée au début !!! Malheureusement , c'est très courant, probablement plus courant que la bonne façon, alors assurez-vous de toujours traiter la navigation comme des chemins logiques avec leur propre historique: si l'utilisateur veut utiliser le bouton de retour pour revenir à un état antérieur de son expérience, vous ne devriez JAMAIS nier cela. Au lieu de cela, vous devez aider l'utilisateur à y parvenir.
Merci Devin pour ta réponse. Je poste cette réponse pour expliquer la façon dont je l'implémente au cas où elle serait utile à quelqu'un.
J'ai fini par ajouter un état d'historique supplémentaire à la boîte modale, pas à chaque image.
Par ici:
1 . L'utilisateur est sur le site.
[example.com]
2. L'utilisateur clique sur une image et la boîte modale s'ouvre. Un état d'historique supplémentaire du navigateur est ajouté en tant qu'ancre, avec l'attribut 'alt' de l'image. (Le hachage est lié à l'attribut id, je dois vérifier quelle est la bonne façon de l'implémenter)
[example.com> example.com/#Building_plan]
3. L'utilisateur clique sur la flèche droite pour charger l'image suivante. L'ancre est remplacée par l'alt de la nouvelle image.
[example.com> example.com/#Building_section]
4a. L'utilisateur clique sur le bouton Fermer. Le navigateur remonte une étape historique. La boîte modale se ferme.
[example.com> example.com/#Building_section]
4b. L'utilisateur clique sur le bouton de retour du navigateur. La boîte modale se ferme.
[example.com> example.com/#Building_section]
Je pense que cela a du sens dans mon cas. L'utilisateur peut appuyer sur le bouton de navigation vers l'avant pour rouvrir la boîte modale.
J'ai intentionnellement remplacé au lieu de pousser un état supplémentaire de 2 à 3. L'importance ici est la boîte Page & Modal, ajouter un état supplémentaire pour chaque image ajouterait trop d'états inutiles à mon avis.
Je pourrais simplement ajouter [example.com/#Modal_box] et je n'ai pas besoin de remplacer l'état de 2 à 3, mais je pense que cela donne des informations supplémentaires (utiles) sur l'image actuelle.
Veuillez noter que j'utilise la boîte modale uniquement pour les images, le chargement de pages complètes serait une autre histoire.