Tips & Hints for
Shareware/Freeware Authors
Written by Matthias Kahlert, mkahlert@kagi.com
http://www.GeoCities.com/SiliconValley/Pines/8031/index.htm
General Information: Interface Design
Your shareware application may be the best one of the world, but if it has a bad interface design it possibly won't be accepted by the users. Usually the interface design needs will consume the greatest part of your work, but do not neglect it! A software is only good if the interface is good!
Make your application look pretty! People are more willing to buy an application that looks good. The better-looking your application is the more copies you will sell.
If there are two applications with exactly the same functions and features, and if only one of them has a good interface design, the other one won't be good selling...
You should really spend a lot of time here: Create a nice splash screen and about box (not just a simple text dialog box, use images or animations), use cool icons and logos, perhaps use a 3-D look, etc. But do not use too many different colors, don't make it too colorful.
And you won't sell a MacOS application that runs in a terminal window, so make use of the MacOS interface: Use windows, menus, dialogs, etc.
Perhaps you should ask one of your friend or some of your registered user what they like best. Also beta-testers can exactly tell you what they like and what should be made better. Just ask them!
Spelling and Grammar are very important things in your applications. Every text the user gets to see (documentation, dialog boxes, alerts, menu commands, etc.) should be correctly spelled. The more mistakes the user gets to see, the less confidence he'll have in your application.
If you are not good at spelling and grammar yourself you should try to find someone who reviews your work. And remember: Spelling Checkers can't find all errors!
| Human Interface Guidelines |
Always create your windows, menus and dialogs according to the Human Interface Guidelines of the operation system you are developing for. Every platform has it's on style, it's own commodities. In the following chapters you'll find some important things.
If you want to find out more about these topic, take a look at Apple's Human Interface Guidelines. Although these guidelines are especially for MacOS computers they contain also some useful hints for other operating systems.
On every platform there are some menus and menu commands that every application should have.
For example: On the Macintosh every application must have a File and a Edit menu.
- The File menu contains items for creating, opening and saving files, for printing and for quitting the program.
- The Edit menu always contains items to cut, copy or paste anything. Although if your app doesn't provide these features you should include the items, just disable them.
And take care of the shortcuts. Some menus always have the same shortcuts in every application, e.g. Quit is always Command-Q, Copy is Command-C, Save is Command-S, etc. But this may be different in each operating system.
Just try some other applications to find out that standard commands...
Another important thing: If a dialog box or window is opened after choosing a menu item, these menu item must have three dots (...) behind it's name. For example: "Open..." let's the user choose a document in a file browser window, therefore it must have the three dots.
And always organize your menus carefully. Users hate it to browse through a maze of menus and sub-menus to find the appropriate menu command. You should organize them in a sensible fashion.
If there are too many menus in the menubar, try to hide those that aren't neccessary and do only show them when the user needs them. For example if your application is able to edit text files and images, you should hide the Image menu while the user is working on a text, and when the user opens an image, hide the Text menu and show the Image menu. But this assumes that you organized your menus clearly...
Dialog boxes are a important thing in every application. The contents of each dialog need a lot of work.
Do not create too cluttered windows. Users like to see windows with just a few buttons and controls and a lot of white space around them. Carefully organize them: group related controls together, perhaps with a frame around them. Separate them from the other controls. Align all the buttons so that the windows doesn't look sloppy. And always place the standard controls where the user expects them to see, for example the "OK" button is normally always in the lower-right corner, and the "Cancel" button is left of it.
If you need to include too many controls in a single dialog think of other possibilities of how to organize them. Try to split this dialog box:
- Pageframes let the user simply switch between the different groups of controls. When the user selects one of the tabs, the other settings are hidden. These technique let's you put a lot of controls into a single window...
- Instead of using pageframes you may also use a popup menu in the top-left corner. Using this menu the user can select one of the settings windows...
- Or you could use a scrollbox on the left side of the window. In this scrollbox you can put the categories, and when the user clicks on one of them the window shows the corresponding settings.
This last technique is especially useful if you need to include a lot of groups (e.g. more than 20 items) that don't fit onto the pageframe tabs...
Also be careful how you organize the items inside the dialogs. Apple has published a very extensive collection of Human Interface Guidelines for Macintosh authors. These guidelines specify exactly where to put icons, where to put buttons, how large these items should be, what colors to use, etc. If you follow these rules you can be sure that the users easily find the items where they expect them.
And always avoid too much dialogs! The fewer the better. Each dialog interferes with the users work, it always disturbes him.
Often dialog windows report errors to the user, so a good way to reduce the number of dialogs is to reduce the number of possible error conditions. If you really need to often report such errors (for example if the user clicks at the wrong place, especially in games), you can report them in a status window that is hidden automatically and that hasn't to be closed by the user.
If you display a dialog box where the user has to answer a question, keep this question as short as possible, but make it also clear what you want. And always use appropriate names for the buttons. If you ask the user if he wants to save the document, the buttons should be named "Save" and "Don't Save". Do not use strings like "Yes" or "No", the user always selects the wrong button! And keep your question as short as possible, just one or two lines. The users are not willing to read complete stories only to find out what you want. Here's an example:
| Do you want to save the file "Untitled"? | | Don't Save | Save |
|
| The document "Untitled" hasn't been saved yet. Choose "Yes" to save the file to your hard disk or diskette. If you choose "No", all changes will be lost. | | No | Yes |
|
Good... | Bad... |
Always try to avoid possible errors. This saves you a lot of work (especially support questions) and the user a lot of nerves... For example if your application works with files you should disable the menu items Close, Save and Print if no document is opened. The user can't print anything, so why should he be able to select the Print command? This would just result into an error alert...
A similar problem are the settings: Don't give the user too much options and attributes to set!
If you have to decide whether a feature should work this way or that way, many programmers would implement both ways and then give the user an option to choose. In most cases this is the best way, but too many options will frighten the users. Anything that looks to complicated to the user will soon be trashed.
Think about how many people really need that option. If about 90% need the first way and only 10% need the second way, it might be better to just implement the first way...
Or you might try to hide these setting. For example:
- If you have a file utility that let's someone display a list of files, you perhaps may want to give the user some information about the listed files in the status line, for example the number of files, the overall file size (perhaps data fork and resource fork), available disk space, etc.
All these infos won't fit into the status line, so you will perhaps decide to put a new option into the preferences where the user can choose what he wants to see. But you can simply avoid this: Just show one of these infos in the status line, and when the user clicks at it, you switch to the next.
Okay, most users may never get to know that this feature is there, but power users can learn about it by reading the documentation or the on-line help.
- Another way to hide settings is to include the options but giving the user no chance to change them inside your application. If the user want to change the settings, he'll have to edit the INI file or to edit your application using ResEdit. This isn't the best way, but it may work with features that are only used by power users.
You can read about some other good ideas on Rick Holzgrafes page about Successful Shareware, Chapter 4 "Polish".
Or take a look at the Electronic Guide to Macintosh Human Interface Guidelines or Macintosh Human Interface Guidelines from Apple Computer.
Do you have any new ideas or aspects? Please let me know. Just send an e-mail to
mkahlert@kagi.com.
Modified on 30. June 1997
Back