Parfois, sur les pages Web, il devient nécessaire d'accéder temporairement à une autre page (appelons-la auxiliaire), puis de revenir en arrière et de continuer à travailler avec. Par exemple, cela peut être - page d'aide, inscription.
Dans ce cas, évidemment, l'adresse de retour peut être très différente. Comment mettre en place une telle transition inverse sur le site ? Le pur html/CSS ne suffira pas ici, il vous faudra utiliser du javascript.
Le plus simple est, par exemple, d'utiliser cette ligne dans un script sur une page d'aide :
La méthode historique se souvient de l'historique des transitions sur la page et, en fait, son utilisation est similaire à l'utilisation des boutons "Suivant" et "Précédent" du navigateur, à peine plus fonctionnels. C'est le moyen le plus simple et le plus pratique, mais à une seule condition : si la nouvelle page (auxiliaire) n'est pas ouverte dans une nouvelle fenêtre. Après tout, sinon la page auxiliaire s'ouvrira pour la première fois (plus précisément, la session pour elle sera la première, il n'y a pas encore eu de transitions dessus). Et cela signifie qu'en fait, il n'y a nulle part où retourner. Par conséquent, cette méthode ne peut pas être qualifiée d'universelle. Cela ne fonctionnera pas si l'utilisateur ouvre de force la page dans un nouvel onglet ou si le navigateur le fait pour lui - conformément aux paramètres. Dans ce cas, l'attribut target = "_ self" du lien n'aidera pas : il ne sera pas possible de revenir en arrière depuis la page auxiliaire ouverte (à moins, bien sûr, de saisir l'URL de la page d'origine dans l'adresse du navigateur barre manuellement).
Un moyen plus polyvalent
Pour l'implémenter, vous aurez besoin de scripts sur les pages source et auxiliaire. L'idée peut être différente. L'un d'eux est basé sur le fait que l'adresse (URL) de la page d'origine est stockée dans la barre d'adresse du navigateur en tant que requête GET. Ainsi. la page d'aide, lorsqu'elle reçoit une telle requête, connaît l'origine de la requête. Sur cette base, il devient possible de revenir en arrière, c'est-à-dire à la page à partir de laquelle la transition a été effectuée.
Ceci peut être schématiquement représenté comme suit :
Le script sur la page d'origine
Sur la page AVEC LAQUELLE la transition doit être effectuée, il y a le script suivant, qui est une fonction - le gestionnaire du clic de souris (onclick):
Pour que la fonction du script fonctionne, vous devez installer son gestionnaire sur un élément de l'une des manières suivantes, par exemple :
http://example.com "onclick =" to_comment_rules ("http://example.com"); return false "> Cliquez pour accéder à la sous-page
Notez que l'attribut href de ce lien a une adresse correspondante, qui est spécifiée dans la fonction de gestionnaire d'événements onclick. Ceci est fait pour que les robots de recherche comprennent à quelle page le lien ira lorsque le lien est cliqué. Si ce n'est pas nécessaire, vous devez créer un attribut href vide, comme
Le principe de ce script est que lorsque la fonction save_back (url) est appelée, une page (auxiliaire) avec l'adresse url est ouverte. Pour ce faire, le protocole de la page (par exemple, http ou https) est défini, ainsi que le reste de l'URL de la page web d'origine, y compris avec, peut-être, les données disponibles de la requête GET (c'est ce est dans l'URL après le signe "?"). Les données reçues sont ajoutées à l'URL de la page en cours d'ouverture - et une transition vers celle-ci a lieu.
Script sur la page d'aide
Il devrait avoir quelque chose comme ce script :
Ce script sera également lancé lorsque la souris sera cliqué sur n'importe quel élément sur lequel le gestionnaire correspondant est installé :
Revenir
Cette ligne remplace l'action de clic sur le lien par défaut. Le fait est que par défaut le lien est suivi. Dans ce cas, la transition se produira exactement à l'adresse spécifiée dans l'attribut href. Cette adresse (en particulier, sur la page auxiliaire) peut ne pas contenir l'adresse de retour de la page à partir de laquelle la transition a été effectuée (si la transition vers la page auxiliaire est possible non pas à partir d'une seule, mais à partir de plusieurs pages sources).
Ainsi, le script de la page d'aide lit le contenu de la barre d'adresse, puis le divise en un tableau d'éléments "?". Veuillez noter qu'il peut y avoir deux de ces caractères dans l'URL. Le premier apparaîtra, comme déjà mentionné, du fait que l'adresse de la page d'origine a été ajoutée à l'adresse de la page auxiliaire (moins le protocole). Et le second pourrait être présent du fait de la présence des paramètres de la requête GET lors du chargement de la page d'origine. En d'autres termes, il peut y avoir un ou deux points d'interrogation dans la barre d'adresse de la sous-page. Pour passer de la page auxiliaire à celle d'origine en cliquant sur le lien
la demande est lue à partir de la barre d'adresse et convertie sous la même forme qu'elle avait sur la page d'origine, après quoi la page est chargée à cette adresse.
Remarques
De plus, il convient de noter que l'article ne consiste pas vraiment à revenir à la page d'origine, mais à la recharger. Ceci est, bien sûr, juste une imitation d'un retour. En particulier, les données saisies sur cette page, ses paramètres peuvent ne pas être sauvegardés. De plus, contrairement au RETOUR, lorsque la page sera chargée, elle sera ouverte dès le début du site (c'est-à-dire que sa partie supérieure sera située en haut de l'écran). Alors que le retour en arrière « vrai » renvoie la page (d'origine) exactement où la navigation a été effectuée. Essayons donc de combiner les deux méthodes.
Méthode combinée
Alors, définissons la tâche :
si la page auxiliaire est ouverte dans le même onglet (fenêtre), alors laissez la méthode history.back () être disponible ;
mais si la page auxiliaire s'ouvre dans une nouvelle fenêtre, alors la méthode décrite ci-dessus devrait fonctionner (car dans ce cas history.back() ne fonctionnera pas).
Le script sur la page d'aide changera légèrement (la ligne ci-dessus sera ajoutée) :
D'abord, nous essayons de revenir en arrière. Si cela fonctionne, le reste du script ne fonctionnera pas et reviendra à la page d'origine au même endroit à partir duquel la transition a été effectuée. Sinon, comme précédemment, nous extrayons l'adresse de la page d'origine des paramètres de la requête GET et y accédons.
Conclusion
Bien sûr, cet article ne montre qu'une des options pour la technologie "retour" ARRIÈRE- à la page d'origine. A cet effet, en plus de la requête GET, d'autres technologies pourraient être utilisées, par exemple, le stockage local localStorage. De plus, pour simuler pleinement le retour ARRIÈRE Il serait bien d'envoyer via une requête GET la quantité de défilement de la page d'origine - de sorte que plus tard, même lors de l'ouverture de la page auxiliaire dans une nouvelle fenêtre, revenez au même endroit sur la page d'origine à partir de laquelle la transition a été effectuée plus tôt .
De nombreuses études d'utilisabilité montrent que les utilisateurs (à la fois novices et expérimentés) utilisent souvent le bouton Précédent de leur navigateur. Malheureusement, les concepteurs frontaux et les spécialistes du marketing réfléchissent rarement aux implications en termes d'utilisabilité, étant donné les modèles de conception Web actuels que les applications, les animations, les vidéos et bien d'autres utilisent. Souvent, la structure technique de telles mises en page ne répond pas bien à la fonction de retour en arrière, ce qui brise le schéma mental des utilisateurs et dégrade leur expérience.
Les conséquences peuvent être désastreuses : lors des expérimentations, la réponse inadéquate du site à l'appui sur le bouton « retour » a été la raison pour laquelle de nombreux utilisateurs sont partis, avec des abus et des critiques peu flatteuses. Dans la plupart des cas, même les sujets de test respectables aux cheveux gris perdaient terriblement leur sang-froid.
Dans cet article, vous apprendrez :
- ce que les utilisateurs attendent du bouton retour ;
- quelles sont les 5 erreurs les plus courantes ;
- solution simple à ces problèmes.
La solution est vraiment très simple, mais elle est souvent délaissée même par les plus grandes marques. Allons-nous corriger cette erreur?
Attentes des utilisateurs
En bref : les utilisateurs s'attendent à ce que le bouton de retour leur montre ce qu'ils perçoivent comme la page précédente. Le mot « percevoir » est très important, car il y a une différence colossale entre ce qui semble être la page précédente et ce qui en est techniquement.
La question se pose : qu'est-ce que les utilisateurs interprètent exactement comme une nouvelle page ? Dans la plupart des cas, si une page est visuellement très différente, mais en même temps conceptuellement liée au site, alors elle est perçue comme nouvelle. Par conséquent, il est très important de suivre la façon dont le site gère divers éléments interactifs : boîtes lumineuses, formulaires, filtres, etc.
La plupart des visiteurs ne comprennent pas les problèmes techniques, mais se fient uniquement à des idées intuitives sur le fonctionnement de la ressource. Ainsi, lorsqu'ils cliquent sur le bouton retour, ils s'attendent à une page qui a déjà eu une expérience importante, et ils obtiennent une page avec une interface légèrement repensée.
Vous trouverez ci-dessous les éléments interactifs les plus populaires et comment les utiliser pour maximiser l'expérience utilisateur et la convivialité.
Le but de l'intégration des superpositions et des lightbox est de montrer à l'utilisateur un élément qui apparaît en haut de la page. Par conséquent, les utilisateurs perçoivent ces éléments comme de nouvelles pages et appuient sur le bouton "retour" pour revenir à leur position d'origine - mais ils ne vont pas là où ils l'attendaient. C'est particulièrement regrettable, car l'utilisation de lightbox ne fait que multiplier la perception négative d'une page Web - la plupart des utilisateurs n'aiment pas ces éléments sur les sites de boutiques en ligne.
L'utilisation de filtres transforme souvent la page et offre à la personne une nouvelle expérience. Par conséquent, la page après tri est perçue comme nouvelle, même si rien n'a été chargé dessus. En effet, après chaque interaction du visiteur avec la page de la boutique en ligne, un nouvel affichage des résultats est obtenu.
Cet exemple souligne que les gens n'entrent pas dans les aspects techniques lors de la définition d'une nouvelle page, mais utilisent uniquement l'intuition et la perception formée.
3. Formulaire d'inscription / paiement
La page de paiement est perçue comme de nouvelles pages, et pire encore - comme un processus en plusieurs étapes, dont chaque étape peut être annulée avec le bouton "retour".
Cette approche peut poser des problèmes, un exemple simple - une personne veut revenir en arrière en remplissant un formulaire afin de modifier les informations saisies. En appuyant sur le bouton "retour", il revient dans le panier et supprime toutes (!) Les données saisies. L'irritation et la sortie du site sont un effet naturel.
La technologie AJAX peut ne pas répondre aux attentes des utilisateurs : techniquement, chaque page AJAX est sous la même URL, mais il semble que de nouvelles pages s'ouvrent.
Dans un contexte de commerce électronique, les utilisateurs ont une perception claire que la page 3 et la page 4 sont distinctes, et que la quatrième à la troisième peut être parcourue en utilisant le bouton retour.
Les utilisateurs ne sont pas prêts à abandonner le bouton de retour
Compte tenu de l'utilisation généralisée de cette fonctionnalité du navigateur Internet, la question de l'inadéquation des attentes des utilisateurs avec la vision des développeurs devient critique - à ne pas prendre à la légère.
Le bouton « revenir en arrière » était particulièrement apprécié des utilisateurs d'applications mobiles et de sites Web. Comme le montre l'étude des versions mobiles des sites, la majorité des utilisateurs ont utilisé cette fonction sur l'ensemble des ressources proposées. De plus, l'utilisation du bouton ne se limite pas à reculer d'une page - certains sujets l'ont appuyé jusqu'à 15 (!) Fois d'affilée.
Les utilisateurs de PC appuient également souvent sur un bouton - mais pas de la même manière que les utilisateurs mobiles, car les utilisateurs de bureau peuvent facilement naviguer sur le site.
Solution
La bonne nouvelle est que HTML5 a une solution relativement simple au problème, et elle s'appelle l'API d'historique HTML5. Plus précisément, la fonction history.pushState() permet de modifier l'URL sans recharger la page. En conséquence, le site se comportera de manière adéquate aux attentes de l'utilisateur qui aura appuyé sur le bouton "retour".
Dans cet article, nous verrons comment vous pouvez créer un bouton "Retour" à tout endroit dont vous avez besoin. Je pense que d'après le nom même du bouton, il est déjà clair ce qui se passera lorsque vous cliquerez dessus. Un tel bouton peut être inséré à la fois dans une catégorie et dans le matériel lui-même. Tout se fait assez simplement.
Il existe plusieurs options pour ajouter un bouton, mais personnellement, je n'ai utilisé qu'une seule méthode. A savoir, la troisième option sur les trois que j'ai proposées. Un peu plus loin, je vais vous dire pourquoi exactement il.
Quelles options avons-nous du tout :
- Modifiez les fichiers de modèle Jooml.
- Collez simplement le code du bouton où vous le souhaitez.
- Créez le module "HTML-code", insérez-y le code du bouton, puis affichez ce module au bon endroit.
L'avantage de la troisième option est que si vous devez éditer le texte sur le bouton ou modifier/ajouter une classe de style, vous devrez alors corriger le module lui-même, et non pas fixer le bouton à tous les endroits où il se trouve.
Ainsi, sur un de mes sites j'ai utilisé la troisième option :
Le module "HTML-code" a été créé et là, à l'aide de l'extension "Sourcerer", qui permet d'ajouter n'importe quel code au matériel, le code du bouton a été inséré.
Mon code de bouton de travail :
Le texte est légèrement décoré d'une flèche utilisant des composants de bootstrap 3, et le bouton lui-même est stylisé avec CSS.
