July 18, 2008

On Dialogue Boxes…

I’m currently writing a few dialogue and interaction menus for my current AIR project, and the thought had occurred to me that having established a reasonable methodology for handling and displaying modal dialogues within my Cairngorm-based app, I was perhaps using them almost by default, without thinking too carefully about whether a modal dialogue was the most appropriate means of interaction. By modal in this context we mean “A state of a dialogue that requires the user to interact with the dialogue before interacting with other parts of the application or with other applications”.

At the same time, Chris and I have been talking about metadata recently (another entry to come, but the premise was that persuading users to input metadata about assets is hard to incentivise). Related to that, Chris sent me this great link to an entry by Jeff Attwood that in turns talks about an entry by Eric Lippert on how dialogue boxes are perceived by users:

* Dialog boxes are modal. But users do not think of them as “modal”, they think of them as “preventing me from getting any work done until I get rid of them.”

  • Dialog boxes almost always go away when you click the leftmost or rightmost button.
  • Dialog boxes usually say “If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No”
  • If you press one of those buttons, something happens. If you press the other one, nothing happens. Very few users want nothing to happen—in the majority of cases, whatever happens is what the user wanted to happen. Only in rare cases does something bad happen.

In short, from a user perspective, dialog boxes are impediments to productivity which provide no information. It’s like giving shocks or food pellets to monkeys when they press buttons—primates very quickly learn what gives them the good stuff and avoids the bad.

I liked that, especially the bit about “Teching the tech” – while it’s quite funny it’s also a pretty accurate reflection of my experience as a user.

This is also related closely to what Chris and I were discussing about metadata; expecting the user to fill in information that has no obvious purpose and slows down the primary task of upload/publish or whatever it is that they are trying to do, is likely to be ignored. If those fields/dialogues are modal or conditional, it’s worth thinking carefully about whether there are alternative ways to complete the operation or gather the infomation. That’s harder to do of course, and there are cases where modal dialogues should be considered appropriate, e.g. where the application is about to do something destructive like deleting or overwriting a file, but there are alternatives, like how IE and Firefox avoid breaking the flow of interaction when blocking certain actions.


- One comment Not publicly viewable

  1. Robert O'Toole

    Further annoyances…

    1. The bar that appears on IE right above the top of the page when there is a security warning or a file to download.

    2. Alert bubbles popping-up from the icon tray thingy in Windows, alerting of urgent updates and uploads just when i’m in the middle of doing something really difficult.

    Nice…

    Pages that are designed to include warnings within their internal flow, at exactly the right place and to exactly the appropriate degree.

    22 Jul 2008, 09:02


Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Search:

MXNA link

Tweets



    Tags

    Other blogs I like...

    Black Pepper Software

    Emak Mafu

    Eismann-sf Go to 'Comments on: Design News for Web, Graphic Designers'

    Ted On Flex Go to 'Ted On Flash'

    Galleries

    Meetups:

    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXIX