Live data from Hacker News

Do not combine footers and infinite scrolling

willfennel.com

91–100 of 129 posts

Re: Do not combine footers and infinite scrolling

#91

I once shipped a new product, and was surprised to receive no negative feedback from users regarding content quality. Happens out, UX team placed the "Send Feedback" button below the infinite scroll content feed.

It's hilarious to me that the Design/UX team is always the one making mistakes like this where I've worked. We're just sitting there saying, even from a non-code point of view, this shit makes zero sense. Ignored as usual.

It’s not just designers. I’ve given up suggesting style improvements because the boss comes back with “no user complained about it yet” when my suggestion is to use less crappy color. Who is going to complain about a color? Smh

Re: Do not combine footers and infinite scrolling

#92

I once shipped a new product, and was surprised to receive no negative feedback from users regarding content quality. Happens out, UX team placed the "Send Feedback" button below the infinite scroll content feed.

It's hilarious to me that the Design/UX team is always the one making mistakes like this where I've worked. We're just sitting there saying, even from a non-code point of view, this shit makes zero sense. Ignored as usual.

A professional medical doctor will make more medical mistakes than I will.

Let us try our best to treat them charitably, forgive the mistakes we see, and provide input to help them do their work even better!

I had success working with Design/UX or any other specialists acknowledging that they spent more time thinking about it than I have, and that, of course, they will be the final decision makers on whether to accept or reject any inputs I give, before providing any feedback or ideas I have. Also, taking the attitude, not of "Let me teach you X", but of "Teach me whether you considered X and, if you have, why you haven't tried X yet".

Re: Do not combine footers and infinite scrolling

#93
post #62

Earlier quoted context omitted.

A lot of smaller shops don’t have dedicated designers. The devs do the design work, too.

That's where I'm at... but of course we don't have footers of doom, because we won't. So that's kinda moot as far as all the internet "don't do this" proclamations go. I suspect the really bad stuff comes from places other than the developers.

No post body was provided.

Re: Do not combine footers and infinite scrolling

#94
post #74

Earlier quoted context omitted.

For almost all the uses you've listed, I can readily think of examples where I've seen it done badly. Thinking of good examples is considerably harder. Can you provide some? In my experience, deferred loading merely guarantees that there's visible latency multiple times when interacting with a page even after it has "finished" loading. And since lazy image loading can now be accomplished without JavaScript, I'm not s…

> Thinking of good examples is considerably harder. It would be, if they’re done well they’re indistinguishable from not being there at all. It’s unfortunately biased against good implementations. As far as examples, the best by far are HTML-only (img with loading=lazy, which behaves as expected almost universally). After that, I’m on mobile right now so limited in my reference capacity, but they tend to use Intersec…

> I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself)

When scrolling through a long document with a touchpad, it's natural to make several swipes in rapid succession, with the second swipe starting before the momentum scrolling or snap animation triggered at the end of the first swipe has finished. On my Mac, in Chrome it appears that starting the second swipe interrupts the snap animation (good) and doesn't start a new one when the second swipe ends (bad), even for a mandatory snap container—leaving the container in what should be an impossible steady-state.

In Safari, things seem to work as expected, except for the more general usability problem that making multiple swipes like this can cause the scrolling to be amplified far beyond what the user would expect for a non-snapping container.

In Firefox, things mostly work, but I'm occasionally seeing instances where the container below the one I'm scrolling also scrolls a bit. Not easily reproduceable, but since I was playing with the horizontal scroll container examples it seems unlikely that I accidentally made the right combination of one and two finger gestures to get the cursor to stray down to the lower container, scroll it a bit, move the cursor back up, and continue scrolling that one. Ordinarily, no amount of frantic two-finger swiping results in that much one-finger cursor movement, and it appeared the spurious scrolling of the second container was more correlated with rubber-band animation when scrolling past the end.

And that's from about two minutes of playing with literally the first example I could find.

Re: Do not combine footers and infinite scrolling

#95
post #62

Earlier quoted context omitted.

That's where I'm at... but of course we don't have footers of doom, because we won't. So that's kinda moot as far as all the internet "don't do this" proclamations go. I suspect the really bad stuff comes from places other than the developers.

Quoted post unavailable.

I think there’s a big difference between unintuitive and the footer thing.

Re: Do not combine footers and infinite scrolling

#97
post #73

Earlier quoted context omitted.

Infinite scrolling works great for search results. I have it enabled in DuckDuckGo, and when I use Google and hit the bottom of the page, clicking the next page button feels sp cumbersome. For anything not ephemeral like search results, infinite scrolling sucks.

if you infinite scroll, you'd also need some sort of url update so that you can always copy the url, and get back to this scroll position. i hate sites that have infinite scroll, but never allow you to "save" a position in the scroll to come back to in the future.

That's my point: most search results are ephemeral, and Google/DuckDuckGo results certainly are.

Re: Do not combine footers and infinite scrolling

#99
post #94

Earlier quoted context omitted.

> Thinking of good examples is considerably harder. It would be, if they’re done well they’re indistinguishable from not being there at all. It’s unfortunately biased against good implementations. As far as examples, the best by far are HTML-only (img with loading=lazy, which behaves as expected almost universally). After that, I’m on mobile right now so limited in my reference capacity, but they tend to use Intersec…

> I haven’t found that to be the case, what improper behavior did you see? (I’m asking because I’ll file an issue if it’s actually wrong and if you don’t feel inclined to file it yourself) When scrolling through a long document with a touchpad, it's natural to make several swipes in rapid succession, with the second swipe starting before the momentum scrolling or snap animation triggered at the end of the first swipe…

Good detail, albeit somewhat revealing of a chaotic testing approach ;)

I’ve also experienced some weird edge cases behaviors with scroll-snap in desktop browsing environments, though seldom as pronounced as what you describe for Firefox (admittedly I don’t test in FF as much as I ought to, but I also don’t do much work that could even be browser-specific at this point).

It sounds like there are a couple potential bugs maybe worth filing here, given precise repro steps. Would you like the honor or shall I? I won’t be back at my desk til mid day tomorrow probably but I’m happy to see what I can repro and file what I can.

Post reply on HN