web karaoke

(attached doc is the same as here) wk_spec_003 1. OVERVIEW i. Develop a web-based Karaoke Player and surrounding community ii. Mouse-over of text (which generates small pop-up ‘windows’) is required iii. Platform – as a web-based site, this product must operate on standard web-browsers running on standard operating systems, including but not limited to: Windows (2000, XP, Vista), Mac OS, Linux, UNIX; Mozilla, IE, Firefox, Opera, Netscape, AOL iv. Service provider must experience/work-with Singshot and either KaraFun or Karoke Builder. 2. DEFINITIONS a. PRODUCER - one who produces karaoke content b. CONSUMER - one who views/listens-to/uses karaoke content c. CONTENT - karaoke material (text, audio, synchronization data) 3. REFERENCES and what must be emulated about them: a. [login to view URL] i. community 1. Consumers don’t need to register to use Content 2. Consumers can register, allowing their participation, comments, voting, utilization tracking 3. Producers must register 4. Content is searchable (by Producer, and other ways) ii. player 1. easy to use / simple controls 2. random access (can jump to various parts of Content) b. KaraFun or Karaoke Builder (do a websearch and install this application) i. Player 1. SHOULD BE WEB-APP, not downloadable application 2. Note: how they allow the user to do synchronization between audio and video 4. USAGE a. See diagrams below b. Ex1: i. User goes to website ii. Users searches for Content via text search or Producer search. iii. Users selects/invokes one of search results and enjoys the Content, hitting pause when necessary or backing up Content to an earlier point if desired. iv. User discovers that mouse-over of certain words in the Content’s text result in pop-ups which have links or information in them c. Ex2: i. Producer logins in to website ii. Producer looks at all Content she has made (in future she can look at comments by Consumers) iii. Producer updates her profile and logs out. d. Ex3: i. A company which thinks there text-content has been stolen and used by a Producer on our site goes to the website ii. Person does a search for text in their song/content. (ex: “so I call you on the phone”) iii. Site returns a list of content iv. Person looks and profile of each Producer whom he thinks might have infringed and sends them each an email 5. DELIVERABLES • First Deliverable: o A simple interface through which a user can:  Upload an audio file (format can be discussed)  Upload a text file (Unicode probably, but open to discussion)  Perform synchronization between to these two files (see how the KaraFun editor works for an idea of how this might easily be done, using the space bar).  See a list of all (or a filtered list of) “karaoke” files, select one, and play it.  Player must have • Pause/play toggle button  (Note that the mouse-over capability required later should probably be thought about early on.)  The method by which synchronization is indicated is open to discussion and is largely up to the service provider to determine what is best/simplest (considering that mouse-over capability will be required on a word-basis). It should be attractive looking. • The words might be highlighted as the synchronization moves. • A ball of slider might move below the words. • The viewing panel might be divided into rows of text and graphics, where a graphics row is below each text row. In the graphics row a synchronization indicator moves. • Second Deliverable o Create a community framework  A simple suggestions button which would allow users to supply feedback.  There are PRODUCERS and CONSUMERS. Producers make the CONTENT and Consumers use/view/listen to it.  PRODUCERS must have a login. (Perhaps just a passphrase?) They should have a series of fields where they can describe themselves (gender, location, age, picture, link to their website, et cetera). All content they produce will be linked to them.  CONSUMERS are not required to have a login. Without a login, they can use content. With a login, they can also • keep track of which content they have used • Rate content o Quality (3, 2, 1) o Usefulness to them (3, 2, 1)  CONTENT will • Optionally, be withheld from posting to site until approved by a monitor of web-site • Be tagged with information about Producer • Be tagged with information about Content source/s (ex: the text came from [login to view URL] or the audio came from “Lenny Jenkins basement rock-n-roll recording 2007-Jan-1st”. • Be tagged based upon how many times it has been used and how it has been rated • Be tagged in other ways. • Although content (audio, text, synchronization) might be merged into an existing or new file format, the original files (audio, text, synchronization) must also be maintained as individual files and be linked to the combined file, if there is one. (Of course, the player might just synchronize the files and not require that they be in one file.)  Search – Consumers can search the text of the Content (the actual lyrics and words) or for works by certain Producers or by other Content tags. • Example1: A search for “love” might find 10 items and it will show the snippets of text as line items (Google-style) and let the user select one, invoking the playing of that content. • Example2: A search for content that has been tagged with a specific tag. • A collection of terms searched will be maintained and provided to the Producers. • Third Deliverable o While the Consumer is experiencing the Content, there must be mouse-over capability on a word basis. Features:  Mouse-over on a word shows a small pop-up window containing data (maybe an advertisement or a web-link or a link to other Content on the site)  After doing a mouse-over, the user might click and store that data to their clipboard.  Data will be provided as a database or XML-type file. The service provider may want to have this data linked in to the content when it is created (meaning there are four pieces: audio, text, synchronization, and also mouse-over text data). • Fourth Deliverable o Producer can insert text content and edit it via a web form/tool as opposed only being able to upload it. o Producer can create audio content via a web tool as opposed to only being able to upload it. • (FUTURE FUNCTIONALITY – please consider as you may be asked to do future development) o Mouse-over additional functions  User can not only mouse-over certain words of Content text and see pop-ups (maybe an ad or link to that reference), but NOW they can click and save that pop-up information (to a clipboard or database) o User can randomly access different parts of the Content by clicking within the ‘window’ where the text is shown. (Maybe earlier there were buttons, but this now will give a simple way to jump to certain sections or lyrics.) OTHER NOTES: • For each deliverable, service provider will setup site on a web-host’s machines. [login to view URL] will be used, unless they lack some required support, in which case service provider will recommend a suitable alternative. • Some items may have been left out of this description which are required and implicit to make a working product. • If service provider is a firm, they must indicate clearly who the developer/s will be and provide direct contact (email, voice, IM) to developer/s. (A non-hire agreement can be signed if that is a concern.) Provider must allow us to keep very close tabs on development and monitor its progress (or lack of progress) on a daily basis. • In general, the site should be SIMPLE to use, CLEAN and uncluttered looking. • Aesthetic Notes: o Ideal: Skype (the tool not the website), Gliffy (the web tool) o Anti-ideal: Avoid the Look of: eBay, yahoo (both are cluttered pages) • Here are some crude drawings of what we have in mind. 1 [login to view URL] 2 [login to view URL] 3 [login to view URL] 4 [login to view URL] 5 [login to view URL] (for some reason these are not appearing when I load them. I may need to send separately.) A major goal is to have a Beta running as soon as possible so that Producers can begin making content and potentially help us work out kinks.