Comment by corry | Hacker News Reader

Comment by corry | Hacker News Reader

Parent Full thread

The article seems to pay scant attention to THE main reason modals make sense to me: they allow for a discrete bit of work to be completed within the greater context of the app, without losing state or position.

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.

No disagreement. In my experience though, modals are used in far too many places. I think if your criteria were applied diligently to every design, this site (and the motivation behind it) wouldn't exist

100% agree. Check e.g. this UI for moderating product reviews:

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".

> Check e.g. this UI

That’s not a modal window, though. Modal windows are overlays [0] over the main page, here it’s to the side.

[0]: https://en.wikipedia.org/wiki/Modal_window

> they allow for a discrete bit of work to be completed within the greater context of the app, without losing state or position.

Literally in the example the modal covers 100% of the view state. Most modals cover a big portion of the state.

The article is not inconsistent with this.

I'd go even further and say that modals make sense in almost any context where there's some underlying state whether it's a game, form, or even just scroll position in a forum thread.

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.

Your example doesn’t suffer from, for example, not being able to bookmark a step in the booking process. At the end of the article, “forms to update/create entities” is specifically mentioned as a valid use case.

I don't understand what you mean without changing your double negative, but you can route URLs to modals.

I was pointing out that a booking funnel is not a place where this is necessarily a bad pattern, and this is already covered in the article. Their framing is that you should avoid modals for "resources", but it's fine for "forms that update/create entities". So that example is not in disagreement with their position.

> just scroll position in a forum thread.

but then you can't reference the thread without closing the modal (and likely losing all progress)

> and likely losing all progress

This is one of my main points: good UX takes some thought. It's harder than doing the bare minimum. In this case, preserving someone's post in a <textarea> is the same concern whether it's in a modal or stuck at the bottom of the page. Neither using a modal nor not using a modal solve this for you.

It usually makes sense to introduce a localstorage draft system regardless of where the <textarea> appears on a forum.

It makes sense to reset seats when you change flight, it's domain logic, not interface logic.

Yes. But contact info, payment info, perhaps amenities, insurance, and all sorts of other components you might encounter in the process.

Most airline flows do preserve this information.

Reply on news.ycombinator.com