Loading a new page, new tab, or simply navigating fully away to a new editing screen are all pretty heavy disorienting actions for something that could be pretty light.
But it's related to the amount of work being done in the modal.
For a very small amount of work (e.g. editing a single text field), inline-editing would be best; for a lot of work (e.g. composing a bunch of textboxes and including other data, etc) a dedicated page is best.
A modal belongs somewhere in-between - editing a few things at once, in context of other things.
"Can this modal be an inline-edit?" <-- first question I'd ask. If the answer is No:
"Will the work being done on the modal take more than 2 minutes to do?" <--- then I'd consider a separate page.
But things in-between seem perfect for a modal.
https://marmelab.com/react-admin-demo/#/reviews
When clicking on a review, the detail appear on the same page. This allows to quickly browse through reviews, and preview some before doing batch edition. It's super effective.
Notice that you can bookmark any review detail, too.
The article should have been called "I dont need a modal window".
That’s not a modal window, though. Modal windows are overlays [0] over the main page, here it’s to the side.
Literally in the example the modal covers 100% of the view state. Most modals cover a big portion of the state.
And I don't see why the modal needs to be limited to quick jobs like inline edits. It could be the place where the bulk of the tasks are done.
Modals done well can remove anxiety and uncertainty from the user.
One example that comes to mind having just bought plane tickets is that the plane ticket flow could be an underlying all-on-one-page UI (flight -> seats -> payment) where each section opens as a form modal on top of that state. You can close modals, open previous sections, edit completed sections, where the modals communicated that you're not losing state by navigating between forms. One of the best UX aspects of the modal is seeing the underlying state behind it and behind able to click out of the modal to return to it.
Meanwhile, when buying tickets 30 min ago, the airline website had a sequence of pages where, I found out, going back to make an edit on a previous page reset the state of the subsequent pages. Obviously they could improve that without modals, but modals communicate state preservation by their nature.
Modals get too much hate just because they can be done poorly. Most UX is done poorly and that's not a reason to wash your hands of it.
but then you can't reference the thread without closing the modal (and likely losing all progress)
This will worsen the UX more often than not. Guaranteed.
All complaints on the page are ultimately grievances against poorly thought-through implementations and as such they are rooted in the wrong thing. It's trivial to complement every modal window with a standalone version, in which case it's possible to bookmark them, middle-click on the links and what have you.
Start with the user experience, craft your implementation around that and all will be fine. Including the modal windows.
The article states very clearly the use cases for which modals make sense:
Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity:
- Alerts
- Confirmation dialogs
- Forms for creating/updating entities
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.
Alerts don't need to stop the world.
Confirmation dialogs block examining the things that you want to confirm.
And forms for creating anything do not need to block access to the rest of the page.
In fact, you can make a link open modal with left click but open in new tab with middle click. I think it is the most balanced way in my opinion.
Modal and tab can co-exist. They are not really mutually exclusive.
BTW, social media websites generally implements this in their feed view. A image behaves different when you click it with middle or left click.
This is yet another instance of optimizing for something that can not be made perfect. Let me decide what I want. Give me the option to do both without much of a hassle. If a decision needs to be made regarding what should happen on a mouse-click, one may choose a sensible default (i.e. what is the most typical use-case), while leaving the option to configure the other choice.
You can always argue that many options are a non-goal, but any sufficiently sophisticated software needs training anyway. Configuration can be a part of that. Nothing is worse than a program in which the designer chose to make your use-case to be painful to be met.
Furthermore, a uri does not need to be bound to a view. In fact, one might prefer different ways to look at the same data.
Voice control software is used most often by people with limited use of their hands, verbal commands replace keyboard and cursor control inputs.
> Standard browser controls are all 100% accessible by default.
Unfortunately, this is not entirely true. For instance, `select` elements and their options don't reflow in most browsers. It is true that the native elements are much more accessible than most alternatives developers create.
If 99.99% of your target audience is not using screen readers, then you need to decide if worsening their experience to accommodate the other 0.01% aligns with your project plans and goals.
In some cases it will, in some it won't. It depends.
Just make a good non-modal view, with whatever transition is needed for continuity to/from the parent view.
As a principle, I don't read any website that has a modal window, especially a modal "subscribe to our newsletter".
Experience shows that this is not the case, provided you keep load times as lowest as possible.
In business apps, this has the additional advantage of allowing users to share information among themselves by simply sharing URLs.
You must use "telemetry" instead of actually talking to your users.
My company requires me to talk to the people who use the web sites I build. (I has a session just yesterday.) They hate modal windows. They even still refer to them as "pop-ups."
There's two words you must learn when talking about UI design - "It Depends".
The one general rule I will state that guides towards using a modal is if the user needs to stay within the context of the originating page and they must return to that page as part of the workflow that launched the modal. But there's also edge cases to this.
source: UXer with 25 years experience in both desktop and webapp.
I mean, there are several people in this thread who like modals as users. I’m another one of those. I find modals very useful, as long as you don’t do them in a crappy way. You shouldn’t insult people just because your experience was different.
I however agree with you, and I don't like the website simply dismissing the idea because it's been over-used and abused all over the place.
Modals have a place in UX.
It is what is wrong with web-designers. They throw away existing browser features, like a scrollbar, and develop their own half-baked replacements, which work differently, they are probably incomplete realisation, and then I'm scratching my head trying to imagine a reason for all this work done by a developer: why to spend additional development time to make my life worse?
It could be a UX improvement, if it was not a modal window but a modeless one: it can help to compare details of different products by placing their windows side-by-side. Or I can right-click on a link and open it in a new window. But a modal window is a nightmare: I can move tabs into a separate browser window easily and to place them side-by-side. It is pain to do it with modal windows. One needs to clone tab and then to open modals.
There's one kind of modality needed for computers, and it's the power switch.
``` history.pushState({}, "", "/new-url"); ```
Moreover, modals serve one very important UI purpose in that they keep the user's mind in a context.
I prefer master-detail views. Like an Email client, where you select a message in a list and then see the body of the email. For smartphone sized screens this should switch to a detail page with a back button. Like the Mail app on iPhone/iPad.
Master-detail can be tough on server side rendered pages though. And you really need a good page structure, because you show a lot of data on one page and it can look cluttered quickly.
> Modal windows can't be bookmarked or shared as links
Why would the user want to bookmark or share a "modal". I believe the author is confusing a modal with a details page (a customer's details page in a CRM for example) on that we can agree that that kind of content is best shown on a separate page. A modal serves a specific function within a web page, be it a website or a web app. Its main function is to allow the user to perform certain tasks within a page, and those tasks will immediately reflect on the underlying page upon submission (or validation/confirmation ..etc). So I fail to understand why the author thinks a user would want to bookmark that modal.
> Modal windows can't be opened in a new tab
Nor should they. Modals, as mentioned above, are one layer above an underlying page, and they either show complimentary information related to an element within that page, or they allow to user to performa task. So they should inherently be accessible within the same tab, not a new one.
> Modal windows make the Back button confusing
Aside from the Close/Abort button inside the modal, a lot of interaction designers and front-end developers are now developing the modals in a way they would close if you press the back button of your browser. No confusion there in my opinion.
> Modal windows are hard to get right[...]if you need to support older browsers, good luck.
Can't find the date this article was published but I assume it's old because almost all new browsers support at least <dialog> element [1]
Modals are a double edged sword, like any UI component or UX pattern really.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
Further reading: https://www.nngroup.com/articles/modal-nonmodal-dialog/
It sounds like you agree with the article, at least according to my reading.
The author states that you should not use a modal for something “bookmarkable”, such as a details page.
They also state that a modal is suitable for performing an action that does not warrant a “resource URL”, such as a “create resource” form.
I think you and the author are making the same argument. I'm sure you've encountered one of those everything-is-a-modal apps and thought "I sure wish I could link to this part of the app but I can't." Then you'd wish you could bookmark the modal.
I use one every day. An example: to edit a user's account information, I go to the accounts interface, open the filters modal dialog and supply the criteria, and them I'm presented with a list of matches. I select one, and it opens the account information in modal dialog. None of those intermediate states are addressable in any way, so it's a real chore to ever access any resource, and I certainly can't share a link with someone else. This is a truly bad experience directly because of its abuse of modal dialogs.
Because the modal contains specific information they want to come back to, or share with others.
> I believe the author is confusing a modal with a details page
The problem against which the author is invecting is precisely the use of modals where details pages would be appropriate.
> Nor should they
How about you stop making decisions for me. I very often want to open settings and other various dialogues in a new tab or as a saved bookmark. This is especially useful in customer support (which is a concept a lot of startups are unfamiliar with, to be fair). You are unaware of every use case, so choose standard browser behavior when possible.
I'm not sure how this justifies your opinion. The fact that "a lot" of people are following a new design paradigm indicates, to me at least, that the pattern is inherently confusing. As a user, do I know what paradigm was used by the design and engineering team? If not, I'm going to be unsure about the effect of clicking "back"
For example, a user may want to edit a few items items in a list Rather than forcing the user to a new page to do each edit, you can pop up a modal and edit in place. With new pages, the user loses the context of the original list. The page swapping is very disruptive.
In this case I'd consider expanding the item on the page when preforming an edit. That way it's clear to the user they're on the same page so won't be tempted to click back and you won't need to worry about confusing keyboard / screen reader users.
Alternatively if you absolutely need to use a modal consider a slide out instead. Slide outs tend to look less like new pages and reduce the likelihood of a user clicking back to "go back" to whatever they were previously looking at. With a slide out the original content is still in view, but now you have some extra options to the side. You still have all the accessibility issues of course, but the UX is slightly better most of the time.
For example, you are running a project review meeting and want to quickly jump between tickets on the kanban board. Your main business context is the entire board (you might have filters/sorting), and you keep a mental record of where interesting tickets are placed on the screen. However, during the group discussion, you need to quickly jump into an individual ticket to reassign it or scan through comments for 5 seconds. In this case, using a modal to show ticket details is preferred to redirecting to a separate 'details' page because it does not scramble the user's context and their mental model about what's on the screen. Of course, the UI still should support cmd+click to open a full page dedicated to that ticket, but that's a 10% use-case.
Also, if you click on something in the modal, you end up getting redirected to a new page anyways, which kind of supports the anti-modal argument.
OTOH, I like Wikipedia's hover previews just fine, so sometimes they're OK.
Lmao, I was making this point at work yesterday. It's really difficult to justify using a modal if you care about accessibility. It's not that it's impossible to do correctly, but even when it's done "correctly" it can still be confusing for users navigating with keyboards / screen readers. So modals are almost always either too much effort to do right, or just not the best approach.
Another thing I'd add to this list is that there are some people who browse without JS enabled. I know it's unpopular to care about those folks these days, but it is another reason to avoid modals where possible.
It’s crazy how much the web platform’s lack of UI expressivity has set us back. Everything is constantly getting desperately reinvented out of a handful of text markup tags cobbled together by scripts, but it doesn’t solve any of the underlying issues.
Also, you're going to have to create modals eventually, alerts are needed in most applications so you might as well create a thorough component.
Avoiding modals because of those who browse with JS disabled doesn't make much sense. Especially when they can temporarily enable on your site, as disabling JS for security reasons would mean they trust your site if they're still using it enough to reach a modal. You can still create fallbacks, but they'll be ugly considering most modals are for nested form changes or alerts.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
I try to give it a best effort, but won’t e.g. rebuild a menu as an HTML checkbox just because some folks are hardliners about running Javascript.
Not before reading your comment I had realized I never missed those extra buttons, or at least remembering missing them.
And I realize that while my implementation takes care of modifiers to open links in new tabs on my web apps, I always overlooked middle button.
The real problem though is that the web is very broken for building apps, and that the DOM API is missing a way to negociate the url changes on default clicked link behavior instead of the current «block event and update url» mechanism.
A few times I’ve encountered sites trying to be clever and detect Ctrl+click or middle-click and use window.open(), but this doesn’t behave natively: natively, middle-click or Ctrl+click probably open in a background tab, but open() opens a foreground tab, which will always be disruptive for people that use this stuff much, and sometimes infuriating.
This isn’t the only reason for having real links; there are also things like status bar text on hover, and context menu on right click or long press, which may include options like Open Link in New Private Window that cannot be emulated in any way.
If you want to intercepting link click events, you must check if the click is modified in some way like this:
if (event.button || event.altKey || event.ctrlKey || event.metaKey || event.shiftKey) return;
It makes me furious
As for <a href="#">, it’s in the same boat, with the sole exception of jumping to the top of the page.
I hit a bug where if I closed the popup (for a ticket on a board) it just reopened! And some ticket links don’t work. All these bugs and complexity for what?
Maybe the browsers should have a built in “open link as popup” for the rare times you want that. And the sites just make it a new page always.
Just pop up a modal and reload the Issue/Bug state when done.
That said the modal load is just as slow.
A modal is not, in itself, an overaly, window, frame, etc. Generally, it really shouldn't even be used as a noun. Modal describes the state of the interface. Most interfaces allow for multiple user interactions originating from the broader interface, i.e., it is multi-modal.
Sometimes, it is necessary to put the UI into a single-purpose state, so, in a single mode. This is required when two interactions can interfere with one another. When one interaction must not be interrupted by another, we must go modal.
The author seems to be chiefly complaining about unnecessary modality and the way that gives rise to clunky UIs that don't allow for things like linking. That's rooted in conflating on-screen, 3D elements like overlay dialog boxes with the concept of one of some interface being modal. An example of this would be an interface with a item list that, on item selection, conjures a modal overlay dialog box with the item details. In the base case, there is no dependency problem here, i.e., it's an entirely acceptable design to allow a user to view the details of two items at the same time, and therefor it doesn't call for a modal detail interface.
What is a modal?
You are confusing it with the much less common but technically accurate meaning in UI. So you are just confused by terminology, and even though it would be better if people stick to unambiguous words, they are talking about something well defined enough that discussing terminology isn't useful.
Run it through user testing and see how your users actually react to new windows being opened all the time. A lot of them are going to be confused, and not be able to make it back to your site. Modals are popular because they work
and at least in my use, the modal is always the better choice there. especially since the advent of <dialog>
https://modalzmodalzmodalz.com/
MODALZMODALZMODALZ.COM
>We use too many damn modals. Let's just not. Help
>The bad news: Modals are the crutch of the inarticulate designer and developer. [...]
https://news.ycombinator.com/item?id=23645447
>bedatadriven on June 25, 2020 | next [–]
>I was just about to share this our designer, who is always talking me down from modals, when I reached the bottom and discovered that our designer is in fact the author.
>I seriously can't say enough for this message. Adrian helped us redesign our app 2 years ago, dispatching many many modals in the process, and delivering a huge increase in usability that our customers and users very much do care about.
Modals are often fine for dialogs and fleeting interactions that happen within the context of the page you are on. Those often don't need their own URL. Don't need to persist after a page refresh, shouldn't be shared, confusingly pollute browser history and benefit from instant loading.
I mostly agree with the author in their examples. If it walks like a page and it talks like a page, it probably should be a page. No need to throw the baby out with the bathwater otherwise.
> Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity:
- Alerts
- Confirmation dialogs
- Forms for creating/updating entities
Compare Safari's Open File to Chrome's Open File. Chrome's Open File modal cannot be moved. Safari's can.
If you have a modal, and it blocks content, you have to be willing to say "I want to prevent my users from seeing this content while dealing with the modal. The content that is being blocked is not important, and it serves NO purpose."
You don't even necessarily need to place it in a new page, probably you can just expand it inline.
Most modals are just lazy.
"Where should I put this piece of UI/information?"
"Just place it above everything else."
With SPAs you don't even have an excuse that "a full-page reload will take longer" because you can change the whole page/layout instantly.
Which opens a whole new can of worms!
What is the meaning of pressing "back" when modal window is shown? Is it "cancel"? What if I already changed something within the modal? What if "back" causes losing some input within the modal? Should we... show another modal for confirmation of going back?
Same with navigation via "back"/"forward" into a modal (which is now present on the history stack) - if this was modal with some action... can I execute it again? Did I just execute it by navigating into it?
If I think about the engineering product I work on and where they do have modals, none of them would work with a separate page. It's things like "Load one or more of your saved graphs (which you can search and filter) into this existing page of graphs"
There is no question that a design gets easier to parse for users when it is serialized by modality. Likewise, serialization is dramatically easier for implementors since it eliminates the need for concurrent execution.
Context matters. Those choices have strong historical reasons for their existence in operating systems and their user interfaces. However, they have little place for being emulated on the web.
Why? Because they give rise to all manner of bad implementation such as the fact that linking structures have not grown at the pace they should have, particularly as it relates to documentation.
All you have to do is look at Amazon's constant proxy to "click here, click there" as a sad excuse for why HCIs don't scale at the same rate as APIs and you can condemn a large portion of the last two decades of design on the internet since these patterns have been copied ad nauseum but only exist because we've employed tools that automated their creation when a link has always been worth a thousand words of "click here, click there".
REST applies to HCIs as much or more than APIs.
It’s the kind of bold, blanket statement that sounds really great and is a fun opinion to hold, but when confronted with reality crumbles (as many statements of that kind do).
Such as the Nielsen Norman Group.
> "Do not use modal dialogs for nonessential information that is not related to the current user flow."
> From https://www.nngroup.com/articles/modal-nonmodal-dialog/
Nonessential information such as, let's say, "details."
I'd say that this minisite is exactly on point.
Small messages that need to be brought to the user's attention and a simple "OK"/"Cancel" button? Yes, this is a good fit. That's what modal windows were originally created for.
You can do the same on a desktop app too, but it is less commonly done. To further avoid confusion, try make sure the pop-up modal appears over the parent window that it is blocking input for (this may mean coding your own window instead of the platform default alert/confirmation box, if the call to open one doesn't allow positioning information to be specified). I've seen alerts/confirmations pop-up on a different screen to the one that the parent window is on which makes missing it much easier (especially if the other screen is away from the main one, perhaps it is being projected at a wall for a demo). To further help: if the user clicks the disabled parent, move the pop-up to where they clicked – usually the title-bar or other chrome on the pop-up flashes in this case, but that isn't helpful if it is on screen 2 and the user is staring intently at screen 1.
Which I thought made sense but I have missed an ok modal before myself let alone seen others as another commenter pointed out. In native apps they also open off screen which is about as broken as you can get.
So, I may go even further than the article and say there are even fewer cases where it is the best way to do a job.
The thing gets implemented and the users like how fast the data is shown. But can we just add some action buttons like Accept and Reject instead of the Ok button? Why close the modal and then hit an action button when you can have them right there?
The buttons get implemented, the users love it. Manager comes back, but can we edit one or two fields? Sure. Some of the fields will open a modal to let users select the value. Should we reimplement it as a regular page so we don't have a modal in another modal? Manager: No, that will take forever. Validation, error messages, scrollbars?
The manager refuses to fix it because he burned through all the allocated time and he doesn't want to have a difficult discussion with the stakeholders. And anyway, in these meetings the developers are not invited and he can just blame the developers because everybody knows how entitled they are.
> Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity:
> Alerts
> Confirmation dialogs
> Forms for creating/updating entities
> Because it looked good in the mockup
Indeed, tools like Figma can create a dangerous illusion of simplicity. I wonder how much time and effort has been wasted during the actual software development process, despite the initial, marginal savings in mockup design.
One must also take in account that the hourly rates for developers are typically higher than those of UI designers, so that it doesn't make much sense to increase productivity of the latter at the expense of the former.
I have lots of frustration with modal views that: 1. block me from seeing the things that I probably need to enter into the view 2. disappear when you accidentally click outside them 3. don't scroll properly 4. don't allow scrolling of the page behind 5. don't play well with reasonable browser extensions (uBlock, but other things as well like Disconnect) or even the tracking prevention build into browsers. 6. store data in a weird place so that a second window of the same site in a different location opens the same (now incorrect) data in the modal.
These things are becoming super common in line-of-business apps, where they interrupt workflow. Better options:
1. New page, as recommended by this link 2. Expanding a region of interest to allow the form to fit 3. Making the page more interactive in other ways so that a modal doesn't seem like the best way to do the interaction
Once you get how it works it’s neat.
SPA page loads can get really slow, which can frustrate or disorient users. Having too many page loads to sequentially drill down your info architecture can get really annoying for users. If your pages are 1 or 2 layers deep in your architecture, and the rest is shown in some way within the page (again, modals are one way to do it), as a piece of "fleeting information", your users will appreciate it.
The location changes are virtual through the history API, with a reload just causing the SPA to start from that location instead of from the root/home view.
AWS Management Console begs to differ:)
Alerts
Confirmation dialogs
Forms for creating/updating entitiesIt's sadly reasonable not to expect users to trust, or even try, the back button.
I refuse to read anything that is said after the example being useless.
Linking to a separate page is like GOTO control flow. You leave it up to the user to figure out where to go from there, but the user usually doesn’t know the full sequence of steps that are part of a task. It’s your responsibility to guide them.
2. once again, there is a failure here to recognize which use cases are best served by a website (i.e., a set of web pages that use native browser navigation) or by a single-page application (which takes native UI paradigms such as multiple windows and modals and implements them using web technologies)
3. blanket criticism for single-page applications often comes from people who have no real understanding of web development and harbor nostalgia for the "good old days" when browsers acted only as display devices for server-generated HTML strings; those people aren't worth arguing with, I don't have time for them, I'd rather spend my time improving web technologies so that more people can implement applications that feel "native" yet work across different architectures, devices, screen sizes, languages, and writing directions, built on top of a platform that is privacy-centric by default, and not controlled by a single company
/MyResource/123 (all operations happen here as various "Modes")
vs
/MyResource/123/View
/MyResource/123/Export
/MyResource/123/EditPropertyA
/MyResource/123/EditPropertyB
/MyResource/123/Delete
etc...
One other benefit to using full routable pages for your various views is that you can subdivide the work a lot more easily. Assuming you have some common layout/style system (which you absolutely should), you can realistically part out the dev work at the grain of a URL at a time. We still have a few modals, but they are all of the "confirm scary operation XYZ" variety.
Modals can definitely be bookmarkable if they are dependent on a certain path or query param to appear.
> Modal windows can be used for views that don't constitute a "resource" or correspond to a domain entity: > [...] > Forms for creating/updating entities
Wow, in my opinion this a perfect example where a separate page IS still superior to a modal: how much better a "create issue" jira PAGE is vs the modal?
You can also take a hybrid approach: many calendar apps have a small popup for adding an event that the user can expand into a whole (nonmodal) window for editing all the details.
We use modal windows specifically for this reason (for our payment application's checkout page).
Also using a modal significantly improves the checkout experience in case of SDK flows for payment methods like Klarna, Google pay etc.
Personally I feel modal windows are better aligned to the user's flow of attention. We also have redirection flows for these payment methods to open the authentication page in a new tab but we pick the modal flow ever single time for a better experience.
You can get a feel of what I'm talking about over here: https://demo-hyperswitch.netlify.app/checkout
Another reason might be to avoid losing state on the underlying page.
If you have a "SPA" style app, it might obviate both of these reasons. In an SPA app (ideally one with good URL and back button behavior of course) the difference between a modal window and a separate page perhaps becomes _only_ one of UX, which presentation is better?
But in a more traditional server-side-rendered app with minimal UI-focused JS, other considerations still exist which are legitimate, it seems to me.
Those are rare. So much easier to mess up than to match native browser UX.
That may sound like gibberish if you're not familiar with Phoenix LiveView, but it all makes sense and it just works.
Just make it so that you can copy-paste the URL and you will see the same page with the same modal openen.
Why is there a completely untested assumption that everything should be linkable?
You don't need most of the cruft that clutters "modern" webpages. While not solely responsible, ever more "clever design" has certainly contributed to the status quo, where we load upwards 30MB of garbage to display <10 lines of information.
Modals have their use and function. Don't overdo it and maybe even provide non-modal options in addition to the modal.
I really don't get it. We're doing mostly SPAs, so any back-button would be as fast as closing the modal.
Sprinting along delightfully, getting everything right, every piston firing... then falls on face at the last hurdle.
No, don't put forms in modals, gah!