To start with, I’m not a huge fan of modal windows in a web application. InVision used a ton of modal windows; and it felt like we painted ourselves into a corner that we couldn’t get out of. My ambiguity on the matter has only been hardened by articles such as “we use too many damn modals“, “modalz modalz modalz“, and “who’s afraid of a hard page load“. That said, modals—and modal-adjacent experiences—do have their place. And, as I start to think about this experience in the context of an HTMX-powered web app, I wanted to come up with a set of functional requirements that I could aim for.
I’m not saying that all of these requirements have to be met. Only that these could be met in a perfect world. And, if I have to trade one requirement off for another, I want to be able to do so in a cognizant way, acknowledging that I’m making a sacrifice (on behalf of the user’s experience).
Functional Requirements of a Modal Window
-
Perhaps the single most important requirement is that the user’s Back Button has to work. Back button functionality is truly the hill that I’m willing to die on. Nothing frustrates a user more than hitting the back button and being whisked away to a completely unexpected location.
-
Except for truly transient dialogs, such as prompts, confirmations, and error messages, a modal window should be deep linkable. That is, the URL should reflect that the modal window is open in the same way that the URL should reflect any area of an application that the user can navigate to.
-
Refreshing the browser page should bring the user back to the same page and modal window. If the modal window is deep linkable, this will naturally happen.
-
If a link triggered the modal window, the user should be able to right-click or CMD+Click on said link to open the page-and-modal in a new browser tab. If the modal window is deep linkable, this will naturally happen.
-
Once the modal window is open, hitting the Escape key should close the modal window, return the user back to the previous URL (ie, the originating page URL less the URL-based modal indicator).
-
One modal window should be able to link to another modal window. For example, a “paywall modal” should be able to link across to an “upgrade subscription” modal.
-
When a modal window is open, the primary page scrolling should probably be deactivated. And, while the content of a modal should aim to fit entirely within the viewport, if it does need to scroll vertically, double-scrollbars should be avoided.
Gripe: this is especially hard for Mac-based developers who think that the world lives in a magic mouse, hidden scrollbar world. It doesn’t – the rest of the world sees scrollbars basically all the time.
-
The content of the modal window should be able to change the URL as needed without destroying the underlying page. For example, a modal window with a search input may need to push a
keywordsvalue into the URL as the user types. -
The modal window should be able to change the window title to aid in the browser history user experience (ie, what the user will see if they look in their list of previously visited pages).
-
If the modal window changed the window title, hitting the Escape should both close the modal window and reset the window title to the title used by the originating / underlying page.
Remember, this is a “perfect world” implementation. I think getting all of these right is a very high bar; and, is probably why modal windows should generally be avoided in a web application. That said, I’ve seen a lot of modal windows out in the wild that barely satisfy a single one of these core functional requirements.
On a subjective note, notice that I have no requirement for animating modal windows into or out of existence. To me, animating a modal window is just this side of useless. And, should only be a concern after the majority of these other requirements have been satisfied. If you feel the need to animate a modal window, it should only be done with the least amount of effort possible (such as a CSS animation keyframe). If you need to start wrapping DOM nodes in other DOM nodes just to power animations, you’ve already gotten too complex.
Modal Windows In an HTMX Application
In an Angular application, this list of functional requirements is a high bar, even with all of the client-side scripting logic that Angular affords. In an HTMX application, this becomes even harder. This is especially true because HTMX is a little fussy about certain control flows. For example:
-
HTMX won’t inherently “boost” a link that has both an
hrefand anhx-getverb applied to it. -
HTMX won’t allow CMD+Click links to open in a new browser tab if the link has both an
hrefand anhx-geton it (due to the way it determine when to call.preventDefault()on the event). -
HTMX handles
hrefandhx-push-urlattributes differently in terms of the browser history cache (it quietly normalizes thehrefvalue to include the full resource path but takes thehx-push-urlvalue as-is, leading to unexpected history cache misses). -
HTMX won’t cache anchor-based URLs, so attempting to drive modal windows off of the URL hash / fragment is basically impossible.
-
HTMX triggers the
loadevent onhx-triggerattributes even when rendering the page out of the history cache (such as when hitting the Back / Forward buttons in the browser).
I’m still learning HTMX through a lot of trial and error; so nailing down why something is working the way that it’s working includes a lot of opening up the HTMX source code and inserting console.log() statements. Thank goodness the HTMX code is so readable! That said, I hope that I’m not getting any of the mechanics wrong in the previous list; but, please be patient if I am.
The more I think about modal windows, especially in an HTMX context, the less I actually want to use them. Modal window are easy to do; but, they are incredibly hard to do correctly.
https://bennadel.com/4802
Source link
