14 ms·

> 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 book

> 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?
  - hombre_fatal 3y ago
    In your example, the work in progress page traditionally never gets to know that the user logged in until the user refreshes that page. That is exactly the status quo UX that sucks.
    - usrbinbash 3y ago
      > until the user refreshes that page Funny enough, a page-refresh is usually what happens, after I fill in a login form that appears in a modal. But even if it doesn't do that: If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh? And on the off chance that the use case actually requires that, what specific advantage does a modal confer over two input fields (Username, Password), tucked discreetly along a "Login" Button into the navbar?
      - hombre_fatal 3y ago
        Like all UX, the best solution depends on a multivariate consideration which is why you cannot dismiss modals with zero consideration. For example, a username/password in the navbar can make a lot of sense. If it's slightly more complicated than that, like if login has multiple screens (e.g. 2fa token, maybe SSO), then a modal can make sense. On a mobile screen, having username/password in your hamburger slide-out menu isn't automatically superior to extracting it into a modal. > If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh I can think of a lot of examples where this can polish the experience. Once again, I'm brought back to the airline checkout process where you might have almost finished booking a flight but you want to get flight rewards and autofill your contact info at the last step and realize you want to log in. Games are another example -- I've built a modal-based UI for a large casino where there's always a round-based game going on. Guests can watch it. They can login to play. Deposit, FAQ, player profiles, game history, etc. are all cheap interactions that users can view and dismiss while participating in the global game without losing their state. At any moment they can login which enhances most of the pages with additional content. Fwiw, I'm arguing that modal should be a tool in one's UX toolbox, not something you use all the time.
- kwhitefoot 3y ago
  > these sound like issues with poorly done modals. There is no other kind. The whole idea of modal window is stupid. It constrains the user instead of empowering them. Solve the server's problems some other way that doesn't impact the user. These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead. > One key design principle of modals is to make them mentally cheap to open/close/reopen Cheap for whom?
  - hombre_fatal 3y ago
    Modal can enhance UX. I've given examples in my post including an answer to your "Cheaper for whom?" I don't think it's a good argument, you could also just use your own argument against you: Pages are only easy for developers but worse for users since you don't have to polish the UX in the way that a modal lets you. It's for developers that don't want to have to think about UX optimizations and defer everything to out of the box browser experiences. Which, granted, might be the best choice for everyone who doesn't want to think about UX. But I find that to be an empty claim. > These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead. That is often a good choice. However, sometimes a modal makes more sense for an all-or-nothing task, or when the user is already in one of those "expando" forms, or a number of other occasions worth pondering for your app instead of dismissing modals without discretion. Knowing when a modal does and does not make sense is part of a good intuition about UX.
- ricardobeat 3y ago
  > URLs are routed to modals In this current age, this usually means an SPA that will first load the underlying page, then the entire application bundle, start up the JS, detect the route, load the data for the modal over another request, and finally display the modal. In the multiple seconds this is happening, nothing indicates that a modal will be opened. Sounds familiar?
  - hombre_fatal 3y ago
    You can think up poor implementations of everything. It's not a reason to not do something better.
    - ricardobeat 3y ago
      Problem is, this is the standard, not a particularly poor implementation. I don't even know where to find an example that shows UI feedback before the modal is loaded.

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?
- hombre_fatal 3y ago
  In your example, the work in progress page traditionally never gets to know that the user logged in until the user refreshes that page. That is exactly the status quo UX that sucks.
  - usrbinbash 3y ago
    > until the user refreshes that page Funny enough, a page-refresh is usually what happens, after I fill in a login form that appears in a modal. But even if it doesn't do that: If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh? And on the off chance that the use case actually requires that, what specific advantage does a modal confer over two input fields (Username, Password), tucked discreetly along a "Login" Button into the navbar?
    - hombre_fatal 3y ago
      Like all UX, the best solution depends on a multivariate consideration which is why you cannot dismiss modals with zero consideration. For example, a username/password in the navbar can make a lot of sense. If it's slightly more complicated than that, like if login has multiple screens (e.g. 2fa token, maybe SSO), then a modal can make sense. On a mobile screen, having username/password in your hamburger slide-out menu isn't automatically superior to extracting it into a modal. > If the page is reachable without logging in, then what relevant information is there on the page to display to the user that is both so important that it immediately needs to appear on login, and so unimportant that it doesn't justify requiring a refresh I can think of a lot of examples where this can polish the experience. Once again, I'm brought back to the airline checkout process where you might have almost finished booking a flight but you want to get flight rewards and autofill your contact info at the last step and realize you want to log in. Games are another example -- I've built a modal-based UI for a large casino where there's always a round-based game going on. Guests can watch it. They can login to play. Deposit, FAQ, player profiles, game history, etc. are all cheap interactions that users can view and dismiss while participating in the global game without losing their state. At any moment they can login which enhances most of the pages with additional content. Fwiw, I'm arguing that modal should be a tool in one's UX toolbox, not something you use all the time.
kwhitefoot 3y ago
> these sound like issues with poorly done modals. There is no other kind. The whole idea of modal window is stupid. It constrains the user instead of empowering them. Solve the server's problems some other way that doesn't impact the user. These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead. > One key design principle of modals is to make them mentally cheap to open/close/reopen Cheap for whom?
- hombre_fatal 3y ago
  Modal can enhance UX. I've given examples in my post including an answer to your "Cheaper for whom?" I don't think it's a good argument, you could also just use your own argument against you: Pages are only easy for developers but worse for users since you don't have to polish the UX in the way that a modal lets you. It's for developers that don't want to have to think about UX optimizations and defer everything to out of the box browser experiences. Which, granted, might be the best choice for everyone who doesn't want to think about UX. But I find that to be an empty claim. > These days almost everything is a single page application so instead of opening a modal window just expand the button that would have opened the window inline instead. That is often a good choice. However, sometimes a modal makes more sense for an all-or-nothing task, or when the user is already in one of those "expando" forms, or a number of other occasions worth pondering for your app instead of dismissing modals without discretion. Knowing when a modal does and does not make sense is part of a good intuition about UX.
ricardobeat 3y ago
> URLs are routed to modals In this current age, this usually means an SPA that will first load the underlying page, then the entire application bundle, start up the JS, detect the route, load the data for the modal over another request, and finally display the modal. In the multiple seconds this is happening, nothing indicates that a modal will be opened. Sounds familiar?
- hombre_fatal 3y ago
  You can think up poor implementations of everything. It's not a reason to not do something better.
  - ricardobeat 3y ago
    Problem is, this is the standard, not a particularly poor implementation. I don't even know where to find an example that shows UI feedback before the modal is loaded.