The Importance Of Interface Text (part 2)

See examples of interface text for menus, windows, buttons, fields and application messages, and find out how to internationalize your application.

A Matter Of Principle

Having set the tone (in the previous segment of this article) for using domain knowledge to its utmost for the interface text, we now come to certain accepted principles to be able to develop intuitive and indicative text.

While there are certain characteristics for each of the interface text components, the following are basic guidelines to be followed at all times:

  1. Conform to norms: There is usually never a need to reinvent the wheel when defining interface labels or commands - many common interface elements already have accepted nomenclature, and using it reduces the users’ learning curve drastically.

  2. Be consistent: ‘Tis said that consistency is the hobgoblin of little minds…but when it comes to interface text, consistency is critical to the user experience. Consistency here includes consistency in:

  • Naming conventions - for example, if your screen titles are prefixed with the action they enable (“Edit Address”), ensure that all screens are titled in that manner.

  • Usage - if you use “Done” or “Save” to denote submission, do not shift to “Submit” in some screens.

  • Tone - if the tone of your instructional text is direct but formal, do not shift to using exclamatory and “Yes, you’ve got it right!”-type statements.

  • Font - decide the styles to be used for denoting titles, labels, messages and instructional text and use them consistently.

  1. Mind your caps: Capitalization may be of two kinds, title case and sentence case. In title case, each word starts with a capital letter, except for prepositions and words smaller than four characters. In sentence case, the first word and proper nouns start with capitals. The norm is to use title case for labels and titles, and sentence case for instructional text and messages.

  2. Be pithy: Each piece of text should be aimed at giving the user that amount of information that is necessary - not more, and not less. For titles and labels, limit yourself to three words, whereas for messages and instructional text, staccato one-liners or even fragments of sentences will suffice.

Similarly, the messages need to be crisp. Instead of “Your attempt to save the address has failed. Would you like to try again?”, you can also say “Save attempt failed. Try again?”

Of course, don’t take it to extremes - the old DOS-style “Abort? Failure? Retry?” would be pushing it a bit.

  1. Be sensitive to language: Try to avoid getting caught up in programming lingo. It is easy to get caught up in what the system does at the back-end, and to try and bring that out in the interface text. For example, on a search screen, if the user needs to select a parameter that the database will parse or filter against, do not label the field “Select Search Filter”, since the term “filter” may not be very intuitive to a lay user.

Brass Tacks

With the generics out of the way, let’s now get a little deeper into the details. Over the next few pages, I’ll be getting into the specific characteristics of menus, windows, fields, buttons and error and confirmation messages.

The biggest function of titles - menu options as well as screens - is to bring to mind a particular task that the user needs to perform. And the terminology used should reflect the user’s understanding of the task rather than the application’s functions. The trick here is to question the users about their actions to perform particular tasks in order to develop appropriate verbiage. While the process flow for a particular task is usually available in your reference documents, asking questions gives you the everyday verbiage the users are familiar with.

Let’s suppose, on questioning, an MIS manager tells you that to add a user to the network, he

  • creates the user ID and password
  • sets the size of the mailbox
  • sets the backup options
  • sets file server access permissions
  • sets Internet access permissions
  • sets up the user’s mail client

Therefore, the menu items could be:

Setup |– User ID |– Mailbox |– Backup |– File Server Access |– Internet Access

Thus, the user’s description of the tasks will provide you with all the necessary verbiage for the menus.

At this point you have identified the general areas in which the user will perform the requisite tasks - but your menu is still to reflect the actual tasks. The essential thing now is to ensure that the lowest level of your menu item is titled as a verb, indicating directly the task that the user needs to perform. Here’s what the revised tree would look like:

Setup |– User ID | |– Add User ID | |– Edit User ID |– Mailbox | |– Add mailbox | |– Edit mailbox |– Backup | |– Add backup task | |– Edit backup task

and so on.

The Screening Process

Having got the menu titles out of the way, we now come to the screen, or window, titles.

Ideally, the screen title should reflect the menu option clicked for ease of understanding and reference.

There may be times when the functions available within the user interface require more than one screen. For example, for an “Edit Item” function, the first screen may allow the user to search for an existing item, while the second screen displays the settings and allows modification.

In such cases, the first question to be asked is whether this is the norm with all such options. If it is, then you may assign nomenclature for these screen types - for example, “Search For Item” and “Edit Item Details” would be appropriate titles. If, however, this is a one-off occurrence, and you cannot fit this screen into any of your existing types, you would be better off not setting nomenclature for the screens. Setting separate titles in such cases merely adds one more level of complexity, and requires more help material for those users who get confused.

Another case is of screens that pop up in new windows for additional data entry. Title these screens to indicate exactly the task they perform, or the data they need. Trying to depict a link with the parent screen is not required, because the context is already set by the display of the sub-screen at that particular point.

Playing The Field

The user has now reached the correct screen, safe in the knowledge that (s)he will be able to perform the intended task. The continuation of this feeling depends on how familiar the data requirements on the form seem.

A lot of this has to do with the structuring of the form - the bunching together of parameters and the manner in which the interdependencies are depicted. A lot also depends on how familiar the words sound to the user. Stick to using terms the user is familiar with, and you can’t go wrong.

The main function of the field label is to indicate the data requirement of the field. This should be short, a maximum of three words (and even that’s stretching it!) If it takes you more than three words to explain what a field does, you need to reconsider the focus of that field.

Button labels need to indicate the “impending action” - that is, what the effect of clicking them will be. Here’s a list of the verbs used for most of the common actions - most users are familiar with these and what they represent:

  • Submit

  • OK

  • Cancel

  • Reset

  • Confirm

  • Save

  • Delete

  • Edit

The important thing, of course, is to use these appropriately and consistently. It also impacts your screen design - design screens so that if at one screen you need to “save” information, you do not need to shift to “confirm” for another one.

When Things Go Bad…

Next up, error messages, one of the most important components to consider when creating interface text, purely because of its potential to unnerve the user.

A well-written error message should cover three bases:

  • What happened?

  • What is the result?

  • What does the user need to do?

You will usually have two kinds of errors - validation errors and exceptions.

Validation errors occur due to incorrect data entry by the user, and therefore, the error message needs to essentially point out the input field where the error occurred and how to correct it. In an online expense claim system, for example, if a user enters an amount claim that exceeds his total permissible expenses, a validation error would occur, and the following message would be generated: “Your expense claim cannot be greater than your total permissible claim. Please re-enter your expense claim.”

An exception, on the other hand, occurs due to a back-end problem - for example, the database has missing data or a resource cannot be found. Typically, these are internal errors beyond the control of the user, and the error message should reflect this, essentially asking the user to contact a more technically-astute administrator to identify and rectify the problem.

Some things to keep in mind with respect to exception messages:

  • The message should specify whether the changes made have been reset and the user needs to enter them again or simply use the “Submit” or “Save” commands to register the changes.

  • Avoid letting the system code for the errors appear on screen. And also avoid using exclamations in error messages - “Oops! You screwed up!!!!” is definitely not a good error message to see in an application.

  • The user need not be informed of any back-end processes that are causing the error. In case there is nothing more the users can do, ask them to contact the administrator.

You can be more professional in your design of error messages by creating a single database of generic error messages, and reusing them in your application - for example, “<field> contains data of incorrect type”, where <field> is a variable that is automatically replaced with an actual field name by the program. The benefit here is that you have a single database of error messages, and can immediately enforce a consistent style across the entire application.

Your other option is to write specific messages, like the message for claim expenses above. You will need to write these for validations that are not common across the application. In practice, you will nearly always end up with a combination of these two approaches. The thing to be sensitive to here is that you should not have an overlap between the two approaches - that is, you should not be writing a specific message for a situation where the generic one will suffice.

Offering Instruction

Instructional text is of two kinds - text that is visible on screen at all times (usually at the head of each section) and bubble help or context-sensitive help, which appears on specific manual or automatic triggers.

The thing to remember with instructional text is that it is not help - it only aims to assist the user in understanding the immediate effect of filling in a particular form. For more specific details, the user should be guided towards the more detailed help module.

On-screen instructional text is usually an explanatory sentence at the beginning of the page, with an emphasis on the impending action and its consequences. For example, in Web forms asking users for their addresses, the instructional text is usually something like “Please enter your address to enable us to send you our latest catalog”.

Sometimes, a form may be divided into multiple sections. In this case each section can have an instructional text message.

The best examples of context-sensitive messages or bubble-help messages are the tags that appear when you move your mouse over buttons, links and other clickable elements of the user interface. The aim of such tags is to tell the user “what will happen when you click this”. To this end, they need to be pithy and direct.

If the tag is on a link, or a button that takes the user to another screen, the message could simply be a statement of what the user will find on clicking it. For example, the tag for the link “Claims Statement” could be: “Snapshot of previous claims”.

However, if the bubble help is for a so-called “action button”, it needs to state the action that will occur when the user clicks it. The most common example would be the tag for the “Submit” button: “Click Submit to save changes”.

Better Safe Than Sorry

Confirmation messages are displayed after modifications have been made to the system by the user. The aim of these messages is to inform the user of the impact of the action and elicit a “yes” or “no” response for further processing.

A common irritant here is messages asking you to confirm what you’ve just done - without a reason for asking it. For example, if your intranet application allows the administrator to delete a folder off the file server, a confirmation message asking the question: “Are you sure you want to delete the Accounts folder?” will only make the user feel that you doubt his or her intelligence. A better option would be: “Deleting the Accounts folder will also delete all the files within it. Do you wish to continue?”

In some cases, it is more appropriate to show a message after an action has been performed. This is especially true if the user’s action triggers off an internal event within the application. For example, suppose your administrative application stores users in separate “data files” based on whether they are confirmed employees or not; these appear to the user as two separate categories, “Probationers” and “Employees”. On the basis of certain criteria, the system turns a probationer into an employee and moves the corresponding data to the “Employee” data file. Let’s assume that one such criterion is the achievement of a Grade A for performance. When the administrator enters this grade into the application and submits it, a post-submission message could be: “Wella Cruz has been updated to Employee status. In future, please access the Employee menu for her data.”

As a parting shot, ensure that your confirmation questions elicit a direct answer. The following is the best example of what it should not be: “You have changed the mail server settings. Would you like to discard changes?”

In this case, the user would need to select “No” to save the changes made…completely non-intuitive and quite illogical.

Globe-trotting

Last, but not least, we come to the part about making your application suitable for international use. Localization of your interface text is something you need to consider and plan well in advance of deployment. If you decide you want to do this, the process and guidelines to develop interface text gets quite intensive - multiply the usual effort by the number of languages you are planning to localize it in!

There are two main considerations to keep in mind when embarking on a localization project: the technical aspect of developing and translating the interface text in the requisite languages, and the actual development of the interface text.

While the technical code required to implement internationalization are beyond the scope of this piece, an important tip is to place the different translations of your interface text in separate language files, one for each language, instead of hard-coding it directly in your source code. Implementing language switching is then simply a matter of finding the correct language file and displaying its contents in the appropriate places.

You will find, though, that the larger consideration lies with the development of the interface text in a manner that allows the translation to be automatically handled by a resource. The following should be your prime concerns:

  • Definite words: While developing the interface text, ensure that you use terms that cannot be interpreted in different senses in other languages.

  • Consistency: Ensure that your messages are consistent in tone and usage of terms; inconsistencies can be further obscured when translated into different languages.

  • Formats: Date, time, temperature, currency and numbering conventions vary vastly from country to country; these will have to be accounted for.

This is by no means a comprehensive list, and even for the items listed above, the nuances are too large to be covered within this piece. The basic aim should always be to develop a database of clear and consistent text, with minimal jargon, local language flavor (exclamations or phrases) and ambiguities.

Also, besides the interface text itself, the interface must be designed in a manner to accommodate differences in label or message widths due to the change in language; most of the time, text written in English will expand when converted to other languages. Application text areas will have to be designed to accommodate that.

And that’s about it for the moment. I hope you found this article enjoyable and useful, and that it offered some tips for the next time you need to create text for your application interface. Happy writing!

Note: Examples are illustrative only, and are not meant for a production environment. Melonfire provides no warranties or support for the source code described in this article. YMMV!

This article was first published on 21 Mar 2003.