Dialog widgets are handy, but only to dig you out of a whole in terms of available space. What they're not so good for is displaying resources. That is, the a given web application is probably made up of hundreds, or thousands, or hundreds of thousands of resources. We definitely don't want the default mode of interaction with the user to be through a dialog widget. Why? They're not designed for such a purpose. This is why we already have a browser window, for each one of the resources in your application. A resource has a URI, or it should anyway, and the user presses a button, clicks a link, or triggers some other event that changes this URI. This is fundamental web behavior, and the dialog widget, when misused, disrupts that behavior.
The quickest and easiest way to tell that you're using a dialog widget incorrectly is to compare how your application interacts with the user, and compare that to a real human-to-human interaction. An actual dialog. This can, however, be misleading since the difference between human-to-human dialog and human-to-computer dialog is substantial. For example, another human may initiate a dialog with you by asking a question — to which you respond. And ideally, this is as far as the human-computer dialog goes. I don't like it when I get asked a question in a dialog box. Than another one. And so on.
But this is just a simple matter of slimming down the actual work-flow of the application, right? Just make the application ask for as little input as possible from the user? Sure, but that's not always possible. And that's what forms are for. Structure the data you need from the user in such a way that it can be presented as a simple form, then you've eliminated the need for a complex human-computer transaction that doesn't make much sense to the user. It probably doesn't make much sense to the developer either — I can't remember having implemented a wizard, or a complex set of dialogs and thinking it was a good design. Granted, I've seldom seen such a design, and there's probably a reason for that.
Input is one thing, presenting resources that have their own URI is another. When the user is reading something about a resource, being simple content such as a blog entry, the state of a remote computer, or a store product, it's simply being presented to the user. Maybe the user can decide to take action on the resource, based on the information they're reading. Fine. They can click a button that performs the action. Or, perhaps performing an action introduces a legitimate need for a dialog widget — to collect secondary input.
The most obvious and common piece of secondary information I can think of is a simple yes or no. A confirmation modal box. This is just to sanity check what the user is doing, to offer them an out if they're trying to do something that could have unpleasant consequences if performed accidentally. And so it's a good idea to have this safeguard in place when such actions are presented to the user. The dialog doesn't exist on the screen, maybe off to the side or at the bottom, waiting to slide into position when the user clicks something dangerous. No, it isn't part of the screen real estate at all. Nor does it disrupt the existing screen layout. These two points are what make the widget so attractive in the first place.
Dialog content should be simple. It shouldn't look like a web resource with it's own URI. Why does that matter? Because it's it takes up less physical space on the screen that way. It doesn't come across as interfering that way. It's more intuitive that way. If I'm using a web application that presents a recipe to me in a dialog, I'm going to think "hmmmm, this seems like it ought to have a URI so I can bookmark it or hit the reload button". But at the same time, I'm probably thinking that "this is a dialog, inside of a regular web page and it doesn't even have an address bar".
Dialogs for the sake of dialogs, it seems. Don't do that. I understand the compelling reasons to quickly implement content that lives inside of a dialog because, it's easier than the alternative of evaluating your current application structure and introducing a new page that looks like a...page. It's easy to have a button open a dialog widget. It's easy to populate dialog content. It's usually easier than the right way. And the rule of thumb is this — if it has a URI, don't use a dialog to display it's content — find a better way that behaves like the rest of the web. The dialog widget has a small set of viable uses — choose them wisely.
No comments :
Post a Comment