 |
|
|
|
|
|
| |
<<Previous | 1
| 2 | 3
| 4 | 5 | 6
| Next>>
|
|
Figure 5. Documentation, help, and even
screens can benefit from diagrammatic presentation, or modular writing.
Yes, it's more work then sentences when creating it. But the time saved
across hundreds of users when reading it can be worth the investment.
Decision tables reduce reading errors, too.
|
|
| |
|
Reduce Memory Work
Issue: Cryptowriting makes end-users
remember too much. What about "acronym acrimony?" Acronyms are
the AKA (Also Known As) for a phrase or product. When the definition remains
TBD (To Be Determined) by the user we have a communication GAP (Greatly
Aggravated Problem). And what about CMOS, BIS, CMS, and ICBM?
Solution: Avoid acronyms. On the other
hand, seeing "International Business Machines" may be equally
surprising to the user who expects to see "IBM." Therefore,
stick with familiar acronyms like DOS, IRS, and BVDs!
Some corollary solutions to memory demands in screen writing:
- Maintain consistent terminology,
e.g., use standard button names (see Figure 6).
- Avoid "read me" files!
(They report discrepancies in the application.)
Who remembers the details when trying to use the application? We have
an actual case that defies comprehension (see Figure
7).
|
|
Figure 6. Your design team should stick
to a single button name for "OK" and "Cancel" functions.
Here are alternatives we have seen. Note that "Close" has a
special meaning in Microsoft-world. It indicates that the window disallows
any edits, therefore, nothing can be "Canceled". Subsequently,
Close is not a universal substitute for Cancel.
|
|
| |
|
|
Figure 7. An actual "read me"
file. The screen terminology failed to match the associated paper forms.
Therefore, the developer had to inflict this tutorial on the hapless end-user.
Could you remember it when using the application?
|
|
| |
<<Previous | 1
| 2 | 3
| 4 | 5 | 6
| Next>>
|
| |
GUI Articles List
|
|
 |
|
