We will adopt some basic design principles from various sources. For now, We are using Jakob Nielsen's guidelines on error messages 1:
Explicit indication that something has gone wrong. The very worst error messages are those that don't exist. When users make mistakes and get no feedback, they're completely lost. Email, for example, offers several situations where explicit indication would be useful. Such as: When you send a message that gets eaten by the system and never reaches the recipient. Another good example? When you state in an email that you'll include an attachment, but forget to do so. Finally a job for that annoying paperclip: "You seem to want to attach a file to this message, but you have not done so. Would you like to attach one now?"
Human-readable language, instead of obscure codes or abbreviations such as "an error of type 2 has occurred."
Polite phrasing that doesn't blame users or imply that they are either stupid or doing something wrong, as in "illegal command."
Precise descriptions of exact problems, rather than vague generalities such as "syntax error." In addition to this Nielsen recommendation, we add that error messages should avoid ambiguous or dual meanings. For example, no "You file was either corrupted or you do not hav permissions to access it." The errors for these two problems are completely different, and both are easily determined (the first, the file reads in correctly, but does parse; the second, the file cannot be opened at all). Sometimes this can't be avoided because of platform constraints.
Constructive advice on how to fix the problem. For example, instead of saying "out of stock," your error message should either tell users when the product will be available or provide a way for users to ask to be notified when the product is restocked.
This should prove a bit more difficult considering that much of the work is done by processing modules implemented by the Domain Developer. We'll have to provide simple methods for Domain Developers to meet these goals.
The interface guidelines will follow Jakob Nielsen's general guidelines for interface usability, plus additional rules that must be followed in the project to get the simplicity we require. 2 - 1994 of relevance to Generic Interface Generator are:
Feedback should be immediate, complete, minimal, and provide visual cues to help the user in their task. Altering available features depending context is also beneficial.
The system should use the same terminology as what the user is familiar with. A lot of this will depend on the Domain Designer, but we should provide tools to help. Also, the domain languages used should not be so wilding different from the target concepts that they are unfamiliar.
Actions should be reversible, and the user should be able to make mistakes without getting into trouble.
The key with this is that similar objects should look and act the same, and that standards are created defining what the system should look like.
Design the interface so that errors are prevented in the first place. This is hare to do in Domain Modeling since so much of the activity depends on the interpretation of the model by the Model User and Domain Designer.
Users should not have to memorize model contents, but rather see what is available and work with that. For example, use a "see and point" rather than a "remember and type" mode of operation.
Since this is a system targeted at expert users in the programming field, we will need to provide capabilities that help them work faster after they learn the basics. Such things as accelerators, augmenting with scripting (the whole system is done this way really), and macro capabilities are essential.
With these standards, the interface should be very easy to use and will follow a consistent model. It should not be hard to follow these guidlines, since there will be a very small number of interface elements.
These standards should prove very challenging with this project since quite a lot of these decisions are in the hands of Action Developers. ObveRsive will need to provide support for Action Developers to interact with the user and the project will need to provide many examples of how to maintain these goals.
Also, the fact that R is a bit more complicated than your average desktop application makes some of these very difficult. The requirement of "Recognition rather than recall" is possible with Actions Scripts that hide much of the details of the R language and provide this very type of interface. It is fairly difficult to meet this requirement with the R Console portion of obveRsive since that interface relies on the user's memory just like traditional R does (and is probably one of the reasons R can be difficult).
Last edited on Wednesday, October 16, 2002 11:32:02 pm.
 
 |
|