What is the best practice for gathering requirements when a customer does not know what he wants? [duplicate]

Question

Possible Duplicate:
How do you deal with changing requirements?

This question must have been asked a thousand times but there seems to be little progress in this area:

• I have asked the customer what he would like the system to do, to little avail!

• I have asked the customer about the system that the software is supposed to replace, but the system is either too complex or he does not know about the system or there is no system to replace.

• I have been through telling the customer what he wants, only to find the requirements change at a later date, etc.

• I have tried using a common language, only to realise later that the customer does not know the difference between a textbox and a label.

The list goes on and too much is taken for granted in methodologies such as DDD. I hint at this here: Which layers should reflect the domain language (if a domain language can strictly exist)?

Let's get this nailed into some kind of algorithm!

EDIT

This is the classical bad customer and is not a one that I would want.

A prevailing attitude about whether a developer should visit a customer would be considered costly. A developer is supposed write software; a day out of the office, away from development work plus expenses can often outweigh the profit on the work to be done.

You can provide mockups and wireframes but if this is not the person who is going to use the system them their input is not going to be of much use.