But SPAs don't need to, they chose to. The history API is fine and can be used to have SPAs and their navigators work with the browser and user, instead of against it. But a lot of developers broke it because they ignored bookmarkability and navigation and the like because they didn't care.
A good SPA works just like a regular website and other than it being fast and responsive, you shouldn't even notice it is one. But alas.
This didn't come through pwas. We've had ajax for ages before they became a thing and mpa also had opaque state for modals/detail views etc.
Blaming SPAs for such things is like blaming the ocean for a hurricane... Sure, you'd have less hurricanes without the ocean, but it's ultimately not the reason for them
if done properly, this allows the url to represent where you are in the app, and makes back/forward work - like in typical web pages, just without a reload.
Most often though, I see it done inconsistently, and it's a painful mess
You know what I don't like? Having to hit the back button far too many times while I was interacting with an element on the page. It makes sense that I should be able to bookmark or send a particular state but I much prefer if the URL is changed in-place (without creating a navigation step) to achieve this.
there are very easy ways to make SPAs which don't fuck with URLs (since, I don't know, ten years?). People who don't care about the web fundamentals/urls/back button/scroll UX/etc have broken the web, not SPAs
I have a single SPA deployed in my life. About 5-6 years ago. I did nothing to preserve the history, it was just working back then. Imagine how more polished are things now. I am thinking that people who are breaking the history should take special steps to do so, otherwise it will just work out of the box with most frameworks/libs.
While we're at it, my hatred for the < > symbols on rows of things on previously explicitly only scroll up/down pages is just as intense today as when I first experienced it.
Streaming media platforms are probably the most notorious offenders in this space, but are definitely not alone.
Nah, I hate that. Frequently it gets in my way when I have my screen split with two browsers side by side. I'll try to hover over the scrollbar on the right hand side of the left page, try to click, and end up clicking the right window. Give me the whole damn scrollbar please.
I usually hide them. I try to not use overflowing content, but when it has to overflow I hide the scrollbar because scrollbars disrupt the design and the standard ones are extremely ugly.
How can you make an assertion like "they are extremely ugly" when they're different or absent entirely depending on device and browser? Don't make decisions for your users, this breaks expectations and accessibility.
I dont want users that need handholding anyway. I want my app to look good. Almost all scrollbars on all of my devices and browsers look ugly. Users that need handholding usually also are the more problematic users.
So if i am building my own house i should also spend thousands of dollars more to make it accessible? If my house isnt accessible do i also spit disabled people in the face?
> you're essentially telling users: "We know better than you." That arrogance doesn't go unnoticed. Respect your users' autonomy
IMHO, that assessment and corresponding answer applies perfectly not only to Momentum scrolling but also to most of the current trends in UX design. I wonder how we got into this worship of aesthetics to the detriment of everything else.
Yeah, that part reminds me of the flatteringly named "Call to Action" buttons. There was a nice blog article named something like "Button presses You" which i can't seem to find. Essentially, it goes on the trajectory of the purpose of any application telling you what and how to do instead of you, the user, deciding what the programm should do.
Only a few applications behave like that because of defective coding hamster browser is a good scroller .Tilt scrolls are available in iPad and this helps old people like me to scroll quickly read me there is an automatic scroll also which is very good
Ctrl+F hijacking, even if it provides a useful app search feature is something I despise. Browsers should have an alternate Shift+Ctrl+F or something that can be used in those cases. I just discovered Shift+Cmd+F that does something on Firefox.
The best part is that the "Back to the normal version" link is only clickable if you smooth-scroll all the way back to the top. You really got me with that.
My most annoying scroll-experience is Grafana, too easy for people to make dashboards with a bunch of scrollbars and I always fail pick the correct one to scroll down.
I'm fine if sites make creative choices for things, if they are a creative site. Homestar runner would be a classic example of this done extremely well. The time he "broke out" of the frame was amazing.
But, if you are making something with plenty of precedent, please follow it. There is a reason we wind up with mandated nutrition labels and such. It is good to be similar to things. Especially if you are, in fact, similar
I really don't face this issue ever, but I tried the demo page and the experience is garbage.
I use vimium to navigate on the web and made scrolling through that website unusable.
Just don't
If you try hard enough, it's possible to fuck with almost any aspect of normal web UI. Trying to prevent existing ways of doing it will lead to worse ways being used by people who think they know better.
Yeah. Don't fuck with scroll, don't fuck with crtl/cmd-click, don't fuck with copy/paste (specially in password fields), don't fuck with the back button, etc.
I'm a bit confused. Smartphone operating systems do momentum scroll since the first iOS. Everywhere, not just in the browser. Is this website specifically talking about websites which try to emulate Android & iOS inertia scrolling on desktop browsers? (I guess momentum scrolling doesn't work well with mouse wheels, where the mouse wheel doesn't have inertia.)
They are talking about adding that kind of scrolling using JS as demonstrated in the alternate version of the page that they link to. I don't understand why anyone would think it's needed though when scrolling already works like that at the OS or browser level. Doing it in JS just doubles up on the effect, leading to a very strange feel.
At least on my iPad here, when the screen is scrolling, and you touch the screen, it stops. On the demo page, it doesn’t. Who would want that, or think that was better? If I encountered that, I’d go away from that website and never go back.
reply