1. My ability to orient myself in the content. 2. My ability to control my consumption of the content (e.g., jump back to top, jump to end, jump to rough internal location).
Some sites have added navigation buttons or tool bars, but, to be useful, they must always be visible, so they take up valuable space that should be used for content. Depending upon implementation, they can also be distracting.
There are certainly ways that navigation options could be restored while still not significantly interfering with content, of course. If decent feedback of current location were also provided, then infinite scroll could be OK.
Most content breaks down pretty naturally into some smaller increments, though (pages, chapters, sections, topics, days -- whatever), so I think it typically makes more sense to present it in that way.
Just because we can do infinite scroll, doesn't mean we should.
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.
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.
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.
"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)
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?
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)?
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.
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 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.
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.
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.
As for the nonsense about 'never getting to the footer', the footer can be stuck to the window or dispensed with entirely, again a-la P-interest.
It is very easy to put together a '10 reasons why I hate this' blog article, it is much harder to put something together that works to the delight of millions.
So if I open a playlist with ~400 songs and I want to reach the bottom, there is no way for me to do it but to just scroll really fast and wait for each page to load. Okay, fine. But when I do this, usually about ~30% of the time it will start repeating pages or it will just start feeding the playlist from the first song again. In this case, I think infinite scroll does ruins the experience. If anyone out there from Soundcloud is listening, please consider implementing pagination.
>Users will lose the page length orientation - the browser scrollbar become useless.
This is entirely untrue I can still use my scrollbar to get back to the top of the page again, it can also be used to easily skim the results that were displayed.
For most retail shopping I actually would rather have this than pagination especially if I am lazily browsing on my ipad, no reason to change hand positions.
The best use I have seen is a hybrid approach. Load 10 or so out of 100 items, use continuos scroll to show the remanding 90 and then use pagination to access the other results.
Pop quiz: according to convention, while using your scrollbar to skim the results that are displayed, what position do you move the scrollbar to (or avoid moving it to) in order to trigger (or avoid triggering) loading the next chunk of content? Hint: it's not the bottom.
I think saying flatly to not use infinite scroll lets me know that the writer doesn't have much technical skill. Rather, stating the current issues with infinite scroll and how to fix them is a million times more useful.
(warning: not mobile optimized)
It solves 1, 2, 3, 4, 5, 7, and 10, and could reasonably be implemented with bookmarking to fix 6 and 9.
SEO is still an issue, but really, when is it not?
I am assuming more results are loaded based on scroll-depth < 100% + an overlay to stop the user clicking.
Google/bots will be able to activate the link and request the next set.
Uesful resource http://www.iana.org/assignments/link-relations/link-relation...
I don't enjoy getting near the bottom of the page and suddenly being warped several screens ahead, then having to go back and figure out where I was. Find a way to prevent this if you're just loading comments to an article.
I find the scrollbar less disorienting because it has a high resolution than most mousewheels, its feedback loop is tighter, and I can jump both short and long distances; that is, there's no tradeoff between speed and continuousness.
I switch to pageup/pagedown/home/end on pages with infinite scroll because I can be guaranteed I won't miss any content and it's just less tiresome that using a mousewheel IMO.
A really stellar example of these sorts of bad user interaction is the Google Art Project if anyone cares.
You could solve some of these problems, like the browser being able to bookmark or get the url of a specific section, and standardizing the way it's done.
https://pbs.twimg.com/media/BkKYEmkCAAA3x8u.png:large
I think an infinite scroll would be better...
If i saw 'page 11' on Facebook, i'd instantly think about all the time i just wasted and try and be sure i didn't so that again.
Infinite scroll is great for browsing images. That's whats it's always been good for.
I am personally not a huge advocate of infinite scrolling (in most cases)but if are you are a seasoned programmer, that's not to say there are practical (and safe ways) to implement it.
If you want to launch a new site, and you have limited time (or are the only programmer) it's not cost effective to spend hours and hours working out all the kinks and make sure it's cross browser reliable etc... the novelty of infinite scrolling is something you should avoid. But if you have a good need, a good team (or yourself can spend time on thinking of all the various issues with it)- there is no reason why you could not implement it successfully.
I will not be using infinite scrolling on the comment system I'm writing for my start-up, pagination is good enough. But I will probably use it for the scroll back on a chat window (no one generally bookmarks chat...)
I agree with rch- people are always resistant to change... when you have something that removes a level of control- people freak out... new challenges introduced does not mean that it's bad, it just means it's a whole new set of things to think about. Humans are pretty resourceful. I liked the full physical keyboard on an old Nokia I had- but I got used to the touch keyboard- sure the touch keyboard is different, but there are many ways to make it better, and a physical keyboard adds a lot of much bulk to the phone.
I agree with the title of the post-- there are many reasons NOT to use infinite scrolling-- especially if it's just more of a novelty. But if done correctly (for for the right kind of content) it can provide an enhanced user experience.
My advice would to be: If you want to implement infinite scrolling-- make sure A) if you want to use infinite scrolling think about the aspects you have to deal with B) know general user's computer systems-- and how much memory you want to capture, C) decide if it's worth all the time to make it work right.
"New technology and trends always have good applications- it is up to you to decide if you are implementing it simply because it's trendy, because you want to learn, or because you want to enrich the community- if it's the latter- the best way to do is by sharing what you have learned, and learn from past failures" - Gus Anderson
Compare that to a page-number navigation scheme where only the displayed resources on a given page are loaded.
Not everyone has a fast computer (or tablet).
And of course flickr doesn't have any good tools for fine-tuning search results, so infinite scrolling is the only way to try and find what you want.
