CAN YOU USE AN ORDERED LIST WITH YOUR H2s?
Hi, Joe, long time no chat!
I opted not to use a list at all because with the amount of content I figured headings were an appropriate fit (though I did consider an opening list with anchor links to each heading). Ate you suggesting I wrap the entire post in an OL and put headings/content in each LI?
Ugh, it's Joe Clark. Joe Clark, everybody.
Nice article. You should take a look at infinite scroll at our RSS reader – http://silverreader.com It has various keyboard shorcuts implemented…
It's an app. Keyboard shortcuts or not, are you suggesting it honors all the rules I outline above, or is this just spam? I'll ask on Twitter before I delete this.
I wanted to point out that you should look at our implementation. I think it covers lot of from your checklist.
It is not spam.
At your prompting I signed up and tried it out.
1. The back button doesn't apply as all links open in a new window, so kudos for bypassing that one.
3. There is no footer, so you PASS #3.
4. As I tab through the page, partway into a second post my keyboard focus jumps back to the first post. Consistently (Chrome 35 Win). It fails #4.
5. I cannot share a URL, though that point may not apply as this is a page behind a login.
6. I cannot jump ahead a few screenfuls, so it fails #6.
7. I only loaded about 20 items, but the memory did increase and will do so even more for longer blog entries. I say it fails #7.
8. I see no option to disable the auto infinite scroll. It fails #8.
9. Have you conducted user tests?
10. Was this feature driven by a clear need or request?
11. Are you measuring (not just tracking) how well this works for users?
Out of 11 items, it passes only 1. Your example fails 5, doesn't apply to 2 more, and the remaining 3 only you know the answer.
I don't consider a ~50% failure rate (or ~10% pass rate) something that covers "a lot" from my checklist.
I'm not sure why you posted it. It's a pretty quick process for you to check it and you have to see it doesn't pass any more than one item, Four items (out of eleven) if you can make a case for your user testing.
Back in Feb Google posted some advice to make infinite scroll mode search engine friendly.
Forgot about that, thanks for posting it. Note that Google has its own checklist of items just to make your infinite scroll indexable. Add those 6 to my 11 above, and you've now got 17 items to check.
IMHO I would offer an “unload first shown items” button. This way you could also manage the dynamic range of items you would like to show via the following URL parameters: first-item, last-item.
This way you can save memory (if the user unloads items, manually or automatically after scrolling) without forcing a paginated list.
Think for example that the user wants to list items 3 to 7 of a list with 8 items. With a paginated list I think it is not possible, even allowing him to choose the amount of items that can be shown in each page.
Replacestate would be the last ingredient. Pushstate is not interesting, because the list has not a unique sorting criteria, the user can choose it.
feedly (RSS reader) executed infinity scroll the right way.
By “the right way,” do you mean in your opinion or in mine? My opinion is clearly laid out above, and while I do not have a Feedly account, a few minutes on the marketing site does not give me high hopes it does a good job of infinite scroll.
[…] (inspiré entre autres de Adrian Roselli, So you think you built a good infinite scroll). […]
[…] (inspiré entre autres d’Adrien Roselli). […]
I am happy to see someone actively criticising infinite scrolling and offering a checklist for implementation.
I have hated infinite scrolling since its invention some 5 or 6 years ago. Can’t find anything useful in it at all.
Nowadays I avoid sites which implemented infinite scrolling.
A good read why it usually is a bad idea is the NN article from 2014 on its usability issues: