3 ms·

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

> 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.
    - GoblinSlayer 3y ago
      You can polish authentication by not requiring it every day, not with a modal.

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.
  - GoblinSlayer 3y ago
    You can polish authentication by not requiring it every day, not with a modal.