Live data from Hacker News

Do not combine footers and infinite scrolling

willfennel.com

61–70 of 129 posts

Re: Do not combine footers and infinite scrolling

#61
post #58

Who makes these decisions really? HN tends to be more developer focused but I suspect most of these horrendous type decisions aren't made by random dev, and random dev isn't in a position to stop it. Many years ago I once worked at a place where a CRM app had "special instructions" and at one point management was so upset about people not following them 100% of the time they were considering "make them blink" so the…

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

Re: Do not combine footers and infinite scrolling

#62
post #58

Who makes these decisions really? HN tends to be more developer focused but I suspect most of these horrendous type decisions aren't made by random dev, and random dev isn't in a position to stop it. Many years ago I once worked at a place where a CRM app had "special instructions" and at one point management was so upset about people not following them 100% of the time they were considering "make them blink" so the…

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.

Re: Do not combine footers and infinite scrolling

#63
post #45

Earlier quoted context omitted.

It’s possible I’m lacking imagination after ~20 years of web dev experience, but I can’t think of a way to systematically prevent this. I can hardly even think of a heuristic to detect it which wouldn’t be either overly broad or overly specific. A spec which privileged more of a page’s “chrome” as part of the browser UX would probably make that more realistic, at the expense of being a very high value attack surface.…

Aside from a handful of web applications (like Google Maps), I struggle to think of a good reason for sites to be able to observe or hijack scrolling behavior. That capability is abused far more often that it actually leads to improved usability, and I don't think the web in general would suffer from sites being denied that power by default.

I understand your perspective but for you and anyone else reading, here’s a more familiar analysis.

Maps apps don’t make much use of scroll APIs at all, they tend to use pointer events (and/or their older mouse equivalents). When they do it’s almost always auto-panning to some item in a more traditional results list, and always a horrible experience. Apart from infinite scroll, the most common uses of scroll-related APIs are:

- deferring load/execution of resources until they’re pertinent; this is almost always a better UX, unless it’s done very poorly (side eye at many news sites)

- removing offscreen elements from long lists to minimize their performance impact; again almost always a UX benefit unless done poorly, though easier to screw up

- restoring scroll position between interactions; generally neutral, about the same level of quality as built in behavior, but better than not doing it when there’s client-side navigation (and I know this is another JS curmudgeon complaint, but it’s almost everywhere and mostly unnoticed)

- scroll-snap, which has eliminated the need for JS for whole classes of presentation (and probably the first unambiguously good thing MS purposefully introduced to web standards)

- offsetting jump in-page anchor/jump links to place content in view where they’d otherwise be obstructed; significantly benefits UX, unfortunately not (yet?) as widely adopted as I’d prefer

- “scrollytelling”, which can be really annoying but also can be incredibly useful if done well; notably a CSS standard is finally getting real world traction and will make the usage much more user controllable and much less awful for users who don’t control it

- shady tracking stuff which is mostly invisible to the user; entirely awful but categorically a whole separate UX topic

- weird event handlers to control things like video volume; I hate these with a burning passion

Overall, IMO, the value is kind of a wash. But the positives generally amplify positives for a lot of other UX problems and newer standards have made them basically mostly harmless.

Re: Do not combine footers and infinite scrolling

#64
post #44

Earlier quoted context omitted.

It’s possible I’m lacking imagination after ~20 years of web dev experience, but I can’t think of a way to systematically prevent this. I can hardly even think of a heuristic to detect it which wouldn’t be either overly broad or overly specific. A spec which privileged more of a page’s “chrome” as part of the browser UX would probably make that more realistic, at the expense of being a very high value attack surface.…

overflow: hidden

That’s effectively the same behavior as a footer below an infinite scroll. It’s just more obviously stubborn about it.

Re: Do not combine footers and infinite scrolling

#65
Something tells me we're seeing more of this partly because of graphql and its first class spec to infinite scrolling. So no - I don't think the decision came from none other than the programmer who do this. And to be quite honest, UX designers I've worked with don't really dictate this kind of stuff. Heck, some don't even know how the scrolling works in their own designs when asked about it!

Re: Do not combine footers and infinite scrolling

#66
post #6

Shh. Don't tell the committee that designed the footer that no one can ever see it. They'll want to go with the supermenu header instead.

That's okay. The menu items in the header will drop down on hover, making it very easy to use when the user is scrolling the page. :)

The good news: No such thing as hover on mobile.

Re: Do not combine footers and infinite scrolling

#68
post #15

I wish this was made impossible by browsers. It's like making a user chase their tail; they won't ever catch it. They just keep going in circles until they explode with frustration. You can't even cancel the requests to load more data. I have come across a couple of these (I think blogs & news sites do this) and it is so annoying.

[deleted]

Re: Do not combine footers and infinite scrolling

#69

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.

I've encountered pages like that and wondered if the ux devs did it for that express purpose... last time I saw it, I was looking for some legal info (copyright/privacy or something); a dark pattern indeed.

Re: Do not combine footers and infinite scrolling

#70
post #58

Who makes these decisions really? HN tends to be more developer focused but I suspect most of these horrendous type decisions aren't made by random dev, and random dev isn't in a position to stop it. Many years ago I once worked at a place where a CRM app had "special instructions" and at one point management was so upset about people not following them 100% of the time they were considering "make them blink" so the…

I'm not so sure. Most of the web devs I have worked with over the years haven't been overly thoughtful regards UX. I'd even go as far to say that it's the least considered aspect of their process. "Not my job" mentality. Tho probably says more about the nature of my experience than anything else.
Post reply on HN