Make Failure Impossible

Problem: Users send malformed or invalid requests to a server or application.

Context: Users often spend time and energy in requests only to find out they failed for some irrelevant reason. This causes frustration.

Forces: Invalid requests are a waste of resources. Frustrated users are unhappy and ineffective.

Solution: Either make it impossible for the user to write an invalid request, or treat invalid requests as valid. In the latter case, create an obviously bogus result to correspond with the invalid request.

Example 1: If a field in a form requires numbers then make it impossible for the user to enter anything else.

Example 2: What you get when you fetch a page which doesn't exist either from the wiki or the web in general.

I object to identifying this as a pattern; instead, this is just good UI practice. Form input fields should always lock out garbage input so that the user can't make that kind of finger failure. This is the simplest thing that could possibly work, is it not?

Why does that mean it's not a pattern?

Technically, a pattern should describe a solution to a problem. It might embody a principle or practice, but a principle or practice alone is not a pattern. In this case IntentionallyBogusResult? would be a pattern that adheres to the practice promoted on this page.

Since FailureIsInevitable, MakeFailureImpossible is, in any case, an AntiPattern that leads to fragility.

I agree with the idea that this is just good User Interface design practice, but I don't think that precludes it from being expressed in some kind of pattern template. A quick starter for ten, that I am happy for anyone to enhance (because it is a rush-job) might be:

Name: Make Failure Impossible

Context: You are developing a User Interface and you want it to be as forgiving as possible for users (ie, you're not a sadist).

Forces:

Users often make typing errors.
Your users might not respond well / know how to respond to "helpful" error messages.

Problem: How do I prevent the users of my system from submitting information that will generate an error?

Solution: Implement features in your User Interface that make it impossible to submit information that will generate an error. Examples of how you might do this might be:

Have field level validation that prevents illegal data entry (prevent alpha in numeric fields, non-dates in date fields, etc).
Use drop down lists, multiple-select lists, radio button sets and check-boxes whenever possible, minimising the need for free format entry.

Resulting Context:

On the one hand...

There are less opportunities for a user to submit information that might result in an error.

But on the other hand...

User's may feel frustration if a field does not let them enter the data they think they want to enter unless there are other visual clues as to what is valid.

-- Matt Stephenson

Better yet, rather than to limit user input, make intelligent user input parsers. Surprisingly many users prefer a (modeless) warning and some illegal characters stripped from the input (or the closest choice automatically selected) than to be met with an error message or be denied free text editing. -- PanuKalliokoski

Can you clarify how fetching a webpage that doesn't exist returns a valid but bogus response?

I think the point is that the browser doesn't put up a unique failure UI dialog, instead it delivers an actual web page (i.e you can view source) that describes the problem and is a "bogus" response to the page request.

: Was it PaulGraham who set up the programming language used to make stores in Yahoo stores? It is an example of this pattern, in that any possible input would create a page of some type, no error messages.

Take note of the text entry facility found on any modern cell phone, Android-based devices in particular. They have spell correction that is often smarter than I am, since I can't spel my weigh out of a wet paper bag with a sharp knife. This is the kind of UI implementation that makes users curse EmbeddedSystemsEngineers a little less.

See: InteractionDesign, FailureIsInevitable

CategoryUserInterface - Category Pattern