(New page: == Usability Rules[1] == #Access: The system should be usable, without help or instruction, by a user who has knowledge and experience in the application domain, but no prior experience ...) |
|||
| Line 18: | Line 18: | ||
== Software Evaluation == | == Software Evaluation == | ||
| − | From the time a project is submitted, all others who wish to submit a project will have 2 weeks to finish their projects and submit it. The software will then be evaluated by the SET team. | + | From the time a project is submitted, all others who wish to submit a project will have 2 weeks to finish their projects and submit it. The software will then be evaluated by the SET team. Unless time constraints make this impossible. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== References == | == References == | ||
[1] Constantine, Larry L., and Lucy A. D. Lockwood. Software for Use: a Practical Guide to the Models and Methods of Usage-centered Design. Reading, Mass.: Addison Wesley, 1999. Print. | [1] Constantine, Larry L., and Lucy A. D. Lockwood. Software for Use: a Practical Guide to the Models and Methods of Usage-centered Design. Reading, Mass.: Addison Wesley, 1999. Print. | ||
Revision as of 10:17, 7 December 2010
Contents
Usability Rules[1]
- Access: The system should be usable, without help or instruction, by a user who has knowledge and experience in the application domain, but no prior experience with the system
- Efficacy: The system should not interfere with or impede efficient use by a skilled user who has susbtantial experience with the system.
- Progression: The system should facilitate continuous advancement in knowledge, skill, and facility and accomodate progressive change in usage as the user gains experience with system.
- Support: The system should support the real work that users are trying to accompluish by making it easier, simpler, faster, or more fun or by making new things possible.
- Context: The system should be suited to the real conditions and actial environment of the operational context within which it will be deployed abd used.
User-Interface Design Principles[1]
- Structure - Organize the user interface purposefully, in meaningful and useful ways based on clear, consistent models that are apparent and recognizable to users, putting related things together and seperating unrelated things, differentiating dissimilar things and making similar things resemble one another.
- Simplicity - Make simple, common tasks simple todo, communicating clearly and simply in the user's own language and providing good shortcuts that are meaningfully related to longer procedures.
- Visibility - Keep all needed options and materials for a given task visible without distracting the user with extraneous or redundant information.
- Feedback - Keep users informed of actions or interpretations, changes of state, or condition, and errors or exceptions that are relevant and of interest to the user through clear, concise, and unambiguous language familiar to users.
- Tolerance - Be flexible and tolerant, reducing the cost of mistakes and misuse by allowing undoing and redoing while also preventing errors wherever possible by tolerating varied inputs and sequences and by interpreting all reasonable actions reasonably
- Reuse - Reuse internal and external components and behaviors, maintaining consistency with purpose rather than merely arbitrary consistency, thus reducing the need for users to rethink and remember.
Software Evaluation
From the time a project is submitted, all others who wish to submit a project will have 2 weeks to finish their projects and submit it. The software will then be evaluated by the SET team. Unless time constraints make this impossible.
References
[1] Constantine, Larry L., and Lucy A. D. Lockwood. Software for Use: a Practical Guide to the Models and Methods of Usage-centered Design. Reading, Mass.: Addison Wesley, 1999. Print.
