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:

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:

Resulting Context:

On the one hand...

But on the other hand...

-- 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

EditText of this page (last edited February 15, 2013) or FindPage with title or text search