Hacker News new | ask | show | jobs
by EvilTrout 4452 days ago
All these problems are solvable. I co-founded Discourse (http://discourse.org) which uses infinite scrolling heavily. Discourse is also 100% open source so you can see how we did it.

My responses below:

> Users will lose the page length orientation - the browser scrollbar become useless.

We have a fixed "x/y" posts widget at the bottom with a progress bar.

> There’s no ability to jump to the end of the list.

The aforementioned widget has an up arrow and down arrow to jump to the top/bottom.

> Your users will not be able to get back to the same in-page position in 1 click.

We use replaceState to update the URL as they scroll. The back button works fine, and you can link to any position in the topic.

> There’s no visible footer until your users come to the end of the list/content.

Isn't this true of all sites where the user scrolls anything? I guess the difference is you see it more often with pagination. We instead have a fixed header with navigation options and extra details.

> Slow Experience - You are using a lot of browser memory as the page scrolls down.

We unload posts that have scrolled off the screen. We released a library for it too - http://eviltrout.com/2014/01/04/hiding-offscreen-ember.html

> If you switch away from the page by following a link there's no way of getting back to where you left off.

The back button works fine thanks to replaceState!

> Lack of sense of completion- no closure for users.

The progress bar and constantly increasing numbers in the widget help a lot.

> There’s no SEO opportunities for content located below the first scroll.

We serve up google indexable content just fine. See: http://eviltrout.com/2013/06/19/adding-support-for-search-en...

> You lose the ability to bookmark a dedicated point of interest.

With replaceState and updating the URL, you can bookmark at any point and return right back to where you left off.

> Distraction - The fear of missing out on data or other options will deter your users from completing an action.

I'm pretty sure this isn't relevant since we support all the above.

9 comments

Infinite scrolling breaks what was a universal UI convention, and an interaction mode which has worked everywhere for well over 30 years, for a downright nebulous gain. You've made my browser's scrollbar widget dramatically less useful. Even on sites where I now know to expect it, I still end up unexpectedly jumping around the page while I'm trying to scroll through and read the content because the scroll bar I'm trained to use (30 years of training, remember) gets displaced out from under my mouse pointer when the next chunk of content loads.

You've replaced something which required no thought with something that requires conscious effort. Not only that, but I now have to learn how every site that implements infinite scrolling does it, because the conventions I expect for page length and page position don't hold any more. Given your response above, the very best you can hope to say is that compared to a paginated interface, you've only broken it a little bit. That's a very long way away from being worth the trade-off.

Infinite scrolling is gratuitous over-engineering, and as far as I'm concerned, any site which uses it is just broken.

This sounds suspiciously similar to popular arguments against the mostly-button-free iPhone interface to me.
The fact that two of the largest sites Facebook and Twitter use it is good enough for me. All the young ladies I've spoken to don't seem to mind infinite scrolling either.
Everything you said, but completely reversed.
Your response is excellent.

But something is missing here, an awareness of when infinite scrolling is good vs bad. Infinite scrolling is good when the information is ephemeral, and changing all the time. Dating profiles, twitter stream, live updates.

But infinite scrolling is bad when the content is fixed. Like a forum. There is a cognitive clue when paging through a forum, how far you have read, where you are.

All your answers are technical based. But they don't answer the UI problem that scrolling through the discourse forums gives people a cognitive headache.

Agreed. I think the discourse developers are not considering psychology and HCI, but only the technical aspects. That the implementation of infinite scroll in Discourse gives you the same information that you get in a paginated view, does not mean that infinite scroll is at least as good.

"post x/y" tells you how far you are in the page, but only if you think about it. There's no longer any intuitive connection between the scroll bar and page position. The End key stops working intuitively, sends you to the end of currently loaded posts and then loads more posts so 1 second after pressing it you're not at the end of anything. Then there's the lag as you hit the top or bottom of currently loaded posts; even if you don't want to read any more, you get more. That's clever if you're a tabloid magazine because it entices the reader to read more, but the impression I get is it's not productive.

For maximum usability, why shouldn't the app support both infinite scroll and paginated, and let the USER choose (by url slug or GET param)? (Or by user setting if logged in)

> For maximum usability, why shouldn't the app support both infinite scroll and paginated, and let the USER choose (by url slug or GET param)?

I've always thought we could do this as there is no technical reason why we couldn't offer both.

But honestly we receive very few complaints about it from users of the software. It seems here on HN that infinite scrolling is not super popular, but we are not getting the same feedback from our users.

I suspect all you'd have to do for the other option is disable automatically swapping out pages when the bottom or top of a page is reached. Leaving the box with up and down arrows, adding a second set of double arrows, and using that for jumping N posts forward or back, or to the beginning and end.

I think javascript in-place loading of different pages is great (avoids reloading a lot of boilerplate and dependencies). What I don't agree with is the automatic altering of page contents based on where I am on the page, absent any indication (like clicking a button) that I want to change pages.

What's the benefit? It seems like you've gone though a lot of trouble re-implementing features of the browser but without any obvious advantage in doing so.
It's really nice to be able to read something without interruption.

In terms of engagement, a user is much more likely to bail every time you require them to perform an action like click "next page." On Discourse they can just keep scrolling down as long as they care to read.

It also helps to track their position. On long topics, users often won't read it all in one sitting. I am a member of the Something Awful forums, and since they use vBulletin with pagination they can only know if I've opened a page and they use that to mark the whole segment of 20 posts as read. What if I stopped half way through? What if I opened the page in a new tab then closed my browser without looking at it? They assume I've read it all!

Logically, what is a "page" anyway and why should a user care about it? What does page 669 mean versus 670? How about we not expose implementation details to users and just let them get on with their reading?

Chapters (and page numbers) give people a cognitive clue as to where they are, when reading fixed content. Try removing the chapters and page numbers from a book, and most people will complain.
I haven't used Discourse, but in general I'm not sure pages are meaningful in forum software. The unit in a forum is the post, not the page. I read from post 1 to post N and the page boundary is always arbitrary. If forum software dropped the pagination but added post-ination, I'd take that as a very beneficial swap.
Your site still breaks when scrolling by dragging the scroll thumb down. On a long page, dragging the scroll thumb down (the way many people actually do scroll) makes the page jump around very fast, and skip larger sections as the page goes further down.
This is like saying someone would rather read a 7ft printed document than a 10 page document with normal 8.5 by 11 pages.
Excellent response.

Yet I feel compelled to ask: how much effort was invested in reaching such degree of finesse?

Pagination is (usually) very easy to implement and can be done completely on the server side. Your (very magnificent) solution sounds like it would require days, if not weeks, to be implemented, and adds plenty of javascript to the server-side part.

Do you think there's a "economy class" infinite scroll, or is it only viable for sites with a big budget (in effort at least)?

It actually was (and continues to be) a lot of work. It's the very first thing we started work on for Discourse and will likely never quite "end."

However, browsing posts is the most core functionality we offer so it's worth spending so much time on.

If the argument of the original article was "it's hard to do infinite scrolling well" I would have to agree. Pagination is much easier to implement. But for some sites, say Twitter or Facebook or apps like Discourse it's worth the effort IMO.

Good question, but you have to such fanboy when you ask?
Don't get jealous. You are gorgeous too <3
Jelous for...? more like a cringe when i see to much azz-kissing ;|.
It's not ass kissing when it's true.

I'm not going to apologize for complimenting someone's work. If that makes you cringe, then you will have to live with that. I think you will be happier if you try to choose other things to get upset about.

So you're essentially rebuilding a browser inside of a browser?
Kinda, but on a different level.

A browser displays the web, but it uses an optimization where instead of loading all of the web, it loads only the web page you're navigating to.

This approach displays a web page, but it uses an optimization where instead of loading the entire page, it loads only the visible sections you're actively looking at.

But isn't that the point of a web browser? You're not viewing the whole of the internet at once, you're just viewing this one document. To go to other documents (down, up, sideways, within) you use hyperlinks?
You've addressed the technical concerns well through a solid implementation combined with some workarounds (requiring specific configuration for searchable content and tradeoffs (ie9 bookmarkable content).

But this doesn't really address the usability concerns - you've mitigated them by introducing new interaction mechanisms... but these mechanisms don't solve the problems raised, they just provide a means to work around them. These workarounds are excellent in comparison to other infinite scroll mechanisms, yet not as friction-free as not having it in the first place.

Yes, this is all my unqualified opinion of course - though these opinions are what have stopped me from adopting Discourse.

> But this doesn't really address the usability concerns - you've mitigated them by introducing new interaction mechanisms

New mechanisms that the user now has to learn, as opposed to the scroll bar, which they already know and understand. And of course, every site that does this will implement its new mechanisms slightly differently, so you've traded a universally useful and understood UI convention for a range of site-specific ones.

Very well done. This is essentially the response I would have given in the abstract, but I appreciate that you actually have a presentable implementation.
I think discourse handles this fantastically well!
I think discourse handles this impressively, and I thought of them for almost every point on this list. They're almost all fairly minor technical obstacles if you really want to solve them. Discourse really wanted to solve them and they did it masterfully.

But the funny thing is...I still don't like using infinitely long pages, even in discourse. The scrollbar is a very capable control that works exactly in a way we are familiar with, and we're accustomed to it in ways that the little progress widget simply can't compete with. And we're not going to get accustomed to the widget in the same way unless it really is universal and behaves in a very standard way (like a scrollbar does), so until that happens, I wish people would stop insisting that a page with a goofed-up scrollbar can be just as good because, hey, magic widget!

EDIT: just to give discourse a chance to prove me wrong, as it had been a long time since I looked at their widget, I went and looked at a 1000 post thread on try.discourse.org and I'm sorry, but the experience completely sucks compared to having a real scrollbar. There's no way to tell how long the thread is at a glance (the widget just says "2" and the scrollbar indicates maybe 40% is visible), there's no way to scroll to somewhere in the middle (say, you know you're looking for something around post 200) without incredible tedium, there's no fast scrolling. Their solution is technically gorgeous, but it's just jaw-dropping to me that anyone could be so stubborn as to suggest that this is a reasonable replacement for a scrollbar for content that is of a very long but known length.

Agree completely. For long threads, Discourse is a usability disaster. phpBB is awful software, but everyone in the world can click on page 20 and know where they are. Jumping 2/3rds into a long topic using Discourse is essentially impossible for the average user.

But I love Discourse for at least trying something new and different - thats how progress is made. But some of their UI/stack decisions seem to have been made with no thought for normal people/web admins.

Question: Why do you need to jump to page 20?

In a long topic, what value does it give you?

We have found that the vast majority of users either link to a single post or scroll downwards. For mega topics, we have a summarize option that shows the "best of."

"We have found that the vast majority of users either link to a single post or scroll downwards."

Well they don't have any choice do they :D

I think that the summary tool of discourse is fantastic. So are the membership management tools/spam tools. A generation above phpBB. Just to balance out the criticism.

But the infinite scrolling is a deal-breaker (for me).

> Question: Why do you need to jump to page 20?

Question: why do you assume that an end user's lack of ability to articulate a need negates it?

Served!! Ha ha