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…
Do not combine footers and infinite scrolling
61–70 of 129 posts
Re: Do not combine footers and infinite scrolling
#62Who 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.
I suspect the really bad stuff comes from places other than the developers.
Re: Do not combine footers and infinite scrolling
#63Earlier 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.
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
#64Earlier 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
Re: Do not combine footers and infinite scrolling
#65Re: Do not combine footers and infinite scrolling
#66Shh. 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. :)
Re: Do not combine footers and infinite scrolling
#67This drives me crazy too. You can never get to the stupid footer.
Re: Do not combine footers and infinite scrolling
#68I 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.
Re: Do not combine footers and infinite scrolling
#69I 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.
Re: Do not combine footers and infinite scrolling
#70Who 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…