|
> What's the difference between a dedicated page that has a link "return back to the table", and a modal that you cannot close by clicking on the overlay. And the only way to close it is by clicking the close button/icon which in fact returns you back to the table as well? You don't have to reload the table, for one thing. In the application I work on, we have to dig through a lot of data to build a given table, and we do it every time the page is shown. It can take 3-4 seconds, sometimes more. You also want to maintain your scroll position (as noted in the article), and to that I'd also add that you want to keep your sorting, filtering, and pagination selections too. I don't think that's very hard to store, but the article seems to think it is when it talks about linking to a modal, so I bring it up as a consideration. There's also situations when a user just clicks on a button, wondering what it will do. If that takes them to another page, and they lose their context, that's not great. If it just opens a modal they can easily dismiss, that's much less anxious for them. "Safe exploration" is what I think Jakob Neilsen calls it. I also don't think that hiding the background of a page behind a semi-opaque scrim is part of the definition of a modal, nor is being centered. The article says you can't really see the content of the page behind a modal, but that's just an implementation decision. A modal window is a window that blocks the user from taking other actions before input is given. You can easily show the user what's on the page and still be in a modal. In general, I think that if you've got a big form with a lot of fields that doesn't require reference to some other page to fill out, you should send the user to another page, because it's probably easier for them. If you've got like, one or two questions to ask them, there's really nothing wrong with a modal window most of the time. |