7

Sometimes whilst bored I read old xkcd's annd although I know all the comics, I do from time to time discover a title text I hadn't seen before. This time I came across

Megan is standing over a book, turning the pages very carefully by touching only the edges. Cueball is standing behind Megan. Cueball: Why are you turning the pages like that?Megan: If I touch the wrong thing, I'll lose my place and have to start over.

Which had the title text: "Maybe we should give up on the whole idea of a 'back' button. 'Show me that thing I was looking at a moment ago' might just be too complicated an idea for the modern web."

This made me think, would it be a good UX practice to make the back button scroll up the page instead of going back a normal URL? And have a refresh load up that specific place in the infinite list instead of the top of the list. As far as I can see there is no technical reason not to do this, yet I haven't seen this implemented anywhere, so I am hereby asking whether you guys know of anybody who researched and/or implemented this? And if not just for opinions which disadvantages this approach could have. (Or a simple 'Yes you should do that!' if none of the before applies).


Example for the UX folk

You are on BBC.co.uk and go to Facebook. You scroll down a couple of pages, when you hit the back button, instead of going back to BBC you just scroll up one page. Till you get up till the first, after which you would after all just go back. When you copy the URL and bookmark it you are able to find the post you were just looking at (and still scroll up for more posts up till the most recent one).


Tech details for the Tech folk

With the History API in the browser you can change the URL at any time, so when you would scroll down you would see the URL change the ?p=n (or in the above example t=i) part all the time. Going back would thus just go back to the previous URL state. (The facebook example would require a simple interaction between replaceStates all the time and a single pushState per page).

  • 1
    My first thought is that pressing back when I have scrolled down to go up one page is pretty abstract - since I don't scroll down one "page" at a time. So the back stage is trying to mimic a discrete step of something that is continuous. – Henrik Ekblom Nov 25 '14 at 14:59
  • @HenrikEkblom: I know, yet the alternative seems to be worse. Though I am open for any thoughts, it seems a pretty interesting issue to tackle. Maybe I should have made the question more generic and self answered... hmm, if anybody thinks I should change it, say so :P – David Mulder Nov 25 '14 at 15:02
  • The question is: Do users have a problem with clicking the back button after scrolling and generally expect it to not go back to the previous web page? I know that it's a problem for some when there are AJAX-ish loaded web content inside paged, where the user thinks he has changed page after an interaction... – Henrik Ekblom Nov 25 '14 at 15:07
  • 1
    Do you really need infinite scroll? Depending on your sites purpose it could be causing more problems than solving - ux.stackexchange.com/questions/33406/… Etsy and Booking.com found that it lowered conversions. Depends on the purpose of your site/app of course. – Stephen Keable Nov 25 '14 at 15:13
  • 1
    @StephenKeable: Yeah, well aware that if you wish to force users to action you shouldn't use infinite scrolling. But right now I was just pondering about how it should function in relation to the back button. After all, the number of times I hit an advertisement by mistake on an infinitely scrolling webpage is countless... so there definitely is an UX problem to be solved here. – David Mulder Nov 25 '14 at 18:08
3

Since the infinitely scrollable page has no real world parallel, perhaps the function of the back button can exist without a real world metaphor.

Imagine that you have been scrolling down an infinite page, pausing for some parts and zipping past others. Now imagine that you tap the back button. What is your intention? too jump back up to the most recent part which you paused on? go back to the top of the page, or maybe you want to leave the scrolling page entirely. It is impossible for the page to know from that single button click, what you desire.

So the page should ask you what you meant by that back click, and it should ask in the least obtrusive manner available.

Split the screen vertically, and leave half showing the current point on the infinitely scrolling page. In the other half, show a menu offering title-text from the last few scroll points which you paused for. Add a button for "top of page" and a button for "leave page".

  • Tapping the current article's part of the screen, gets rid of the menu, returning the interface to full screen.
  • Tapping on any of the menu options moves the scroll to the selected part and banishes the menu.
  • Tapping the top of page button does what you would expect.
  • Tapping the leave page (or hitting the back button again), leaves the page.

The toughest part would be writing the javascript to monitor the page for scrolling and keep a list of recently paused parts of the page.

-3

I think it's abusing push state Api by pushing state every time you scroll down one page

Plus it's annoying that when I scroll down 10 pages I have to click back 10 times to go back To where I came from . In that case I would just close the window

  • 1
    This does not appear to really be answering the question. Can you expand on your answer to make it clear how it addressing the question? Please include links to references that show your answer is based on how people actually interact with systems, versus simply your personal opinion. – Evil Closet Monkey Nov 25 '14 at 18:32

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.