I am a huge enemy of infinite scrolling. It forces me to constantly open links in a new tab instead of being able to use the back button as I am used to. It also forces me to think about my decisions on that website in a critical manner because if I mis-click anywhere or do anything that I would consider normal browsing it forces me to re-scroll through all that infinite data to where I was before. Usually I just click off in frustration.
It's possible to use the new HTML5 History API to update the current URL as you scroll, and so allow you to return to that specific place. Alas, as with most behaviors that have to be manually implemented by each site, we can be sure that a large numbers of them won't do it correctly.
I think infinite scroll is, for the most part, a lazy design pattern that tries to take advantage of our laziness. Every time I go to Facebook, I want to catch up on the latest shares from the people and pages I care about. I only need up to the last article I read, then I'm done. It's queue processing, not television watching. You should be able to get to the end of the feed. Instead it just starts rehashing old content.
Certain applications do more resemble television watching, where there's way more content than you could ever fit into a processable queue. Instagram, for instance. What I want there is for pics I've seen to get marked as seen and not come up again. Here infinite scroll makes sense.
Another interesting example in this space is Tinder. I'd like an Instagram-like experience for Tinder. Instead of having to swipe to see a new pic, I should just be able to scroll, and already-seen pics are treated the way left-swipes are.
I occasionally see the "There are no more posts to show right now." message, but it usually appears after you have waded through lots of old posts way down at the bottom.
Regarding the memory argument: better implementations of infinite scrolling, like Facebook, actually replace content with a single element of the same size when out of view, to decrease the DOM size. Content in and just around the viewport is still in memory.
I do agree with many of the other arguments though, especially bookmarking/history.
Don't know why you're getting downvoted. It's a fact - when you keep scrolling Facebook, it eventually slows to a crawl. Want a proof? Just go to a profile page of any of your frequently-posting friend and keep scrolling down.
Also, given how fast you can scroll back to the beginning, I don't buy the DOM-replacing technique. I've never seen it working on the desktop website.
Both Tumblr and Facebook do indeed replace off-page content in the DOM with placeholders. A chrome extension I am making that makes an offline copy of a page will make a snapshot of the page content with the hidden DOM elements in place, as can be seen here: http://i.imgur.com/bwGA0tp.jpg. Also - previously I worked at Tumblr, so familiar with the code base driving the dashboard.
While this technique does save on immediate memory consumption, I am sure that maintaining the stack still causes eventual slow downs.
Could it be because older content is not cache prioritized as much as new content? I would imagine anything after 1 day gets accessed much less than new content.
This misses the even more important question: while these baiting tactics work long term, or make users hate our guts and our site and jump ship the moment something more respectful emerges.
The increased adoption of ad blockers happened for a similar disrespect for the user -- and an over-embrace of "baiting"
I don't think infinite scrolling is an obvious lowest common denominator manipulation technique like sexy photos, pimple popping thumbnails, or clickbait titles. Mainly because it isn't signalling that the content is obviously low quality, it's just a more accessible reorganization of the layout.
On some sites, I have a tendency to click on the scrollbar and drag it instead of scrolling with the keyboard -- and then when the infinite scrolling kicks in, I find myself suddenly way down the page off in the weeds somewhere. So then I exclaim "shit!" and think about not returning to that site.
I think that's exactly the other way around. While my desktop has a lot of memory for the large pages, my mobile device has only about 2 gb. Browsing tumblr for example kills my phone's browser if I read more than 10 "pages".
I am also more likely to open tabs on my desktop than on my phone because it's more complicated to switch to the newly opened tab in Chrome.
Precisely correct. Like you, on my desktop, I counter the user interface deficiencies of infinite scrolling by opening links in new tabs. This prevents the very real and very annoying problem of not being able to return to the infinitely-scrolling list view at the position I left it. Tabs prevent that loss of page context.
On a mobile device, tab-based workarounds are possible but more cumbersome, so I usually choose to open one item from the infinite scrolling list traditionally. If when I return via the back button, context is lost, I usually concede defeat by this bad user interface paradigm and leave the site.
I've found the other way around to be my reality on Monday Mornings coughbittorrenting when my network is somehow constrained.
Tumblr refuses to load the `next page`, and I don't want to hit the refresh keystroke combination because I really really don't want to go back to the top of the "page". I simply want the "next page" to load correctly.
I think numbers speak for infinite scroll to keep users on the site.
No matter how bad it is: Either the problem is wider or there is a benefit.
A wider problem would be tying people to services with annoyances and playing on addictive behavior.
A Benefit would be an undisturbed flow of skimming over content or using the edge of the screen as a reading aid (I hate it, when I scroll down one screen on HN and the site bottoms out. I than need to find until where I read and where the previously unseen content begins¹).
¹ ok, might need to write an extention for a red line fading away after you skipped a page :). A bit like the "read until here" lines in irc clients.
You state "either the problem is wider, or there is a benefit". There are other options. The possibility, say, that infinite scroll (plus crappy filtering) feeds into psychological dysfunctions such as FOMO.
That optimises for keeping-users-on-site, but may well (and I'd argue doesn't) optimise for user satisfaction, utility, or ultimately, satisfaction.
As Clay Shirky says, it's not information overload, it's filter failure. The slogan of the old nn Usenet reader was "no news is good news". A stream full of crap isn't a good thing. A stream with an occasional flow of gems is far better.
I've suggested datelines (to tell when entries were added), read/unread indicators, and introducing of other-than-alread-seen content into streams. I've yet to see any of these adopted.
I don't mind it if it's a mainly text page, but hate it when it's an image heavy page. Trouble is, most pages are now image heavy.
If it's something mainly images, like tumblr, I'd be much happier actively paging through than forcing my phone, or even my desktop, to load GBs of images I'm skipping past.
Google+ and FB become unusable (and the browser you visit them in) if you go down too far, so it's not just a bad idea, it's basically breaking.
I don't feel like a "show more" link should fall into this bucket. With a show more link, the user remains in control and they can opt for the footer if they prefer. It's also pretty straightforward to implement proper bookmarking using the history API should that be needed.
The back button is usually broken with this approach. At best the user is going to get a very jumpy experience, usually they will need to scroll down and click "show more" several times.
To combat #1 my team advocates for a "semi-infinite" scroll whenever clients request an infinite scroll. A screen will implement an infinite scroll for 2-3 pages of data, then we turn off infinite scroll and display a "load more" button so the footer shows.
This UX pattern does have benefits for the user. It has a low cognitive load with very little friction to show more items. All the UX challenges he calls out are solvable.
In addition, this has been solved on the desktop. File browsers and Media players with large collections already do this well. The challenge is building a great scrolling experience on the web.
I've seen many folks try to solve this with a repeater control and they quickly find out that there's a long way to go to get something with great performance. What's really needed to solve the problem is UI & data virtualization, which is something that native app developers have a lot more experience with.
Seems like the problems pointed are all about a bad implementation of infinite scrolling, not about the problems of it. You should use a virtual list that already knows how many elements are available totally, in this way you can already provide the right size to the list and the scrollbar is not affected. The footer could just be fixed ok bottom of the page. I mean, there are plenty of good solutions.
What if Infinite Scrolling were utilized inside of a fixed or static positioned element? I imagine a webpage with a header and a footer, and the body element is of a fixed height and implements some type of Infinite Scrolling?
Have you seen this approach used, is it a reasonable compromise, what problems remain?
Is there a standard approach to release memory from items at the beginning of the scroll when they're far off screen?
That obviously depends on what you're doing. Paginated content (with the obvious exception of multi-page articles) is often a symptom of poorly defined search criteria. Did you really mean to view all 6 billion cat pictures? Or only the latest ones? Maybe only the ones of cute ginger cats?
I don't think the author is particularly against infinite scrolling. He provides a great checklist of do's and don'ts, and is basically calling you out if your page sucks.
If your page eats memory, needs finer analytics, and doesn't comply with bookmarking and back button functionality, don't do it. But good infinite scroll pages solve this.
Choice paralysis and scrollbar issues seems less relevant, because having 100 pages can be just as paralyzing and the scrollbar is a non-issue with wheels and touch.
As for the last point he makes, being harder to use, the entire list applies to any paginated page also.
Google Images is a good infinite scroll page. Content opens inline, you're engaged in a visually seeking task where anything beyond looking would be distracting, and the page does tap-off (cop out?) at a certain point so that it isn't too infinite. Though you can "load more", at that point you are given the opportunity to rethink your search criteria, and that speed bump is practical.
> and the scrollbar is a non-issue with wheels and touch.
Yes, let's just completely dismiss the concerns of people whose preferred way to move up and down in a web page is to grab the slider with their mouse or stylus. Everyone is perfectly able to curl their fingers around a little pod that makes them put their wrist into a position that can cause strain on the tendons and make lost of tiny, precise movements with it. Nobody has any RSI issues.
- signed, a lady who uses her Wacom tablet instead of a mouse for all of her desktop computing after her index finger decided it refused to double-click without pain.
All I stated was the scrollbar is a non-issue with wheels and touch. And it isn't.
I sympathize with any health issues, but to be fair, if we were discussing accessibility then RSI is just the beginning.
Also, maybe you're not able to use it, but most Wacom pens have options to allow scrolling by just clicking and dragging, making the scrollbar a non-issue. The scrollbar has never been the most convenient of interfaces.
Right. Except either way, the length of the page hardly ever corresponds to the amount of content. With pagination we are left counting the O's in goolge for example.
tbf you can either design for everyone or you can be at the cutting edge of adoptability and "coolness"
you don't see snapchat caring about folk without arms for example- useability concerns depend on the service you're building.
Speaking of scrolling & performance degradation, there's something wrong with Medium pages: with JavaScript turned off, and in Firefox on Linux, they scroll agonisingly slowly.
While I agree with the premise, I do find it ironic that his blog platform's header sporadically drops down to block the content I'm trying to read every time I scroll down. >:(
Because the table can change. Imagine showing the first 0..10 rows, deleting the 5th row, then showing 11..20 rows. And what happens if you insert rows while paginating?
"Infinite scroll" to me screams "bad or nonexistant filtering tools".
Some of the issues listed in the article (memory consumption) can be addressed through hacks (keeping the current and 1-2 higher or lower screens resident, flushing others). Some (footer unusability) are real problems -- I've largely concluded that sidebars are an anti-pattern for virtually all textual content (hence my use of Reader Mode or Pocket for such content).
More often, though, I view a scroll or list as a set of potentially interesting candidates that I want to further winnow down. The lack of ability to do so in far too many contexts simply boggles me.
Not just Facebook (which I don't use), or G+ (which I do when Google aren't overtly backing antidemocratic anti-equality measures such as the TTP and TTIP -- oh, Facebook and Apple do too), or Reddit. But, say, shoping sites.
I hop onto Amazon and am interested in, say, laptops. Or cords. Or pens. Or chairs. And am presented with, in response to a reasonable search for that term:
1. A great many items which are in no way, shape, or form, laptops. Or cords. Or pens. Or chairs.
2. Items far, far outside my price range.
3. Vendors whom I will not, ever, under any circumstances, purchase from.
Etc.
If I were in an actual full-service store, I'd indicate my preferences to the salesclerk, and, if they were in the least worth their salt, they would remove the offending items and not present them again. (And if they refused to do so, I'd simply leave.) For all its vaunted capabilities, online selection doesn't do this.
For content, I compare a stream with an offering of, say, publications, authors, topics, and quality-of-writing. In a physical stack, again, I could eliminate publishers, authors or reporters, genres, publication dates, etc., to get to specifically what I want. But online:
1. Reddit doesn't allow me to filter by total quality of a post or discussion. (The fact that its moderation system makes such filtering all-but-useless is another problem).
2. Google+ doesn't have author, topic, negative match (e.g., term exclusion, say, -trump or -kardashian), or date selection in its searches.
3. Amazon doesn't allow filtering within merchandise categories for matching vs. nonmatching items. Say, stationary items which aren't pens, or clothing items which aren't slacks.
None of these tools allows me to select a specific match and indicate "go away" with some level of prejudice: don't show me this item, don't show me this author, now, or forever, etc.
I've got hugely more utility with a pile of books or articles sitting on a table.
Yeah: scrolls are lazy-ass cheap copouts to psychologically hook users (the ones who aren't immediately pissed off and run like hell), and to avoid both useful filtering and the necessary deep content classifications required for actually beneficial content selection.
I came to think that an actually useful, really pro-user ("user-friendly"?) interface for the sites you listed would generally be a very thin UI over a query language. So to use your example, when I visit Amazon, what I really want to do is something like this:
SELECT * FROM products WHERE category="stationery"
AND tags NOT LIKE "%pens%
AND price BETWEEN (20, 200)
AND vendor NOT IN [my blacklist, fetched from the profile]
ORDER BY price ASC
LIMIT 100;
It isn't hard to make an interface for generating such a query with a mouse. Hell, most of the sites already have most of the elements for that, they aren't just showing enough of them enough times. I could imagine with such an interface I could further refine my search by hovering over e.g. a "paperclip" tag and clicking an "exclude" button that would dynamically show itself. Etc.
Now this interface would be infinitely more useful than what most of e-commerce & social networking sites have, it would be much easier to do than what they have - but here's the kicker. They don't want that. It's not in their interest to make an useful tool, because they get to make less money this way.
And speaking of social media and usefulness, Facebook got close to my ideal a while ago. You could do almost SQL-like selects when searching for content. But this function, known as Graph Search, is gone now. Probably because some people called it "creepy". I guess everything even remotely distinguishing your product from a TV program is now "creepy".
That's one part of the problem, and yes, it's a large part.
The other, though is that the coding, presentation, and awareness of what's offered is utterly shite.
Amazon quite literally has no fucking clue what the hell it's selling. And it's among the better sites. Craigslist is even more abysmal -- I was searching for a specific type of chair some time back and found myself presented with anything from that (rarely) to hammocks to porches.
Whether it's quality control over item descriptions, or AI to sort out what things are, or collaborative filtering, or nominated expert filtering, or whatever, better data over what's actually represented by systems is also required.
For articles and textual content, author, authority, and various other metadata need stronger control. I see a Web in which such information being accurately presented as crucial to search results placement helping, possibly.
Not really, if you've developed this the right way - which is render only items that are currently visible and derender the ones that are above the current scroll canvas.
> 3. Analytics is harder to implement
> 4. Bookmarking and the back button become problematic
I put those together, because they are relevant. Anyway Google suggest how to remove this [1] and even presents a demo [2]
As other people here suggested, this depends on the content. If you work in e-commerce there is quite a habit people to scroll infinitely with a huge amount of products ( disclaimer - I'm the sole developer of `www.bagaholic.me` - bags price comparison website ).
> 6. The scrollbar becomes unusable and untrustworthy
Not a significant reason at all. Twitter, Pinterest, Facebook proved that.
> 7. It’s generally hard to use
I think stating that, without some stats is kinda "opinionated". Again based on the content a valid context with fixed sidebar, header is a must.
Who said the site has a fixed sidebar? Why create a design that necessitates one?
>Not really, if you've developed this the right way - which is render only items that are currently visible and derender the ones that are above the current scroll canvas.
So change the list constantly under the user, and thus the scrollbar and relevant position. Plus, the extra coding complexity, and what for?
>5) As other people here suggested, this depends on the content. If you work in e-commerce there is quite a habit people to scroll infinitely with a huge amount of products
Even in commerce, choice paralysis is a thing, regardless of if people tend to "scroll infinitely" if they are shown a huge amount of products. That they scroll doesn't mean they don't feel the choice paralysis.
>6. The scrollbar becomes unusable and untrustworthy
FB wants to be immersive and keep you lost deep inside to show you ads, not to do what's best for usability.
This argument could go on forever, but why create a design that necessitates a footer to begin with?
I mostly agree with the article, but it's crazy to say any one design solution is universally good/bad. There are good and bad ways to implement just about anything.
Design is primarily about presenting information according to its relevance. A footer is a way of presenting unlikely-to-be-relevant-but-still-necessary information. It is a tool that accomplishes something that is necessary for just about every webpage.
"Footers" (or related things like captions) exist in just about every design, and they almost always function the same. Art galleries have plaques. Books have footnotes. Food packaging has nutritional info. If your design doesn't have a footer, then it's probably a mistake.
>This argument could go on forever, but why create a design that necessitates a footer to begin with?
Because a footer, like a header, are staples of web design since day one, and work well as anchors that the user knows and expects to find at the top and bottom of the page.
They also leave all other (layout) options open.
Whereas a sidebar for example, while good in some situations, it prevents e.g. to have full side-to-side images and other such content, or distracts from the main text when reading long form, etc.
For points 1, 2, and 4, I do agree that solutions exist, but I found myself agreeing with the author that they're an issue simply because I run across enough sites that continue to have these problems despite many good sites demonstrating how the pages should operate.
I think the article's point would stick a little better though if the author focused more on the implementation than on the ∞scroll itself, since it's inconsistency across user experiences that causes frustration with ∞scroll, not so much ∞scroll itself. The only reliable constant across implementations of ∞scroll is that you'll be able to continually scroll; how it interacts with static content on the page, how it interacts with the back-button, and so on depends completely on how well it's implemented. It is very frustrating to come across sites where you follow a link far down in the page and hit back, only to be taken to the very top of the list and having to scroll and reload everything again. It's not even so much a performance issue; my old iPhone4s handles most ∞scroll just fine, but it's still just frustrating to go through pages and pages of scrolling because hitting Back didn't return me to where I was. This is particularly bad on mobile where fat-fingering links is pretty easy/common.
Edit: not sure why you're getting down voted - I think your comments are fine and worth discussion; I also think they're wrong, but that's the point of discussion...
> Not really, if you've developed this the right way - which is render only items that are currently visible and derender the ones that are above the current scroll canvas.
This way the browser's "find" feature doesn't work at all. Are you going to implement your own "find" feature too?
