I run a collection of websites that all use infinite scroll and serve ~90 million MAUs.
#1 Poor performance issues
We started doing off-screen clean up, but it's a similar pattern to any ListView like component. Setup and teardown. The browser is smart though. It's not any more work than the setup/teardown a typical SPA should be doing.
#2 Footer is drowned
Footers are useless. Put it in the menu.
#3 Difficult to implement analytics
No more difficult than triggering a SPA pageview. This is misleading.
#4 Navigation is muddled
This is the most valid argument. We solved by being clever about History.pushstate(), triggering when the next article title hits 50% of screen. Bookmarking works fine.
#5 Scrollbar is hard to use
Misleading. The web is mostly mobile. People generally use efficient scroll input devices, scroll wheels trackpads. Most browsers hide the scrollbar because of this. Scrolling many tens-of-thousands of pixels is NBD.
#6 It is hard to use
Misleading, not quantifiable.
#7 Disorients users
Misleading, not quantifiable.
#8 No skipping allowed
Easily solved. We built an in-between module to provide the user with the option to modify their infinite scroll path. If you pick something here we use that to make the rest of articles closer to your interests.
#9 No bookmarking
Solved with History.pushstate()
#10 Terrible user experience
Any UI pattern can be abused to be bad UX.
# Pagiantion UX is usually bad
To counter the arguments. Arguably pagination is more broken. Navigating pages. Generally they aren't bookmarkable unless you implement advanced cursor pagination.
# Content consumption flow
Data supports that users want to consume content with minimal interaction and engagement. If you provide a consistent scroll experience to get from one thing to another, and it's relevant enough, people will really stick around and consume it.
Bounces, time spent, and other KPIs for web-traffic engagement have all gone up as a result of using infinite scroll.
Perhaps we're an outlier and paid attention to the difficult to solve implementation nuances but I don't mind it on other sites.
The alternatives were footers full of information I'm not interested in and outbrain modules...
> This is the most valid argument. We solved by being clever about History.pushstate(), triggering when the next article title hits 50% of screen. Bookmarking works fine.
As a user this bothers me the most. If I have no intention of reading the next article but scroll to the end it then takes two clicks to leave the site via back button - sometimes more.
IF you wanted to do it right, only set history when the title of the next article is at the top of the viewport. 50% just isn't enough and likely just messing up your kpis.
I'm going to rail against your attitude here, not you:
0. Appeal to authority.
1. Sounds like job security.
2. Footers are NOT useless. Menus are aggravating.
3. Analytics are 99% evil, 1% hot gas.
4. Stay out of my History.pushstate(). I don't need 50 things in my back stack just because your "page" couldn't fit on one screen.
5. Too many incorrect facts to address in one line.
6. It depends on what the definition of "is" is. No. Single cluttered pages are quantifiably easier to use than a dynamic page of unknown length. Is it ever going to stop?
7. It disorents me, and I'm a super-ultra-mega power user. Spinning a 3D model when the user scrolls down is downright unexpected behavior. It's a trick. A gimmick. A distraction. It's disorienting.
8. I don't want a choose-your-own-adventure. I want a damn single page with damn information on it.
9. I don't think that's a solution.
10. I don't care about "User Experience." I want "User Interface". "UX engineer" is just job title inflation for non-committal designers.
“Analytics are evil”? Seriously? How else do you propose understanding how people are interacting with your site? How can you A/B test improvements without analytics?
as often happens, the article focuses on technical aspects; technical arguments are easy to dismiss with more technical arguments.
The real problem with infinite scrolling is that it's temporarily addictive, and the only reason it exists is to maliciously keep you scrolling. I don't like that and I think infinite scrolling should not be used by (and is not adding anything useful to) benign services/products
It says in 2018, mobile was 58% and desktop 42%. Optimizing for the 58% is fine, but when it comes at the expense of the 42% it is harder to justify just handwaving it away.
More interestingly, the above page indicates that while there are a greater number of mobile visits, they don't stay as long and are twice as likely to "bounce", which I infer means leave the page before spending any significant time.
So by those metrics, although desktop users are fewer, they spend more total time. Again, ignoring their scrolling preferences to optimize for mobile seems questionable.
I'm guessing the person who posted this works at a US-based publishing group, in which case mobile traffic is likely ~75%.
Scrollbar hijacking is a valid objection but I do wonder how many users in that 25% it affects. I'm on a Mac and the freaking scrollbar disappears after less than a second of non-use. I think I've pretty much ignored it since Mac started doing this...
I'm guessing you work for a publisher like Condé Nast that pushed this pattern onto unsuspecting properties like Pitchfork? I am extremely annoyed every time I encounter one of these - it makes skimming articles impossible since you miss the end.
>I run a collection of websites that all use infinite scroll and serve ~90 million MAUs.
The point is whether those same ~90 million Monthly Active Users would be better served by more traditional page flipping or some other navigation mode.
I believe that it greatly depends on the specific site and its contents, but the original article sounds like good (and often "rare") common sense, if you have good reasons (and can actually provide a working, not annoying, solution) go "infinite scrolling" if you are not 100% sure stick to more traditional pages.
#1 Poor performance issues
We started doing off-screen clean up, but it's a similar pattern to any ListView like component. Setup and teardown. The browser is smart though. It's not any more work than the setup/teardown a typical SPA should be doing.
#2 Footer is drowned
Footers are useless. Put it in the menu.
#3 Difficult to implement analytics
No more difficult than triggering a SPA pageview. This is misleading.
#4 Navigation is muddled
This is the most valid argument. We solved by being clever about History.pushstate(), triggering when the next article title hits 50% of screen. Bookmarking works fine.
#5 Scrollbar is hard to use
Misleading. The web is mostly mobile. People generally use efficient scroll input devices, scroll wheels trackpads. Most browsers hide the scrollbar because of this. Scrolling many tens-of-thousands of pixels is NBD.
#6 It is hard to use
Misleading, not quantifiable.
#7 Disorients users
Misleading, not quantifiable.
#8 No skipping allowed
Easily solved. We built an in-between module to provide the user with the option to modify their infinite scroll path. If you pick something here we use that to make the rest of articles closer to your interests.
#9 No bookmarking
Solved with History.pushstate()
#10 Terrible user experience
Any UI pattern can be abused to be bad UX.
# Pagiantion UX is usually bad
To counter the arguments. Arguably pagination is more broken. Navigating pages. Generally they aren't bookmarkable unless you implement advanced cursor pagination.
# Content consumption flow
Data supports that users want to consume content with minimal interaction and engagement. If you provide a consistent scroll experience to get from one thing to another, and it's relevant enough, people will really stick around and consume it.
Bounces, time spent, and other KPIs for web-traffic engagement have all gone up as a result of using infinite scroll.
Perhaps we're an outlier and paid attention to the difficult to solve implementation nuances but I don't mind it on other sites.
The alternatives were footers full of information I'm not interested in and outbrain modules...