12

I have come across a lot of infinite scrolls browsning the web but I have yet to find one that does not break when returning back to the list from for example looking at a newsarticle. What is the appropriate way to deal with the "back" button going back to the list?

In most cases I get to the top of the list and I have to scroll down all over again(loading more and more for each article I watch further down in the list). It can even be so frustrating that I just don't want to browse older articles on mobile devices! (On a desktop I mitigate this issue by opening the article in a new tab)?

Does anyone have an example where this problem have been solved in a ux friendly way? Maybe only load the last chunk the user was actually on? Loading the complete list all the way down to the user's previous position seems rather inefficient.

Improve this question
2
  • possible duplicate of Infinite scrolling + back button – Igor Milla Jan 28 '15 at 12:57
  • 1
    That other question seems to be about adding scroll events to the browser history and using the browser back button to move back within the same page, whereas this question is about navigating from an article page back to a point in an infinitely scrolling page. Similar but I'm not sure it's a duplicate. – Matt Obee Jan 28 '15 at 14:16
10

I think the forum software discourse has a good solution for this.

They are updating the url while you are scrolling down. If you goto to another page from the list and return using the back button, you are at the same position you have left the page.

Try it yourself: http://try.discourse.org/

This blog article has more details of the reasoning behind this and about the implementation:

http://eviltrout.com/2013/02/16/infinite-scrolling-that-works.html

Improve this answer
4
  • That is a nice solution. I wonder if it reloads the entire page or if it is cached or something? My concern is that if you have a big list and you scrolled down like 200 pages. Go into an article and back and it reloads 200 pages again, which seems inefficient both bandwith and that the user have to wait quite a long time. Edit: Thanks for the link, will read. – Todilo Jan 28 '15 at 8:05
  • 1
    The browser can cache the requests. I think I've read that the number of elements in the Dom is the challenging part. But they try to remove elements from Dom the which are not currently needed. – stefan.s Jan 28 '15 at 8:07
  • Very valid point @stefan.s a hughe list is very resource heavy DOM wise. – Todilo Jan 28 '15 at 8:09
  • 1
    "They are updating the url while you are scrolling down" I don't think this is the case anymore – rofrol Jan 8 '17 at 18:36
1

You pretty much answer your own question:

  • Update the URL to reflect whatever content is being shown

Here's an example: http://blog.rnf.me/ux-of-urls/#/.

As you press space bar to move through slides, the URL updates: http://blog.rnf.me/ux-of-urls/#/19.

The URL update is also a little delayed so that you don't pollute your Back history too badly. However, for me, I'd like a slightly longer delay.

Improve this answer
2
  • 3
    You can update the URL in a way that remove the last version of the URL from the back history. – Ian Jan 28 '15 at 10:12
  • Not Found anymore – PirateApp Oct 2 '19 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.