User Interface HOWTO

1. Introduction
2. Documentation
3. User Interface
4. Bug And Wish Reports Management
5. Programming
6. Communication And Promotion

User interface is a very wide subject, and very subjective too, as something obvious to someone is absurd to others and vice versa. Therefore, don't assume, argue clearly, stating your logical steps. Your main tool discussing it are objective reasoning and good sense.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it. The good part is that given the Qt/KDE Framework, there are some things even a non developer can implement.

The KDE Usability Mailing List is very active and a good place for discussing your ideas. If you are already an usability expert, please check OpenUsability.org, a project that brings open source developers and usability experts together, and is collaborating closely with KDE.

Before Starting: Guidelines And Useful Documents

You don't need to read the documents listed here to perform simple tasks, like verifying shortcuts' coherence with other KDE programs, making simple logical analysis or presenting anecdotal usability feedback and opinions. More knowledge is required to perform a more profound study, but you will find all the information needed easily.

The basic KDE documents on usability are KDE User Interface Guidelines (design standards) and KDE User Interface Guidelines (design principles). The first is a comprehensive collection of standards for KDE applications, or in other words, down to earth conventions and rules for immediate use. The second is a general set of useful principles for designing user interface, and a good place to start studying.

There are books and other good sources of information about this fascinating subject, many of them online. The KDE Usability Website has an excellent collection of usability information, including windows, apple and gnome user interface guidelines, usability course notes and even an online book on the subject.

Analysis

You can perform very useful analysis using the KDE user interface guidelines and other usability material. Suggestions on what to cover include:

KDE User Interface Guidelines (design standards) conformance: It sets standards for the maximum dialog size, exiting applications and closing documents, capitalization rules, among others. It is really a very good to start reviewing the user interface, as it covers all mains aspects of common applications: dialogs, menus, toolbars, shortcuts and accelerators, drag and drop, the status bar, etc... All KDE application should at least follow these standards, and below we assume they do.

Shortcut keys coherency and accessibility: to reduce the learning time required for an application, shortcut keys should, first, follow as closely as possible the scheme already used by other KDE applications, and second, follow the scheme used by similar applications. One good example is making Konqueror use the same basics hotkeys as Mozilla or Internet Explorer. If you don't agree with a shortcut used in widely in KDE, don't make your application different, try to persuade other people to change to your approach instead. Another good target is to minimize the use of more than two keys at the same time for the most important functions, as handicapped people may have difficulties accessing commands with tree or more keys at the same time. Verify if a commonly used action lack a shortcut, and do some research on what key should be used for it: consistency is the main priority, look what other KDE or similar applications do.

Dialogs review: The basic rules are the user should not be required to read about things unrelated to his current task or decide about things he does not want to. He should get things done easily, fast and with minimum data entry. Worthy points to review are if the dialogs are clear, if the widgets are displayed in a logical sequence, avoiding unnecessary information, if the information is presented in relevance order, if related options are grouped together, either in a simple dialog or a more complex multi-tab dialog. You can use the KDE User Interface Guidelines (design principles) as a guide, checking if its principles are being followed. The Configuration dialogs are constantly being redesigned, because new options are constantly being added and obsolete ones removed, making them obvious targets for review. Examples of improvements are the Panel Configuration Dialog Redesign or the Clock Applet Configuration Dialog.

You have a powerful tool to help you improving the dialogs: the Qt Designer. Using the Qt framework, you have two basic option to write dialogs: a text editor, as writing the general code of application (usually .cpp files) or the Qt Designer(.ui files). If the dialog you are reviewing was developed using the Qt Designer, you may redesign it yourself, even if you have little knowledge of programming. Search for all .ui files among the source files of your application. Open them (you can use the faster ui file viewer) to see if it is the desired dialog. If you cannot find the dialog you are analyzing, it may be because it is hand coded or a shared dialog from KDE libraries (module kdelibs from KDE CVS).

Even if the dialog was written by hand inside the code (no .ui file), you can make a proof of concept using the designer, a mock-up, to show other people your ideas and state clearly the seriousness of your proposal. Trolltech makes available as part of the Qt Designer Manual, a small guide on how to create dialogs using the Qt Designer that should enable you to create simple dialogs or mockups.

Usability Tests

An example of empirical test is your own experience with the software. The challenge is to transform it from subjective opinion to objective facts people can work with. One idea is to perform a simple user test, you being the user, setting tasks to perform, documenting the process, taking notes of the problems you find and providing solutions. Most of your conclusions can be used in a way or another to improve the application. But it can be even more useful if the test could be extended to more people, as you are probably not a regular user: you have more intellectual curiosity, different habits and are more capable of working around design flaws. To prove that, the evidence is that you are reading these lines...

It is easy to perform a usability test with other users, and it may result in major improvements in your application. Select the most important tasks to perform with your application and find some friends to perform them. The people you select should fit the profile of the user the application targets, so make a small questionnaire about people's background. More information and tips on how to perform an usability test can be found in the short and useful Infodesign usability testing page (also in PDF format). Employ a chronometer to record the time taken to perform each task and take note of all pitfalls found. Tabulate the data and try to extract conclusions and recommendations. There is invaluable insight and information to be obtained in this kind of test. An example of field test with KDE is the Relevantive Report on KDE usability.

[ Edit ]