Successful Shareware Successful Sharewareby Rick Holzgrafe
of
Semicolon Software
"The first 90% of the job takes 90% of the time, and the last
10% takes the other 90%." Ever heard that one? It's true -- when the
programming's done and all the features work flawlessly, you're not nearly
done preparing your product for release.
I think a better 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 can see in it, the
less likely they'll be willing to pay, even if the product performs its
job perfectly. That may not be rational, but it's true.
So what kind of details are we talking about?
This one took a while for me to learn: people are more willing to buy
a product that looks good. Prettiness is not a substitute for robustness
or functionality, of course. But the better-looking your product is, the
more copies you will sell.
The best advice I can give you here is that if you are not an artist (and
especially if you don't have much taste) then you had better find one. Talk
a friend into doing it for free, or hire someone you can afford. A tasteful
splash screen, a spiffy logo, cool icons and button labels all go a long
way toward making 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!
Every platform -- Mac, Windows, Unix, you name it -- has a "style."
The Mac especially has a reputation for a completely consistent user experience:
in every application, you find the commands for Quit, Print, Open, Save,
Cut, Copy, Paste, Undo, and many others in the same place, with the same
names and the same keyboard shortcuts. Most Mac developers have learned
by now not to mess with those, because Mac users will turn their noses up
at any application that gets them wrong.
But there's much more to good HI (Human Interface) design than those obvious
points. For example:
Lay Out Dialogs and Alerts Carefully -- Many programmers create cluttered,
crowded windows. Users prefer to see windows with only a few controls in
them and plenty of white space all around. What controls and displays there
are should be carefully organized: related controls should be together,
perhaps with a box around them to group them and separate them from other
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 pretty much the same place in all your windows. If
you display an icon ("Stop," "Warning," "Note") put
it in the same location in all windows, and so on.
If you simply have too many controls, consider using swappable panels: 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 a lot
of controls into a smallish window without crowding. Have a look at Netscape
Navigator or Microsoft Word for some examples.
Apple Computer has published Human Interface Guidelines for Macintosh authors.
These Guidelines specify in detail where icons and buttons should be placed,
how large these elements should be, how much whitespace should surround
them, the proper use of color and sound, and much more. Although they are
intended specifically for Mac programmers, the advice is good and much of
it is applicable to any platform.
Avoid Dialogs -- The fewer modal dialog windows you present, the
better. They interfere with the user's workflow (or "playflow").
Often they are used to report error conditions of various sorts, so a good
way to eliminate them is to reduce the number of possible errors that need
to be reported to a user.
A good bad example is a solitaire game I saw once. To move a card, you first
had to click on it. Then you had to go click on the place you wanted to
move it to. If allowed by the game rules, the card would then make the move
to the new location. Sounds simple, but it was annoying to use. If you clicked
on an illegal destination, then you got an alert window in your face, 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 in your face, and dismiss
it before you could try to move a different card. Most annoying was when
you forgot that you had to do it: you'd go click on some other card
you'd decided to move instead, the program thought you wanted that second
card as the destination for the first, and BEEP! In your face with
an alert.
A better interface is to have the user drag the card, and drop it over the
intended destination. This is a single click-and-drag, where you push down
the mouse button and keep holding it down while the card follows the mouse.
When you release the button, the card drops. If the card is not dropped
over a legal destination, there is no alert or annoying beep: instead the
card just quietly zips back to its starting point, and the user can immediately
try to move something else. (An improvement is to have legal destinations
highlight as the card is dragged over them. Then it's no surprise at all
when the card goes back to its starting point. You already knew it would
because the intended destination wasn't highlighted when you dropped the
card.)
Another, simpler example is the usual behavior of menu items like Print
and Close Window in word processors. These commands are meaningless if there
is no document currently open. A poorly-made program will give an error
message if the user selects those items without a document open. A better
program will show those menu items as disabled whenever they shouldn't be
used, and then ignores them if they're selected anyway. No error alert is
needed: the user is neither surprised nor confused when a disabled menu
item does nothing.
If you can design your interface so that the user can't make a mistake,
you'll eliminate a whole class of user annoyances, and avoid writing a lot
of boring dialogs and alerts.
Too Many Options Are Bad -- This is an easy sin for a programmer
to commit. Every time 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 in the form of an option. And certainly this
is the right thing to do sometimes: I would never argue that all options
are evil. But too many options will frighten off users. Not everybody out
there likes to think of themselves as a power user. 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 keep options to a minimum? One way is to ask yourself how
many people will really need this choice. If 90% of your users all want
the feature to work the same way, you might be better off just hard-coding
it and letting the other 10% be frustrated.
Sometimes options can be "hidden." Peter N Lewis's ftp client
Anarchie puts up a progress window during file uploads and downloads. The
window shows progress in a variety of ways; one readout is a text-and-numbers
estimate of how much longer the operation will take. But not everyone wants
to see that information. Instead, some want to know how long it's taken
so far; others want to know what time it will be done ("5:35 pm"
instead of "12 minutes from now"). And many people will want all
of the above. Peter could have put all those different indicators in the
window simultaneously; but this would have made a huge, cluttered, unreadable
display. He could have put a bunch of options in a Preferences window, but
this would just have made the Preferences window complicated instead of
the progress window. What he did instead was simple and effective. He left
the Preferences window alone, and put only one such readout in the Progress
window. But if the user clicks on that readout, it will switch to an alternate
form. Click again, and see a third form. Click again, and you're back to
the first. Power users learn about this by reading the documentation or
the on-line "Tips," but users who don't care may never know the
feature is there.
And sometimes, options are just the wrong solution to a problem. A utility
of mine (The Tilery)
lets you switch easily among open applications by clicking on a tile that
displays an app's icon. 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 app instead. The
Tilery winds up as the second-to-frontmost app, right behind the one whose
tile was clicked. This is fine until the user decides to quit from several
apps at once. He types command-Q to quit from the frontmost app. Then the
next app in line, The Tilery, automatically floats to the front. But The
Tilery doesn't look like a normal app, and users tend to forget that it
is. The next thing they do is type command-Q to quit from the app they think
is now frontmost -- and the bad thing happens: The Tilery quits instead.
Very annoying, and I used to get a lot of mail about it.
My first solution to that problem was to put in an option to have The Tilery
ignore command-Q (so that you had to select its Quit menu item with the
mouse to make it quit). That solved the problem, but in the wrong way: The
Tilery no longer quit unexpectedly, but only if you had that option set.
You had to read a bunch of documentation to find out what the option was
for, and the menu item that controlled it contributed to the general clutter
and apparent complexity of what should be a simple utility. And the basic
problem still existed: The Tilery wound up frontmost at unexpected times.
To quit more than one app, you had to manually bring the second and following
apps to the front before you could type command-Q to them.
The real solution was to find a way to have The Tilery remain in the background
until and unless it is deliberately brought forward. It took me a while
to figure out how to do this, but I did it, and the result is a great improvement.
Now when you quit the frontmost app, something other than The Tilery comes
to the front to take its place, just as you expected all along. (Confession
time: the old Ignore-Command-Q option is still in there, because it was
an established part of the user interface by then. And 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!)
Organize Menus Carefully and Sensibly -- I'd like to offer you some
good and bad examples of this, but I haven't been able to think of any offhand.
(If you know some, send them to me!) But the point here is that 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. The best I can tell
you is that 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.
There's more -- the list of HI details to attend to can seem endless. One
source of good feedback is your beta team; your users (later, after you
ship) are another. They'll tell you what works and what doesn't: not just
bugs, but subtleties of interface too. Your job is to listen when they talk.
They're important. 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 app makes on every potential customer: the more flaws they see, the less confidence they'll have in your product.
If you're not good at spelling and grammar yourself, 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.
This one's a real toughie. A truly well-designed application may not need much documentation; it may be intuitively obvious how it should be used. And anyway, lots of users never bother to read the manuals, so why waste time writing them? But many users do read manuals, and I presume you at least want them to read enough to know how to send you your payment!
Knowing how to write a good manual is a career in itself; plenty of people make good livings doing it, and I can't teach you the art in a few paragraphs. (I'm still learning it myself, as any reader of this article can see.) But I can give you a few useful tips.
First, unless your product is dirt-simple, you should ship it with both
a short Read Me file and a separate, comprehensive manual. The Read-Me should
be a text document that briefly covers the following points:
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 Read Me file, and keep it short and to
the point.
See To Read or not to Read
by Tonya Engst for a good discussion of this subject.
Next is your manual. As I said, I can't tell you how to write a good manual.
But before you start writing, think about how your 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 want to do something with your product and can't figure out how. To help
these people, organize your manual in those terms. Instead of documenting
every menu command in order, have chapters labeled "How to...."
Have a chapter labeled "Trouble-shooting" that people can turn
to when they're having problems, and organize it so that people can easily
look up their problem and find a solution. (After you've put out a couple
of upgrades, you'll know what the most common problems are. In your first
release you'll have to guess.)
The first chapter of your manual should explain the rest of the manual:
tell what each chapter covers, so users can quickly find what they need.
Use diagrams and pictures: much better than text for explaining some
things.
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; far too many users
won't have it. Mac and Windows platforms have a variety of ways to create
stand-alone documents that can be displayed and printed on anybody's system;
this is usually a good way to go.
Finally there is on-line help. There are a bunch of ways to do this, 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
like "How can I..." and "Why can't I..." and "Explain
this," and your online help, like your manual, should be arranged so
that users can quickly find the answers they need.
Jeremy Nelson contributes these extra reasons for concentrating on your
documentation, and an argument for making your manual available on the Web:
"Documenting 'features' has a way of accentuating bad UI. If it is hard to write down how to do something, then it is probably too hard to do. After you've gone through the process of explaining how to set the root directory and you've realized it takes 5 pages, you become a lot more convinced that you may as well write the code which removes the need for an explanation...
"I have the documentation on the web, and I use it, quite extensively, as reference for doing support e-mail. Of course, I didn't write some of the applications that I support, but that is the point: in the best case, you aren't going to be supporting the applications you wrote, and the people who *are* going to be supporting them need really good references. Also, I can quote the URL, which includes section markings, that points to the exact point in the documentation where the user's question was answered.
"Which gives me some small personal satisfaction, and actually lets the user get more context than I feel is a good idea to quote in an e-mail reply."
The Next Chapter: Pay Up
Introduction Product Patience Polish Pay Up Propagation Promotion Politics Links