Talk:An institutional workflow

From Steeple

[CM] I think I should point out that I'm looking to completely overhaul the information on naming conventions, based on our experiences, some of the following may apply:

Audio Encoding

• I am being swayed by the idea that providing AAC encoded files would be beneficial, and perhaps target those directly at iTunes U users whilst primarily using the MP3 files for web portals.
• I'm not yet sold on the 3GP format or value of such outputs
• Introducing Ogg encoded content is an easy win to support those users who want file formats they feel are free of patent issues, or that they can not get playback software for on their less mainstream platforms
• I don't believe that encoding content for WMA is worthwhile. As a format it has little merit over the alternatives and a wildly varying user experience on a single platform. Whilst Microsoft does not support MP4/H264/AAC natively in any of their freely provided media playback applications, they do support MP3 for audio.
• Silverlight is a possible ray of sunshine for the Microsoft platform as, similar to Adobe Flash, they are now (from late 2008 in beta, full release of Silverlight 3 July 2009) supporting H264 and AAC formats within the framework. Unfortunately the Silverlight penetration of the market is still very very low and I'm not personally convinced it will really take off like Flash has.

Carl, I have a list of formats here: http://www.sciencemedianetwork.org/Multiformat_Media_Delivery. It's an older list, and aimed at being comprehensive. I've added an update now. You might find it useful. Bjoern 14:10, 27 August 2009 (UTC)

Bjoern, indeed a useful listing and in more depth than I've so far written down anywhere. I agree with 98% of it ;) I also think it's very useful and am pondering how we can best reference the material to avoid duplication. You may need an extra note on Silverlight with respect to Flash and video capabilities. It potentially changes the landscape for H264 with Windows platforms. I'm still trying to determine whether Microsoft have introduced any native support for H264 playback within the Window 7 platform - my feeling is that they are trying to defend the position of WMV and exclude H264 as much as possible. Also, your notes on HTML5 need a little more updating with reference to Safari/Webkit support for <video>, etc. I'm not sure how much public material is available detailing it so far, but I've got a fair few notes from WWDC'09 which I can probably discuss with you.

I've done a new table of formats now, see [1]. I've added some notes about Silverlight too, and yes I do need to write more about html5 too :-) Maybe I could do a short version - which bits do you disagree with? Bjoern 17:41, 27 August 2009 (UTC)

Location of media files

• There should be a level of abstraction between the physical location of the files and the presented URL to the content. This will facilitate underlying physical layout changes as technology systems evolve and are replaced without breaking the historical linking to the content. This could likely be implemented as part of a CMS with URL rewriting, or via a more manual process of rewriting URL linking via Apache conf
• I'm falling more in favour with the idea of a flat filestore that groups related content items within folders or packages, typically uniquely identified via GUIDs. Whilst this removes a human readable view of the filestore directly, it becomes much easier to manage programmatically and removes conflicts over naming and changing heirarchies/multiple homes, etc. Part of breaking the linkage between use of content and the presentation/linking to of content

RSS and Web URLs

• Should start taking account of SEO/SEF concepts by using or repeating keywords/titles as part of the presented path. As content items can and should be able to appear in multiple locations, the path to an item could vary and be better utilised to increase it's relevance and discovery rate.
• The multiple, similarly named RSS feed approach is still necessary to support multiple file formats for a single item of content. However, this may be subsumed by an Atom based metadata service in the near future.
• We need something to support the idea about keeping feed content types separated (e.g. Audio/Video/PDF).

Recording of access data

• The minor overhead involved in abstracting the linkage between URL and content allows more effective methods of data collection to be introduced.
• We can not overemphasise the importance of being able to accurately and authoritively capture as much user access information as possible. A key problem within our (Oxford) process is that our filestorage is widely devolved and data collection strategies almost non-existant. This makes it near impossible to understand anything about our audience and their interests and technical systems, which makes enhancing or supporting our users less informed.