|How Much Documentation Do Applications Need? – A Simple Example|
By Lee Barnard, SAP, Knowledge Design & Engineering – August 1, 2000
Disclaimer: Please note that this edition was written in 2000. Therefore, statements in the articles, particularly those regarding SAP's products, product strategy, branding strategy, and organizational structure, may no longer be valid.
Making Web applications easy to understand and easy to use is a real challenge! It's not just about using new technologies to produce new software products for new markets; it's also about working in a very different way throughout the design and development phases. This article talks about some of the differences between traditional software applications and Web applications and how this affects the use of texts to convey information.
With traditional applications, software companies used to be able to get away with a minimum of usability. The users of traditional software are often experts in a particular business field. They spend a high percentage of their time working with specific functions in their systems, or use the functions on a regular basis. Such users, often referred to as "professional users", accept having to invest time learning an mastering an application. They accept the fact that they will need training before using the application and that they will need to read or at least refer to a comprehensive documentation suite. Many professional users take pride in their knowledge of a complex system and are sometimes tolerant of poor interface design, providing they can do their work without too much unnecessary effort. Also, their managers usually recognize the high costs of training their staff as a necessary evil.
In the past, software companies could take advantage of this situation and provided the functions demanded by the market at the expense of usability. Design was often carried out solely by software developers with varying expertise, and usability testing was either rushed or left out completely. Documentation, for example, was frequently "misused" to try to cover up design faults. Extra training or consultation was also a way of coming to terms with the shortcomings of the user interface and a means of communicating the complex technical concepts behind many business applications.
With the Internet, however, the software market is changing and user expectations are becoming higher. Professional users, now familiar with the Internet, see that software does not have to be complex to be useful. Functions for professional users, therefore, have to be more user-friendly to be accepted. More importantly, Web applications are being used by a wider range of people: employees and private individuals who do not have much experience with software applications, and many of them not even with computers.
Such users are referred to as "occasional users", because they do not spend a great deal of time using a computer, and most of the functions they use (such as ordering a book, booking a flight, or displaying a company sales report) they do not need regularly. Such users have different expectations from professional users. They expect to be able to perform their task in a short space of time with little intellectual effort. Occasional users expect the user interface to be intuitive, and any information they need to complete a task to be brief, clear, and in exactly the place where they need it. They certainly do not expect to have to attend training or to read documentation. If they are confused by a Web application, they will simply look elsewhere. So how can developers of Web applications get the message across when they only have the user interface at their disposal?
One important aspect of user interface design is the use of text. With traditional software applications, developers could restrict their use of text to menu entries, brief field descriptors and messages. Technical writers took care of the rest of the documentation, providing field help, step-by step procedures, and conceptual information in the form of printed or online manuals. In the case of online help, the user would often have to access a separate help system to display the documentation. One recently advancement in some software applications is the use of embedded help, where the help is not in a separate window, but appears directly on in the user interface, usually in a designated help area.
The most critical text in a Web application is its title. Having a clear and meaningful title that describes the user task can mean the difference between an application being used, misunderstood, or completely ignored. The reason for this is that Web applications are often accessed via hyperlinks or from lists and not always from an organized hierarchical structure such as an application menu.
The absence of field help in Web applications means that field descriptors have to be clear and meaningful. It's amazing what a difference two or three extra words can make to how quickly a user understands what a field is for. The same applies to pushbuttons. Technical writers, who are experts in user-oriented terminology and formulations have a great deal to contribute in this area and are playing a more important role in the design of user interfaces for Web applications.
Even when step-by-step procedural help is automatically displayed as embedded help in a Web application, usability tests show that users mainly ignore it, regardless of where it appears. If they can immediately recognize where the work area of the Web application is, they prefer to start there. Users expect the sequence of steps in a Web application to be intuitive. In other words, they start at the top and work their way down. Fields, pushbuttons and other elements must, therefore, have a logical sequence to support the user. The sort of texts users do like, however, are the individual steps built in to the user interface exactly where the information is needed. Such texts can take the form of instructions or brief examples.
Other texts that users find useful are short overviews of what a Web application is for, if it is not completely self-explanatory. The text really does have to be short, though: continuous text in a Web application is off-putting if it is longer than a few lines. Overview texts are mainly useful the first time somebody uses a Web application or as a reminder, but can be irritating once the user is familiar with the application. The system should therefore provide a way of hiding the text if the user no longer wants to see it.
System messages, traditionally displayed in separate dialog boxes or in a designated area (such at the bottom of the application) are disconcerting for users of Web applications. Users prefer messages to be context sensitive. An error message, for example, should appear near to the field where the user has to correct something. Also, the wording has be chosen very carefully in message, so as not to confuse, intimidate, or even insult inexperienced users. Teamwork between software developers, user interface designers and technical writers is, therefore, especially important with system messages.
The combination of the various skills from the disciplines of programming, technical writing and user interface design is a must for successful Web applications. This teamwork is one of the aspects that makes software design and development in a Web environment so exciting.