Table of Contents
Write down the type of people you expect to use your application. Then write some "scenarios" for each type of user— a little story that describes the typical tasks those users will use your application for. These tasks should be along the lines of:
Fred needs to find an email about widgets that he received last week
rather than
Fred clicks on the Find button and types widgets into the dialog.
This way, you can use the same scenarios to test and compare different interface designs, and to spot any missing functionality.
Include these user descriptions and scenarios with the documentation you commit to CVS. This way, other contributors will get to understand your users too, can help to develop the application with that knowledge, and can provide more scenarios of their own.
When you have started implementing your interface, hide your mouse, and make sure you can still use it to do everything using only the keyboard. Implement keyboard functionality at the same time as mouse functionality— don't leave it until the end.
Using only keyboard commands, move the focus through all menu bars and toolbars in the application. Also confirm that:
Context sensitive menus display correctly (Shift-F10).
Tooltips can be popped up and down for all controls that have them (Ctrl-F1, Esc).
All functions listed on the toolbar can be performed using the keyboard.
You can fully operate every control in the client area of the application and dialog boxes.
Text and objects within the client area can be selected.
Any keyboard enhancements or shortcut keys are working as designed.
Verify that when moving among objects, the visual focus indicator is easy to identify at all times.
Test various GNOME themes to ensure that your application respects all the available settings.
Test your application with black and white, high contrast themes and confirm that all information is still conveyed correctly. If you don't have a suitable high contrast GNOME theme available to test, print off some screenshots in black and white (not greyscale) and make sure all the important information is still visible— this will approximate what a high contrast theme user will see.
It's always tempting, but don't start coding your interface straight away. Sketch out some ideas on paper first, or in Glade or HTML if you prefer. (But don't be tempted add any functionality at this point if you do it this way!)
Show these prototypes to other people— the GNOME mailing lists and IRC are ideal for finding likely candidates. Ask them to use these prototype interfaces to run through some of the scenarios you came up with earlier. You'll probably get questions like "how would I do X", "which menu is Y on"... these questions will help you think about the interface from the user's viewpoint. You'll probably also get a few suggestions about how to do things differently— these ideas may or may not turn out to better than yours, but any idea from a potential user is worth considering!
You should also consider seeking opinions from the GNOME Usability team. They have designed many user interfaces before and may be able to spot potential problems at this early stage, before you take your design too far to change easily.
Once you've decided on the basic interface design and have started coding parts of it, find somebody to try it out again— it doesn't have to be the same person. You'll probably find some more problems that were hard to see on your static paper prototype. By finding these now, it's usually not too late to fix them without too much trouble.
If you intend your application to be translated into different languages, show draft designs of your application to the GNOME Translation Team. They'll help you find potential translation problems, such as not leaving enough space for translated labels, shortcut keys that cause problems on a different keyboard layout, or using new terms in your app that are hard to translate.
If possible, try out your application with users from the locales you are targeting. This will help you determine whether users understand how to use the application, if they perceive the graphics and colors the way you intended, and if there are words or images in the application that may cause offence to users of that locale.