Sometimes on web pages it becomes necessary to temporarily go to some other (let's call it auxiliary) page, and then go back and continue working with it. For example, it can be - help page, registration.
In this case, obviously, the return address can be very different. How to implement such a reverse transition on the site? Pure html / CSS will not be enough here, you will need to use javascript.
The simplest thing is, for example, using this line in a script on a helper page:
The history method remembers the history of transitions on the page and, in fact, its use is similar to using the browser's "Forward" and "Back" buttons, only slightly more functional. This is the simplest and most convenient way, but only on one condition: if the new (auxiliary) page is not opened in a new window. After all, otherwise the auxiliary page will open for the first time (more precisely, the session for it will be the first, there have not been any transitions on it yet). And this means that, in fact, there is nowhere to go back. Therefore, this method cannot be called universal. It will not work if the user forcibly opens the page in a new tab or the browser does it for him - in accordance with the settings. In this case, the target = "_ self" attribute of the link will not help: it will not be possible to navigate back from the open auxiliary page (unless, of course, you enter the URL of the original page in the browser address bar manually).
A more versatile way
To implement it, you will need scripts on both the source and auxiliary pages. The idea can be different. One of them is based on the fact that the address (URL) of the original page is stored in the address bar of the browser as a GET request. Thereby. the helper page, when it receives such a request, knows the origin of the request. Based on this, it becomes possible to switch back, i.e. to the page from which the transition was made.
This can be schematically represented as follows:
The script on the original page
On the page, WITH WHICH the transition should be made, there is the following script, which is a function - the handler of the mouse click (onclick):
In order for the function in the script to work, you need to install its handler on some element in one of the ways, for example, like this:
http://example.com "onclick =" to_comment_rules (“http://example.com”); return false "> Click to go to the sub page
Note that the href attribute of this link has a corresponding address, which is specified in the onclick event handler function. This is done so that search robots understand which page the link will go to when the link is clicked. If this is not needed, then you should make an empty href attribute, like
The principle of this script is that when the save_back (url) function is called, a (auxiliary) page with the url address is opened. To do this, the protocol of the page (for example, http or https) is defined, as well as the rest of the URL of the original web page, including with, perhaps, the available data of the GET request (this is what is in the URL after the "?" Sign). The received data is added to the URL of the page being opened - and a transition to it takes place.
Script on helper page
It should have something like this script:
This script will also be launched when the mouse is clicked on any element on which the corresponding handler is installed:
Return
This line overrides the default link click action. The fact is that by default the link is followed. In this case, the transition will occur exactly to the address specified in the href attribute. This address (in particular, on the auxiliary page) may not contain the return address of the page from which the transition was made (if the transition to the auxiliary page is possible not from any one specific, but from several source pages).
So, the script on the helper page reads the contents of the address bar and then splits it into an array of "?" Elements. Please note that there can be two such characters in the URL. The first will appear, as already mentioned, due to the fact that the address of the original page was added to the address of the auxiliary page (minus the protocol). And the second could be present as a result of the presence of the parameters of the GET request when loading the original page. In other words, there may be one or two question marks in the subpage address bar. To go from the auxiliary page to the original one when clicking on the link
the request is read from the address bar and converted to the same form that it had on the original page, after which the page is loaded at this address.
Remarks
In addition, it should be noted that the article is not really about returning to the original page, but about reloading it. This is, of course, just an imitation of a return. In particular, the data entered on this page, its settings may not be saved. In addition, unlike the RETURN, when the page is loaded, it will be open from the very beginning of the site (i.e. its upper part will be located at the top of the screen). Whereas "true" backtracking returns the (original) page exactly where the navigation was made. Therefore, let's try to combine both methods.
Combined method
So, let's set the task:
if the auxiliary page is opened in the same tab (window), then let the history.back () method be available;
but if the auxiliary page opens in a new window, then the method discussed above should work (because in this case history.back () will not work).
The script on the helper page will change slightly (the above line will be added):
First, we try to go back. If it works, the rest of the script will not work and will return to the original page in the same place from which the transition was made. If not, then, as before, we extract the address of the original page from the parameters of the GET request and go to it.
Conclusion
Of course, this article shows only one of the options for the "return" technology BACK- to the original page. For this purpose, in addition to the GET request, other technologies could be used, for example, the local storage localStorage. In addition, to fully simulate the return BACK It would be nice to send through a GET request the amount of scrolling of the original page - so that later, even when opening the auxiliary page in a new window, return to the same place on the original page from where the transition was made earlier.
Many usability studies show that users (both novice and experienced) often use the back button in their browser. Unfortunately, front-end designers and marketers rarely give a thought to the usability implications of this, given the current web design models that apps, animations, videos, and more use. Often, the technical structure of such layouts does not respond well to the go-back function, which breaks the mental pattern of users and degrades their experience.
The consequences of this can be dire: during the experiments, the site's inadequate reaction to pressing the "back" button was the reason for the departure of many users, moreover, with abuse and unflattering reviews. In most cases, even the respectable, gray-haired test subjects lost their temper terribly.
In this article, you will learn:
- what users expect from the back button;
- what are the 5 most common mistakes;
- simple solution to these problems.
The solution is really very simple, but it is often neglected even by the biggest brands. Shall we fix this error?
User expectations
In short: users expect the go back button to show them what they perceive as the previous page. The word "perceive" is very important, because there is a colossal difference between what appears to be the previous page and what is technically it.
The question arises: what exactly do users interpret as a new page? In most cases, if a page is significantly different visually, but at the same time is conceptually related to the site, then it is perceived as new. Therefore, it is very important to track how the site handles various interactive elements: lightboxes, forms, filters, and more.
Most of the visitors do not understand technical issues, but rely only on intuitive ideas about how the resource should work. So when they click the back button, they expect a page that has already had important experience, and they get a page with a slightly redesigned interface.
Below are the most popular interactive elements and how to use them to maximize user experience and usability.
The purpose of embedding overlays and lightboxes is to show the user an element that appears on top of the page. Therefore, users perceive such elements as new pages, and press the "back" button to return to their original position - but they do not go where they expected. This is especially unfortunate, because the use of lightboxes only multiplies the negative perception of the web page - most users do not like these elements on the sites of online stores.
Using filters often transforms the page and gives the person a new experience. Therefore, the page after sorting is perceived as new, even if nothing was loaded on it. This is because after each interaction of the visitor with the page of the online store, a new display of results is obtained.
This example emphasizes that people do not go into technical aspects when defining a new page, but only use intuition and formed perception.
3. Form of registration / payment
The payment page is perceived as new pages, and even worse - as a multi-stage process, each stage of which can be canceled with the "go back" button.
This approach can bring problems, a simple example - a person wants to go back a step in filling out a form in order to edit the information entered. Pressing the "back" button returns it to the basket, and deletes all (!) Entered data. Irritation and leaving the site is a natural effect.
AJAX technology may not live up to user expectations: technically, every AJAX page is under the same URL, but it looks like new pages are opening.
In an e-commerce context, users have a clear perception that page 3 and page 4 are separate, and that the fourth to the third can be navigated by using the back button.
Users are not ready to give up the back button
Given the widespread use of this feature of the Internet browser, the issue of mismatching user expectations with the vision of developers becomes critical - not to be taken lightly.
The "go back" button was especially liked by users of mobile applications and websites. As shown by the study of mobile versions of sites, the majority of users used this function on all the proposed resources. Moreover, the use of the button is not limited to rolling back one page - some subjects pressed it up to 15 (!) Times in a row.
PC users often press a button too - but not in the same way as mobile users, as desktop users can easily navigate the site.
Solution
The good news is that HTML5 has a relatively simple solution to the problem, and it's called the HTML5 History API. More specifically, the history.pushState () function allows you to change the URL without reloading the page. Accordingly, the site will behave adequately to the expectations of the user who has pressed the "go back" button.
In this article, we will look at how you can create a "Go Back" button in any place you need. I think from the very name of the button it is already clear what will happen when you click on it. Such a button can be inserted both into a category and into the material itself. Everything is done quite simply.
There are several options for how you can add a button, but I personally only used one method. Namely, the third option out of the three I have proposed. A little further I will tell you why exactly he.
What options do we have at all:
- Edit Jooml template files.
- Just paste the button code where you want.
- Create the "HTML-code" module, insert the button code there, and then display this module in the right place.
The plus in the third option is that if you need to edit the text on the button or change / add a style class, then you just need to correct the module itself, and not fix the button in all the places where it stands.
So, on one of my sites I used the third option:
The module "HTML-code" was created and there, using the "Sourcerer" extension, which makes it possible to add any code to the material, the button code was inserted.
My working button code:
The text is slightly decorated with an arrow using components from bootstrap 3, and the button itself is styled with CSS.
