Back button in source code. Create a "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 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 way. Namely, the third option out of the three I proposed. A little further I’ll tell you why.

What options do we have:

  • Edit Jooml template files.
  • Just paste the button code in the right place.
  • Create a module "HTML code", insert the button code there, and then display this module in the right place.
  • The advantage of the third option is that if you need to edit the text on a button or change/add a style class, you will only need to fix the module itself, and not fix the button in all the places where it is located.

    So, on one of my sites I used the third option:

    The “HTML code” module was created and the button code was inserted there using the “Sourcerer” extension, which makes it possible to add any code to the material.

    My working button code:

    come back

    The text is slightly decorated with an arrow using components from Bootstrap 3, and the button itself is styled via CSS.

    In this video tutorial we will look at 3 options for how to make a BACK button to move around the site to previous pages in reverse order. The BACK button is also necessary when links from several pages of the site (A1, A2...An) lead to the same page (B), and from this page (B) you need to return to the previous page (An) of the site from which you got to page (B).

    Watch the new video tutorial:

    Code for the “go back” button for placement on the site:

    < a href = "#" onclick = > < img src = "assets/back2.png" alt = "Back" / > < / a >

    Back button. What is it for?

    In this video tutorial we will make a button to return back to previous pages of the site in Adobe program Muse. This button will return along the same path that we followed on the site.

    Back button. Lesson project.

    In order to make this lesson, I prepared a small project, or rather it cannot be called small, here it consists of top-level pages, first-level pages, and also for the “page-2” page there are several more child pages. And for variety, I created two templates. I applied the first template to the first three pages. And I applied the second template to everyone else.

    Let's start. We will create a Back button in “Template C” so that it immediately appears on those pages to which this template is applied. I go to edit this template, and this is where we will insert our back button.

    Back button. 3 ways.

    We can insert a “Back” button in three ways. I have a special file that I have already prepared in notepad. And there are three ways, three codes, using which we can insert such a button on the site.

    Back button. Method No. 1 - simple text.

    The first option is just text. The button will be in the form of text. I copy this code:

    < input type = "button" onclick = "history.back();" value = "Back" / >

    And I paste it into the template. It looks like this. We just have text and it is highlighted in white. I'll post it here. In order to understand how this all works, we press the ctrl+alt+E keys to view the entire site with all its pages in the browser. This is what the main page of the site looks like. We can surf the menu, select pages. Here we have drop down menus. And, for example, from the main page we immediately went to page “page-3”. And here we have a back button.

    This button is active, but when you hover the mouse over it, a hand with a finger does not appear. We can safely click on this button, and we will be redirected back to the main page. In the same way, we can click on page “page-3”, then go to page “page-4” and click on the “Back” button, it will take us to page “page-3”, and if we click on the “Back” button again ", then it takes us to the main page. This is how the back button works.

    But it’s difficult to call this button a button, since it is just such an inscription, highlighted in white. If we want to edit it in Muse, we can only change the size of the text, for example, I'll put "36" here so you can see it better. In my opinion, we cannot change the color of the text. Now I'll try to put red. I chose red, but this did not affect our lettering in any way, so we cannot change the color. We can change the size. Let's try to make it bold and center it. All we can do is edit like this. If we want to fill this block, for example, make it orange, then our text will still be highlighted in white, and, in principle, it does not look very nice.

    Back button. Method No. 2 – Link text.

    < a href = "#" onclick = "history.back();return false;" >Back< / a >

    Now we will copy it. I press ctrl+C and go to the program, and press ctrl+V to paste it onto the site. It looks like this link. Our link is blue. Now she is not very visible. Let's also make a 36th font to enlarge it and see it closer. Here we have just a blue link. If we now press ctrl+alt+E, we will see that when viewed, it looks like this regular blue link. Let's go over it a couple more times to see, click once, twice, come back. This link has the same appearance as a regular link.

    We can apply link styles to it in Adobe Muse. Find link styles in the “Hyperlinks” section, select “Edit link styles”. I already have a prepared version. Now I already have a prepared version. You can see that it has a style applied to it. In the standard state and when hovering the mouse cursor, the color is blue and in the active state - red. You saw it while watching. The second style I created was simply all black states. We can apply this style to this button. For example, I'll select and apply this custom style to this button. And you will see that our inscription has turned black.

    Here we can also do a fill, for example, I'll do it with the same orange color. Here you can already edit the text. Let's put it in the middle and make it bold. And, in principle, this option is already more similar to a button. There is no longer such a white highlight, and, in principle, this option is already quite suitable. While browsing (ctrl+alt+E), let's go to page "page-3", to page "page-4" and click again. This button works exactly the same as the first one, only it has more options for editing the design.

    Back button. Method No. 3 – button – picture.

    And the third option for how we can place a button is that the button will be an image. I copy this code:

    < a href = "#" onclick = "history.back();return false;" > < img src = "img.png" alt = "Picture" / > < / a >

    I go to Muse and click “Insert”. And this third option we have is a picture. In order for us to have some kind of picture here, we need to download some picture file from the Internet or create it ourselves. We add the picture through the “File” function of the program, select “Add files for transfer”. I have already downloaded a couple of pictures from the Internet. We can choose one. Let's select this one with the back button. Now if we look in the “Resources” section, we have added a button “back2.png” - “Transmit”. We have this file for transfer.< a href = "#" onclick = "history.back();return false;" > < img src = "assets/back2.png" alt = "Back" / > < / a >

    That's it, click "OK". We won't see any changes in Muse itself. We will see all changes only when viewing the site in a browser. Let's press ctrl+alt+E again to view the site in the browser and try to surf our pages.

    Back button. View the result.

    Let's go to the page, for example, "page 2-1", now let's go to page "page-2", now let's go to page "page 3", then to page "page-4". And now, if we press the back button, we will go back sequentially in reverse order to home page site. Click “Back”, move to page “page-3”, to page “page-2”. And here we no longer have a button. If we placed it in a template that was applied to page “page-2”, then we would also have a “Back” button here. Since we don't have one, we have to navigate to the main page only by clicking on the "Home" button in the menu. Let's go, for example, to page “page 2-2-2”, then go to page “page 2-2-1”, then to pages “page-3” and “page-4”. And now in reverse order: page “page-3”, page “page 2-2-1”, page “page 2-2-2” and to the main page.

    Of course, you don’t have to place this button on your website, but use regular arrows in your browser. But if you want such a button to be on your website, then you can make it in these ways... And the link to the article will be under this video. That's all. Dmitry Shapovalov was with you. Like this video, subscribe to the channel, write comments below, and I say goodbye to you until the next video lessons.

    Sometimes on web pages there is a need to temporarily go to some other (let's call it auxiliary) page, and then return back and continue working with it. For example, this could be a help page, registration page.

    In this case, obviously, the return address can be very different. How to implement such a reverse transition on a website? Pure html/CSS is not enough here; you will need to use javascript.

    The simplest thing is, for example, using this line in the script on the auxiliary page:

    The history method remembers the history of navigation on a page and, in fact, its use is similar to using the browser's Forward and Back buttons, only a little more functional. This is the simplest and most convenient way, but only under one condition: if the new (auxiliary) page is not opened in a new window. Otherwise, the auxiliary page will be opened for the first time (more precisely, it will be the first session for it, there have been no 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 is forced to open the page in a new tab or the browser does it for him - in accordance with the settings. In this case, the link attribute target=”_self” will not help: it will be impossible to go back from an open auxiliary page (unless, of course, you enter the URL of the source page manually in the browser address bar).

    A more universal way

    To implement it, you will need scripts on both the source and auxiliary pages. The idea may vary. One of them is based on the fact that the address (URL) of the source page is stored in the browser's address bar as a GET request. Thereby. The helper page, when receiving such a request, knows about its source. Based on this, it becomes possible to switch back, i.e. to the page from which the transition was made.

    Schematically, this can be represented as follows:

    Script on original page

    On the page WHICH the transition should be made, there is the following script, which is a function - a mouse click handler (onclick):


    function save_back(url) (

    var docum_href = document.location.toString().substring(docum_protocol.length+2);
    if(docum_href.substring(0,1) == "/") (
    docum_href = docum_href.substring(1);
    }
    var href = window.location.protocol+"//"+document.location.hostname + url + "?"+docum_href;
    window.open(href);
    }

    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:

    Click to go to support 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 you click on the link. 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 determined, as well as the rest of the URL of the original web page, including possibly any GET request data (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 occurs.

    Script on help page

    It should have a script like this:





    var docum_protocol = document.location.protocol;
    var number_questions = docum_location.length-1;

    var question = "";
    if(number_questions > 1)(
    question = "?";
    }
    document.location = docum_protocol+"//"+ docum_href + question + get;
    }

    This script will also be launched when the mouse clicks on any element on which the corresponding handler is installed:

    Return

    This line cancels the default action when the mouse clicks on a link. 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 an 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 page, 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 a URL can contain two such characters. The first will appear, as already mentioned, due to the fact that the address (minus the protocol) of the source page has been added to the address of the auxiliary page. And the second could be present as a result of the presence of GET request parameters when loading the source page. In other words, there may be one or two question marks in the address bar of the help page. To go from a secondary page to the original page when you click on a link

    Return

    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.

    Notes

    In addition, it should be noted that the article, in fact, is not about returning to the original page, but about reloading it. This, of course, is just an imitation of a return. In particular, the data entered on this page and its settings may not be saved. In addition, unlike RETURN, when the page loads, it will be opened from the very beginning of the site (i.e., its upper part will be located at the top of the screen). Whereas a “true” backtrack returns the (original) page to the exact location from which the jump was made. Therefore, let's try to combine both methods.

    Combined method

    So, let's set the task:

    if the auxiliary page opens 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 auxiliary page will change slightly (the line mentioned above will be added):


    function return_to_initial_page() (
    history.back();
    var docum_location = document.location.toString().split("?");
    var docum_href = docum_location;
    var docum_protocol = document.location.protocol;
    var number_questions = docum_location.length - 1;
    var get = docum_location;
    var question = "";
    if (number_questions > 1) (
    question = "?";
    }
    document.location = docum_protocol + "//" + docum_href + question + get;
    }

    First we try to go back. If it works, the rest of the script will not work and you will return to the original page in the same place from where the transition was made. If not, then, as before, we extract the address of the source page from the parameters of the GET request and go to it.

    Conclusion

    Of course, this article shows only one of the technology options for “returning” BACK - to the original page. For this purpose, in addition to the GET request, other technologies could be used, for example local storage localStorage. In addition, to fully simulate a return BACK, it would be nice to transmit the scrolling amount of the original page via a GET request - so that later, even when opening the auxiliary page in a new window, you can return to the same place on the original page from where the transition was previously made.

    Many usability studies show that users (both new and experienced) often use the "go back" button in the browser. Unfortunately, front-end designers and marketers rarely consider what implications this might have for usability, given modern web design models that use apps, animation, video, and more. Often, the technical structure of these layouts does not respond correctly to the “go back” function, breaking the user’s mental pattern and degrading their experience.

    The consequences of this can be dire: during experiments, the site’s inadequate response to pressing the “back” button was the reason for many users leaving, with abuse and unflattering reviews. In most cases, even the venerable, gray-haired subjects lost their temper terribly.

    From this article you will learn:

    • what users expect from the “go back” button;
    • what are the 5 most common mistakes;
    • a simple solution to these problems.

    The solution is really very simple, but it is often neglected even by the largest brands. Shall we fix this error?

    User Expectations

    In short: Users expect a “go back” button to show them what they perceive as the previous page. The word “perceive” is very important, because there is a huge difference between what appears to be the previous page and what technically is it.

    The question arises: what exactly do users interpret as a new page? In most cases, if a page is significantly different visually, but is conceptually related to the site, then it is perceived as new. Therefore, it is very important to monitor how the site processes various interactive elements: lightboxes, forms, filters, etc.

    Most visitors do not understand technical aspects, but rely only on intuitive ideas about how the resource should work. Therefore, when they click the “back” button, they expect a page where they have already had an important experience, but they receive a page with a slightly changed interface.

    Below are the most popular interactive elements and recommendations for using them to maximize user experience and usability.

    The purpose of implementing 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 end up in a completely different place than 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 online shopping sites.

    Using filters often transforms a page and gives a person a new experience. Therefore, after sorting, the page is perceived as new, even if nothing was loaded on it. This happens because after each visitor interaction with the online store page, a new result is generated.

    This example highlights that people do not go into technical aspects when determining new page, but use only intuition and formed perception.

    3. Registration/payment form

    Payment pages are perceived as new pages, and even worse - as a multi-step process, each stage of which can be canceled with a “go back” button.

    This approach can cause problems; a simple example is that 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 meet user expectations: Each AJAX page is technically under the same URL, but it appears that new pages are opening.

    In the context ecommerce Users have a clear perception that page 3 and page 4 are separate and can be navigated from page 4 to page 3 using the back button.

    Users are not ready to give up the back button

    Considering how widely used this Internet browser feature is, the issue of mismatch between user expectations and the developers' vision becomes critical and should not be taken lightly.

    Users especially liked the “go back” button mobile applications and websites. As the study showed mobile versions sites, the majority of users used this function on all offered 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 also often press the button - but not as much as mobile phone owners, because users desktop computers Convenient site navigation is available.

    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 in accordance with the expectations of the user who clicked the “go back” button.

    Publications on the topic