The User is Always Right

Sometimes, we software developers get a little arrogant. I believe everyone designs their software to be as easy-to-use as possible, but we don't always hit the mark. And when users gets themselves into trouble because of something they did, our first reaction is to blame them:

• "It's covered in the help file; didn't you read it?"
• "Don't click that button unless you know what you're doing."
• "Why did you do that?"

I found myself guilty of this recently. In Stonefield Query, you start a new project by clicking the New Project button in the toolbar and selecting the directory where the project files should go. The project files are specified in a file named SFQuery.INI, which is created after you click OK in the File dialog. Works great.



Well, almost. One developer reported an error in this process. It turns out that not only did he select the desired folder, he also changed the name of the file to something like MyProject.INI. Of course, the application is looking for SFQuery.INI, doesn't find it, and gives a warning message. My reaction (not stated to the developer; I'm not that rude) was why did he expect that to work. I wouldn't change the name of a Microsoft Word DLL and then be surprised when it stopped working.

However, we added some text to our help file documenting that the file name can't be changed so no one else would run into this. That's when we ran into Doug's Axiom of Software Development #1:

Axiom #1: People don't read.

Another developer ran into the same problem. Were these guys roommates in college? When we pointed out that this was documented, he replied that he hadn't read the documentation. Why should he -- how complex is it to click on the New button, pick a folder, and click OK?

So, we "fixed" the problem by ignoring the filename entered by the user and just used the path when we created SFQuery.INI. That's the end of that issue.

We get a call from a developer, during which Doug's Axiom #2 appeared:

Axiom #2: People aren't very good at communicating.

He said the New function wasn't working. I love that level of detail. Let's see, "not working". Does that mean you get an error message? Have to use Windows Task Manager to terminate an endless loop? The monitor shatters, flinging shards of glass into your face? Nope, it just didn't create the project. When we pursued this further, it turned out that he had typed a new filename (the infamous MyProject.INI) but when he checked the directory, no such file existed, just some other file named SFQuery.INI.

Then the light bulb came on. This wasn't the user's fault; it was mine. Why, when we wanted the user to select a directory, did we display a file dialog? The reason was that we wanted the user to see if a Stonefield Query project already existed in that directory or not; if they saw SFQuery.INI in the list of files, they'd know it did. That's not a good reason, however, so we finally did the right thing: we changed the dialog to a Get Directory dialog. Now there's no confusion about what the user needs to do.



A second example: a user complained some of his reports were missing. After some detective work, it turns out he'd deleted them by accident: he meant to edit the report but clicked the delete button by mistake. But how could it be an accident: we prompt the user with the typical "are you sure" dialog, so he must've clicked Yes to confirm the deletion. Ah, but we forgot Axiom #1. The problem is that Windows has so trained users to simply click Yes without reading the message whenever a dialog appears that it's now second-nature. There are a few possible solutions to this:

• Reword the prompt so Yes means don't delete the file. Probably not the best choice.
• Provide an undo function so the user can recover the deleted report. We'll likely do this, but that only works if the user immediately realizes what they've done. It wouldn't have helped this user.
• Make the delete function harder to select. Right now, the delete button is right beside the edit button. In hindsight, this is clearly a disaster waiting to happen. Maybe it shouldn't be in a toolbar, only a menu, since report deletion is pretty rare compared to creation or editing.

The conclusion: I need to spend more time thinking about things from the inexperienced user's perspective. And remember Axiom #3:

Axiom #3: The user is always right.

Not necessarily in how they communicate their ideas (see Axiom #2) but at least in their intent.

For other ideas along these lines, see http://www.codinghorror.com/blog/archives/000550.html.

2006 Conferences

This should prove to be a great year for FoxPro conferences. So far, I've committed to speaking at five of them:

• Great Lakes Great Database Workshop (GLGDW, aka Whilfest): my session is "Best Practices for Vertical Application Development".
  
• Advisor DevCon on Microsoft Visual FoxPro (aka DevCon): my topics are "Integrating RSS and VFP" and "Adding IntelliSense to Your Applications".
  
• Prague: no topics selected yet.
  
• Southwest Fox: I'm speaking on "Adding IntelliSense to Your Applications" and "Installing Applications Using InnoSetup".
  
• German DevCon: no topics selected yet.

In addition to these conferences, there's also FoxForward and OzFox Lite (and maybe even OzFox Heavy later this year?).

In my opinion, conferences are a great way to learn some new techniques, meet new friends, visit with old friends (and some that aren't necessarily that old), and rub shoulders (or other body parts) with some of the best and brightest lights in the FoxPro universe. The cost and time away from work are cheap compared to the benefits. You owe it to your career to attend at least one conference this year.

The Start of Something New

After thinking about starting a blog for some time, I finally got off the fence after reading Craig Bailey's call to blogging action. So, welcome to my blog. I'm going to try to model my posts after my blogging hero, Rick Strahl, who has hand-down the best blog I've ever read. So, there will be tidbits about what I'm working on, problems I've encountered and solved, interesting ideas, and so forth.