Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Today, I came across a site where the submit button to a login form was disabled unless you have filled in the username and password. Unfortunately, I could not reall the URL, but it looked like this:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

I have also seen this pattern (or perhaps anti-pattern) being used in software installation screens:

mockup

download bmml source

From these 2 examples, the possibility of a fail state is either reduced or completely removed:

  • In the login form, the failure state where either both or one of the fields is blank will never occur.

  • In the license agreement example, there will never be a fail state.

I feel that these type of interfaces lack feedback to the user. I would prefer to let the user fail and then display a mesage to assist them to recover.

For example, in the license agreement example, if the user is not familiar with disabled buttons, he could keep clicking the button, but still find that the application is not doing anything.

Is there any rationale or reason for preventing failure states like this?

share|improve this question
5  
You should also make sure that users who have JavaScript disabled can still login -- i.e. the button starts out enabled, and a script disables it. –  Simon Richter Jul 30 '12 at 12:05
    
I feel that the title of the question is much too broad given the actual question asked. If I consider only the question body then @dhmholley has answered it all, if I ponder the title then I feel that none of the answers are adequate. –  Joshua Drake Jul 30 '12 at 13:30
    
@JoshuaDrake I agree with you; I tried to answer the question as written but there's a much longer discussion to be had about failure states in general. –  dhmholley Jul 30 '12 at 13:44

4 Answers 4

up vote 12 down vote accepted

The addition to these of a roll-over that indicates why the button is disabled would improve these, but they are common and perfectly OK, and better than allowing failure when failure just looks stupid.

Recently, I submitted a complaint to the BBC. In the process there was a drop-down response to "Have you read the details of what comes next", with Yes and No options. However, if you select the "No" option, all it does its tell you you have to select Yes. This irritated me intensely, as the above pattern would have been a better way of indicating this.

Failure has two big problems. First, it can be expensive in terms of time and resources ( depending on how it is handled ), and secondly, it interrupts the users flow of process. Disabling buttons is a good way of indicating "You are not yet ready to click this", and fits with the idea of only letting people do things that make sense.

I would prefer to let the user fail and then display a message to assist them to recover.

I think this is the core problem here. Letting the user fail is usually wrong - it often ends up (as it would in these scenarios) as very patronising. Guiding the user to success is a far better approach, and normally ends up being supportative. If the computer knows that I shouldn't be able to click "log in" yet, why does it let me? The answer is usually "You hate me", in some form, which does not give a good impression.

share|improve this answer
    
+1 To addition to these of a roll-over that indicates why the button is disabled. It's extremely annoying when buttons are disabled as you can't figure out why. –  Brendan Long Jul 30 '12 at 14:39
    
The roll-over idea is a great suggestion and provides some feedback as to why the form can't be submitted. +1 :) –  F21 Jul 31 '12 at 4:46
    
Do note that roll-overs are not always the best idea. But something to indicate why the button is disabled would make all of the difference. If you are not using JS, then a permanent message would be as good. –  Schroedingers Cat Jul 31 '12 at 7:56
    
Also, roll-overs don't work on touch devices. –  André Jul 31 '12 at 8:55

I would prefer to let the user fail and then display a mesage to assist them to recover.

What purpose does failure serve?

The only reason you would want to deliberately allow someone to fail is so they can avoid it in the future. But if you can remove failure entirely, why is the learning process necessary?

I don't believe that making users feel like they are stupid (and failure always does this, unless the user can blame the system - an equally undesirable outcome) is ever a desirable thing in UX design. Failure and recovery are unnecessary steps towards a user completing their goal, so why have them at all?

The rationale for preventing failure states is that they are irrelevant to the user, hinder their progress, and degrade their experience by either insulting them, making them feel inadequate or making them feel like they're fighting against the interface.

The question only remains as to whether it is possible to avoid all failure states. Maybe this is not the case for certain applications given other constraints - and in that case, perhaps learning to avoid failure by failing might be useful. However I don't believe that we need to accept failure as a part of every process.

To deal with your example specifically - the reason that it is a bad example is that it substitutes one failure state for another. If you were worried that users would fail by clicking on an inactive button, remove the button and find a different control that works. Hell, don't have an "I agree" checkbox at all - just have a button which does performs the whole action.

share|improve this answer

Since there are several "layers" of error-prevention and feedback-loop, there isn't any single answer to your question.

You need to consider each issue individually and choose the appropriate error prevention / feedback model. (Yeah. And you should also consider each issue to each other.)

Error prevention:
- Hide option
- Disable option
- Enable option (and raise an error)
- Enable option (and ignore consequences)

Sometimes it is appropriate to actually hide input fields, menu items and buttons, but in other situations it is better to show the UI elements, but to disable them. If they are visible and disabled, it must be clear why it is disabled. If that's not clear, then it might be better to enable the UI element and give a proper feedback if the users uses this.

The "Print" action is an example of an action that could be enabled, and give error message if there is no printer available.

The "Cut" and "Copy" actions should not be enabled all the time, only when you have chosen something you actually can cut/copy.

"Table tools" and "Image correction tools" etc should only be visible when you are actually working with such an element.

Feedback:
- Passive feedback (hint/instruction)
- Immediate feedback (timely hints related to what you're doing)
- Interruptive feedback (dialog that interrupts your work-flow)
- Batch feedback (Submit info and get feedback on everything)

Sometimes it is enough to just give some discrete hints or instructions. "Fill out every field marked with *)" or "No decimals needed". But in other situations, it might be nice to give a clearer message to the user, but avoid to interrupt the work-flow. Eg. invalid e-mail or invalid social security number. The important issue here is whether the information is helpful to the user at that moment, and not a disturbing element. You can validate on field exit or while the user is editing. It depends. Event the latter one can be aggressive or subtle. If you enter an e-mail, there is no need to yell out "invalid e-mail" right after the first character is entered, because the user will probably fill in the rest of the e-mail address. You could wait until you know that the e-mail really will be invalid. Eg the moment he enters two @'s or an invalid char.

For some situations (especially intersection validation), it might be better to let the user complete the form and submit the form and then provide a proper list of errors.

share|improve this answer

Just like any other decision, I would ask myself what I had to gain from allowing an action to fail as opposed to recovering from it automatically or preventing it in the first place. In this case, @phpdev answered it: letting the user know what they were missing.

This becomes your new problem. It is no longer about letting failure happen or not, but about guiding the user through the process.

Anyway, now that you have identified what your true intent was, address that new problem. Solutions might involve watermarking Required in your input fields or putting a red asterisk next to them, or simply writing "Enter your username and password to login" somewhere on your form, etc.

Preventing failure is usually preferred whenever possible, and automatic recovery is very good if there is no ambiguity in how to recover from the error. Errors are time/resource-expensive and very annoying to the user. In a lot of cases, I ask myself why the system allowed me to go through if it already knew I had done something wrong, and how come it didn't warn me beforehand.

One problem not to be overlooked with throwing errors in web forms is the potential loss of data when returning to the screen due to improper view state management, etc. Stopping errors as soon as possible obviously reduces your code's surface area.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.