Aza recently posted on modal overlays, those dialogs that pop up and disable the background behind them. You can click anywhere inside modal overlays, but you can’t click anything in background until the dialog goes away.

Usually when we think of modals, we think of dialog boxes like the one below from Google Documents. Aza’s critique applies to this kind of modal. After you call up the find/replace box, you can’t click anywhere but inside the dialog. That means you can’t scroll the document underneath the dialog or copy and paste a word from the document into the dialog box while the dialog box is displayed.

But that’s not the only kind of modal overlay. Check out this Preference pane from Apple’s It has nothing to do with modifying the content behind it. It could just as well be a separate screen.

Actually, this fact that it could be a separate screen caught my interest. At 37 we never use modal overlays. All our settings screens are completely independent from the other screens in the app. In order to explore the difference between these two approaches, I mocked up an alternate version of Apple’s preference screen that fills the entire window like a typical web app might.

It’s interesting to compare these two versions. I have to admit I like the modal one a lot better. On the one hand it has more visual interest and depth. On the other, it raises some interesting questions about navigation.

Modals as alternatives to navigation

Two questions that often float in our minds when we use software are “Where am I?” and “How do I get back?” There are common techniques we use to ease these concerns like tabbed interfaces, breadcrumbs and “Cancel” links. We should think of the modal overlay as a tool in the same family. It is uniquely powerful at quieting these nervous questions. “Where am I?” is a non-starter because you never left the original screen. And “How do I get back?” is trivial when the original screen remains visible in the background.

Screen size as a reflection of importance

Another thing I like about the modal approach to Preferences is that the preference screen doesn’t feel equal to the other application screens. You get the feeling it didn’t deserve its own browser window’s worth of real estate.

When we design the UI for a particular screen we always try to make the important and frequently-used elements larger and more prominent than the lesser-used elements. It’s a good rule of thumb to think that if elements in the same context all have the same size, then they must be equally important. Apple’s Preferences modal applies the same principle to the scale of entire screens. The preferences screen is itself smaller than the browser window that plays host to the more important screens full of real data.

Modals aren’t all bad

While Aza’s critique still holds for modals like the Google docs example above, demonstrates that modal overlays do have a place as an alternative to navigating between independent screens. It’s also very interesting to consider which screens really deserve their own browserful of real estate and which should be reduced to substates of other screens. I suspect that when people praise applications for being particularly “Ajaxed” or “Desktop” in style, this lack of navigation between separate screens is a big part of the appeal. Apple has shown that it’s possible to bring desktop-style interactions into web apps without falling into the extreme of a desktop clone. It should be fun to see where other designers take the inspiration.