7 ms·

> As soon as something is a resource, that is, an article to read, a picture to watch, a diagram to open, a sound to play, in short anything for which it makes

> As soon as something is a resource, that is, an article to read, a picture to watch, a diagram to open, a sound to play, in short anything for which it makes sense that it should be reachable via an URI, a modal is the wrong choice. These feel incredibly unrelated to me. Why does that matter at all for the display choice? A modal is getting used because it's a view into another section of the application that doesn't lose the current location of the user. Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. It's just not important to most people what the string of characters is. So... Anywhere you've got multiple steps to complete, or an adjacent resource that might be related and viewed/edited in the context of the parent resource. Or a form is being filled in and a user wants to enable extras, which requires filling in a different form, etc... The modal is about not losing the current place for the user. Because most current users don't use multiple tabs/windows for the same product, and they don't pay any attention to the urls. "Dont open a modal" in cases where the user is likely going to get lost in a detour otherwise is bad advice.

scbrg 3y ago
> Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. It's just not important to most people what the string of characters is. This is not correct. Normal users have learned that if they copy that URL thingie, and send it to someone else, that someone else will see the same thing they see now. I don't know how many times I've received a link from someone saying "lol look at this hilarious dog" and ended up on some useless overview page completely devoid of hilarious dogs. Because some fucking designer decided to do exactly what TFA is complaining about.
- mock-possum 3y ago
  Fair, but there’s no reason a URL can’t resolve to a landing page and already open modal state populated with the content the other person shared to you. Deeplinking / permalinking works just as well with modals as it does with anchor named content blocks below the fold.
  - usrbinbash 3y ago
    > ut there’s no reason a URL can’t resolve to a landing page and already open modal state populated with the content the other person shared to you. I can think of 2 very good reasons right away: 1. It increases the complexity of the webpage 2. It makes it impossible to simply download or integrate the resource elsewhere
  - zelphirkalt 3y ago
    Sure, if you want to put in the effort to make it work. Most however don't and then their websites suck in that regard.
  - avisser 3y ago
    Permalinking has worked since Netscape 1.0 w/o any code from the developer. Why fight the system?
  - Brian_K_White 3y ago
    So, something can intrinsically work by default, or it can possibly work only when and if you go out of your way to make it work. Two totally equal choices!
    - horsawlarway 3y ago
      > Two totally equal choices! No, because in the one that intrinsically works, you're losing the user's context by navigating them away. Which is what the modal is good for. Whether that's worth it is a discussion, but at least this part of it is trivially easy to implement.
      - usrbinbash 3y ago
        > you're losing the user's context We're talking about BOOKMARKS, so what context do we lose? The users browsers home screen?
usrbinbash 3y ago
> Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. Tell that to my non-techy spouse and her +1400 bookmarks. You know what her most recent rant was about? That she cannot bookmark certain timetables at a booking platform she uses. Why? Because guess what: The timetable shows in a modal. > The modal is about not losing the current place for the user. Resources opening in tabs also don't lose the place of the user. But you know what modals do usually lose the user? The ability to interact with anything but the model while it's open. A usual gem is a form which opens a modal, where I would then really really like to copypaste some info I already entered in another part of the form, but can't, because the effing modal is in the way. So I have to close it, and that usually wipes all the info in it. > "Dont open a modal" in cases where the user is likely going to get lost in a detour otherwise is bad advice. If a web design can cause the user to get lost in the first place, then the problem isn't that there is no modal, and adding one will likely not fix it.
- hombre_fatal 3y ago
  Once again, these sound like issues with poorly done modals. I've made multiple websites where URLs are routed to modals because the app made most sense as pages on top of an underlying state. GET /things/42/edit loads thing#42 in the background and opens the edit modal prefilled with thing#42's info. A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task. Preserving form data during navigation is something you have to consider for any form, even forms on the same page or separate pages where you don't want the form to clear when the user navigates away. One key design principle of modals is to make them mentally cheap to open/close/reopen, and modal state preservation is usually a part of that.
  - usrbinbash 3y ago
    > A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task. That cherry on top can be just as easily implemented by opening the /login in a new tab. Auth gets set, there, user is logged in even in the old tab, and doesn't lose his position in the page either. Added cherry on top of that: If the user decides to log into the page halfway through the application, he can still bookmark the login page. The same is true for almost every other use case of a modal where it displays a resource. Tabs are builtin capabilities of the browser. Even terminal browsers like w3m support tabs. Why built something else that can be built poorly, instead of using what the browser already can do?

scbrg 3y ago

> Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. It's just not important to most people what the string of characters is. This is not correct. Normal users have learned that if they copy that URL thingie, and send it to someone else, that someone else will see the same thing they see now. I don't know how many times I've received a link from someone saying "lol look at this hilarious dog" and ended up on some useless overview page completely devoid of hilarious dogs. Because some fucking designer decided to do exactly what TFA is complaining about.

mock-possum 3y ago
Fair, but there’s no reason a URL can’t resolve to a landing page and already open modal state populated with the content the other person shared to you. Deeplinking / permalinking works just as well with modals as it does with anchor named content blocks below the fold.
- usrbinbash 3y ago
  > ut there’s no reason a URL can’t resolve to a landing page and already open modal state populated with the content the other person shared to you. I can think of 2 very good reasons right away: 1. It increases the complexity of the webpage 2. It makes it impossible to simply download or integrate the resource elsewhere
- zelphirkalt 3y ago
  Sure, if you want to put in the effort to make it work. Most however don't and then their websites suck in that regard.
- avisser 3y ago
  Permalinking has worked since Netscape 1.0 w/o any code from the developer. Why fight the system?
- Brian_K_White 3y ago
  So, something can intrinsically work by default, or it can possibly work only when and if you go out of your way to make it work. Two totally equal choices!
  - horsawlarway 3y ago
    > Two totally equal choices! No, because in the one that intrinsically works, you're losing the user's context by navigating them away. Which is what the modal is good for. Whether that's worth it is a discussion, but at least this part of it is trivially easy to implement.
    - usrbinbash 3y ago
      > you're losing the user's context We're talking about BOOKMARKS, so what context do we lose? The users browsers home screen?

usrbinbash 3y ago

> Further - users (and I mean normal paying users, not HN commentators) rarely ever give a shit about URLs. Tell that to my non-techy spouse and her +1400 bookmarks. You know what her most recent rant was about? That she cannot bookmark certain timetables at a booking platform she uses. Why? Because guess what: The timetable shows in a modal. > The modal is about not losing the current place for the user. Resources opening in tabs also don't lose the place of the user. But you know what modals do usually lose the user? The ability to interact with anything but the model while it's open. A usual gem is a form which opens a modal, where I would then really really like to copypaste some info I already entered in another part of the form, but can't, because the effing modal is in the way. So I have to close it, and that usually wipes all the info in it. > "Dont open a modal" in cases where the user is likely going to get lost in a detour otherwise is bad advice. If a web design can cause the user to get lost in the first place, then the problem isn't that there is no modal, and adding one will likely not fix it.

hombre_fatal 3y ago
Once again, these sound like issues with poorly done modals. I've made multiple websites where URLs are routed to modals because the app made most sense as pages on top of an underlying state. GET /things/42/edit loads thing#42 in the background and opens the edit modal prefilled with thing#42's info. A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task. Preserving form data during navigation is something you have to consider for any form, even forms on the same page or separate pages where you don't want the form to clear when the user navigates away. One key design principle of modals is to make them mentally cheap to open/close/reopen, and modal state preservation is usually a part of that.
- usrbinbash 3y ago
  > A more obvious example is /login and /register in a modal, a cherry on top if logging in or registering doesn't reset app state if the user decides to register halfway through a task. That cherry on top can be just as easily implemented by opening the /login in a new tab. Auth gets set, there, user is logged in even in the old tab, and doesn't lose his position in the page either. Added cherry on top of that: If the user decides to log into the page halfway through the application, he can still bookmark the login page. The same is true for almost every other use case of a modal where it displays a resource. Tabs are builtin capabilities of the browser. Even terminal browsers like w3m support tabs. Why built something else that can be built poorly, instead of using what the browser already can do?