Middlebury

Difference between revisions of "MiddTube"

(Nice To Have)
(Nice To Have)
Line 32: Line 32:
 
**Other AD groups
 
**Other AD groups
 
**Guest accounts
 
**Guest accounts
 +
**Group-based management of media (specifically for administrative departments)
 
*tagging
 
*tagging
 
*voting
 
*voting

Revision as of 05:18, 2 December 2007

Description

Using the Flash Media Server as the media manager, we will build a front-end interface to help users manage their own media, implementing a self-service model. Faculty, staff and students can create video on their preferred platform, save a rendered file in a platform-specific format, then upload their media through the Flash Media Encoder, which will convert standard formats to FlashVideo (.flv)*, allowing anyone with the Flash Player to view. Uploading the video can involve compression, reducing the storage space needed to host the media.

* H264 video may be used once we have a new version of Flash Media Server that supports it.

Required Features

  • Users defined by LDAP/AD
    • Frontend application needs to be organized by user
  • Users upload video/audio
  • Users manage their video/audio
  • Generate embed code
  • Default and custom limits on size of upload and storage
  • Granular permissions, allowing restrictions on who can see which videos a user owns, as defined by AD.
    • Public
    • Middlebury only
    • Private
  • if closed source code, then needs API for at least uploading media files

Desired Features

  • Playlists or favorites
  • Users record video/audio in browser, right into their library.
  • RSS feeds of users' channel/playlist
  • Granular permissions, allowing restrictions on who can see which videos a user owns, as defined by AD and/or secondary authentication.

Nice To Have

  • Permissions for other Middlebury users:
    • Class
    • Other AD groups
    • Guest accounts
    • Group-based management of media (specifically for administrative departments)
  • tagging
  • voting
  • folders/groupings/channels of video/audio allowing media created by multiple users to be grouped together.
  • Embed a playlist into a viewer
  • Support for multiple viewers with different feature-sets.
  • Comments on videos
  • Retrieval/Export of videos after graduation.

Potential Client-Side Solutions

View items tagged 'MiddTube' on del.icio.us.

FlowPlayer

Easy to use, open source flash video player with room for customization. Embed code is generated by the Flash player, and native support for playlists and chapters. This player is in use by AbroadView.

Potential Server-Side Solutions

View items tagged 'MiddTube' on del.icio.us.

Broadcast Machine

Broadcast Machine is a video-blogging platform created by the Participatory Culture Foundation. It sounds like it would be very similar to what we are looking for for MiddTube:

3. Run a Community Site
Want to get everyone involved? Broadcast Machine has a simple user management system that lets you accept submissions of videos and video links from visitors to your site (you can require them to register first, if you choose to). This means you can create a channel for a community: let anyone post to an "open" channel and then pick the best stuff to include in more selective channels-- "Featured Videos", perhaps. Perfect for communities and organizations of every kind.

Unfortunately it is no longer under development. They are awaiting funding for a redesign.


Joomla

ACHTube Component for Joomla Youtube site


Wimpy

http://www.wimpyplayer.com/


In-House Development

Advantages:

  • Easy integration with other campus systems.
  • Code would be a known commodity, written to our standards and security practices.
  • Minimal configuration difficulty once written.
  • Access control of videos could follow practices already used in our existing systems.

Negatives:

  • Need to fit the project into already busy schedules.
  • Will need to work out details ourselves rather than relying on other developers.

Several possible tracks...

Segue Component

"MiddTube" could be composed of as several screens within the Segue UI, for instance linked off the user's portal page.

  • Possibly a little easier to do a staged roll-out with only the barest functionality first.
  • Could tightly couple with Segue UI if desired, for very rich integration.

Stand-Alone Application

Would be built similarly to a Segue component (Harmoni-based), but would have its own branding and url.

  • Separate branding from Segue.
  • Could be developed on a different schedule from segue.
  • Could run on separate servers.
  • Looser/standards-based coupling with Segue.