Poll: Infinite Scrolling
-
You do realize that scrolls were invented before paged books, right?
Of course (and papyrus was used as a writing material before vellum though a good rock predates both). But those scrolls were definitely not infinite; nobody could have picked up an infinite scroll (and wouldn't have wanted to if it was filled by some of the ranting round here).
I don't know what my point really was any more.
-
-
The problem with infinite scrolling is that it's a robust Web 2.0 paradigm.
If you don't understand why that's a bad thing, you're part of the problem.
-
you're part of the problem.
It's harder than you might think to keep that up.
Filed Under: That's what she said
-
And since @codinghorror and @sam have made it clear that we're idiots for wanting such a thing, why shouldn't we attack them?
Not at all, I have never said that, in fact I understand why people are clamoring for it here. You are used to using a site in a certain way, that certain way has certain advantages and disadvantages.
Discourse is an ambitious project, we don't simply want to shuffle stuff around, we are trying to make fundamental changes to forum software. Doing this kind of stuff means you end up doing lots of cutting edge work. It means we need better scroll bars, better search in page, better performance, better filtering and so on.
To me, the reason infinite scroll is so important is this:
No Microsoft Word user (or Excel for that matter) out is demanding a UI that displays chunks of 10 pages with [group 1 / group 2 / group 3] links.
Placing arbitrary hard breaks between post #50 and #51 can actively damage conversation, it adds a barrier to responding to the 2 posts in conjunction. You need to page back and forth to deal with them as a whole. Introducing arbitrary non semantic breaks in a topic hurts.
That said, I understand. You are used to a pile of modes of operation that are not simple here (yet), you can't easily jump to post (we will fix it). Search is not ideal (we will fix it), Filtering can be a lot better.
There are also other points raised that have nothing to do with infinniscroll (for example history updating as its done here is not a necessary feature for infinniscroll)
We are doubling down on improving infinniscroll, its our core mission, we don't want to split out our efforts and build (and maintain) a secondary view in core.
-
We are doubling down on improving infinniscroll, its our core mission, we don't want to split out our efforts and build (and maintain) a secondary view in core.
That's the meat of it. Infinniscroll IS broken, just in different ways than pagination. Maybe one day, your implementation will be better than pagination. Right now, it's not, but it's getting better. We can only hope that the ideas created based on our experience here help fix it.
EDIT:
It's not broken because it's bad, it's broken because it's new. It needs to fight a few wars before it's battle-proven, and this is the first of many.
-
I'll admit, infinite scrolling has its uses - Twitter, Google images, and Facebook have all been mentioned. But notice how Google hasn't tried to implement infinite scrolling on, say, web searches, or news searches. Why? Well, since I don't work for Google, I can't say, but I bet it's because they know that infinite scrolling is a bad fit for those scenarios.
If Google didn't provide a useful search result on the first page, it would have long since gone out of business. Pagination is irrelevant on Google because nobody looks at page two, they already got their search answer in the first 10 results.Conversations don't work that way. (stack overflow works similarly to Google in that the best answers are at the top, but it is also not a conversation, it is directed Q&A)
-
There are even studies to back up the Google page thing:
Top Google Result Gets 36.4% of Clicks [Study] - Search Engine Watch
![Top Google Result Gets 36.4% of Clicks [Study] - Search Engine Watch](https://www.searchenginewatch.com/wp-content/uploads/sites/25/cnt-import/sew/IMG/827/171827/optify-ctr-1-20-png.png)
Itās critical for websites to appear on Page 1 of Google, especially in one of the top three organic positions, as these spots receive 58.4 percent of all clicks from users, according to a new study from Optify. Websites ranked number one received an average click-through rate (CTR) of 36.4...
First result 36.4 percent of clicks, second page 1.5% click through.
-
The psychological burden imposed by infinite scrolling really can't be emphasized enough.
lol wut
-
As anyone who's ever been tasked with "Clean your room!" knows, attempting to take in a large task all at once is vastly, disproportionately more daunting then when subdivided into smaller, more immediately manageable goals. That's what pagination does for people. "Oh my, this thread is a hundred pages long! Well... I'll just read the first couple pages..." and off you go. Cheerleading for infiniscroll is thinking like an engineer, not a human.
Were you high on mansplainers when you wrote that?
I tire of this.
-
If Google didn't provide a useful search result on the first page, it would have long since gone out of business. Pagination is irrelevant on Google because nobody looks at page two, they already got their search answer in the first 10 results.
Actually, there are times (maybe 5% of the time) that I end up looking at the second page of results because the first page didn't give me what I needed. In those cases, I will often find what I need on the second or even third page.
So much for your argument.
-
Not at all, I have never said that
I may have inferred the meaning, but you did tell us that pagination is godawful.
-
No Microsoft Word user (or Excel for that matter) out is demanding a UI that displays chunks of 10 pages with [group 1 / group 2 / group 3] links.
I hope you realize that MS Word is pretty much the worst possible example to use in favor of infiniscroll, given that it paginates-- well, every page.Also wondering why you keep spelling infiniscroll as "infinniscroll".
-
I hope you realize that MS Word is pretty much the worst possible example to use in favor of infiniscroll, given that it paginates-- well, every page.
But it mounts all the pages in an infinite scroll, at least in some of the views (including most of the default ones).
-
It's not really infiniscroll though, because the entire document is loaded in memory all at the same time, so there's a 1:1 correlation between your position in the document and the position of the scroll bar thumb. An infiniscroll document, OTOH, is like a glass that refills itself. Every time you think you've gotten to the bottom-- nope, there's more!
-
You should pay more attention when Word is loading a long document in. The mysterious extending scrollbar?
The usability problems? The āgets better once everything is loadedā? (Better yet, don't read ā or edit! ā long documents in Word.)
-
The āgets better once everything is loadedā?
Except in Word, everything is going to eventually be loaded with no interaction from the user. In Discourse, you can't even achieve the "everything is loaded" state, because it unloads top posts.
-
But usually breaking things up into digestible pieces (like pages) helps a lot. (Chapters and topics do correspond.)
See our current thinking about this here:
Natural breakpoints or "chapters" for long topics?
One thing weāre thinking about is how to determine natural breakpoints or āchaptersā for long discussion topics ā and we can eventually display these breakpoints as navigation selections on the expanded topic progress bar. Say you have a 500+ post topic that you want to explore. How do you do...
-
Infinite scroll is a productivity killer.
I do most of my browsing from the toilet at work. I use page breaks as stopping points. Now I end up sitting here until the motion sensor shuts off the lights and have to wipe in darkness!
-
You are obviously doing it WRONG
-
-
In the above case I don't see a right way of doing it. Unless it involves turning the light on.
-
I used to work on a system that was transitioning from an aging desktop app to a web interface, and the client was used to being able to Ctrl-F to find a single record from thousands. The webapp had grids with simple paging, and we got a few complaints that the page was slow to load... because the user was hitting "All" and then using Ctrl-F, which not only replicated the functionality they were used to, but was a hell of a lot faster than the desktop app once the page loaded.
While we initially suggested they were doing it wrong by initially selecting "All," we thought, hey, this is pretty cool. Even with all the rows coming back, the pages were only a megabyte or two, and being able to search the entire grid/table was worth the wait (and weight) of a couple seconds to load the page.
I believe @Lorne_Kates mentioned earlier that users find novel ways to use your product better in ways you never intended?
Discourse has gotten a bit better in the past few weeks, but posts loading and unloading makes the UI feel sluggish and unresponsive. If I hit Home or End (or variants with Ctrl) I expect to be at the bottom or top of a page instantaneously. I would almost prefer to have the entire thread loaded on a single page (and be made to wait a couple seconds) rather than load the posts on demand.
Sure, a thousand-post thread is going to be heavy, but pagination solved that problem well over a decade ago. And yes, pagination sucks when there are 100+ pages, but I don't see how infinite scrolling sucks less in that case.
-
I've seen threads hit 25k or 30k posts on some forums in the past now. While I'd certainly argue that's an edge case, it's the sort of edge case that you can't readily prepare for, and 'all on one page' isn't going to cut it in that case.
-
-
Then load the first X, the visible X, and the last X. You'll always have 3 sets of posts loaded, but the beginning and end jumps won't need to hit the server.
