Le bouton Retour montre l'ancien état de l'utilisateur
QA a trouvé le bogue suivant dans notre application Web:
- Accéder à une liste de pignons
- Créer un nouveau pignon
- Cliquez sur le bouton retour
Résultat: La liste des pignons affichée n'inclut pas le pignon qui vient d'être créé.
La raison en est que le navigateur met en cache la version de la page avant que le pignon ne soit affiché - intuitivement, cela ressemble à une mauvaise utilisation, la solution étant de vaincre le cache du navigateur pour s'assurer que la page affiche toujours l'état actuel, mais j'hésite à remplacer le comportement du navigateur par défaut.
Les applications Web doivent-elles remplacer le cache du bouton de retour du navigateur pour garantir que l'état périmé n'est pas affiché pour l'utilisateur?
Du point de vue UX, il ne fait aucun doute que vous devez toujours montrer à l'utilisateur l'état actuel du système , sinon, les utilisateurs pourraient penser que leur action n'a pas été vraiment joué/enregistré qui ne peut dériver que de mauvaises choses. (les utilisateurs ne faisant pas confiance au système, se fâchent, refont des actions puis découvrent qu'ils ont dupliqué des données et perdu leur temps, etc.).
La seule raison de ne pas le faire serait que les conséquences des modifications techniques ne puissent que dériver d'un problème UX plus important (ce qui n'est probablement pas le cas).
btw, est-il vraiment nécessaire de remplacer le comportement du navigateur? Ne sera pas suffisant avec un "drapeau" et du code javascript pour vérifier si la version chargée est la dernière et sinon déclencher le rechargement?
Connexes: Comment actualiser la page en cliquant sur le bouton Retour?
L'événement onload doit être déclenché lorsque l'utilisateur appuie sur le bouton de retour.
Les éléments non créés via JavaScript conserveront leurs valeurs.
Le problème auquel vous êtes confronté est principalement dû au fait que votre équipe QA s'attend à un comportement d'application monopage (SPA) hors de ce qui ressemble à une conception d'application multipage (MPA).
Vous avez raison de remettre en question la modification du comportement du bouton de retour, car les utilisateurs ont appris à s’attendre à ce que si la page se recharge au fur et à mesure qu’ils "avancent" dans une AMP, cette page et la page qu’ils ont parcourue soient "dans le passé". Et il existe de nombreux sites Web MAJEURS qui se comportent de cette façon.
Vous pouvez maintenant modifier ce comportement et (1 - selon la conception de votre site dans son ensemble, et 2 - en supposant que vous résolvez tous les problèmes potentiels liés à la modification du comportement standard du navigateur), cela pourrait ne pas avoir un impact drastique sur les attentes des utilisateurs, mais, en supposant que j'ai raison sur la conception MPA, vous allez à l'encontre du modèle/expérience standard MPA).
Certaines options alternatives incluent:
Amène automatiquement l'utilisateur (avant) à une vue mise à jour de la page précédente dans le cadre de la confirmation que le nouveau pignon a été ajouté. Cela leur permet de voir qu'il a été correctement ajouté et réduit la probabilité qu'ils souhaitent revenir à l'ancienne version.
Pensez à mettre à jour votre application vers une conception SPA, si vous constatez que vos besoins commencent à vous pousser de cette façon. Bien qu'il s'agisse probablement d'une GRANDE entreprise de refonte de la conception de votre application, vous feriez BEAUCOUP mieux de faire une refonte que d'essayer de moderniser les comportements SPA dans une conception MPA.