Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Infinite Scrolling: When to Use It, When to Avoid It

nngroup.com

Post reply on HN
Print view View original

161–170 of 175 posts

Re: Infinite Scrolling: When to Use It, When to Avoid It

#161

Post by bastawhiz »

xorcist wrote: post #57
Dalewyn wrote: post #2

Infinite scrolling is universally bad for one, very simple reason: It breaks the scroll bar. One of the purposes of a scroll bar is to indicate how long (and/or wide) some piece of content is relative to your window. Another purpose is to indicate your current X/Y position within some piece of content. Both of those purposes are completely broken with the use of infinite scrolling, because the length (and/or width) o…

It also breaks the find button. The item you wanted to search might get unloaded, or not loaded yet, in some bizarre attempt at optimization when the javascript library resposible is an order of magnitude larger than the actual content anyway. My phone has gigabytes of memory. If you want to present five hundred items in a web shop, just list them and do not bother with any type of pagination, invisible or otherwise.

In fairness, without unloading, it will be slow. Really slow. I never added unloading to a long list in my app, and for lists with thousands of items, Chrome will take seconds to paint on my MBP if you do any vigorous scrolling. It's not about memory use, it's about practical browser performance.

Re: Infinite Scrolling: When to Use It, When to Avoid It

#163

Post by spicybright »

xorcist wrote: post #57
Dalewyn wrote: post #2

Infinite scrolling is universally bad for one, very simple reason: It breaks the scroll bar. One of the purposes of a scroll bar is to indicate how long (and/or wide) some piece of content is relative to your window. Another purpose is to indicate your current X/Y position within some piece of content. Both of those purposes are completely broken with the use of infinite scrolling, because the length (and/or width) o…

It also breaks the find button. The item you wanted to search might get unloaded, or not loaded yet, in some bizarre attempt at optimization when the javascript library resposible is an order of magnitude larger than the actual content anyway. My phone has gigabytes of memory. If you want to present five hundred items in a web shop, just list them and do not bother with any type of pagination, invisible or otherwise.

Idk if this would be better or worse, but there should be a "find on page" js API. Like how the history api is used for SPA's.

Re: Infinite Scrolling: When to Use It, When to Avoid It

#164

Post by gjvnq »

ZoomZoomZoom wrote: post #12

Infinite scrolling makes the contents of the page unlinkable, breaks searchability and caching. It always makes the experience worse for unclear benefits. What's the problem it solves? Not resending the header and the footer on changing pages? Really?

Not if you keep changing the URL through JS to reflect the current offset.

Like:

exampe.com/products#offset-999

Re: Infinite Scrolling: When to Use It, When to Avoid It

#165

Post by PostOnce »

Not only does archive.org have infinite scrolling...

It has no pagination interface for regular people!

AND YET! It has pagination on the backend! It's a URL parameter!

So I emailed them. At first, they didn't understand, they said the design team wanted infinite scroll, so I said, that's fine, infinite scroll is fine, that doesn't preclude pagination, in fact pagination is already implemented on the backend.

I offered them a couple of possible 5-minutes-to-implement unobtrusive designs and also offered to do it for free. All it requires is links since the backend is done...

https://i.imgur.com/R12ckYU.jpg (the proposal)

They don't care. They choose to die on this hill for absolutely no discernable reason; regular users who can't edit url parameters be damned.

I love them and their mission so much, but good lord, this one particular decision is so stupid. Just put the damn pagination buttons on the site so regular people can use them, they don't know how to use URL parameters!

edit: If the value of pagination isn't self-evident, one of the values of pagination is that it allows you to go back to where you were a different day or on another machine, instead of scrolling through 70+ pages of stuff you've already seen... Or, perhaps, to skip 50 pages to find much older/newer/more interesting stuff, etc...

Re: Infinite Scrolling: When to Use It, When to Avoid It

#166

Post by 0x457 »

bluefirebrand wrote: post #137
sodapopcan wrote: post #59

Earlier quoted context omitted.

"Um, yes". As a catalog grows, past items get pushed to later pages making page-linking useless.

This is assuming things are added to the front of the catalog and not the back. That's the usual default, but there are usually sort options along with pagination that can make an items place in a list more or less fixed.

Sorting could be anything. If it's a storefront, then the first page will definitely change from time to time.

Paginated pages are about as linkable as properly implemented infinite scrolling.

Re: Infinite Scrolling: When to Use It, When to Avoid It

#167

Post by melagonster »

amelius wrote: post #54
Dalewyn wrote: post #2

Infinite scrolling is universally bad for one, very simple reason: It breaks the scroll bar. One of the purposes of a scroll bar is to indicate how long (and/or wide) some piece of content is relative to your window. Another purpose is to indicate your current X/Y position within some piece of content. Both of those purposes are completely broken with the use of infinite scrolling, because the length (and/or width) o…

> Infinite scrolling is universally bad for one, very simple reason: It breaks the scroll bar. It also breaks the back button, in all implementations I have seen so far.

e.g. FB create a search for their website, apparently this is because browser's don't work like user's need. sometimes, I find there are 3 different search box on one FB page, I should remember which one is it...

Re: Infinite Scrolling: When to Use It, When to Avoid It

#168

Post by cudgy »

“Frequently, users will click on an item in the infinite list or feed to go to its detail page and, when they come back, using the Back button, they will find themselves at the top of the list, having to scroll down through screenfuls and screenfuls of already seen content.”

This is such a common problem with web sites that I have reverted to habitually clicking “Open in new tab” when clicking a detail link on these types of screens to avoid this issue.

How this type of terrible UI is allowed and even commonplace on websites (and some hybrid mobile apps) speaks volumes about the company’s regard for its users.

Re: Infinite Scrolling: When to Use It, When to Avoid It

#169

Post by cudgy »

hombre_fatal wrote: post #104
dahfizz wrote: post #84

Earlier quoted context omitted.

It's a problem with web technologies in general. A real application framework would have hooks for knowing where the viewport is. The web was designed from the ground up to display documents, so we would have to resort to URL hacks.

This doesn’t make sense. You can build this feature into a web app. It just isn’t often worth it when items aren’t in deterministic order, you’d have to track the hundreds of items the user has already scrolled, and the user doesn’t really care if they start over. There’s nothing magical about this that a “real app framework” gives you.

> the user doesn’t really care if they start over.

This user certainly does, and, unless there is strong evidence otherwise, I’d go out on a limb and assume that most users would dislike having to “re-scroll” to the point they were in the list.

Re: Infinite Scrolling: When to Use It, When to Avoid It

#170

Post by cudgy »

gjvnq wrote: post #164
ZoomZoomZoom wrote: post #12

Infinite scrolling makes the contents of the page unlinkable, breaks searchability and caching. It always makes the experience worse for unclear benefits. What's the problem it solves? Not resending the header and the footer on changing pages? Really?

Not if you keep changing the URL through JS to reflect the current offset. Like: exampe.com/products#offset-999

This only works if the data is static. As soon as any item before 999 is deleted or added, offset 999 no longer points to the same data.
Post reply on HN