Don't kill the modal

Back when computers were coal-powered, showing more information to site visitors meant shuffling them off to a new page. We were sad.

In time, the modal window was introduced, and those of us who built websites considered it our savior: it permitted the presentation of relevant, contextual content or transactions in the same screen. We were happy.

Over time, however, we abused our savior: we began stuffing entire pages of content or multi-step forms into that poor little floating box. (And don't even get me started on ad modals that appear the moment you land on a new screen.) All of this misuse and abuse of the humble modal has left many calling for its demise. 

But the modal still serves its original, invaluable purpose of presenting snippets of content or simple transactions in a focused area without forcing a context shift. On TED, for example, we implemented a modal that lets users do things like save talks to watch later without having to be redirected to a login screen first. 

So instead of getting rid of the modal, let's be smart about its use:

  • Use a modal when a trip to a new screen might be overly disruptive.
  • Include no more than a few lines of content or a very abbreviated form.
  • Avoid spawning a new modal from an existing modal.
  • Allow users to close the modal multiple ways — e.g, the esc key or clicking outside the modal — not just a close button.
  • Fix the modal's position so it can't scroll off-screen.
  • Make sure it works well on mobile, or design an alternative.
  • Make it accessible.
  • Never spawn a modal automatically (unless you'd like a midnight visit from Jakob Nielsen).

If a modal isn't right, but shifting screens is less than ideal, there are alternatives including slides, accordions, expanding panes, and enhanced tooltips. These are all great ways to add depth while keeping people anchored in the current experience, but none is a universal replacement for the humble modal.

Weekly Waffles

Every Friday I create a brief status report for my work projects, each consisting of 5-10 bullet points. Each point outlines what happened on the project in the past week, and what's coming up. 

A typical bullet point looks like this:

  •  Subscription sign-up flow: UX complete and approved; Joe to start front-end dev and integration next week. 

Although I send these updates to my bosses, they're not a requirement. I started writing them for myself: they remind me what I've accomplished in the past week, and force me to think about what's next. And they take about 5 minutes to write.

I save a copy of each week's update in an email folder as they're helpful for annual reviews. Mostly, however, they're just a great way to cleanse my brain of the various project-related bytes swirling around inside.

And the subject line? Weekly Waffles, in honor of my nickname here at TED.