Modal Windows Considered Harmful

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

On the Wicket user’s mailing list there was a question about modal windows and it set me off. Since my excellent wisdom ūüėČ is larger than just modal windows and Wicket, I thought that it would be of interest to all of you, dear readers.

I have discovered that the modal windows that was gone when web applications started to spread, are starting to come back. And they are bad, even if they are not as bad as the goto statement that was accused the same way as I just did: harmful.

A modal window is something that pops up in the face of the user, screaming its importance by not letting the user touch anything else until the modal window had its way.

We have a back office application written in Swing that use modal windows a lot and it is just getting worse by each feature added.

Modal windows are really a last resort and should not be used at all, if you can avoid it. What I have seen is that they tend to grow in functionality over time and suddenly you are faced with the question: "should I put a modal window here, oh, I am already in a modal window".

(Ranting further), modal windows are primarily for non-expert users that need guidance when you wish to be certain that they know the implications of what they do.

There should be nothing but some information and a yes/no question.

If the users are pushing you around demanding modal windows and customer is always right, so what to do? I suggest take a step back and present a complete new style of interaction that would give users a much better flow in the interaction than now.

Having said that on the list, the following question was fired at me.

"Per,
I see what you’re saying and I have a question.
How would you implement (UI concern) a setting page?
What I mean is, suppose I have a page that shows some statistics.
The statistics can be set by the user.
We implemented a link / button that opens up a modal window to select the
statistics.
How would you do it?"

Oh, that is a good one.

You could make it a modal window. After a while that window (I assume) would get to contain more and more settings. Then all of a sudden, the last setting you added will really make statistics take a very long time. Since the user probably can’t foresee that, you wish to confirm that the user have understood the implications. So you need a modal window that … oops … you are already in a modal window.

The first thing is to think about as an alternative is to start with direct manipulation. Is there any way you could change the settings right when you are looking at the statistics?

Typical example is the familiar "click on column heading to sort table on contents of that column".  Consider drag-n-drop objects if that is natural.

Second is to have the modal window inline on the page in panel. After all, selected settings and the result in the same window feels better than switching to another window, modal or not and then back.

But there may not be room for that. Can you split the settings in groups to inline on several places on the page?

Next thing to consider is to have it on another page and here comes another concern in regarding the concept of settings, life cycle. Do all settings have the same life cycle?

Which ones are per request, per session, per user, per application? Side point? Well, it sure controls presentation since settings with different life cycle should not be presented together.

If the selection of statistics is a very separate activity, maybe it should be on separate page before the page that presents the result? Changing settings would be reached by pressing the back button.

These are my thoughts on alternatives to modal windows jungle:

  • Try direct manipulation,
  • Keep selections visible all the time
  • Resort lastly to a separate page
  • Save modal windows for that yes/no confirmation. You will need it eventually.

Thanks for reading!

Leave a Reply

Your email address will not be published. Required fields are marked *