Animated scroll vs jump for a "back to top" button

Question

I am looking at implementing a back to top button for documentation pages that tend to get very long.

The button will be shown in a fixed position at the bottom right of the screen.

My question is: when the user clicks on the button, should the jump to the top of the page be immediate, or should I instead implement a javascript solution where the viewport scrolls (animated) back to the top?

Answer 1

This is not about fancy "cinematic effects" or decoration. The animation actually serves the purpose of telling the user, that he or she is returning to a previous section of the document, thereby counteracting attention blindness and preventing confusion, especially in the case of the user accidentally clicking the back to top button.

So yes, animate.

Answer 2

Both work, but it's more important to make sure that the top of the page is visually clear

Let's look at what happens when the user hits the home or scroll to top button:

1. The screen changes (either by scrolling or by jump).
   • This is going to be cognitively disruptive for long documents, whether you scroll or jump: the user will still be confronted with a new page of content.
2. User expects to be a the top of the page.
3. User visually confirms that she is back at the top
4. User continues with her workflow

What can we learn from this?

Smooth scrolling can help reduce friction #1, but the user STILL has to go through #2 and #3.

On the other hand, if you can take care of #3, then #1 and #2 don't matter as much. By making sure the user quickly confirms top of page orientation you are speeding up the overall user flow.

---

What does this mean for you?

• Before thinking of scrolling, make sure that the top of the page is clear for the user "at a glance".
• Scroll vs jump is then a secondary decision. I'd recommend:
  • If users tend to return to top frequently (e.g. they are diving into particular sections then returning to the top to choose another section), then responsiveness/speed and workflow are more important than smootheness so jumping is just fine. That's why many long technical documents tend to use jumps.
  • If users are new to the document, or position within the document matters as context, then scrolling can help communicate that positional context to users.
  • Scrolling is obviously a little smoother as a transition, but it's easy to overestimate the usefulness of animations...they can also make the site feel frustratingly slow to users who are, say, looking for a speedy answer in a technical document....here the impression of responsiveness conveyed by a jump may actually improve the user experience.

Answer 3

Never use an abrupt change on the layout. Instead, use a transition to avoid confusing the user in case of accidentally touching the "scroll to top" button. And same goes for any other action performed on your page/app: some mild transition helps the user understand there's a change in what he was seeing.

Now, for long documentation pages, instead of a "back to top", I suggest using an "anchor" navigation, allowing the user to navigate through different sections, chapters or title. See a simple screen I made to illustrate what I mean

Finally, you can read more about the use of transitions applied to actions at the following links:

• http://azumbrunnen.me/blog/transitions-in-ux-design/
• http://i-proving.com/2014/04/09/ui-ux-considerations-the-effective-use-of-transitions-and-animations/
• https://creativemarket.com/blog/2014/07/24/ux-tips-why-transitions-matter

Answer 4

The Home key gets you to the top of the page.

The only time I've found a "Go to top" button useful is on infinitely scrolling web pages where some cleanup is done when you click the button.

If you do implement it, have it collect some stats, see how many people actually use it. I would be surprised if many do.

Jump vs Scroll

A smooth scroll can provide a "cinematic" effect. This is nice on certain types of sites/webapps. But if this is documentation, especially technical documentation, avoid cumbersome animation.

If it slows the user down, it should be avoided when your website's main purpose is productivity.

So while I don't see the button as useful, if you do implement it, make it jump to top.

Take a look around

Look at the documentation for similar products/services. If it's code, something like the momentjs docs are a great example. I can hunt for some different examples if you can be more specific about the documentation type.

Answer 5

It is a good question. If the size or length of the page is very long then don't use immediate transition from bottom to top. Instead provide page breakups like jump to title1, title2 etc.

If the length of page is not really long then you can go with the transition but some subtle animation. It should be immediate change for a user.

Answer 6

Start by questioning the design requirements, for example:

- What is the intended purpose of the documentation page?

- What is the desired outcome.

I think having back to the top button only masks information architecture issues and lays the burden of dealing with complex content on the user.

A more structural solution would be to focus on understanding the documentation, its inherent structure and potential and restructure it in a meaningful manner if necessary. Documentation pages like these could evolve and perhaps add more value.

---

Below are few approaches you can explore to deal with long documentation pages:

• Text organisation is key, so its important to provide users with clues. These could include: Section titles, sub-titles, illustrations etc. This will allow users to efficiently survey the documentation to get a general idea of what it is about before digging deeper into the details if the wish to do so.

• You could also explore ways of disclosing additional information in a progressive manner, which should allow you in principal to shorten the page considerably and give more control to your users.

• Consider providing a navigation menu.This is far more explicit and practical than back to top button.