Java Platform, Enterprise Edition

Java EE Journal

Subscribe to Java EE Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Java EE Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


J2EE Journal Authors: Douglas Lyon, Stackify Blog, APM Blog, Sumith Kumar Puri, Javier Paniza

Related Topics: Java EE Journal, Java Developer Magazine

Article

Dialog Boxes, Habituation, and Single Threaded Thought

Being able to process information and analyze it intelligently is crucial to our ability to solve problems

In Jef Raskin's excellent book, The Humane User Interface, he discusses how the human brain is able to perform many tasks simultaneously while only having the ability to focus on one conscious thought at a time. Being able to process information and analyze it intelligently is crucial to our ability to solve problems, but once we have learned how to deal with a particular situation, just as vital is our ability to remember and recall the response without thinking. This allows us to drive a car while thinking about what we're going to have for dinner that evening. If, on said journey, an unexpected situation does occur, it's important that the brain recognizes it as such, pages out the pictures of seared sea bass, tasking the conscious high-priority brain to analyze and react to ensure we don't cause an accident. This process by which conscious though is relegated to subconscious processing is known as habituation and is important to GUI design for a number of reasons.

Users don't want to think about your application - they want to use it without engaging their conscious brain. An example is when a dialog appears, it means they have to stop their thoughts of dessert choices, so their reaction is based around thinking as little about whatever the dialog is asking them, and to move back to subconscious operation of the software as quickly as possible. Wizards fall especially foul of this when they gray out finish buttons until a minimum amount of information has been completed. All the user will do is enter whatever it takes to get the "Take me back to day-dreaming-Finish" button enabled, causing bogus values in entry fields, next pages with potentially important information that won't get visited, and so forth. A problem all dialogs suffer from is that since they are separate windows covering the original application, they are obscuring information (possibly modally) and the user's natural desire is to get rid of them by dismissing them.

The other problem with habituation is that whatever technique is used to try to grab the user's conscious brain will eventually become relegated to subconscious processing when done a number of times. An example of this is the ubiquitous "Are you sure? Yes/No" pop-up. Users get asked this so many times that pressing "Yes" is the default response whatever the question; so developers, when trying to ensure the user really does read the question because something irreversible is about to happen, play tricks like swapping the "Yes" and "No" buttons and changing which one is the default. Web sites that solicit e-mails often use this trick to keep you awake with two questions, both of which are asking whether you want to receive spam from them, one of which must be checked and the other unchecked; however, without reading them in detail you run the risk of being double spammed, hence you're kept awake and might read the rest of the gubbins the site is pushing.

The whole process by which users learn and operate software and whether subconsciously learned actions or conscious interrupted responses are being used is a topic that I think we don't pay enough attention to when designing user interfaces, and is responsible for a very high rate of so-called "computer errors," which often is a euphemism for incorrect operation. The basic assumption for any user interface should be to ask as little information as possible, to not ask questions (Jef Ruskin believes strongly in this and in having everything undoable so even if bad things happen, Ctrl+Z always undoes them), and to avoid dialogs altogether.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
JulesLt 07/10/09 04:28:00 AM EDT

I know you're suggesting modal dialog boxes are bad altogether, but a good recommendation (generally adhered to on OS X, but also backed by Joel Spolsky's User Interface Design for Developers) is that rather than Yes/No and OK/Cancel, dialog box buttons should always be verbs - Delete/Cancel, Save/Cancel.

This avoids needing to read a sentence to understand what the button may do.

But you are right - I like the idea of a system where you never 'save' and can always 'undo' - I think Etoile looks really interesting in that respect.