This is a product requirements definition for screencast support on SUMO.

Overview

Screencasts can be thought of as animated screenshots. A good screencast can serve as the unique user experience that bridges a well written how-to article together with interactive live support. Not everyone is comfortable reading written instructions containing complicated computer and software terms; with screencasts, users can instead choose to watch a video demonstrating exactly how to solve the problem.

Since we are unable to provide live support to every single Firefox user (we have north of 250 million of them these days!), screencasts is a leveraged, community-powered solution that come pretty close to live support while still allowing it to scale to meet the demands of our growing user base.

Requirements

File types

• [Required] .swf Flash container OR .flv Flash video
  • .swf must be supported because of our large pool of .swf screencasts from the Screencast Contest
  • .flv must be supported because not all screencast software can export to .swf. Wordpress (Podpress) includes an open source (php) FLV player that we could use to play .flv files.
  • All screencast uploads must include either a .swf or a .flv file.
• [Optional] ogg/theora
  • During or after a screencast upload, it should be possible to also upload an already converted ogg/theora version of the .swf file, in addition to the required .swf file. The ogg/theora file would be used in browsers that support them.

Infrastructure

• Need a server to store screencast files on, e.g. videos.mozilla.org -- location TBD (mrz)
  • SUMO server app needs write access to the storage
• Storage requirements: 10 GB
  • May expand depending on how many contributors upload localized content
• Bandwidth requirements: ~ 1500 GB/month
  • We get approximately 30,000,000 page views per month
  • The average file size of a screencast is 1 MB
  • Let's assume that 5% of all page views will load a screencast
  • 30,000,000 * 0.05 / 1024 = 1,464 GB

Presentation & website integration

Backend

• If an ogg/theora version of a screencast exists and the browser supports the video tag, the ogg/theora file would be used. Otherwise, it would fall back to an object tag with the .swf file, or the built-in video player with the .flv file.

Frontend

• Screencasts can be embedded anywhere in a KB article, including more than one screencast per article
• Typically they will be used above numbered lists of instructions, e.g. Bookmarks not saved
• Since screencasts can be very large in terms of screen space, they should not be embedded upon loading of the article. Instead, only a link/icon should be displayed.
  
  
  
  • Default text of link should be "Watch a video of these instructions" but it should be possible to override when embedding a screencast.
  • Subtle frame around the bar to make it stand out
  • Recognizable Play or Movie graphic to the left of the text
  • Final design to follow shortly (Tara)
• When clicking on the video link, the whole embedded video player (or Flash .swf object) should be displayed, along with links to switch between the Flash or Ogg version of the video, if both exist.
  
  
  
  • Embedded Video object on already existing mozilla.com page -- copy this
  • Box should correspond to the size of the video object (with a lower limit to ensure UI doesn't look broken)
  • Link at the bottom to switch source from Ogg to swf/flv and vice verca (default should be to load the Ogg file if it exists and if the browser supports it)
  • Make sure the Ogg video is the default format for capable browsers, and embed the Ogg file in the same way as the flash file is embedded (i.e. don't do it like they do with just leaving the page altogether to display the raw .ogg file).

Uploading & managing screencasts

Backend

• All screencasts must be stored on our server to ensure we control the content. If screencasts are stored externally, people might replace an existing screencast with offensive/illegal content.
• Never overwrite existing files -- For security, when uploading a screencast with the same name as an existing screencast, the old file should not be overwritten. Need some unique hash to ensure that all file names are unique.
• Naturally because of SUMO's review system, a screencast will always show up on the staging article first, allowing reviewers to approve the content before it's shown to our users. Note: this is not a requirement, just an explanation of how we're protected against malicious content.
• It should be possible for contributors to upload an .ogg version of an existing screencast that only has a .swf file.
  • Need to figure out how the new .ogg file can be inserted to the article(s) that is using the screencast. We need to track which articles use which screencasts in the database so we can identify orphans (as we do with images).
  • Also need to ensure the complementary .ogg file is not malicious and that it's indeed just a converted copy of the .swf file. Maybe we only allow trusted contributors to upload complementing .ogg files of existing screencasts? Answer: ogg is no more likely to be malicious than flv. Review to check both files as part of review.

Frontend

• Use same mechanism as for images -- two simple upload fields in the Edit Article view; one for .swf (required) and one for .ogg (optional).
  • See bug 450548 comment 13 for how this is currently implemented for screenshots
• Allow people to provide a url to existing .swf/.ogg files, but always grab that file and store locally
  • Question: can URL support work in the same text field, or would we need separate fields for URLs? This requirement is not critical, so if it's too complicated to do this, let's drop it.
• Show a progress bar using jQuery when uploading a screencast, since the operation can take quite a while to complete.

Wiki syntax for embedding screencast

• Simple tag taking file names and size as parameters - TBD (zzxc)
• Example: {SCREENCAST(flash=>jing-filename.swf,ogg=>video.ogg,label=>Watch a video of these instructions)}Title of video{SCREENCAST}, where either swf OR flv is required and ogg is optional.)} (flash type should support either swf or flv)
• Question: Do the dimensions have to be known by this plugin, or can that info be extracted from the video itself?
  • If they have to be known, we need parameters for that too in the plugin.
  • What about different sizes for different formats? (E.g. the OGG version has different dimensions compared to the SWF version.)
• The title of the video can also be a parameter if the above syntax isn't possible (it is just an example; I don't know all limitations of TikiWiki plugin syntax!). So, this works too: {SCREENCAST(flash=>jing-filename.swf,ogg=>video.ogg,label=>Watch a video of these instructions,title=>Title of video)}{SCREENCAST}

Timeline

• PRD finalized Q1 2009
• UI finalized early Q2
• Server Backend / IT stuff done April 2009
• Implementation / frontend stuff finished May 2009

Tasks

• Get server storage up
  • video.mozilla.org/sumo? (IT)
  • Ensure that SUMO web app can write to this storage folder
• Investigate whether we can just use the open source (php) FLV player used in Podpress to play .flv files.
• Implement frontend for uploading screencast to wiki article, using jQuery for the progress bar.
  • Use similar UI as the screenshot uploader, i.e. after uploading show a thumbnail that can be clicked on to insert the code snippet into the editor.
• Implement {SCREENCAST} TikiWiki plugin that can display/embed a screencast in an article.