71–80 of 129 posts
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.
We're just sitting there saying, even from a non-code point of view, this shit makes zero sense.
Ignored as usual.
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.
Do not use infinite scrolling. Much simpler, much better.
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.
Earlier quoted context omitted.
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…
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 sure what still needs to be lazily loaded via scripts watching scroll behavior.
Removing elements after you scroll past them sounds like the kind of optimization only necessary on infinite scroll pages, unless the page in question has a multitude of auto-playing videos.
Restoring scroll position between interactions: I'm not sure what kind of interactions make this necessary, so an example would help.
Scroll-snap: The examples on MDN don't even behave properly.
Offsetting jump in-page anchor/jump links: Stop obscuring 20+ % of the vertical space with "position:fixed" dickbars. Then you have a much smaller problem which I'm not sure requires JS scrollhacking to solve.
I'm not sure scroll hijacking is completely bad, but it's overwhelmingly more bad than good. Breaking fundamental interaction mechanisms should only be done where it's absolutely necessary, or in a context where all the normal expectations for interaction can be abandoned. These capabilities go beyond merely "ripe for abuse" and are perhaps better described as UX footguns that are mysteriously attractive to web designers.
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.
Ideally, there is a QA pass on staging, involving the designer, in which more than "does this feature work as written in the ticket" is the question you try to answer before releasing the feature. Many teams don't do this, and the blame for that lies with different people in different organizations I've worked in.
But developers often sneeringly deride designers for not catching things like this — "you had one job, lol" — but the sad truth is that there's no testing suite to help designers catch stupid mistakes. Speaking practically, the unit tester for a design is often the developer who tries to build it. Imagine what your interpreter or compiler or testing framework would say about your intelligence if it could talk!
Earlier quoted context omitted.
It’s not a hard problem to notice or fix, probably just comes from people not using their site a lot. All you need to do is insert your content in a fib before a final “filler” div that has the same height as the floating footer. If your floating footer doesn’t have a fixed height (and there is some really good reason for that) a further hack is to measure it and then set the height of the filler div in js.
or just display the scrollable content in a container with overflow: scroll you can then make the container fill the height/width with flexbox
Earlier quoted context omitted.
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.
To add to this, I absolutely believe it is the developer's role to interrogate a design (and its implementation) and feedback where appropriate.
Earlier quoted context omitted.
or just display the scrollable content in a container with overflow: scroll you can then make the container fill the height/width with flexbox
Also works well, but that might introduce janky behavior with iOS safari’s title bar and tapping the top to scroll to top in my experience. I don’t know if this has been fixed, it’s been a while since I wore a CSS hat, but I vaguely remember fighting with mobile safari and overflow divs a lot.
in that case you can just add position: sticky and bottom: 0 to the footer
with this trick you get the same behavior as with position: fixed but won’t need a wrapper div as in the comment i replied to
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.
For many I suspect it really isn’t their job to decide otherwise if someone wants a horrible footer…