5 ms·

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 expl

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.

II2II 4y ago
Especially when you are trying to reach the RSS feed link in the footer, which you are desperately trying to reach since an RSS reader will allow you to avoid infinite scroll!
- iostream24 4y ago
  RSS first design needs to become a thing
eyelidlessness 4y ago
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. This is almost certainly better addressed by discouraging and shaming than by trying to fix it at the browser level. I agree with the clarity and brevity of the article (even if I can’t muster such brevity to save my life). And it’s very rare that this kind of UX is any more onerous to me than closing the tab/leaving the site.
- ushakov 4y ago
  overflow: hidden
  - eyelidlessness 4y ago
    That’s effectively the same behavior as a footer below an infinite scroll. It’s just more obviously stubborn about it.
- wtallis 4y ago
  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.
  - ushakov 4y ago
    observing is great for marketing pages overriding scrolling behaviour or virtual scrolling is a complete no-go eg. this one: https://www.fortnitelookbook.com/en https://www.fortnitelookbook.com/en
    - wtallis 4y ago
      Every scroll-related behavior on that page is entirely gratuitous, and it made my laptop's fan spin up audibly. I'm not sold.
  - eyelidlessness 4y ago
    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.
- wruza 4y ago
  Yeah, discouraging and shaming always works. Many of examples out there.
deleted 4y ago
[deleted]

II2II 4y ago

Especially when you are trying to reach the RSS feed link in the footer, which you are desperately trying to reach since an RSS reader will allow you to avoid infinite scroll!

iostream24 4y ago
RSS first design needs to become a thing

eyelidlessness 4y ago

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. This is almost certainly better addressed by discouraging and shaming than by trying to fix it at the browser level. I agree with the clarity and brevity of the article (even if I can’t muster such brevity to save my life). And it’s very rare that this kind of UX is any more onerous to me than closing the tab/leaving the site.

ushakov 4y ago
overflow: hidden
- eyelidlessness 4y ago
  That’s effectively the same behavior as a footer below an infinite scroll. It’s just more obviously stubborn about it.
wtallis 4y ago
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.
- ushakov 4y ago
  observing is great for marketing pages overriding scrolling behaviour or virtual scrolling is a complete no-go eg. this one: https://www.fortnitelookbook.com/en https://www.fortnitelookbook.com/en
  - wtallis 4y ago
    Every scroll-related behavior on that page is entirely gratuitous, and it made my laptop's fan spin up audibly. I'm not sold.
- eyelidlessness 4y ago
  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.
wruza 4y ago
Yeah, discouraging and shaming always works. Many of examples out there.

deleted 4y ago

[deleted]