$800 Software Bounty: A/V tools for Rhea

The goal of this bounty is to enable Rhea users to easily upload and view video and/or audio files. You must be a Purdue student in order to participate. You may choose to work either on the audio portion of the bounty, the video portion of the bounty, or both together. You will be responsible for integrating your software to the current Rhea code.

As soon as we receive a functional piece of code, we will announce that there remain 14 days to the competition: anybody who wishes to compete must hand in their code before 14 days have passed in order to be considered for the bounty. The author(s) of the best software that satisfies the requirements will receive the money. Note that we strongly prefer open source solutions...

If none of the software competing is satisfactory, we will reopen the call for bounty until the money is claimed.

We thank the Motorola Foundation for their financial support for this competition.

Questions? Write them below or talk to Andrew Haddad haddada@purdue--Haddada 17:54, 9 April 2010 (UTC)

$ Amount:

Audio:	$250 (Audio Only)
Video:	$550 (Includes Audio as Part of Video Format)
------------
A/V:	$800 (Independent Audio and Video

Use Cases

The software developed must satisfy the following use cases:

• uploadingFromFile
• capturingFromComputer
• uploadFromURL
• postingToAPage
• watchingAVideo
• listeningToAudio
• publicizingMedia
• controllingMedia (play, pause, FF, RW)
• deletingMedia
• watermarkingMedia
• downloadingMedia
• compressingMedia (on upload)
• splittingMedia (on upload)

Bounty Requirements/Acceptance Criteria*

1. Software must complete all of the proposed use-cases as specified.
2. Software must meet the Usability Rules as proposed by Constantine & Lockwood in their text Software For Use - see below
3. It is highly suggested that developers follow User-Interface Design Principles as proposed by Software For Use - see below

Getting Started

We will soon have an SVN repository available to checkout a testing/integrating codebase.

Usability Rules[1]

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
2. Efficacy: The system should not interfere with or impede efficient use by a skilled user who has susbtantial experience with the system.
3. 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.
4. 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.
5.  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]

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.
2. 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.
3. Visibility - Keep all needed options and materials for a given task visible without distracting the user with extraneous or redundant information.
4. 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.
5. 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
6. 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.

If the Audio or Video is completed separately, it will be compared to the A/V projects and a decision will be made to announce a new bounty for Video or Audio respectively or accept a full A/V project.

Current SETeam (Anyone who is not submitting a project is welcome to participate.):

1. Andrew Haddad
2. Dhruv Lamba
3. 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.

Questions

• Write a question here
  • answer will be written here
• write another question here
  • answer will be written here.

Back to Rhea Bounty Page