Have you ever appreciated that a cash machine will return your bank card and insist that you take it BEFORE it will give you any money?
This is a very deliberate design decision which perfectly illustrates this design pattern.
This pattern says you should do absolutely everything you have to get done in order to achieve your complete your Primary Objective - particularly with users.
Oops, forgot to take my card
Back in my uni days when I still worked at Pizza Hut, I used to bank with the Halifax who had a crusty old ATM machine. It used to give you your cash before your card, and I made the classic mistake - walked away with my cash and not my card. My experiences help me to understand the consequences of the subtle reordering of the process made my newer ATMs.
The essence of good usability design is to create solutions that do not allow users to make mistakes. In the ATM example, I would have to take my card and then drop it or hand it to a stranger to actually lose it.
Programs that Fall at the last fence - you were robbed son!
This design pattern is relevant at many different levels. Not only at the interface level, but also when designing and writing good code.
There is nothing worse than complex operations failing due to trivial peripheral logic. For example:
A valid solution to our Meaning of Life program goes like this:
In this case it would be worth loading the config file first just in case it was going to fail, prior to starting work on our Primary Objective.
Call it Defensive Programming, or just common sense but this lesson is often learnt The Hard Way.
If you have long running processes or business critical logic these can be easily thwarted by badly arranged logic that falls at the last fence.
In summary: If it is really important, make sure it is done last.
Other examples of Primary Objective Last
This is a very deliberate design decision which perfectly illustrates this design pattern.
This pattern says you should do absolutely everything you have to get done in order to achieve your complete your Primary Objective - particularly with users.
Oops, forgot to take my card
Back in my uni days when I still worked at Pizza Hut, I used to bank with the Halifax who had a crusty old ATM machine. It used to give you your cash before your card, and I made the classic mistake - walked away with my cash and not my card. My experiences help me to understand the consequences of the subtle reordering of the process made my newer ATMs.
The essence of good usability design is to create solutions that do not allow users to make mistakes. In the ATM example, I would have to take my card and then drop it or hand it to a stranger to actually lose it.
Programs that Fall at the last fence - you were robbed son!
This design pattern is relevant at many different levels. Not only at the interface level, but also when designing and writing good code.
There is nothing worse than complex operations failing due to trivial peripheral logic. For example:
You write a program to computer the meaning of life, the universe and everything. In fact it will email you the answer when it has computed it. It reads your email address from a config file.Are you one step ahead? If you are familiar with Murphy's Law you'll know that Anything That Can Go Wrong Will Go Wrong. And it does.
A valid solution to our Meaning of Life program goes like this:
1. Compute the meaning of life, the universe and everything (tricky, may take a while)Any problems encountered whilst reading the config file (stage 2) could give us an output of "error - file not found" Boy would you be pissed!
2. Read email address from config file
3. Send email containg The Ultimate Answer
In this case it would be worth loading the config file first just in case it was going to fail, prior to starting work on our Primary Objective.
Call it Defensive Programming, or just common sense but this lesson is often learnt The Hard Way.
If you have long running processes or business critical logic these can be easily thwarted by badly arranged logic that falls at the last fence.
In summary: If it is really important, make sure it is done last.
Other examples of Primary Objective Last
- Vending machines - you pay BEFORE you get your item.
- Data Collection during online shopping - your details are collected prior to paying.
- Estimatation process - don't give an estimate until you've had all your questions answered.
94 comments,
Patterns, Tuesday, September 27, 2005 02:05
