Hacker News Reader

Comment by Dalewyn | Hacker News Reader

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) of the content keeps changing (increasing) and thus your position in that content also keeps changing.

I shouldn't have to explain how terrible this is from both accessibility and simple practicality standpoints.

View on HN

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.

Gigabytes of memory yes but there is load time and render time too. And rendering a 120mb payload of items and their thumbnails before I can even view the top of the page seems… not the best user experience.

I don’t think there is an easy answer here. All options have some trade offs.

That is not how browsers work. The browser will render the viewport immediately, long before the page has loaded. It will also load the visible thumbnails first, unless made impossible by complicated markup of course. Otherwise surfing the web on dialup in 1996 would have been intolerable.

Typically when I serialize data for #index endpoints I return much slimmer payloads than I do in #show endpoints. I recognize that 120mb was an extreme, but you should be able to serialize lists of 500+ items into well under 1mb, with enough data to render your list view thumbnails/links.

I always thought the infinite scroll pattern was designed for analytics purposes. So that you can track user engagement. Not because technology constraints necessitated it or that it was a good user experience.

Just have JS track where the user is?

Sooner or later you have to unload content or the browser crashes. There's an upper limit to how many DOM elements browsers can handle, even with modern optimizations.

Deferring rendering of the images seems like an easy enough thing to do if your alternative is infinite scrolling. Pre-load the text and layout but leave the images and video until they're close to the viewport.

It also breaks the “back” button.

If you click on an item after significant scrolling, view the item, then click back, where are you? almost never where you were. Usually just at the top of the list.

Jira goes one better. Issues in some lists are paginated into 50s. Change to "page 2", use the back button and you'll be back on the page you were on before looking at the list, because the URL hasn't changed. Go forward again and you're back at the first page. Argh!

Gah! Breaking basic navigation functionality, along with the clipboard, on page search functionality (i.e., basic application and OS level stuff), keyboard navigation, and common keyboard shortcuts and mouse/touch gestures, are amongst the absolute cardinal sins of web applications. These ought to be acceptance criteria for every single "story" implemented that impacts the client-side. Does anybody do it? Well, some, but very few.

yeah the nielsen article calls this 'pogo sticking'

The back button problem is fixable. Discourse (which you’ll see on discuss.python.org and users.rust-lang.org) uses the history API to keep track of your location. You can create a URL that points at any individual post, and the page will appear “pre-scrolled” to it, so you can not only use the back button to return to your location in the infinite scroll, you can even bookmark your location in the infinite scroll.

The scroll bar and find function can be mitigated, but not as elegantly.

The real problem is that, when you load a page in the middle, it’s easy to scroll down, but scrolling UP is glitchy. That one can’t be fixed. https://meta.discourse.org/t/scroll-jank-when-scrolling-up/1...

the lack of not being able to find something not yet loaded or recently unloaded is infuriating to me. I file shitty pagination systems with no Show All in the same category.

The “find” thing is something I hadn’t considered. Yes it’s annoying when you cant search content “below the fold”

I do think it depends.

I love infinite scrolling for random content. There is no “position” so to speak. And there is no concept of “find” since you don’t know what you’re looking for. “Back” continues to work as long as your browser cached the previous page state.

Sometimes you really do want to simulate an infinite list of 4,000,000 entries!

An example: https://wikiscroll.blankenship.io

I find spotify is really bad with unloading ui, to the point where you have to stop and wait to see song titles if you are scrolling even moderately fast

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.

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.

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 what I can see, modern viewers display the first page instantly by accepting being caught in their lie when a PDF has pages of wildly varying size.) Even a gigabyte of Unicode plain text with no line breaks in a proportional font is a serious problem. I don’t think we can special-case network streaming here (although it’s not unimportant either).

> 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.

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.

That seems silly as well, doesn’t it? Why should I wait for all the 1030 pages and 155 MB of Matter and Interactions[1] or 1442 pages and 126 MB of Life[2] to load before I can do anything with it? (Not that a hundred meg should take that much time to load, but then you realize PDF is the moral equivalent of a bunch of gzipped JSON files pointing to each other...) It would be handy if PDFs included an index of all page sizes in a single place, but they don’t, so we need to make do with what they do include somehow.

[1] https://matterandinteractions.org/

[2] https://www.macmillanlearning.com/college/ca/product/Life-Th...

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.

Draconian error handling vs Postel’s law? Both behaviours are still in browsers for XHTML (and XML+XSLT) resp. HTML (though the removal of <noscript> in XHTML5 makes me sad).

Scrollbars can be dynamically updated as the content is processed. This is also a distinct advantage of a proportional sized scollbar elevator like those in Windows since the elevator shrinks to its final size rather then starting at a small fixed size and shifting around.

I remember Android apps some years back that showed an approximate scrollbar, when it knew how many items there were (paragraphs, in the case I’m vaguely recalling—and although all the content was available, it might not have wanted to render it all at once, as it could have tens of thousands of words) but not how tall each was. I think it drew a scrollbar with the assumption that off-screen items would be a certain height, so if you went from a screenful of long paragraphs to a screenful of short paragraphs the scrollbar could be amusingly wonky, considering our usual expectation of spatial scrollbars. In some contexts this itemwise rather than spatial scrollbar can actually be more useful, but whether or no, it’s not a concept the web supports directly, and there will be certain niggles in the result of implementing it.

> I don’t think we can special-case network streaming here (although it’s not unimportant either).

The relative position inside an infinite stream is always 0, and the height of the scrollbar handle (showing relative size of the viewport relative to the entire document) is also 0.

As the size of a finite-sized document grows, these problems also show.

Problems are: you can't click on the handle since its size is close to 0; you can't click above the the handle to do effectively go one page up, since the handle is at position 0 (or close to it).

Scrollbars are pretty useless for large documents, even more so for infinite streams.

I recall desktop UIs solving this by having a minimum scroll button size. Then just aligning the bar to the full height of the doc, at least where the data size was known. And when first loaded the bar would sometimes shift as it loaded, albeit without having to scroll to force further loading.

  "How do you show the current position in a document for which, for one reason or another, you cannot instantly compute the visible height? "

Actually, that sounds like an idea, make the height of the page roughly the real height of the total pages. It can still load content on scroll, but being able to leap ahead a few pages sounds great. Now if we can just get it to remember our position when we hit back, and not just return us to the beginning of the adventure, then infinite scroll would be tolerable.

That's like claiming every data collection should have a reasonably limited length. Even if that were true, scrollbars in general break when the data gets too large (a pixel of screen movement jumps pages of data) not to mention browser layout performance, memory requirements, etc.

Pagination doesn't work either, because data can shift and you get repeated elements (if the page size is less than the remaining data when moving back to the start) or else truncated pages, or you start on page 10 and move backwards to page -3 before reaching the start. If you jump to a particular element, it requires you to know the absolute offset of all data to calculate page numbers correctly, which when jumping and filtering a large table might be a significant performance cost. Plus it breaks up content - if you're looking at chat history for example, often related messages are broken up into several smaller messages. Having one message on page 10 and the remainder on page 11 would be a terrible experience.

Don't blame this on designers, infinite scroll has been around (apparently?) almost 20 years now. Browsers still don't have an accessible solution despite the ubiquity of this pattern today - browser devs are to blame.

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).

I mean, the obvious solution to this problem is to not have both footers and infinite scrolling; you have to pick one.

It also breaks the "virtual scrollbar". if you reload the page you have to start all over

This is the killer for me. I’ve gone from loving GitHub to hating it for this one quirk. When you reload the page while viewing a PR, you invariably land at some random spot instead of where you were.

This is my primary issue with infinite scrolling. However, I wonder if it’s mostly a problem with today’s web browsers.

Heck—maybe it’s not even browsers, but websites. I’m pretty sure a website could change the URL as you scroll, so if the page is reloaded (or bookmarked, etc) you’re brought back to where you left off. I usually dislike it when websites mess with URLs, but this seems like an excellent use case!

even if the website did re-start where you left off (difficult), what if you scroll backwards? When you send a link, should it point to the page that you scrolled to, or to the beginning of the list? How many items before/after should load? These arise solely because people chose to reinvent a browser -in-the-browser. With pagination we dont have these issues, the link points to a specific results page, uniquely.

You can still have weird issues with pagination if the data set you're paging through is mutable.

Reddit used to struggle with this back in the day. The way they did pagination was to say "show the next page after id postId=xyz123". Since the algorithm kept re-sorting the posts on the front page, the content moved around quite a lot and you'd see the same things re-appearing on page after page, and sometimes post xyz123 was deleted and then everything broke.

Infinite scroll or not you’ll have this problem on a mutable set of items. You’ll have to dedupe the next “page” either client side or server side. Or something!

It’s one of the reasons that the “I can build XYZ app in a weekend” crowd sounds so silly. I bet Reddit spent dozens of not hundreds of man-months nailing their scrolling behavior. It probably took many iterations of UX, product and engineering to get it right. And even now I bet they have a pile of JIRA tickets buried in their backlog relating to the pagination system.

In my experience there is a non linear relation between the more seemless and “easy” something appears and the amount of work that went into it. Things seem “easy” because the developers poured a pile of fit & finish on the system.

I'd note that Hacker News doesn't have this problem.

Although Reddit's design decisions are almost certainly to accomodate their much larger scale.

I've seen the problem on Hacker News. A story which was at the bottom of my page 1 is also at the top of my page 2.

Yeah, that's fine I think. I mean the problem of the pagination "crashing" due to removed posts.

Infinite scroll isn't really useful in a low velocity environment like Hacker News, hot threads being the exception.

Hacker News being designed to display trees sorted by karma also makes it difficult, you would have to re-sort the entire page to re-rank every new subtree within the current display.

Apparently, this also makes pagination difficult, since pagination is implicitly chronological - what people want from pagination is to easily find the latest items - which karma sort doesn't allow.

IIRC the first version of reddit and the Python rewrite were each more or less built in a weekend. They were neither scalable to millions of users nor heavily optimized to keep users on the site as long as possible.

The latter point is relevant to a variety of UX decisions across many products and services. Making it easy, efficient, and pleasant for the user to do what the user wants may not be the overriding concern in the design.

> you’re brought back to where you left off

Which is all fun and games until the “page” is actually a mutable and constantly changing list. With a mutable list there is no concept of “where you left off”.

As alluded to in sibling comments—does pagination fix this problem?

This is caused by pagination. Without pagination, there's no pages that can get out of sync.

More specifically it's caused by offset pagination. The kind of pagination where you track "user is 90 items deep into the list" or "user is 3 pages into list and each page is 30 items"

Alternatively, index based pagination works by going "the last item the user viewed was id=12345". With this model refreshing the view won't cause a change, but the downside is you lose an easy way to tell the user how many "pages" deep they are. Even though "pages" is a flawed metaphor in a dynamic stream of data, users still like to see "you're on page 3 of 1 million"

Also this is only considering "append-only" style lists. Like comments sorted by time, or a list of versions of software, etc. If your list is dynamic, like the pages of Hacker News, where isn't ordered consistently but is instead a dynamic order or has mutable items, pagination will still be inconsistent.

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.

...I guess, to be quite honest, I'm starting to think we've reached the point where we ought to throw everything out and start over.

HTML can stick around indefinitely for legacy websites and truly static pages, but browsers should introduce a new standard DOCTYPE optimized for what we actually want the web to do.

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.

Discourse is a web app that does that. The url should be the place to keep navigational state.

> 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.

What is “back” on a dynamic page like Reddit, Facebook or even this site? If “back” means “show me exactly what I last saw” it might mean you are showing stale data.

I dunno. Shit ain’t easy once you think about it for a while.

If all you have is a static unchanging set of items… might as well just use old school pagination! At least in my opinion. It’s when the list of items is constantly changing that things get interesting.

It might be stale, but it's the content I want to see. The F5 key still works if I care about getting it up to date.

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...

This is like saying that electric cars are universally bad because they break the MPG meter…

Scroll position as measured by a scroll bar doesn’t make sense for an infinite (or indefinite) document. That doesn’t make an infinite document bad.

> 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.

Seems fine to me? New content is appended, so the length and your position changes. Scroll bar reflects what’s going on. What’s the problem?

Yeah, I'll bite. How is a growing scrollbar bad for accessibility? Why is an understanding of how long a page is an accessibility concern?

Because not everyone has the hand-eye coordination and/or motor skills to keep track of an arbitrarily changing scroll bar, particularly the elderly and the disabled.

An accurate and consistent scroll bar is a valuable navigation tool, please don't break it.

Why do you need to coordinate your hand and eye to use a scroll bar? Don’t you use touch to scroll or a scroll wheel?

Clicking/touching the scroll bar and dragging it directly is a valid way of using a scroll bar. Especially for people who come from a time when mice didn't have scroll wheels, clicking and dragging the scroll bar itself predates the convenience of whole-screen dragging (touch) and flicking the scroll wheel.

Dragging the scroll bar has its benefits over touch/wheel too: It allows for quicker, longer distance travel with fewer (and in the sense that you just move your arm, also simpler) movements.

Hm. Do the the elderly and the disabled keep track of the scroll bar length? Does it getting longer actually confuse people? I'm not convinced this is as important of a thing.

Opening modals changes the scrollbar length. Opening accordions do too. The scrollbar doesn't "break" when content is added to a page, it just adjusts accordingly. It seems like this is all good, expected behavior; not an a11y concern.

Most of us take for granted the fact we are all still physically and mentally fit (and also know how to operate computers!). Inevitably though, age will catch up to us one day.

Particularly for the elderly and disabled, but honestly pretty much anyone not familiar with using computers, elements of the user interface suddenly changing seemingly at random is extremely disruptive and disorienting. In the spirit of accesibility, as an engineer you want to eliminate such behaviour because being disrupted and disoriented like that is really unpleasant.

> eliminate such behaviour because being disrupted and disoriented like that is really unpleasant

This appears to be postulation on your part rather than actual knowledge of accessibility needs.

The specter of "visually changing things are bad" may hold some water (WCAG requirements do include things along those lines), but in order to discourage folks from using common web components I'd definitely need to see some actual evidence of this phenomenon w.r.t scrolling.

>in order to discourage folks from using common web components I'd definitely need to see some actual evidence of this phenomenon w.r.t scrolling.

I mean, this whole thread is rife with people telling stories of being terribly annoyed by the shenanigans that infinite scrolling causes. Including issues both involving the scroll bar as well as other forms of navigation that break down with infinite scrolling.

I'm sure you have also experienced moments of disorientation when something you were using (not necessarily infinite scrolling) suddenly decided to do something all on its own and left you to figure out what just happened.

I completely agree with you so I wrote one awhile back that doesn't break the scrollbar and also returns you to where you were on browser back.

It's not perfect but I don't really care to improve it and no one has had any complaints.

Check it out here: https://sayartii.com/search

This doesn't appear to be infinite scrolling. I can scroll to the bottom of the list with Cmd-Down. It just appears you're lazily rendering results.

N.b. it's incredibly slow, because it has to load every batch above the scroll position first. Try going to the bottom of the page and seeing how long it takes for results to render.

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-and-hold'er, I do not use the scroll bar. I just went through my pages and frankly I'm surprised how the bar looks. I honestly never look at it or use it.

As this article demonstrates the scrolling on mobile as well, I have to point out that your complaints are sadly more of edge cases w.r.t. to the products we're making for the general public.

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.

An autohiding scroll bar is still a scroll bar.

I legitimately cannot get Chrome for Android to show a scroll bar under any circumstance. Android 13 / pixel 6 pro / Chrome, there is simply no scroll bar on any page no matter what.

EDIT: Ah! I see it! I have a curved screen and the 1 px thin "bar" is only on the curved edge of the screen which catches the light and isn't visible. Fair enough.

Wow! Okay, well that's dumb, never mind then!

I think this depends on what kind of content you are scrolling.

If you know how many items there are and all the items have the same height, then you can simply set the height of your container for the scrollbar to be accurate.

Furthermore you can listen to the scroll event and load the correct items if the user uses the scrollbar to jump to a particular spot.

So I think the bigger problem is a) people being lazy and not implementing this properly b) using this pattern where the preconditions don’t hold.

Expand your perspective: What does scroll bar mean when you have no intention of ever scrolling all the content?

"Infinite" scroll isn't breaking anything, the content all broke scrolling inherently.

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.

It is possible to implement infinite scrolling and maintain the scrollbar height if you know the full number of results you’re going to scroll through and the height of each element (both of which are usually knowable). You simply set the scroller div to elementCount * numElements regardless of the number of elements. Most libraries that provide infinite scrolling do this.

Infinite scrolling is bad because it has ZERO respect for document boundaries. An "infinite" document is a travesty.

Define document. Is a log file a document? How would you render a log file in real time without some sort of streaming (i.e. infinite scrolling)?

tail -f considered harmful?

Not only this, but every time it happens I have to wonder how it is that designers have never tried to actually use the scrollbar, getting to the bottom only to have it double in length, the placekeeper jumps out from underneath your cursor, the scrollbar then detects your cursor, and bam, you just skipped half the content without meaning to and it is virtually impossible to get back to where you were. This gets even worse when it isn't a list of entries you're reading but a single very long article or comment thread that should have just been paginated to begin with. It seems entirely motivated by a basic laziness of not wanting to create separate mobile and non-mobile views and defaulting everything to mobile-friendly even if it destroys the browsing experience of people using ordinary desktops and laptops.

Not maintaining a separate site for mobile and desktop isn’t lazy. Having two separate interfaces is not at all easy and it has its own set of trade offs.

For example with two sites you now have two URLs and need to figure out which experience a browser should actually see. If I’m on a desktop and somebody sends me a mobile link, which page should I see?

> 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

And how would you do that when there is infinite scroll?

Scrollbar hasn't been useful for that (at least for me) ever since websites started putting comments after the content (e.g. article, blog)

It also means that when dragging the scroll bar, the page will suddenly jump when it loads in more content

That sounds like a deficient implementation for a scroll bar widget, more than anything else.

On mobile devices the scroll bar is barely visible. So this is a non-issue for mobile.

I don’t even think you can grab the scroll bar and move around on iOS… though I kinda remember you being able to way back in the day…

you definitely can, try long pressing on it

Just don't ever use it.

Reply on news.ycombinator.com