5 ms·

Phoenix is awesome. Modals are a UX anti-pattern that should be avoided. https://youdontneedamodalwindow.dev/ https://youdontneedamodalwindow.dev/

norman784 3y ago
I would say it depends on the kind of app you are building.
- nelsonic 3y ago
  Yes, "it depends". If you're building something internal and Desktop-only then maybe a Modal can be OK. But for a mobile-first app, you will never be able to test it on all the devices people use so consistent UI/UX is impossible. If you have ever done any "in the wild" usability testing with older people with older devices (think iPhone 8 form factor) Modals often break the UX. Seen it happen many times, it's super frustrating to the person trying to use it. :-(
scythmic_waves 3y ago
Your link says at the bottom that modals can be used for forms.
- going_north 3y ago
  I don't think modals are very usable for forms, especially if the form is big – it risks somebody spending a lot of time filling out the form and then closing the modal by accident. I would much prefer a `/resource/[new|edit]`
deleted 3y ago
[deleted]
arcanemachiner 3y ago
You may be aware of this already, but the current LiveView generators address many of these concerns by serving the same LiveView template for multiple routes, but the assigns will be different based on which route is accessed. So, for the :index route, the modal will not be visible, but it will be visible for the :new route. Plus, with live patching, you preserve back button functionality (and it even preserves the page state as a bonus). So that addresses the back button problem. But the problem still exists where clicking outside the modal (or pressing the back button) will destroy the form and any unmodified content, which is super annoying. This can be addressed by listening for changes to the form's input fields and showing a warning when any navigation event occurs when the form is changed-but-not-submitted (easier said than done, but ). I'm not even disagreeing with your point, really. It's just worth mentioning that 1) many of the problems described have an out-of-the-box solution when using the current LiveView generators, and 2) refinements can be made to address some of the remaining issues.

norman784 3y ago

I would say it depends on the kind of app you are building.

nelsonic 3y ago
Yes, "it depends". If you're building something internal and Desktop-only then maybe a Modal can be OK. But for a mobile-first app, you will never be able to test it on all the devices people use so consistent UI/UX is impossible. If you have ever done any "in the wild" usability testing with older people with older devices (think iPhone 8 form factor) Modals often break the UX. Seen it happen many times, it's super frustrating to the person trying to use it. :-(

scythmic_waves 3y ago

Your link says at the bottom that modals can be used for forms.

going_north 3y ago
I don't think modals are very usable for forms, especially if the form is big – it risks somebody spending a lot of time filling out the form and then closing the modal by accident. I would much prefer a `/resource/[new|edit]`

deleted 3y ago

[deleted]

arcanemachiner 3y ago

You may be aware of this already, but the current LiveView generators address many of these concerns by serving the same LiveView template for multiple routes, but the assigns will be different based on which route is accessed. So, for the :index route, the modal will not be visible, but it will be visible for the :new route. Plus, with live patching, you preserve back button functionality (and it even preserves the page state as a bonus). So that addresses the back button problem. But the problem still exists where clicking outside the modal (or pressing the back button) will destroy the form and any unmodified content, which is super annoying. This can be addressed by listening for changes to the form's input fields and showing a warning when any navigation event occurs when the form is changed-but-not-submitted (easier said than done, but ). I'm not even disagreeing with your point, really. It's just worth mentioning that 1) many of the problems described have an out-of-the-box solution when using the current LiveView generators, and 2) refinements can be made to address some of the remaining issues.