DON'T BE DIFFERENT!
The number one rule of GUI design, especially for beginners, is DON'T BE DIFFERENT! The biggest advantage of GUI design is that once a user learns how to operate Windows (or Macintosh) software, they already know most of how your program works!
For example, your users already know that when they are done, they look in the leftmost menu, File, and choose Exit. You may decide you like the word "Quit" instead. Or you may decide that since exiting is the last thing people do with your program, it should logically go in the last menu, not the first one. Too bad. Don't confuse your users by being different. They will dislike you for it. Stay with the standards.
Remember the old DOS days when everyone used Word Perfect, Lotus 1-2-3, and dBase? Did learning one of those programs help you with the others? How do you exit each? How do you cut and paste in Word Perfect? Does that work in Lotus 1-2-3? (No!) How do you find help? How do you get something from Lotus into Word Perfect? Yuck!
The nice part about GUI software is its consistency. You know what types of things are in the File menu, and if you need to Open, Save, Print, or Exit, you know that is where to look. You know that the second menu, Edit, contains Cut, Copy, and Paste, and you know how they work, because all applications treat them consistently. Don't disappoint your users.When in doubt, just look at other well-written Windows applications and use the same layout, keywords, and shortcut keys.
The leftmost menu is File. It contains choices such as New, Open, Save, Save As, Print, Print Setup, and Exit. Don't put these choices in other menus. The access keys for these items are N, O, S, A, P, I, and X, in that order. When in doubt, look at other well-written programs!
The second menu is Edit. It contains Cut, Copy, and Paste. Sometimes it contains Undo and Delete, and other choices related to editing. The access keys for Cut, Copy, and Paste are T, C, and P. The shortcuts are Ctrl-X, Ctrl-C, and Ctrl-V. Use them.
The rightmost menu is Help. It should contain some explanation of how to use your program, plus an About option. Without getting into using the Help Compiler, the simplest way to build a help screen is to create a second form, put a large, multiline, scrolling text box on the form and an OK button. On form load, read the contents of a text file into the text box. The text file contains your instructions for the program.
Use standard dialog boxes in most cases. The only reason to not use a standard Open or Save As dialog is if you want to add extra features, or if you want to restrict novice users to a particular drive or directory.
KEEP IT SIMPLE
Use the controls that are appropriate for your application. Make it as easy as possible for the the user to understand and use your program.
Fewer clicks and keypresses are better.
Fewer controls in your application and visible at any time reduce the clutter and complexity.
Don't show off. Just get the job done, as simply and elegantly as possible.
Application Window and Dialog Boxes
Don't use forms haphazardly in your application. The most elegant applications use a single application form, with dialog boxes for special communications with the user. A dialog box should have OK and Cancel buttons. Either should return to your main application form.
In some instances, a complex dialog box can be broken down so a first-level dialog launches a second-level dialog (Advanced..., or More...). That way users who frequently use the items in the first-level dialog are not confused or distracted by the advanced or seldom-used features, but there is a way to get to them. The second-level dialog should always return to the first-level dialog, which should then return to the main application window.
A diagram showing the relationship among the various forms in an application should look exactly like a tree diagram, with your main form at the root and the dialog boxes branching off, but always returning to the root.
Tip: Dialog buttons, such as OK and Cancel, appear across the bottom of the form, or down the right side.
Saving
Most applications should automatically save changes made by the user. Don't require the user to "save" unless you are dealing with entire documents, like a word processing or paint program. Even then, if the user MUST choose Save, BE SURE TO WARN THE USER if they attempt to do something (exit, start a new document...) that would wipe out their previous work! If they skip the Save step, BE SURE TO ASK before destroying what they've done.
Database applications and programs that let you choose preferences are just a couple examples of types of program that should automatically save work.
Resist "Creeping featurism"
"Creeping featurism is a disease, fatal if not promptly treated" - Donald Norman
The more neat and cool features you add to your program, the harder it will be to understand. There are examples too numerous to count of neat little programs that evolved into awful things over the years as their authors added more and more functionality. The evolve to the point where they are almost impossible to use, if not impossible to learn.
Consider a few Microsoft programs for typing and saving text: Notepad, Write, Works, and Word. They all can be used for saving stuff you type. How many people need all the functionality in Word? Does anyone know all of it? Most of the people who use Word use only about 10% of its features.
Most of us realize that a program is never "done". Be careful as a program evolves that you don't lose the good things in the original design. A good trick is that when you add new, "advanced" menu items and features, make them invisible. Add one extra item in your menu that says "Advanced Features". When the user clicks that, set its Checked property to True and set the Visible property of all your advanced menu items to True. Novice users aren't bothered by all the clutter and advanced choices, but your power users can choose to see and use them if they wish.
Let Your Users Have Control
It is quite possible to write a GUI program that is very sequential, demanding that your users follow steps in exactly the order you desire. Usually that is not necessary, and it's overly restrictive.
Allow your users to learn by trial and error. When you get a new Windows program, do you install it, then read the manual to see how it all works, then try running it? Or do you install it, then run it and try clicking on everything?
Whenever possible, set default options so your program works with minimal entry and customization.
LOOK PROFESSIONAL!!!
Perhaps this should be listed as "Rule #1", since this is what your user will first see about your program! Before anything else happens, before any clicks or keystrokes, your user will make some judgement about your program based on what they first see.
If the first impression is that your program appears unprofessional, you've got an uphill battle. Because if it appears unprofessional, before I make a single mouse click I'm thinking that it's a sloppy program that's not going to work properly and it will probably crash. And I haven't done a thing yet! It doesn't matter if you've got the coolest, slickest code in the world under the surface. I'm ready to give up on the first impression!
Size and Alignment
Be consistent with the sizes and alignment of your controls. Sloppiness here will make your program seem like it was slapped together without any thought, no matter how good your code.
Type
Don't mix fonts. Choose one, and stick with it. You can use various sizes and styles (bold, italic) of the same font, but the only time a second font should be used is for logos or display type. ("Display type" is the term for headlines in advertisements. Generally you will see one font for the headline, and another font then used through the rest of the body of the work.)
DON'T USE ALL CAPITALS! IT SHOUTS AND ANNOYS PEOPLE!
Dark type on a light background is preferred.
Color
Don't rely on color. Not everyone can display it or see it. 10% of the male population is color blind to some extent.
Be careful about color on color. On a grayscale monitor, some combinations disappear.
Color has a subliminal quality connotation. Which is better, the stereo receiver in the black cabinet, or the one in the bright yellow cabinet? Which is faster, the red car or blue car? A news report on supermarkets tells us white packages are for lite foods, green for healthy, red for gourmet...
To infer quality, stick to conservative colors: grays, white, black, modest blues, deep magenta. Think of the colors used for quality cars or electronics devices. These are not used by accident. Unless critical to your application, stick to just a few colors, and use the color scheme throughout.
Avoid Clutter
Only include elements on your form that are pertinent to your application. Things like your company logo are best left in a title screen or About box.
Group Related Items
Use Frame or Tab controls to group controls related to a common task. Look at their use in dialog boxes in some well-written applications.
BE DIRECT
Make your program easy to follow. The user should be able to select an object, then perform an action with it. List boxes should usually be accompanied by an action button.
Command buttons and menu items should contain short action words. Use a message bar or tips in your MouseMove events to provide more descriptive information.
Avoid computerese. Be careful with words like record, transaction, field, query, key... We know the meanings, but computer novices will not. Know your audience and speak in their terms.
Use shortcut keys and access keys for your menu items and command buttons.
Actions vs. Dialogs
Command buttons and menu items should have action words, but sometimes clicking on the menu item or button performs the action, and other times clicking will launch a dialog that may perform the action, if the user chooses so. To make that distinction clear, use ellipsis (...) after action words that launch a dialog.
For example, in the File menu, clicking on a choice that says "Print" should perform that action. Clicking a choice that says "Print..." launches a dialog box that lets me choose some print options, and then lets me click OK (to perform the action), or Cancel (if I change my mind).
Icons and Images
Icons and images can often be used to give the user a visual metaphor for a command, making it easier to remember and faster to use. Image controls have a click event, so they can be used just like command buttons.
Don't rely solely on the images and icons. Your users may not remember what an image means. Your menu bar should have choices that do the same thing as your icons. Pop-up tips also help explain your icons. Graphics with some form of text is the best combination.
Don't stretch the metaphors, and try to keep your icons and images in a consistent style. If you can't find something appropriate, don't use an image. Don't mix cartoon styles and business-like styles. It will look weird.
An Image Control Trick
Create two pictures, one shadowed on the lower right, the other shadowed on the upper left. User your visible image control, plus two more invisible image controls holding the two pictures. A click event can also be treated in two parts: MouseDown and MouseUp. Set the visible image control to use the first picture, which appears raised. In the Image1_Mousedown event, change the image's picture to the second image, which appears lowered. In the Image1_MouseUp event, change back to the first picture. The user will see a visual response when clicking the image, just as with a command button.
Be consistent with the real world
In your icons, images, and terminology, make sure your program is consistent with what the user would expect from the real world. A file cabinet icon would represent being able to store something, and being able to retrieve it later. A trash can is somewhere to throw something away. A shredder discards AND destroys something so it cannot be retrieved.
Be consistent within your own program
Make sure controls that look the same act the same. Text boxes can be edited by the user; label controls cannot. They can be made to look alike by putting a border on the label. It would be confusing to your user to see a whole bunch of boxes on your form, some of which can be edited and some of which can't! If you want to use a label to display data that can't be edited, either leave off the border, or if you put the border on it, use a different background color to show that it is "different" than the text boxes.
Make sure keywords used in different places mean the same thing. "Exit" leaves your program entirely. "Close" closes a form, but not necessarily the application. Don't use "Exit" to close a form and not your application.
|
