Things software developers should do right rather than wrong.
After almost 30 years of software engineering experience, I'm now on the other side of the fence: my business is Macintosh training and support.
I now see how normal people think. As software engineers, we don't think like others — many of us never realize this. I don't want to hear that these problems give me job security. It's that kind of attitude that causes them in the first place.
I may even name a few names here. If you're unhappy finding yourself here, then fix your software. Change your ways.
Installers That Don't: MacOS X has been out since March 2001, so it's high time people get their installers working properly. Many installers simply fail when trying to install for Classic (e.g. some Epson printer drivers).
Other installers don't have a clue about administrator privileges.
Even dumber are the installers that ask for the administrator password, then fail some distance into the install process.
For a while, Palm Desktop was in the latter category. It only worked properly when you were logged in as the administrator. Authorizing didn't work for non-admin users. Bzzzt. Fix it.
When the installer fails after getting started, what is the state of the system? Have all files been installed? Some? None? A failed partial install can be a terrible situation to fix.
Why Does This Happen? I see two major reasons: First, many developers don't want to write an installer, so they buy one from a third party, like VISE from MindVision. (I think little is MindVision''s fault: I expect they fix bugs quickly.) But do you as a software vendor (e.g. Epson) use the latest version of the installer? Take the extra time to check that you have a good installer. Make sure your installer scripts are right. Occasionally, there will be cases where the shipped product contains a buggy installer. So tell us on the web site, and help us get through the process.
Second, not enough configurations are tested. I know it's impossible to test every possible configuration, but there are some simple tests that would work. Start with a clean system install and test the installer. Make a non-admin user for the test. Try several versions of the OS, to ensure that everything looks normal. Trying a reinstall is absolutely essential; people do this all the time, and they sometimes have removed some of the files.
Software development doesn't end when you hand something off to the folks responsible for packaging it for distribution. Installer failures are the cause of lots of hardware being returned to retailers, and thence back to the manufacturer. If you want to improve your company's bottom line, make sure your product's software installs properly on most systems.
Reinstalling: While trying to install Canon's digital camera software after a clean-install of MacOS 9.1, I found the installer had failed to put any files in the system folder. Why? The installer checked for the presence of one or more of the applications and simply assumed everything had been installed.
Moral: If you need a file installed to operate, make sure it's really there. Check its version if that's important. If I had not been there to diagnose the problem, the user would have simply been out of luck.
Warn Of Existing Files: I had a recent situation where the OS X printer driver for a Primera Bravo CD duplicator stopped working, and the client tried to reinstall it. The installer simply said there was an error installing: no details at all. He then tried removing all the applicable files he could find. Did Primera provide an Uninstall option? Of course not.
I finally found that he'd missed either a preference (plist) file or something in the Application Support folder (I forget). Once I removed that file, the install proceeded normally and things returned to normal.
Had the Primera installer warned "I found this and this file..." I would have immediately known to delete them. Better yet, had they taken the time to provide an Uninstall option, that would have taken care of deleting all the appropriate files.
Install Everything: A CD install of Final Draft 6 said it was going to install a new version of CarbonLib on a 9.1 system. After the FD6 portion of the install completed, however, the old version of CarbonLib was still present; it hadn't been replaced. As as result, the first launch of FD6 crashed immediately.
Could an unsophisticated user have figured out this problem? No. I found Apple's CarbonLib installer on the FD6 CD, ran it, went through the required restart, and all was fine. The FD6 folks get extra points for at least telling us about the intended CarbonLib install. Without that important tidbit, troubleshooting could be more difficult.
Keeping It A Secret: Many of the error messages that come up on an install failure are downright useless. When Epson fails to install for Classic, often the error message complains about the lack of permissions for some folder. What folder? An HP upgrade installer merely said something like "The required location cannot be found." What location? Why is it required? HP tech support advised us that the installer was an upgrader. Once I knew that little fact, it was obvious that the install would fail, because the original software had not been installed. But why should I have had to call (and wait on hold) in the first place? Hint to HP: You'll save money on tech support if you improve the installer messages.
Moral: When an error occurs, give enough information for someone to figure out a solution. Even if a user is unable to solve the problem, at least he/she can read the error message to a professional. Stop assuming that everyone will know what happened.
Ever Need To Verify? Windows has a mechanism to verify the installed copy of a file against the original (usually on CD). Why don't we have this for the Mac? How about an installer option that simply produces a verification report? Every file that would be installed is checked for presence and a checksum or content match. This option would save a lot of time, eliminating guesswork as to what might files be missing or corrupted.
Nobody wants to make this better because it isn't leading-edge science. It isn't interesting. It isn't prestigious. It isn't cool. Don't simply throw the product to a summer intern and say "Do the Installer." Make the installer as important as the product, because it must deal with a large number of system configurations and installation options.
Don't limit testing to software professionals. They immediately realize "Oh, I know what I did." The instant that happens, it indicates the need to inform the user about the error in detail, so that a support professional can effect repairs. Don't simply shrug it off and continue testing. Report this situation as a bug that needs fixing. I'm sure that if Steve Jobs' mother runs into problems, people will fix things immediately or be cleaning out their desks.
Invisible Commands: I've seen several examples of programs that simply hide commands and settings when you're not in the right mode. Microsoft Word 98, for example, has a Style Area that can be shown when in the Normal View mode. Unfortunately, the preference to change the width of the Style Area (and make it invisible by using a width of zero) is completely missing from the Preferences dialog unless you're currently in Normal View.
Why couldn't they simply gray-out the field? Don't blame it on Microsoft: they don't have a lock on doing this. (This has been fixed in Office X, and probably in an earlier version.)
Moral: If the user can't do an operation in this mode, gray it out. It's very useful to know that something is possible, even if it can't be done at this time.
Multi-Purpose Buttons: I'm sick and tired of buttons that change meaning based on what mode you're in. You've seen it in iTunes and many audio applications: The Play button changes to a Pause button when the audio is playing. Then it changes back to a Play button when you stop playback.
In most cases, there's plenty of room to have separate buttons.
People often confuse a button with an indicator. "Does that mean I click there to play, or does it mean it is playing?"
User Interface From Jupiter: The HotBurn CD-burning software from IOMega is a spectacular example of a user interface from Jupiter. What are you guys thinking? Were you thinking? If you can't make a user interface follow the Macintosh style, at least make it look like Windows. Those are the two predominant styles on this planet: use one or both of them. If you like alien-style "skins" on programs, put them on your own personal programs: don't inflict them on others.
|
