I'm a dad. One of the things I really enjoy about that is getting to watch my son figure things out (he's 20 months old at the time of writing). Often, there comes a time when he almost has a toy apart – or back together – but can't quite push through. At this point, I'm torn. The problem solver in me wants to let him figure it out on his own, instill that drive in him that will make him tear his hair out solving software problems for the next 50 years. The compassionate dad in me wants to run to his aide and fix the problem, averting further frustration and potential tantrums. In the end, I usually try to divert his attention while fixing the problem with some sleight of hand, making him think he figured it out on his own.
Just recently, I've been thinking of the same situation, except this time substituting father and son with software and the end user. We often focus so much attention on documentation and error messages, when in many cases we can intelligently and transparently guess what the user is actually trying to do and avoid an error altogether.
Sounds good. Example?
In the few weeks since the Koken public beta was launched, our installer has been getting rave reviews for its simplicity. However, the one issue that has surfaced almost daily is confusion over database connection information. Koken requires the hostname, database name, username and password for the database. Our users are a mix of web developers and photographers DIYing their site. For those who don't do this sort of thing every day, navigating through a host's control panel looking for MySQL information is not the easiest thing in the world.
In the end, most people are able to find the database name, username and password. The hostname is often confusing though, and many users simply put their own domain there, which is almost always wrong. Their next step is to fire off an email to us that usually goes like this:
User: MySQL info not working. Help!
Us: Try "localhost" for your hostname.
User: Thanks, that worked!
I bet I get one of those a day. You see, a large number of shared web hosts have MySQL setup on localhost, so in almost all cases where the user doesn't know what to input, localhost is the answer.
As I started thinking about what to do, my mind immediately jumped to bandaid solutions like documentation, or a better error message suggesting they try localhost. But then it hit me: instead of suggesting, we should just immediately try the connection again with localhost as the hostname and if it connects, simply use that. The user never knows. No frustrations. No tantrums.
So next time your dealing with a common user error in your system, ask yourself if there is a way you can fix it in code, automatically and transparently. Your users will love you for it, and they won't even know why.