Infinite Scrolling: When to Use It, When to Avoid It • Hacker News Board

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

#31

Post by mananaysiempre » Sat, Sep 10, 2022, 1:22 PM UTC

plugin-baby wrote: post #29

9dev wrote: post #22

Earlier quoted context omitted.

But why on earth would I want to wait for a document to open, just so the height of the scrollbar is accurate when I see it first..? That is such a minor detail when viewing a document. Maybe the metaphor of the scrollbar is just a bad one?

Or just imperfect, but often useful?

Imperfection (or non-universal applicability) isn’t the problem, absence of a graceful fallback when it hits is.

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

#32

Post by LinAGKar » Sat, Sep 10, 2022, 1:24 PM UTC

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 means that when dragging the scroll bar, the page will suddenly jump when it loads in more content

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

#33

Post by chrisweekly » Sat, Sep 10, 2022, 1:25 PM UTC

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 also immediately destroys the concept of a footer. IME (building websites/apps for a living since 1998) footers are an excellent and underutilized place to put large amounts of supporting materials, expanded navigation links and related affordances. Consider the absurdity of infinite scrolling in a page with a layout containing a footer that can never be reached (perhaps briefly glimpsed before being pushed out of sight).

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

#34

Post by amaccuish » Sat, Sep 10, 2022, 1:27 PM UTC

The worst is when there's important links on the footer of the page. You end up trying to race the loading to click the link you need in time.

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

#35

Post by SnowHill9902 » Sat, Sep 10, 2022, 1:27 PM UTC

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…

Some datasets don’t have a natural order so a position is arbitrary. You just want to iterate over all of it in some useful sequence without arbitrary seek.

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

#36

Post by gcau » Sat, Sep 10, 2022, 1:33 PM UTC

There's some small satisfaction and fulfillment from reaching the bottom of a page. Each page is like a breakpoint, imagine if books were 1 long page.

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

#37

Post by chrisweekly » Sat, Sep 10, 2022, 1:33 PM UTC

> "Infinite scrolling is also not a good fit if you have a large user group from areas with low bandwidth or if your website is visited frequently by users with accessibility needs."

Good thing mobile is a passing fad and a11y doesn't matter. /s

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

#38

Post by criley2 » Sat, Sep 10, 2022, 1:33 PM UTC

d0gbread wrote: post #26

criley2 wrote: post #6

Earlier quoted context omitted.

I have seen infinite scroll paradigms that simply load the next bit of content, causing the page to elongate, causing the bar to shrink and reposition. This is fine to me as the bar remains in exact sync with the document. I also think the scroll bar is an entirely desktop tool, and as infinite scrolling most benefits mobile, this is a moot point. Nobody on mobile uses the scroll bar. Personally, as a middle-click-an…

I use the scrollbar on mobile. It's a way to quickly navigate to a section of a particularly large document that would take tons of swiping. Not a frequent use case but an absolute necessity on occasion.

Interesting, none of my mobile browsers even have a scroll bar.

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

#39

Post by ivanjermakov » Sat, Sep 10, 2022, 1:44 PM UTC

My biggest issue with infinite scrolling is that content position is not preserved in the URL. Page reload/history back returns to the top of the page and specific position cannot be linked

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

#40

Post by Waterluvian » Sat, Sep 10, 2022, 1:47 PM UTC

RunSet wrote: post #17

mananaysiempre wrote: post #10

Earlier quoted context omitted.

On one hand, yes, I agree. On the other hand, it seems to me that this is partly the fault of the scrollbar as an idea. How do you show the current position in a document for which, for one reason or another, you cannot instantly compute the visible height? I still remember an Android PDF viewer which would run through every page of a 2000-page document to get the page dimensions before displaying anything. (From wha…

> How do you show the current position in a document for which, for one reason or another, you cannot instantly compute the visible height? Perhaps by not "instantly" displaying the document- that is, displaying it before you are able to display its scrollbar.

Could someone remind me what the name is for the eternal debate between the two valid camps: “HTML should never ever render if there’s an error” vs. “Renderer should try its best to render part of a document if there’s errors” ?

I feel that this is akin to that. I strongly believe both perspectives are valid for often overlapping contexts.