| Line 1: | Line 1: | ||
| − | = Software Bounty: A/V tools for Rhea | + | = Software Bounty: A/V tools for Rhea = Description of Tools: <...to be written during meeting...> == $ Amount: == |
| − | + | ||
| − | Description of Tools: <...to be written during meeting...> | + | |
| − | + | ||
| − | == $ Amount: | + | |
<pre>Audio: $250 (Audio Only) | <pre>Audio: $250 (Audio Only) | ||
Video: $550 (Includes Audio as Part of Video Format) | Video: $550 (Includes Audio as Part of Video Format) | ||
------------ | ------------ | ||
| − | A/V: $800 (Independent Audio and Video</pre> | + | A/V: $800 (Independent Audio and Video</pre> |
| − | == Bounty Requirements/Acceptance Criteria*<br> | + | == Bounty Requirements/Acceptance Criteria*<br> == #Software must complete all of the proposed use-cases as specified. #Software must meet the Usability Rules as proposed by Constantine & Lockwood in their text ''Software For Use'' - see below #It is highly suggested that developers follow User-Interface Design Principles as proposed by ''Software For Use'' - see below == 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.<br> == 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 Team == All submissions will be evaluated by a team of volunteers. Anyone who is not submitting a project is welcome to participate. Current SETeam: #Andrew Haddad #Dhruv Lamba #Anshita Kumar == 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. |
| − | + | ||
| − | #Software must complete all of the proposed use-cases as specified. | + | |
| − | #Software must meet the Usability Rules as proposed by Constantine & Lockwood in their text ''Software For Use'' - see below | + | |
| − | #It is highly suggested that developers follow User-Interface Design Principles as proposed by ''Software For Use'' - see below | + | |
| − | + | ||
| − | == 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.<br> | + | |
| − | + | ||
| − | == 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 Team | + | |
| − | + | ||
| − | All submissions will be evaluated by a team of volunteers. Anyone who is not submitting a project is welcome to participate. | + | |
| − | + | ||
| − | Current SETeam: | + | |
| − | + | ||
| − | #Andrew Haddad | + | |
| − | #Dhruv Lamba | + | |
| − | #Anshita Kumar | + | |
| − | + | ||
| − | == 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. | + | |
Revision as of 12:32, 9 April 2010
Software Bounty: A/V tools for Rhea = Description of Tools: <...to be written during meeting...> == $ Amount: =
Audio: $250 (Audio Only) Video: $550 (Includes Audio as Part of Video Format) ------------ A/V: $800 (Independent Audio and Video
== Bounty Requirements/Acceptance Criteria*
== #Software must complete all of the proposed use-cases as specified. #Software must meet the Usability Rules as proposed by Constantine & Lockwood in their text Software For Use - see below #It is highly suggested that developers follow User-Interface Design Principles as proposed by Software For Use - see below == 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 Team == All submissions will be evaluated by a team of volunteers. Anyone who is not submitting a project is welcome to participate. Current SETeam: #Andrew Haddad #Dhruv Lamba #Anshita Kumar == 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.
