
We use too many damn modals (2018) - juancampa
https://modalzmodalzmodalz.com/
======
bedatadriven
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.

~~~
prox
I implore everyone to read the fundamental book : about face

This book argues about a lot of UI topics, and with a lot of detail. It’s the
bible of UI design imo.

~~~
mrgreenfur
What's the book title? "About Face"?

~~~
prox
[https://www.goodreads.com/book/show/289062.About_Face_3](https://www.goodreads.com/book/show/289062.About_Face_3)

This is a link, you can also search “about face interaction design”

------
l0b0
There's a very simple rule of thumb: must the user give some feedback before
it makes any sense to use the rest of the site? If so, it's fine to use a
modal. Otherwise, don't. Some examples:

Payment page: not a modal. The user might want to add more stuff to the cart,
even when they are literally one click away from purchasing. Blanking out the
rest of the page means they now have to work _around_ the site to buy more
stuff.

Error message: not a modal. The user is vanishingly unlikely to report an
error immediately (obviously it's logged in any case), and probably just wants
to try again with slightly different input.

Irreversible action confirmation: not a modal. For the same reason as the
payment page, the user might want to do something else before retrying the
irreversible action. Just display a _prominent_ message so the user knows the
action is not yet done. Or, if at all possible, implement undo instead.

My job depends on it: OK, use a modal. We forgive you.

------
aylmao
I remember reading somewhere that most (modal) dialogs are just lazy design.
It's easier to have a dialog component and throw whatever notice or controls
in there. It's a predictable and flexible canvas.

Your password is incorrect? Error dialog. Easier to design and build that a
warning state on the text-boxes and a message close to the login button.

Writing a post? Editor dialog. It's easier to design and build than something
that's inline, grows to accommodate what you're writing, and works predictably
when you scroll away or click something else.

There's something the user should know? Alert dialog. Much easier than
figuring out where in the component hierarchy you should inject a warning, how
it should look, what controls you should disable, etc.

~~~
elcomet
Maybe it's lazy but the important question should be: is it good design?

I don't think it is, as it hides some information from the main page. But I
think it can be done well and be useful, as said at the end of the article.

After all, OS use a lot of modals.

~~~
grumple
The more important question: do the people paying you care if it’s good
design? Because the people who have paid me thus far in my career have not
cared.

~~~
lucasmullens
Design is one of those things people often don't consciously notice, but
affects their overall impression of a product.

I think there's a pretty universal consensus that a good design matters.

~~~
tobr
A lot of people don’t understand design as something that goes beyond the
surface layer, though. They see that someone picked a pleasing color palette
and layout, but maybe they don’t imagine that a designer would come and tell
them to stop using modals.

------
ameyv
I don't want to complain, website is harder to read with all that 8 bitsh font
type...Maybe normal post with one example for each idea would be good enough.

~~~
kinkrtyavimoodh
The irony of a website with a deliberately terrible and gimmicky UI
complaining about a functional UI model that has worked for decades.

~~~
justanotherc
That's kind of what I thought too. Our app is very Modal heavy (including
modal inception), but I can't think of any case where the suggested
alternatives would actually be better. And that's backed up by the fact that
our users regularly tell us how easy and awesome it is to navigate through it.

~~~
winrid
It's one of those things that when you prototype a design without them you
really feel the difference.

------
systemvoltage
I agree about modals. But seems like the same points can be made about the
website's design that trying to teach others about modals, have you considered
using plain text or a more readable website to convey your point across
without resorting to 1-bit retro decoration?

Edit: 1 bit lol

~~~
post_below
I don't love retro design either but that seems irrelevant.

To anyone who's familiar with the topic it's immediately clear from the copy
that the author understands it.

Considering that the target audience is other designers, why does the
presentation matter?

~~~
buzzerbetrayed
> Considering that the target audience is other designers, why does the
> presentation matter

I fail to see the logic here. Good design helps people learn easier. It's not
like designers have some unique ability to learn equally well no matter how
poor the design is.

~~~
post_below
Well context... the information the author is presenting is simple, right
brain stuff. No one with UI experience is going to have a hard time digesting
it.

It's not like he used gifs or flashing colors.

Now I kinda want gifs and flashing colors.

~~~
gindely
That isn't actually true. I think I have UI experience, but I would actually
have preferred some mockup examples instead of 1 bit bmp pseudo-thumbnails to
represent his ideas. Surely it would be better to show some good user
interfaces.

------
x32n23nr
Modals are basically the fancy clone of old school javascript's alert(), and
while everyone would rightfully be annoyed being "alerted" needlessly,
designers have convinced themselves that it's fine to show modals frequently?

Edit: Claiming it's only designers' fault, or generalizing that all designers
do that, is obviously wrong. I did not mean that. What I meant to convey
(partially failed) is that examples propagate, and somehow design choices are
the beginning of this propagation chain.

~~~
pvg
Modal dialogs are a lot older than alert(). alert() is an instance of a modal
dialog, not the other way round.

~~~
seventh-chord
My impression from seeing old windows version (never having used anything
older than vista) was that in general using an extra window instead of a
separate pane inside the window was more common. As far as I can tell, the old
windows explorer would pop open a new window for each opened folder. Now it
seems like most programs are run in half/full-screen; They arent really
treated as windows. IDEs have their own window-layout system anyways, right?
(Modal) dialogs are probably more at place in a world where windows is more
that just the name of the os.

~~~
pvg
What I was getting at is that the important thing is the concept (which is
about as old as GUIs), the other stuff is implementation detail. The 'modal'
part of the a modal dialog is that it takes you out of the 'modeless'
interaction state where you can take one of the many UI actions available to
you to a state (mode!) where you can do very few things and nothing else.

Making GUIs less modal is a similarly ancient UI design holy grail.
Applications are modes hence everything from OpenDoc to the just-announced App
Clips. A familiar clunky modern mode is 'native' apps vs 'apps' in browsers -
a big chunk of technologies many programmers work with today are directly or
indirectly related to mitigating its effects.

~~~
gindely
Yeah I think nowadays a lot of people think "modal" means "a dom element
positioned with respect to the viewport that prevents interaction with the
rest of the webpage".

The classical sense of "a collection of related controls that prevents
interaction with the rest of the application (however the collection, controls
and application are implemented)" is surprisingly rare now, particularly since
the older sense were often called "dialogs" (and indeed, "modal" was short for
"modal dialog") - intended to emphasise that this was communication between
the user of the application and the developer of the application to decide how
the application should behave.

Therefore, a _modal_ dialog should be used when the communcation couldn't have
happened before and cannot happen later, and the developer of the application
cannot do something intelligent and allow the user to correct it later on.
(For instance, just delete the thing and let them undo it - no interaction
between the developer and the user actually needs to transpire.)

------
recursivedoubts
Let me see if I can articulate this well:

The problem problem with modals in a web page context is that they go against
the statelessness of the html request/response model. They end up building up
a lot of local state in the client, both model state as well as UI state, that
eventually need to be reconciled with the server. If the user closes the
modal, is the data saved for later? Does the form reset? Does the server know
anything about it? If it is a wizard, were previous steps saved? And so on.

After many years of working on and with intercoolerjs/htmx, I now typically
prefer inline editing and wizards, to a modal solutions. It fits better with
the web model, allows for proper URLs, etc.

The inline-edit demo from htmx is a good example of something that might be
implemented as a modal by some developers, but works very well as an inline-
edit UI instead:

[https://htmx.org/examples/click-to-edit/](https://htmx.org/examples/click-to-
edit/)

(NB: I was lazy and did not make the URL update as I should have)

~~~
runawaybottle
I’ll try to condense it more. If you play a video game and a modal pops up, it
takes you out of the experience. It’s the same as (hypothetically) me having
to go into my HN profile to find a list of comments I upvoted to then go ahead
and downvote (versus just having the downvote button next to the post).

Can’t teach this stuff, you basically need to be confronted by tons of bad UI
in software, games, physical printed forms, processes, until you get a good
sense of taste.

I can’t _teach_ HN devs that my thumb covers both the upvote and downvote
button on mobile. Can’t teach it.

~~~
ozaark
> Can’t teach this stuff

There is literally a field of science called Human-Computer Interaction that
teaches this stuff.

~~~
gindely
Yes but have you seen software - almost anything that's been developed since
the growth of mobile platforms has basically done the exact opposite of what
that field of science teaches.

This seems to confirm the op's point.

~~~
ozaark
That fault lies solely with the designers and developers of those software.

"Yeah but they didn't know what they were doing and didn't want to learn" is a
more appropriate take.

You can think of it this way: your neighbor nextdoor made a soapbox car. Does
that qualify them to be your mechanic? Probably not.

------
w_for_wumbo
My biggest issue with modals, is that they never seem to be tested with mobile
devices in mind. So when I'm on my phone, the ability to close it is often off
the screen. The only choice is to leave the website at that point.

~~~
labster
I often find the pattern on websites that I visit the site for the first time
due to a link, read maybe half a paragraph, and then get a modal popup asking
for my email address to subscribe. I've never read any content from them
before, how would I know if I want to subscribe? My phone is also in landscape
mode, so the modal's close button is off the screen, and I can't scroll to it
cause it's an absolutely positioned modal.

So the only logical thing to do is avoid the site in the future, they're more
interested in extracting money from their existing readers than getting new
readers. Sorry, maybe if you had let me read one article I may have liked your
content.

------
ozaark
The key design principle overlooked here is Progressive Disclosure[1], which
modals and dialogs can be very good at delivering.

Progressive disclosure retains user focus on a single task as opposed to
showing everything at once. Accordions have similar function to modals and
dialogs but adding further task controls to an already complex interface isn't
always the best solution.

The author goes on to state that even full screen modals are bad, but what
difference does the user see? If done well the user should still be able to
use the browser back button, escape key, etc to navigate out. In modern
applications, pages can transition from one to the next without a "full page
load" -is that also bad for some reason?

Think of many popular mobile apps like Instacart, Doordash, etc that allow a
user to dive into categories that slide on top of the existing content to give
further controls; is that not ok?

Every element in the DOM can be applied inappropriately but that doesn't shift
the blame to the elements themselves. One could argue an entire dedicated site
that only uses modals based on the misuse of illegible fonts would be about as
apropros.

[1] [https://www.nngroup.com/articles/progressive-
disclosure/](https://www.nngroup.com/articles/progressive-disclosure/)

~~~
andreareina
TFA is not saying all modals are bad, just most. Progressive disclosure is a
fine thing, but that doesn't have to mean modals. Most of the time a discreet
notification that doesn't interrupt the user's flow is what's appropriate; I
think Tidal does a good job here, by highlighting _one_ feature per screen,
and if I don't tap on it to see what it is I'm able to go about my way.

Since we're quoting NNGroup, here's their guidance on modals[1] (emphasis
mine):

1) Important warnings

2) Critical to continuing the __current process __

Most modals are unasked for, not relevant to the user 's current needs (no
matter what the dev/marketing might think), and unwanted. Modal to select
filter settings when I've clicked/tapped the 'filter' button? That's a good
use.

[1] [https://www.nngroup.com/articles/modal-nonmodal-
dialog/](https://www.nngroup.com/articles/modal-nonmodal-dialog/)

~~~
ozaark
TFA literally says don't use full screen modals, ever. I disagreed with
examples of that not being necessarily relevant with the way today's
applications can work.

Important from the NNGroup article you linked even demonstrates great modal
usage and states "3\. Modal dialogs can be used to fragment a complex workflow
into simpler steps." and "4\. Use modal dialogs to ask for information that,
when provided, could significantly lessen users’ work or effort."

That's important - modals are not just intrusive pop-ups as many designers and
others in this thread have decided that they are. Again, every element can be
used inappropriately but that doesn't mean the elements are to blame.

~~~
andreareina
You're right about full screen modals, I've seen those done right and "never
use x" is rarely right all of the time. And modals can be done well, but 90+%
of the time I encounter them, they're not. They're not related to the workflow
I'm currently engaged in, they don't save me any time, they don't serve me.

Again, I'm not saying (and I wouldn't characterize TFA as saying) modals _per
se_ are bad. But the priors are such that absent any other information, modals
are suspect.

------
winrid
I hate modals - I'll never add them to products I build.

Edit: To provide a little more substance here - for example in one product of
mine that actually has customers - confirmation is done via inline elements
that slide into the page.

So you want delete a comment for example. The delete/cancel buttons slide into
the box for that comment. No weird context switch for your eyes.

~~~
gindely
Since you deny a weird context switch for your eyes, are these actually inline
elements? That would imply the size of the containers is changing. Which would
surely be a weird context switch. But at least I can have no doubt what my
action is about to affect - I get frustrated on sites when it says "you're
about to delete these items" and i have no idea whether it agrees with me
about which items I'm about to delete or not.

But if they're overlaid elements, like a context sensitive menu that contains
two options - delete, cancel - is there any substantive difference between a
menu and a modal? The main advantage of a classic menu over a modal seems to
be that it has a implicit cancel option that is uniformally implemented. But
nowadays, menus are implemented without toolkit support - yay dom, yay - so
even that is not consistent.

~~~
winrid
This is what I mean: [http://imgur.com/a/hY9eM77](http://imgur.com/a/hY9eM77)

Content size doesn't change in my case and I would highly advise against
changing the sizing of elements on the page for something like this.

The buttons are sized vertical based on the content up to a limit.

~~~
gindely
Yep okay, so I guess that's not inline by my definition (since it overlays the
text). I have definitely seen webpages that change the size of the containing
box to add in the confirmation message and buttons.

I guess it's an between case I didn't consider - it's maybe not modal with
respect to the whole app, but it seems to be modal with respect to that one
comment (you can ignore it and do something else with the rest of the program,
but with that comment, you can't even read it).

------
quickthrower2
In what context?

If you design a desktop application, like say Word then modals are more
appropriate than the alternatives in many situations. For a site like Medium,
a modal is an annoyance. If I asked for something (click Settings) then I am
happier with my modal than if I didn't ask (we're going to stuff cookies on
your page anyway, here is our arse coverer).

The underlying message I take is we "use too many things that make it easier
for the coder and harder for the user". Sometimes that's a modal, but
sometimes that's NOT using a modal!

------
js8
Typing this from Ubuntu, Gnome 3 I think, in Firefox, I press Ctrl-S to save
the page, and I get a modal dialog, which cannot be even moved. Sometimes, it
actually obscures something that I cannot read on the screen.

If you have to use a modal element at least allow me to get it out of the way
so that I can read the text under it!

~~~
yencabulator
Every time this happens in any environment, the information I need for
deciding the filename is below the modal.

------
Kaze404
This is only tangentially related, but one thing I'm absolutely sick of is
rounded corners. I don't know why, and I don't know if it makes any sense, but
opening a page and seeing literally _everything_ with border-radius makes my
blood boil. It feels like they're trying to protect me from sharp corners, as
if they're dangerous. Come on, we're all adults here. We can take a few 90
degree angles.

~~~
gindely
> Come on, we're all adults here. We can take a few 90 degree angles.

I know that 90 degree angles on webpages are not more dangerous for children,
parents, adults, or any other known subcategory of humans than for any other
known subcategory of humans, but ... lots of people who use webpages and dev
tools are actually children.

Didn't a lot of us get started as kids?

Have we collectively forgotten the olden days, when to print something, the
solution was to ask the neighbor's next door kid? (who was probably you).
Printers aren't any easier to use today than they were back then, but I guess
that practice is over nowadays.

~~~
Kaze404
Fair enough, but some of the worst offenders of this aren't really targeted at
children or something they'd be interested in. The new Github UI (which I
adore, besides this particular issue) is a really bad offender for example. If
you go to your profile page, there's not a single not-round border. The
exception are the little squares showing activity, which makes it even worse
because in the caption underneath they _are_ rounded. What happened there?

------
seph-reed
Modals are a good way to show complex content without throwing away your
current render. Whatever you were doing before the modal came up, you can go
straight back to that. No re-draws, no scrolling back to the place you were
at.

Ofc we've all seen them done terribly.

------
justanotherc
Modals are good for when you need to show a new blocking state without losing
the current state. There are many valid reasons for that scenario. Even for
modal inception.

Use them for that purpose, no need to swear them off completely.

------
grishka
The one UX anti-pattern that needs to die for sure is what this site calls
"self-spawning modals". They're not only on websites — iOS is very annoying
with them for example.

------
qntmfred
I've been preaching against modals and carousels for years. I'm a big fan of
[http://shouldiuseacarousel.com/](http://shouldiuseacarousel.com/) and while I
had long ago intended to create with a similarly implemented site that
demonstrates the pitfalls of modals with a series of modals, this site does a
pretty good job of highlighting the main issues and alternatives too

~~~
klyrs
Wow, that's almost useable when you don't have to wait for a new ad to load
with every click...

------
davedx
Hah! I often have the experience that indeed a modal should actually have been
a new page, but I was too lazy to build the thing so I went with the modal.
Then later the modal needs more options or fields, and I end up having to
convert it to a new page anyway... lesson mostly learned now. Agree with the
article.

------
saagarjha
One thing I like to do is preview a link by Force clicking on it in my browser
and scrolling through it–the preview window lets me scroll, but not interact
with the page. For many sites this is quite convenient, because I can skim the
page without being interrupted. But when modals pop up they cover the content
and I can't read the page because I can't dismiss them! So if you're looking
for another reason to drop modals, here's one.

Also, hilariously this website uncovers a bug in Safari where the cursor
doesn't reset once you leave the page bounds, so I have a huge pixellated
cursor hanging around until I click somewhere else :P

~~~
gindely
What does that mean? Force clicking? You apply so much pressue that it breaks
a touchscreen/touchpad so that it makes a click noise when you tap?

~~~
saagarjha
In case that wasn’t a joke: [https://support.apple.com/en-
us/HT204352](https://support.apple.com/en-us/HT204352)

~~~
gindely
Oh, another of Apple's hidden features. Once upon a time, one button mice were
a feature so that features weren't hidden and even beginner users could
quickly become power users.

~~~
saagarjha
This used to be three-finger tap on older Macs.

------
mlonkibjuyhv
There are so many bad modals in mainstream desktop software. Is there any good
reason that an open file dialog completely disables all other interaction?
What if I quickly have to task switch, or a piece of info relating to which
file i wanna open is just off screen?

A personal favourite is osx Preview and the rename and move file drawer you
can get from the status bar of an open file. That guy can't even be moved, and
perfectly covers up the portion of a document likely to contain info relevant
to a filename.

------
tbirdny
I'm reminded of a quote in Inside Macintosh Volume 1: "But, gentlemen, you
overdo the mode." From John Dryden, The Assignation, or Love in a Nunnery,
1972. That quote really stuck in my head.

------
jaequery
I must be in the minority as I love modals.

------
nameoda
The list of reasons why modals are bad are all very subjective. A little more
explanation would have helped make the case that modals are bad.

Not to mention that what should be a list is displayed as a table (－‸ლ)

~~~
diegof79
I agree, the site visuals and short messages doesn’t explain well why they are
bad.

I’ll try to fill that gap.

Modals switch the application normal mode to get your attention. So they
interrupt your “flow”.

Most of the reasons to use them could be resolved by other means, that are
better in terms of UX but requires more work in both design and
implementation:

\- Confirmation modals can be substituted with auto-save, undo, and restore,
but is more complex to implement.

\- Modals to show more info can be resolved with progressive disclosure or by
improving the information architecture.

However, like with many design choices there are cases where modals are a good
option. For example, for certain confirmations and navigation the advantage of
the modal is that the backdrop makes clear where do you go after dismissing
the modal (bottom sheets in mobile are a example).

Another reason why modals get a bad rep is that they have all sorts of
implementation issues in web, and in the desktop the mode change for a window
is not prominent (macOS solves that with sheets, but Windows still has that
problem)

~~~
Enginerrrd
They also break zoom and other features some people rely on a lot.

------
slezyr
The website is readable only at 30% zoom(couldn't zoom out even more) on the
4k 27" display also it messed up mine scroll wheel in some way, broke mouse
cursor.

------
627467
Modals can be a lazy (and worst, wrong) solution. But I've found that
pavlovian bashing of modals is as lazy and unproductive.

> And remember to always ask, kids: >“Why does this have to be a modal?”

In my experience people don't need to be remembered to ask this. And generally
people can't justify why it shouldn't be a modal or why a non-modal solution
is better than a modal one.

------
ascotan
Back when js frameworks became a thing, modals were a shiny ball that everyone
wanted to put into their app (because they came with the framework). Designers
that worked with these modals became poisoned to the fact that this is how a
UI should look. Like an old hairstyle they're now thankfully going out of
fashion.

------
discordance
I've been using Azure a lot, and they use blades (essentially horizontal
accordions) instead of modals.

I was playing with Alibaba Cloud's UI and it's all modals and feels much much
nicer to use. I wouldn't use Ali Cloud due to Chinese ownership issues, but I
do like their UX.

------
imtringued
Eclipse uses modals in the worst possible way. Usually you want to copy the
name of a type or variable into a modal but you are already into two layers of
modals. You will have to close all of them and lose progress. Using more than
one layer of modals is always bad design.

------
farouqaldori
The awful readability of that website must be satire, right?

------
Areading314
The reason modals are so popular is because they work really well when trying
to convert views to signups.

------
pablosca
Love this a lot! The author is right on most (well, all) of the statements.

------
renewiltord
Very easy to use a modal if I’m editing other parts of UI.

------
jevgeni
I have a rule: if I get an unnecessary modal, I leave.

------
jerry40
Oh I thought the subject is about the modal verbs

------
triyambakam
Is this website considered "brutalist"?

~~~
WorldMaker
In the web sense of "true to web form" brutalist? Not really, for instance the
tables are not made to look like TABLEs and are in fact ULs and such. This
design aesthetic might better be described as "(Mac) Classical". (Brutalist
isn't only about minimalism.)

------
Kagerjay
the worst thing is doing a modal that calls a modal, that's the worst offender
of them all

------
6510
also see: popups

------
supernova87a
My main gripe with modal windows is the name. The first couple times some
developer told me that's what she was using, I waited for her to explain what
modal meant. But she did not, as if it was standard self-explanatory
terminology. Way to name something a word that sounds like it has a standard
(even deeper) meaning, but does not.

With time, I have just accepted that this is what modal means (I'm going to
create a window of this type to display the data/filters), disconnected from
any meaning of the term "mode".

But I still don't like it.

~~~
aasasd
It's a term from the UI design world, and it goes way back. A mode is a state
where the app accepts certain inputs from you, the user. A new mode means
previous buttons and shortcuts are inaccessible, and the same input may
produce different results. Either coincidentally or directly related, Vim's
modes illustrate the idea well—in contrast to editors where input, motion and
shortcuts for extra functions are available together.

[https://en.wikipedia.org/wiki/Mode_(user_interface)](https://en.wikipedia.org/wiki/Mode_\(user_interface\))
and
[https://en.wikipedia.org/wiki/Modal_window](https://en.wikipedia.org/wiki/Modal_window)

The trouble with elaborate modes is that the user has to mentally keep track
of which mode they're in (which is what the term describes); and that other
functions are inaccessible even though they might be useful to resolve the
situation. However, modal dialogs are a streamlined and visually distinct
extreme of modes, with an established history, so some don't consider them
problematic. (Modes that are difficult to notice are still a no-no.) OTOH
dialogs are frequently used as cheap bail-out by programmers, especially in
desktop interfaces—since they're very easy to produce, completely synchronous,
and shift all problems onto the user.

~~~
supernova87a
Thanks for that explanation.

I guess I just have to live with it when I pop in and out of the UI coding
world. Just like in Python a .method isn't what the natural word typically
means, but just has gotten a domain-specific meaning attached to it in that
world.

