By Peter Kent
Something irritating just happened while I was working with Windows. (Yes, yes, I know, I can hear you Mac lovers saying "working with Windows is always irritating," but that's not my point.)
I was writing an e-mail message in one program, while my Web browser transferred a file in the background. All of a sudden a small dialog box opened. But I was still typing; the box appeared, and a split second later, before I had a chance to realize what was going on, I typed something that activated a button on that dialog box, closing the box!
What was the box? I figured out it must have been the box that appears at the end of a file transfer from the Web, the box that asks if you want to save the file even though it hasn't been digitally signed and could contain viruses.
And I'd just canceled the dialog box -- the default button was No, so when I typed the letter N, or perhaps pressed Enter, the dialog box closed.
Now, I find two things interesting -- and irritating -- about this. First, this is quite common. I've run into a lot of programs that will run in the background, then pop up a dialog box, one that can be keyboard activated, while the user happens to be doing something else. And the second thing is that I can't possibly be the only person to have realized that this is shoddy programming, yet it's still very common.
For instance, I use Schedule+. Each time this program informs me of an appointment, it opens a small dialog box. And if I just happen to be typing in another program at the time (this is, after all, a multi-tasking system, isn't it?), that dialog box may be closed. Sometimes it's closed for good because the Don't Notify Me Again option button is selected. But as it all happens so fast, I don't know what the appointment was, and I don't know for sure if it's been reset to inform me later or never will reappear.
Or consider Dial-up Networking. I start my Internet connection, then go to work in another program. At the moment that Dial-up Networking completes the log-in procedure it opens a dialog box; and if I happen to be typing at that very moment, the Disconnect button is activated, closing the connection!
It seems a simple concept to me; you don't allow a dialog to be activated by a simple keystroke if that dialog box may open at a point at which the user may be doing something else! Yet it's a concept that many programmers don't seem to understand.
Which brings me to another point. Why is it that programs often include "features" that appear to users to be quite obvious program flaws? Not only that, how do these "bug-like features" remain in the program, version after version after version. I'll tell you how. Because all too often programmers and software companies spend very little time listening to users.
This may be hard to believe (on the other hand, consider all the software you've used; maybe it's not quite so far fetched). In this age of "customer is king," surely these people and companies can't ignore their clients? Well, I've been working with software development teams for about 14 years now, and believe me, they do. In fact many programmers have a "we know better than the user" attitude. All too often products hit the market with virtually no testing, and publishers are surprised when users don't like the program, or like it in general but point out some serious flaws.
What about beta tests, though? Beta tests are generally little more than a joke. Here's how they work. First, keep users away from the program for the first year or so of the development. Then, a couple of months before the release date (which is already six months later than the original scheduled release date), send out a couple of dozen copies to users.
Don't give the users any instructions or advice. Make it hard for your users to respond with problems they find -- provide them with a large and complicated form that must be filled in for every single bug encountered. Don't bother providing an e-mail address that users can respond to. Better still, don't provide any contact information whatsoever (no, really, I've received beta software without any information about how to deliver my bug reports).
Then sit back and wait for responses from your beta test. Don't follow up. Don't check to see if anyone actually has installed the software, or try to encourage them to send in bug reports. Just sit and wait.
Of course a few responses will dribble in. Unfortunately many of them will be related to problems that should have been fixed long before the software ever went to beta, obvious bugs or usability problems so glaring that any user would notice them right away. But you didn't bother talking to users until the beta, remember, so you've wasted a few months programming features incorrectly.
It's also unfortunate that it's too late to fix these problems now. You are so close to release that none but the most serious of problems can be fixed. Never mind, you can start work on those problems once the software's released, for Version 2. Of course you'll be adding lots of new features to Version 2, but you can have those checked out during the beta test ... no need to get users involved too early.
Think this is an exaggeration? Just talk to people involved in software development, the programmers, technical writers, technical-support staff, and so on. Or simply take a look at some of the shoddy software you've been sold over the last few years. What other system could deliver so many bugs in such a short time?
Peter Kent is the co-author of the Official Netscape JavaScript Book (Netscape Press). He can be contacted at geek@topfloor.com.