Things I’ve Learned From Users

Remember Fernando, Billy Crystal’s character on Saturday Night Live back in the 80’s?

“It is better to look good than to feel good,” was one of his catchphrases. Another one was, “You look mah-vel-ous!”

I try to make my apps look mah-vel-ous, always trying to conform to Windows standards, and always trying to keep one eye on the future. I don’t want my app to look too outdated when a new version of Windows (or Office, or “insert any other mah-vel-ous looking app here“) is released.

A few years ago (think Office 97), I developed a bad habit of creating wizards for almost any activity you could perform in my apps. They looked modern (if your users had Office 97), and it was an easy way for me to dictate how the user used the app (remember this line, it haunts me daily).Want to add a new customer? Try the Add a New Customer Wizard. It’s really cool! And, most of all, it looks mah-vel-ous! Want to pack and reindex your tables? Try the File Optimization Wizard (I’m not kidding)It’s so cool, and easy to use! And, most of all, it looks mah-vel-ous!

You want gradient-looking forms? Sure, I can do that.

Smooth, animated controls on forms? I can do that, too.

Want the app to look as if it were a web page instead of a desktop app? Thanks to Rick Strahl, I can do that, too.

Want that “Longhorn“ feel? Yeah, I can do that, but it’ll cost extra. And you better quadruple my original time estimate to calculate the delivery date.

When I show my work to (some) other programmers, or people who use computers daily and are very knowledgeable about Windows and apps in general, they sometimes say, “Kev, that looks really good.“ On occasion, I might even get a “You can do that with FoxPro?“

But for every one of the “knowledgeable“ folks, I know a hundred people who have to use a computer for their work, but otherwise they’d like to throw the computer out the window. Most of the times I’ve been to client sites to see my app in action1 I get bombarded with questions and suggestions about the app. Some of the suggestions involve me jumping off a very high bridge and taking that stupid computer and piece of crap software with me.

“Piece of crap? But it looks so good!“

Client-site visits can be a wonderful resource, as long as I wear my Teflon suit (sometimes I can take criticism a bit harshly). Most of the time my role is typically designer, developer, tester2,debugger, documenter (does anyone really ever read the help files?), and deployer of the apps. With that much investment in the app, it can be tough to hear something critical about it. But the client-site visits are most informative when I actually listen to what the client has to say. Here’s a few bits of wisdom I’ve picked up from my “not-so-knowledgeable” customers:

  • They don’t care how it looks, they want it to work.
  • They don’t care how it works, as long as it is efficient and intuitive.
  • They don’t like it when apps intimidate them.
  • They don’t like to be taunted by an app with “You shouldn’t have done that, you big dummy!“ messages.
  • They don’t care if I use Collections, Arrays, or a combination of both.
  • They don’t care if they deleted the export file your app created for their accounting software after they purged the data from your app and before they imported it into the accounting package. They just want to get the data back — easily — so they can do the export again. And again, they don’t want to feel like a big dummy because they deleted the file.
  • If your app works 999 out of 1,000 times, users believe the app is a “piece of crap.“
  • They really don’t read the help files.

Hmmm. Maybe Fernando was wrong. Just because it’s pretty doesn’t make it good.

1 In case you were wondering, seeing my app in action means the users have had repeated problems I’ve been unable to recreate in-house, so I need to go show them the “proper” way to use it – remember the dictate how they use it line earlier in the post? I’m telling you, that one haunts me every day.

If you work as the sole tester on your own apps, you are doing a grave dis-service to yourself and your customers. Testing your own work exclusively guarantees that at least one user will use the dreaded “piece of crap” phrase when describing your app. It can also subliminally force you into dictating how the users use your app.

When Do You Say Your App Is “Not Supported”?

Do you develop your apps for the least common denominator, or do you provide a set of absolute minimum requirements that must be met in order for your users to install your app?

I have an app that is installed in roughly 750 locations. Of those, nearly two-thirds of the users are still running Windows 98. Naturally, whenever I work on enhancements (and bug fixes) for this app, I have to develop to the least common denominator (in this case, Windows 98). As you can imagine, with the hardware for most of these users I also have to be careful about memory, hard drive space, and dial-up connectivity versus cable/dsl.

Some developers I’ve worked with insist that the absolute minimum OS for their software is Windows 2000, preferably Windows XP, and even more preferably, Windows XPProfessional. I dunno. If I took that approach, I’d lose over 500 customers for this one app alone.

On the other hand, dropping support for the app on Windows 98 would save me a ton of time on testing… One less OS to worry about. And I have to admit, sometimes it would be nice to say, “You’re running Windows 98? Sorry. Not supported on Windows 98.”

When I look at Microsoft’s Product Lifecycle dates, I see that “Paid incident support is now available through 30-Jun-2006” for Windows 98, and I wonder if I should follow the same type of path with the apps I’m developing today.

Do you use Microsoft’s Product Lifecycle in determining your minimum requirements, or are your minimum requirements simply based on what’s needed by the individual app?