4 ms·

While I like this approach as well, these URLs ending up in the browser history isn’t ideal. Autocomplete when just trying to go to the site causes some undesir

While I like this approach as well, these URLs ending up in the browser history isn’t ideal. Autocomplete when just trying to go to the site causes some undesired state every now and then. Maybe query params offer an advantage over paths here.

linked_list 11mo ago
JS does have features for editing the history, but it's a trade-off of not polluting the history too much while still letting the user navigate back and forth
- orphea 11mo ago
  I'm glad to see that prismjs site mentioned by the blog is doing the right thing - when it updates the URL, it replaces the current history item.
  - embedding-shape 11mo ago
    Does that handle back button correctly? Nothing more annoying that sites/apps that overwrites the history incorrectly, so when you press the back button it goes to the entry before you entered the website/app, rather than back into what you were doing in the website/app. Both approaches (appending/rewriting) have their uses, the tricky part is using the right thing for the right action, fuck up either and the experience is abysmal.
    - LegionMammal978 11mo ago
      It's pretty weird, my impression is that the APIs are flexible enough to implement most sane behaviors, but websites keep managing to mess it all up. Perhaps it's just one of those things that no one bothers re-testing as the codebase changes.
      - embedding-shape 11mo ago
        In my experience, the problem is two-fold. First product managers/owners don't consider the URIs, so it ends up not being specified. They say "We should have a page when user clicks X, and then on that page, user can open up modal Y", but none of it is specified in terms of what happens with the URIs and history. Then a developer gets the task to create this, and they too don't push back on what exact URIs are being used, nor how the history is being treated. Either they don't have time, don't have the power to send back tasks to product, simply don't care or just don't think of it. They happily carry along creating whatever URIs make sense to them. No one is responsible for URLs, no one considers that part of UX and design, so no one ends up thinking about it, people implement things as they feel is right, without having a full overview over how things are supposed to fit together. Anyways, that's just based on my experience, I'm sure there are other holes in the process that also exacerbates the issue.
        nkrisc 11mo ago
        As a UX designer, this is a failure of the UX designers, IMO. If you're a UX designer for web, you should be aware of web technology and be thinking about these things. Even if you don't know enough to fully specify it, you should be able to enough such that you can have conversations with a developer to work together to fully spec it out. That said, I've also worked with some developers that didn't like intruding on their turf, so to speak. Though I've also worked with others that were more than happy to collaborate and very proactive about these sorts of things. Furthermore, as a UX designer this is the sort of topic that we're unlikely to be able to meaningfully discuss with PMs and other stakeholders as it's completely non-visual and often trying to bring this up with them and discuss it ends up feeling like pulling teeth and them wondering why we're even spending time on it. So usually it just ended up being a discussion between me and the developers with no PM oversight.
        _heimdall 11mo ago
        Web developers should make it a habit to ask/require URL structures be part of the spec. I've had people be surprised by the request because its something they don't usually consider, but I've never had anyone actually push back on it.
    - macNchz 11mo ago
      It’s definitely possible to make a really stellar experience, but that winds up being the exception. The URL and history state are sort of “invisible” elements of the user experience but require thoughtful care and attention to what the user expects/wants at each step, a level of attention which is already a rarity in web development even in the most visible parts of a page…so frequently the history/back button stuff just totally sucks.
      - embedding-shape 11mo ago
        Yeah, in my experience you only get great stuff when both product and engineering has equal care for the final experience. If either parties lack care, you'll miss stuff, particularly things that are "invisible" as you say.
DrewADesign 11mo ago
I think it’s a “use the right tool for the job” thing. Putting ephemeral information like session info in URLs sucks and should only be done if you need to pass it in a get request from a non-browser program or something, and even then I think you should redirect or rewrite the url or something after the initial request. But I think actual navigational data or some sort of state if it’s in the middle of an important action is acceptable. But if you really just want your users to be able to hit refresh and not have their state change for non-navigational stuff like field contents or whatever, unless you have a really clear use case where you need to maintain state while switching devices and don’t want to do in server-side, local storage seems like the idiomatic choice.
hamdingers 11mo ago
Browser autocomplete behavior is reliably incorrect and infuriating either way, so it's not a good reason to avoid the utility of having bookmarkable/sharable urls.
- SoftTalker 11mo ago
  Yeah it's an annoyance more than it helps. I always disable it.
  - noir_lord 11mo ago
    I do as well - it's just irritating. Same with search ahead.
Dwedit 11mo ago
My personal take would be if it takes you to what's basically another page (such as the entire page being rewritten), then involve browser history.
porridgeraisin 11mo ago
Yeah, lichess does this. On lichess.org/analysis, each move you make adds a history item, lichess.org/analysis#1, #2, and so on. Pretty annoying.

linked_list 11mo ago

JS does have features for editing the history, but it's a trade-off of not polluting the history too much while still letting the user navigate back and forth

orphea 11mo ago
I'm glad to see that prismjs site mentioned by the blog is doing the right thing - when it updates the URL, it replaces the current history item.
- embedding-shape 11mo ago
  Does that handle back button correctly? Nothing more annoying that sites/apps that overwrites the history incorrectly, so when you press the back button it goes to the entry before you entered the website/app, rather than back into what you were doing in the website/app. Both approaches (appending/rewriting) have their uses, the tricky part is using the right thing for the right action, fuck up either and the experience is abysmal.
  - LegionMammal978 11mo ago
    It's pretty weird, my impression is that the APIs are flexible enough to implement most sane behaviors, but websites keep managing to mess it all up. Perhaps it's just one of those things that no one bothers re-testing as the codebase changes.
    - embedding-shape 11mo ago
      In my experience, the problem is two-fold. First product managers/owners don't consider the URIs, so it ends up not being specified. They say "We should have a page when user clicks X, and then on that page, user can open up modal Y", but none of it is specified in terms of what happens with the URIs and history. Then a developer gets the task to create this, and they too don't push back on what exact URIs are being used, nor how the history is being treated. Either they don't have time, don't have the power to send back tasks to product, simply don't care or just don't think of it. They happily carry along creating whatever URIs make sense to them. No one is responsible for URLs, no one considers that part of UX and design, so no one ends up thinking about it, people implement things as they feel is right, without having a full overview over how things are supposed to fit together. Anyways, that's just based on my experience, I'm sure there are other holes in the process that also exacerbates the issue.
      - nkrisc 11mo ago
        As a UX designer, this is a failure of the UX designers, IMO. If you're a UX designer for web, you should be aware of web technology and be thinking about these things. Even if you don't know enough to fully specify it, you should be able to enough such that you can have conversations with a developer to work together to fully spec it out. That said, I've also worked with some developers that didn't like intruding on their turf, so to speak. Though I've also worked with others that were more than happy to collaborate and very proactive about these sorts of things. Furthermore, as a UX designer this is the sort of topic that we're unlikely to be able to meaningfully discuss with PMs and other stakeholders as it's completely non-visual and often trying to bring this up with them and discuss it ends up feeling like pulling teeth and them wondering why we're even spending time on it. So usually it just ended up being a discussion between me and the developers with no PM oversight.
      - _heimdall 11mo ago
        Web developers should make it a habit to ask/require URL structures be part of the spec. I've had people be surprised by the request because its something they don't usually consider, but I've never had anyone actually push back on it.
  - macNchz 11mo ago
    It’s definitely possible to make a really stellar experience, but that winds up being the exception. The URL and history state are sort of “invisible” elements of the user experience but require thoughtful care and attention to what the user expects/wants at each step, a level of attention which is already a rarity in web development even in the most visible parts of a page…so frequently the history/back button stuff just totally sucks.
    - embedding-shape 11mo ago
      Yeah, in my experience you only get great stuff when both product and engineering has equal care for the final experience. If either parties lack care, you'll miss stuff, particularly things that are "invisible" as you say.

DrewADesign 11mo ago

I think it’s a “use the right tool for the job” thing. Putting ephemeral information like session info in URLs sucks and should only be done if you need to pass it in a get request from a non-browser program or something, and even then I think you should redirect or rewrite the url or something after the initial request. But I think actual navigational data or some sort of state if it’s in the middle of an important action is acceptable. But if you really just want your users to be able to hit refresh and not have their state change for non-navigational stuff like field contents or whatever, unless you have a really clear use case where you need to maintain state while switching devices and don’t want to do in server-side, local storage seems like the idiomatic choice.

hamdingers 11mo ago

Browser autocomplete behavior is reliably incorrect and infuriating either way, so it's not a good reason to avoid the utility of having bookmarkable/sharable urls.

SoftTalker 11mo ago
Yeah it's an annoyance more than it helps. I always disable it.
- noir_lord 11mo ago
  I do as well - it's just irritating. Same with search ahead.

Dwedit 11mo ago

My personal take would be if it takes you to what's basically another page (such as the entire page being rewritten), then involve browser history.

porridgeraisin 11mo ago

Yeah, lichess does this. On lichess.org/analysis, each move you make adds a history item, lichess.org/analysis#1, #2, and so on. Pretty annoying.