Oct. 30th, 2012

codeman38: Osaka from Azumanga Daioh enjoying sticking her face into a bed of flour a bit too much; captioned 'headdesk'. (headdesk)

I've never been a huge fan of the whole 'infinite scrolling' pattern, largely because there are so many ways to implement it wrongly, and so many implementations seem to screw it up.

Consider the following use cases, both of which I've experienced, and the expected behavior that would occur on a normal paginated implementation:

  1. You're on a site with infinite scrolling, and decide to click on a link within a post that's several pages down. The website's maintainers didn't add a 'target' attribute to links so that they'll open in a separate window, so the link you clicked on takes over the window. You have to click your browser's 'back' button to return to the page you were just viewing.

    Expected behavior: When you click 'back', you'll be returned to the post you had just been viewing.

  2. You're using a public Wi-Fi connection that's a bit overloaded by all the other users on the same network. The connection often ends up timing out before web pages finish loading, and it's frequently necessary to reload the page several times until all of the content manages to load.

    Expected behavior: When you reload the page, you'll be returned to the same general set of posts where you had been before reloading.

The question, then, is: if your site uses infinite scrolling, does it produce the expected behavior in these scenarios?

With LiveJournal's new friends page beta, the answer is a resounding NO.

How can we screw up infinite scrolling? Let me count the ways... )

Profile

codeman38: Image of a Shy Guy and several Hothead enemies from Super Mario, with the caption 'A shy guy in a world of hotheads'. (Default)
Cody B.

December 2018

S M T W T F S
      1
2345 678
9101112131415
16171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 15th, 2025 09:03 am
Powered by Dreamwidth Studios