The Importance Of Interface Text (part 2) - Better Safe Than Sorry (
Page 7 of 8 )
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.