Hide full article
In part one of this article (see TidBITS-395), I introduced my list of seven "Ps" that shareware authors must consider when creating and marketing their products, and talked about the first two: Product and Patience. This week's installment covers the extremely important third P, Polish. Next installment I'll hit the last four Ps: Pay Up, Propagation, Promotion, and Politics.
The Third P: Polish -- "The first 90 percent of the job takes 90 percent of the time, and the last 10 percent takes the other 90 percent." It's true - when the programming's done and all the features work flawlessly, you're not nearly done preparing your product for release.
Another great quote is "Sweat the details." Tiny details matter more than many programmers think. Your potential customers want to have confidence in your product. The more flaws they perceive, the less likely they'll be willing to pay, even if the product performs perfectly. That may not be rational, but it's true.
So what kind of details are we talking about?
Make It Pretty -- People are more willing to buy a product that looks good. Prettiness is not a substitute for robustness or functionality, but the better looking your product is, the more copies you will sell.
If you are not artistically inclined, then find someone who is. Talk a friend into doing your graphics for free, or hire someone you can afford. A tasteful splash screen, a spiffy logo, cool icons, and button labels go a long way toward a good impression. Every time I've improved the appearance of Solitaire Till Dawn I've had a big jump in sales, and I don't think it's a coincidence. Pretty pays!
<
http://www2.semicolon.com/Rick/STD.html>
Human Interface Guidelines -- Every platform - Mac, Windows, Unix, you name it - has a "style." The Mac especially has a reputation for a completely consistent user experience, due to Apple's early publication of its Macintosh Human Interface Guidelines. These guidelines specify in detail where icons and buttons should be placed, how large these elements should be, how much white space should surround them, the proper use of color, sound, and much more. This is why, in every application, you find the commands such as Quit, Print, and Open in the same place, with the same names and the same keyboard shortcuts. Most Mac developers have learned not to mess with these commands, because Mac users turn their noses up at applications that get the Human Interface Guidelines (HIG) wrong. But there's much more to good human interface design than those obvious points.
HIG: Lay Out Dialogs and Alerts Carefully -- Many programs have cluttered, crowded windows. Users prefer windows with only a few controls and plenty of white space. Controls and displays should be carefully organized: related controls should be together, perhaps grouped and separated from unrelated controls. Align checkboxes and buttons so your layout doesn't look sloppy. Place common elements consistently - the OK and Cancel buttons should be in the same place in all dialogs.
If you have too many controls, consider using swappable panels or some way for the user to select a category of controls so that the window displays only those controls and hides the rest. This technique lets you cram many controls into a small window without crowding. Look at Netscape Navigator or Eudora for examples.
HIG: Avoid Dialogs -- The fewer modal dialog boxes you present, the better. They interfere with the user's workflow (or "playflow"). Often they report error conditions of various sorts, so a good way to eliminate them is to reduce the number of possible errors that must be reported to a user.
A good example of bad dialog use is a solitaire game I once saw. To move a card, you first had to click it. Then you had to click the place you wanted to move it. If you clicked on an illegal destination, you saw an alert dialog, telling you that you couldn't make that move. Worse, if you clicked a card you wanted to move, then changed your mind, there was no easy way to cancel the move. You had to click someplace illegal, suffer the alert, and dismiss it before you could try to move a different card.
A better interface is to have the user drag & drop the card over the intended destination. When you release the button, the card drops. If the card is not dropped over a legal destination, the card quietly zips back to its starting point, and the user can try to move something else immediately. An improvement would be to have legal destinations highlight as the card is dragged over them.
If you can design your interface so the user can't make mistakes, you'll eliminate a whole class of user annoyances and avoid writing lots of boring dialogs.
HIG: Too Many Options Are Bad -- Whenever you have to decide whether a feature should work this way or that way, the temptation is to make it work both ways and give the user the choice. Sometimes this is the right thing to do, but too many options frighten users. Most people want programs that are simple to understand and use. Anything that looks too complicated will be tossed in the trash.
So how do you minimize options? One way is to ask yourself how many people will need the choice. If 90 percent of your users want the feature to work the same way, you might be better off hard-coding it that way and letting the other 10 percent be frustrated.
Sometimes options can be hidden. Peter Lewis's FTP client Anarchie puts up a progress window during file uploads and downloads. The window shows progress in a variety of ways, including a numeric estimate of how much longer the operation will take. Some people, however, prefer to know how long it's taken so far; others want to know what time it will be done ("5:35 PM" instead of "twelve minutes from now"). Peter could have put all those indicators in the window, but that would have made a huge, cluttered, unreadable display. He could have put the options in a Preferences window, but that would have resulted in a complicated interface. His solution was simple and effective. When the user clicks the numeric readout, it switches to an alternate form. Click again, and see a third form. Click again, and you return to the first. Power users learn about this by reading the documentation or the online Tips, but users who don't care may never realize that the feature exists.
<
http://www.stairways.com/anarchie/>
Sometimes, options are the wrong solution to a problem. A utility of mine, The Tilery, lets you switch among open applications by clicking tiles. When you click a tile, The Tilery comes to the front, as all applications do when their windows are clicked; it then immediately tells the operating system to bring forward the selected program instead. The Tilery winds up as the second-to-frontmost application, right behind the one whose tile was clicked. This is fine until the user decides to quit from several applications at once by pressing Command-Q repeatedly. When the frontmost application quits, the next in line - The Tilery - floats to the front. But because The Tilery doesn't look like a normal program, users tended to forget that it is, so when they press Command-Q again, they quit The Tilery (which in most cases isn't what they intended). Very annoying, and I used to get a lot of mail about it.
<
http://www2.semicolon.com/Rick/Tilery.html>
My first solution to the problem was to provide an option to have The Tilery ignore Command-Q (so you had to choose Quit with the mouse). That solved the problem, but in the wrong way: The Tilery would still quit unexpectedly unless you set that option. You had to read documentation to find out what the option was for, and the menu item that controlled it contributed to the apparent complexity of what should be a simple utility. Also, the basic problem still existed: The Tilery wound up frontmost at unexpected times.
The real solution was to keep The Tilery in the background until and unless it is deliberately brought forward. It took me a while to figure out how to do this, but the result is a great improvement. (Confession time: the old Ignore Command-Q option is still in there, because it was an established part of the user interface by then. The new feature brought options of its own, so the options interface is now even more cluttered. But at least the right problem is being solved now!)
HIG: Organize Menus Carefully and Sensibly -- Users shouldn't have to hunt through a maze of menus and sub-menus to find a command. Menus should be organized in a sensible, intuitive fashion. Examine each command's function - does it belong under File or Edit? If it's a command with a host of sub-commands, consider making it a new menu instead of creating hierarchical menus. This isn't always as easy as it sounds, but "sweat the details" and try to design a set of menus that is clean, simple, and elegant in its layout and wording.
The list of human interface details to attend to can seem endless. One source of good feedback is your beta team; after you ship, users are another. They'll tell you what works and what doesn't - not just bugs, but interface subtleties, too. Your job is to listen when they talk.
Spell Stuff Rite -- Good spelling and grammar are vital. All text that you display to your users, whether it's in the manual or an alert box or a menu, should be properly spelled and grammatically correct. It's part of the overall impression your software makes on every potential customer: the fewer flaws they see, the more confidence they'll have in your product.
If you're not good at spelling and grammar, find someone who is and beg or hire them to review and correct your work. Use spelling checkers if you like, but remember that a spelling checker won't tell you that you should have written "lose" instead of "loose" or that "its" should not have an apostrophe when it's a possessive. You may not think these fine points are important if you don't notice them yourself, but plenty of your users will, including reviewers. [We editor types cringe when we see these basic mistakes, and believe me, they happen even in big commercial products. -Adam]
Documentation -- A well-designed application may not need much documentation; it may be obvious how it should be used. Users never bother to read manuals anyway, so why waste time writing them, right? In fact, many users do read manuals, and I presume you at least want them to read enough to know how to send you their payment!
Knowing how to write a good manual is a career in itself; plenty of people make their livings doing it, and I can't teach you the art in a few paragraphs. But I can give you a few useful tips.
Unless your product is dirt-simple, you should ship it with both a short ReadMe file and a separate, comprehensive manual. The ReadMe should be a text document that briefly covers the following points:
- Product name
- Version
- Ship date
- Company name
- Author name
- Description (the "elevator presentation" - see TidBITS-395)
- What's new (list of fixes and new features, if an upgrade)
- Requirements (Mac, system software, RAM, monitor bit-depth, etc.)
- Price
- Payment instructions
- Copyright
- Distribution information and restrictions
- Contact information (email, Web site, postal address, fax, phone)
Nearly everybody who might care about your product will want that information, including users, reviewers, and people who want to put your product on their Web site or CD-ROM. They'll be frustrated if it's missing, scattered, or hard to find. Put it all into the ReadMe file, and keep it short and to the point. See Tonya's article on ReadMe files in TidBITS-330 for a good discussion of this subject.
Before you begin writing your manual, think about how users will want to use it. Few will read it front to back before trying your product. Most will refer to it later, when they encounter something they don't understand, or can't figure out how to do something. To help these people, organize your manual in those terms. Instead of documenting every menu command in order, have a chapter labeled "How to..." Include a "Troubleshooting" chapter organized so that readers can look up problems and find solutions easily. After you've released a few upgrades, you'll know the most common problems. In your first release you'll have to guess.
The first chapter should explain the rest of the manual and mention what each chapter covers, so users can quickly find what they need. Use diagrams and pictures, which work better than text for explaining visual concepts.
Use any medium you like for your manual, as long as every user can read it. Don't ship your manual in Microsoft Word format, for example: far too many users won't have Word. A variety of ways exist to create stand-alone documents that can be displayed and printed on any Mac. If nothing else, save it as a text file.
Also consider online help. There are a bunch of ways to do it, but again, the key is organization: the way you see your product is different from the way the user sees it. The user will be wanting answers to questions such as "How can I..." and "Why can't I...", and your online help, like your manual, should be arranged so that users can find answers quickly.
[In the next installment, Rick will discuss the final keys to shareware success.]
[Rick Holzgrafe has programmed for a number of well-known Silicon Valley firms when he's not crafting shareware products.]
