For those who find this site, this is a partial copy of the official blog which can no longer be updated from that live site due to a change in the service provided by OUCS.
Please visit the official blog site at http://steeple.posterous.com/ for all the latest news and an RSS feed of postings.
For those tracking what’s going on, but not noticing the wiki or the mailing list, here’s a brief reminder of our (last?) Benefit’s Realisation Workshop for Steeple. We’re gathering at UCL on Monday 22nd November for a 1 day workshop to cover a range of topical issues. More details can be found at http://www.steeple.org.uk/wiki/BR/Workshop_Nov_2010_UCL.
See some of you in London 
Carl
http://www.theregister.co.uk/2010/09/30/downloads_performance_ruling/
The above story caught my eye in relation to a US court decision to term “downloading” as not equal to “performance”, but to say that “streaming” is a “performance”. It’s got me curious about the UK position on the matter now, but since IANAL, I’m not going to chase that one for a while.
I have the feeling that this judgement could make an interesting impact on damage calculations for say, a libellous (or is it slanderous?) recording. After all, if they’re podcasts and being downloaded, they’re not being performed, so has a person been damaged by them? But if it’s youtube, or a streamed output… well…
And if that logic holds, does this suggest that any perceived “risks” to an institution are less from podcasting than streaming?
Anyhow, the Steeple blog isn’t dead…it’s just a little quiet at the moment with my being busy on various other projects. Some more coming this way in the next few months though as I’m tackling stats and monitoring/management setups for institutional podcasting.
Carl
Greetings all!
We’ve recently (i.e. in the last hour) added some new resources to the Steeple website that could well be of interest to you:
Launching iTunes U Project Kit
This collection of slides, documents and notes was compiled by Apple in conjunction with Steeple and it’s members to provide a starters guide for anyone else looking to join the iTunes U public system. You can find the kit referenced in the Outcomes and Outputs section of the Project Report on the Steeple Website.
Quicklinks to download for:
Open University Podcasts
There are three video and three audio podcasts from the OU about their podcasting experiences, including a new audio podcast discussing issues of Rights management. You can find these files on the Steeple website in Resources -> Audio and Video -> OU Podcasts.
New interviews with community members
Another output from the Open University as part of the Steeple project is this collection of 11 audio interviews with various academic, support and administrative staff from 5 institutions within the Steeple community, where they discuss their experiences with podcasting and service creation within their institution.
You can find all these under the Interviews heading on the OU Podcasts page within the Steeple Website (Resources -> Audio and Video -> OU Podcasts).
Thus concludeth my marketing message for you today. More news soon on the recent Workshops run through our Steeple Outreach programme (Steeple BR) including screencasts and notes.
Carl
There’s much debate going on in multiple locations about the future of various video codecs and playback mechanisms. If you’ve not already seen them, I’d recommend a read through these two postings from Jeroen Wijering, creator of perhaps the most popular flash based video playback tool in use on the web.
I mentioned the debates, well ignoring the official ones around the standards group, I’m paying close attention to those going on within the Terana TF-Media and the Opencast community (notably a discussion group being pulled together by Brian O’Hagan). I’ll report more on my observations and our actions as we move on.
Carl
Techie note that might be of help to some, and one I’ve just encountered.
Problem: Unable to publish a workflow to Podcast Producer 2 cluster – Client returned Unknown Error with a little yellow triangle warning.
Also found:
- that I could not connect to the PcP2 server via Podcast Capture on either the host server or any remote machines; – that the podcast cli was failing with:
LTGS-Macbook:zinstance ltgadmin$ podcast –installworkflow -s cynewulf.oucs.ox.ac.uk -u ADMINUSER -p PASSWORDHERE –path /Users/ltgadmin/Documents/Basic\ Single\ Test\ 1.pwf Packing workflow bundle: /Users/ltgadmin/Documents/Basic Single Test 1.pwf…
Packed workflow bundle archive: /var/folders/T5/T5mWe7F+GXWdPTvQsSRQxE+++TI/-Tmp-/podcast-workflow-download-CD308355-34A8-4B0D-ACDB-F11369786B68-20100611-7686-10decbx/CD308355-34A8-4B0D-ACDB-F11369786B68.pwf.cpgz
Installing /Users/ltgadmin/Documents/Basic Single Test 1.pwf…
Destination server: https://cynewulf.oucs.ox.ac.uk:8170/podcastproducer
Destination workflow: Basic Single Test 1
NoMethodError
/usr/lib/podcastproducer/auth/auth_challenge.rb:37:in `auth_properties_to_hash’/usr/lib/podcastproducer/auth/auth_challenge.rb:31:in `each’/usr/lib/podcastproducer/auth/auth_challenge.rb:31:in `auth_properties_to_hash’/usr/lib/podcastproducer/auth/digest_auth.rb:22:in `generate_authorization_header_value’/usr/lib/podcastproducer/client/remote_command.rb:141:in `add_digest_authorization’/usr/lib/podcastproducer/client/remote_command.rb:393:in `execute_once’/usr/lib/podcastproducer/client/remote_command.rb:284:in `execute’/usr/lib/podcastproducer/client/remote_command.rb:281:in `each’/usr/lib/podcastproducer/client/remote_command.rb:281:in `execute’/usr/lib/podcastproducer/client/remote_command.rb:66:in `post’/usr/lib/podcastproducer/client/workflow_administration.rb:121:in `install_workflow’/usr/bin/podcast:1002
Remote command ‘https://cynewulf.oucs.ox.ac.uk:8170/podcastproducer/workflows/create_upload’ failed: undefined method `-’ for nil:NilClass
- or something simpler:
LTGS-Macbook:zinstance ltgadmin$ podcast –listworkflows -s cynewulf.oucs.ox.ac.uk -u ADMINUSER -p PASSWORDHERE
NoMethodError
/usr/lib/podcastproducer/auth/auth_challenge.rb:37:in `auth_properties_to_hash’/usr/lib/podcastproducer/auth/auth_challenge.rb:31:in `each’/usr/lib/podcastproducer/auth/auth_challenge.rb:31:in `auth_properties_to_hash’/usr/lib/podcastproducer/auth/digest_auth.rb:22:in `generate_authorization_header_value’/usr/lib/podcastproducer/client/remote_command.rb:141:in `add_digest_authorization’/usr/lib/podcastproducer/client/remote_command.rb:393:in `execute_once’/usr/lib/podcastproducer/client/remote_command.rb:284:in `execute’/usr/lib/podcastproducer/client/remote_command.rb:281:in `each’/usr/lib/podcastproducer/client/remote_command.rb:281:in `execute’/usr/lib/podcastproducer/client/remote_command.rb:49:in `get’/usr/lib/podcastproducer/client/workflow_administration.rb:20:in `list_workflows’/usr/bin/podcast:861
Remote command ‘https://cynewulf.oucs.ox.ac.uk:8170/podcastproducer/workflows?language=en’ failed: undefined method `-’ for nil:NilClass
… but that the PcP2 web interface worked just fine with any valid username and password I tried.
Looking at the PcP2 logs I would see:
From attempts to login via Podcast Capture (on host server):
Processing WorkflowsController#index (for 163.1.13.145 at 2010-06-14 15:58:03) [GET]
Parameters: {“action”=>”index”, “language”=>”en”, “version”=>”2″, “controller”=>”workflows”}
Rendering default/failed.xml.builder (401)
Filter chain halted as [:authorize] rendered_or_redirected.
Completed in 32ms (View: 1, DB: 2) | 401 Unauthorized [https://cynewulf.oucs.ox.ac.uk/podcastproducer/workflows?version=2&langua...]
From successfully login via Podcast Producer Web Interface:
Processing CaptureController#login (for 129.67.101.46 at 2010-06-14 16:01:37) [GET]
Parameters: {“action”=>”login”, “controller”=>”capture”}
Rendering capture/login
Completed in 10ms (View: 5, DB: 3) | 200 OK [https://cynewulf.oucs.ox.ac.uk/podcastproducer/capture/login]
Google and Apple Mailing lists have been my friend in terms of finding a working solution, however I’m not yet confident about the cause of the upset in the first place. We have been doing some work to create a working OD for our institution based off of our lack of a central directory service, but this should not have impacted on the Podcast Producer setup, nor the machines used to connect to the PcP2 service, nor the accounts used (as they’re locally created in the OD, not imported from outside).
The Solution was to remove the Digest option from the http_auth_type keyset in the cluster_preferences.plist as described here:Greetings fellow Steeplers
Time for a quick update… Rumours of our demise are exaggerated, the official funding for the main project has come to an end but our community work is still active and funded through our Benefits Realisation programme, led by the fantastic Dr B based at Cambridge. Our final report has been accepted by JISC and can be read online via our website or you can download a pdf of the report from the same location. This blog (and associated Twitter feed) are remaining active and I’ll be posting irregular updates as often as I can with news, notes from Oxford, bits of Steeple documentation that was left out for various reasons and more. You too can provide updates to keep this an active channel for UK HEI podcasting news and notes by posting here too – drop me a line at steeple@oucs.ox.ac.uk for me to let you know how. In other news and to explain the recent silence, I’ve been out of the country for a month honeymooning with my new wife and enjoying the delights of P&O’s Arcadia and the Caribbean… back now in sunny (though cooler) Oxford where I’m still working through some of the outstanding emails, so those that are expecting to hear from me, please be patient a little longer
Carl
In a ironic piece of timing, I had the pleasure to be catching up on a series of Podcasts, most recently from Stephen Fry, just after I’d written the previous posting. Now, I’m going to commit some more of the sins he talks about simply through this bit of self-indulgence of sharing the link to his Podgram with you.
var agent=navigator.userAgent.toLowerCase(); var is_iphone = (agent.indexOf(‘mobile’)!=-1) && ((agent.indexOf(‘iphone’)!=-1) || (agent.indexOf(‘ipod’)!=-1)); if (is_iphone) { $(‘quicktime_embed-jwbmqBqlIg’).show(); $(‘flash_embed-jwbmqBqlIg’).hide(); } else { $(‘flash_embed-jwbmqBqlIg’).show(); $(‘quicktime_embed-jwbmqBqlIg’).hide(); }
Why? If only because he eloquently speaks with humour and zest about several of the feelings I went through yesterday whilst mashing the keyboard to produce that “wee”± note. So, mindful of being shorter, I’ll stop right there…
Carl
±Yes, I will have to realise that, often, I don’t do short in a first draft. Keep watching this space, and it might receive some judicious editing, but then again, as an experimental outpouring of ideas and momentary perceptions, maybe it won’t.
It’s final report time in the JISC project land of Steeple. For those unfamiliar with the wonderful world of JISC funded activities (which included myself prior to this), this intensive period of a month or so at the end of a project is largely focussed on delivering three Documents for submission to our funder. These include: a Budget Report where the dry numbers of spending and actions are accounted for and then left for scrutiny by the kind of people who don’t believe in daylight and joy (or so I imagine…); a Completion Report which reads like a blow-by-blow account of what was originally planned and proposed over 18 months ago contrasted to what came out of the mill after the wheel-of-time ground through the efforts and imagination of this creative and talented project team.
And a Final Report.
Yes. Quite. A Report. Finally. On what the project is about…
Hmmm.
I find I’m not particularly fond of blank pages. A need to fill them with insightful content motivates me, but when faced with the blank pages that start this Final Report, I find myself pulled in so many directions. So, I’m writing this wee note (they always start as wee notes) partly as a way to help me structure these concepts and directions a little more, and partly to let you know some of the motivations behind some of what we are going to say in that document.
Writing for this report leads to a lot of reflective thinking, something which has been challenging to do in amongst the work and activities we have collectively done. The purists amongst you can debate project management mantras and theories with me at length another time (and ideally in a bar, after you’ve plied me with drink), and of the value of constant evaluation and reflection. I will simply state that reality hasn’t allowed for such noble ideas to flourish, and that perhaps our ambition and drive to deliver so much to so many, hasn’t been restrained enough to dot the i’s and cross the t’s.
Let me reflect for a moment on collaboration, chiefly the makeup of the project team, just so you can imagine day to day life in the Steeple world a little better. We have a creative and talented Principle Investigator in Peter Robinson (based in Oxford) who provides the core direction for Steeple’s work. Though when I say “have”, I should clarify that we have about a fifth of his time officially – or a day a week. As we are spread across three institutions along an arc 100 miles around London, we can note that there are local Project Managers to facilitate oversight of work in these locations.
Laura James has been the woman on point at Cambridge, and the tiny % of her that Steeple claims has been to work with a percentage of Bjoern Hassler (another immensely creative and passionate advocate for the use and development of media in education) and a few weeks of Aaron Zeckoski (Cambridge Portal developer). After finishing another project, the remaining % of Bjoern is now energising the Steeple Outreach mini-project funded through the Benefits Realisation portion of the JISC programme.
Over at the Open University, a tiny % of Ben Hawkridge has been overseeing and directing the work of a range of contributors including Laurian Gridinoc (Developer), Bernadette Attwell (Rights), Nick Watson (Editorial Policy), John Sinton (Technical Advice), Catherine Chambers, Kristoff van Leeuwen, Stewart Nixon, Jenny Barden, Jane Roberts and Angela Davies who have collectively focussed on Policy and Processes reporting, as well as touching on a range of the other technical areas.
I’d prefer to skip over my own role, but to complete this I’ll mention that I have been responsible for overseeing, well, myself. On paper I have been the only person 100% on the Steeple project, though in reality it’s more like 90% of me. Having been seconded from my prior duties as the Technical Lead for the Podcasting Service at Oxford, I joined this project in Feb 09 to oversee the project as a whole in support of Peter, and to do the technical development work based in Oxford, where we’ve been wrestling with existing hardware and software and trying to make it into a harmonious user experience in support of all podcasting activities. This has been… challenging I think is the euphemism applied. Nigh on impossible I think might be the plainer way to state it, a tough proposition made harder by the setup of IT provision within Oxford. I may touch on that again later.
An honourable mention should go to UCL’s Jason Norton and Adrian Birch, who but for a few minutes of bureaucratic nonsense would have been either part of the main Steeple project, or at least leading another Steeple mini-project through Benefits Realisation. Instead, they’ve been founding members of the community of practice that has built up around our work. Much more on that later.
Curiously, when I started writing on this blank page, I wasn’t intending to draft out the acknowledgements and appreciations, but perhaps in a way that’s a parody on the project itself. Let me explain…
The project started as a way to document and disseminate the hastily learnt skills and knowledge gained by the institutional partners through their involvement with UK launch of Apple’s iTunes U portal. The 6-9 months of near hell that the tiny teams at each institution went through to gather enough content for, and to lay the foundations of continuing support of, their iTunes U portals was something that had many similarities and shouldn’t have to be faced unprepared by any other UK HEI. On top of this was a stark awareness that the resources thrown at these launches in terms of manpower and money couldn’t be sustained in any meaningful way, so there had to be ways found to reduce that effort through automation of the many simple, repetitive tasks, whilst also increasing the scale and capacity of these efforts, as the content would only grow in quantity as time passed and rate of creation as awareness increased.
When I joined in February, 5 months after the project kicked off, we were focussed on gathering existing knowledge together and setting up an event to facilitate dissemination and discussion of this knowledge – and on institutional podcasting in general – which was the Beyond Walls conference held in Oxford on the 3rd April 2009. Open were working on the policies and processes report. I had just come back from a Media Management and Distribution meeting in Zurich which ultimately lead to a Terena (or Europe-wide) Task Force for Media being setup, where it seems I was the sole UK representative. Oxford had, just a few months earlier, hosted an international conference on Podcasting that brought Berkley’s Opencast movement to the fore in the UK and Europe.
Through these events, and the many personal contacts made by those in and around the Steeple project team, the nucleus of a community of practice emerged in UK HEI, with Steeple seen as the leader/co-ordinator. This formal, and informal, network of people and institutions, with tangible communications seen through the wiki, mailing-lists and web-conferences, but also the intangible, through many one-to-one phone calls, emails and meetings, have shared not just information, but also emotional support, primarily for those who’ve been suddenly tasked with new and ever expanding requirements related to podcasting. The challenge of setting up a podcasting initiative/service isn’t just about technical systems, but about institutional change, and that is largely a challenge of politics and people. The application of reasoning, leveraging and general schmoozing needed to get support and remove the roadblocks. And now I’m dismayed at the pseudo-management-bable I’ve sprinkled into that statement – whatever happened to my technical background(?!)
This working with others approach at the core of our project only exploded further with work on the Cross-Institutional Aggregator Demonstrator. Here was something that had been put into the project as a tiny little concept to help sell the ultimate vision of what could be done after all the ground work represented in the Steeple project plan had been done. What happened was Bjoern’s experimenting produced a tangible asset which was seized upon by many spectators as something they could understand, something they liked, an accessible/independent portal to rival iTunes U in the making. Of course, this is a classic victim of its own success. What wasn’t apparent to those not behind-the-scenes, was that combining the loose data available from the three institutions was tortuous, and very difficult to automate due to a lack of compatible metadata. That many other institutions didn’t have the means to publish podcasting RSS metadata in the first place was also an issue. As was the choice of metadata and file formats to support, and the amount of control available. It wasn’t even searchable easily in the first incarnation.
This community interest combined with a tangible hint of what could be done, led to extra time being spent on developing the mechanisms and technologies needed to make this truly work, thus the Ensemble concept was born. Here we could see the need for some middleware service that would parse feeds of feeds (OPML linking to RSS initially, now likely ATOM linking to ATOM, or a combination), combine multiple institutions’ data into a harmonious construct, and then support the searching and filtering of this data and republishing as consistently formatted RSS/ATOM XML feeds. This middleware would be needed to accelerate this data mangling and provide a caching point because of network latency issues (realtime querying of 100s of RSS feeds is not practical). Through having such a system, institutions could deploy an instance as their primary metadata publishing service, national initiatives could use it to harvest wide swathes of video and audio content, subject specific portals could harvest and filter to specific content types, etc. The portals supported by an Ensemble metadata engine could then add further value to the content with educational pathways, community tagging and rating, comments and feedback could be collected, forums of discussion could be setup up around related content, and much more.
Well, reality has to intrude here. It all sounds so simple, everyone is using RSS, lets just mash it all together and voila! No. Not quite. I alluded to some of the issues this faces, and we’re not alone in this. Metadata standardisation and co-operation is critical for such reuse and distribution to succeed, and here our still growing community of practice comes to the rescue again. Two elements are needed to make a standard successful – agreement over the details, and significant usage and support by the intended audience. Through our community we have been able to get both of these ingredients, and so continuing work on Metadata schemas for podcasting are proving ever more popular and useful. Some refer to this work as being Steeple compliant, a compliment I think to everyone’s willingness to work together on this. But it’s not just the UK, this is a much wider problem, far larger than this project can support solely. However, our leadership in this (step forward Bjoern again) has seen the work be picked up by the Opencast community too, and that continues a feedback loop that is iterating now and likely to continue for some time yet.
It’s not all been smooth sailing though. When it came to moving from gathering requirements for web portal systems, to implementing a solution, opinions differed slightly on some of the details. It is worth noting that both Oxford and Cambridge were and are, needing to replace their respective web media portals, and the Institutional web portal work package was seen as a way to achieve this. As a Cambridge-led portion of work, their aim is to produce not just a demonstrator, but a production ready piece of code that they can deploy asap in support of their Streaming Media Service. At Oxford, our now 20 month old single-page listing of podcasting content has barely evolved and clearly needing a major upgrade, however, the hosting technologies and development philosophies aren’t compatible with Cambridge’s solution, so further work has been done to develop a second form of Institutional Web Portal, based around the Drupal CMS. Whilst the bean-counters might suggest this duplication of labour isn’t efficient, it actually is much more beneficial to our community. For one, it practices what we’ve been preaching about the use of standards to expose podcasting data, and the need to separate content hosting from display and selection (i.e. separate data from presentation). Both systems are built to ingest the common RSS/ATOM standards developed and established and to provide integration with secondary features/benefits such as we mentioned in the Ensemble area. For another, it means that at least two production capable systems could be picked between by other institutions allowing them to meet their own hosting and support needs.
So what about the background servers and services needed to gather content, transcode and publish it to these portals? The new work in this area has been the focus of Oxford’s efforts, and our background has been to build on an existing system and relationship with Apple and their Podcast Producer (PcP) system.
Reflecting back on when the project brief was written, there was no practical software or system available to support end-to-end podcasting workflows, and certainly not ones suitable for the varied HE environment. Oxford (and Open) had earlier been working with Apple to trial their (then beta) upcoming Podcast Producer system and saw in it much potential and the belief that it would be the best platform to build on for reasons of scalability, interoperability and continued support. Version one was out when the project bid was placed and whilst the core had much more development needed on it, version two promised to address a lot of this and was due out towards the middle of the project timescale. It therefore seemed like a reasonable projection that may of the issues we needed to resolve in terms of system integration and feature expansion would be taken care of outside the project itself.
As the project was started, we had also come to discover a range of other home-grown solutions to institutional media management and processing, many of which presented at Oxford’s podcasting conference in 2008. One of these was a system developed by a creative and innovative team at ETH in Zurich, called Replay – seen as the swiss army knife of podcasting. More systems crept out of the woodwork as time went by and we made more contacts, however, almost consistently, these home-grown solutions were deeply embedded in their host institutions and not ready to be transplanted. This also factored into Oxford’s decision to build around the Podcast Producer platform.
So how have we fared? Not as well as I have wanted. Events and happenings are said to be the worst things to occur when you have a plan, especially one forecasting 18 months of broad ranging work. I can give a laundry list of factors that have worked against us or delayed our efforts, but I’m saving those for another time. Needless to say things like: not having hardware to develop on till 6 months later than planned for; not being able to integrate with a centrally managed directory service until 2010; having to wait extra time for hardware drivers to be available to enable the deployment of PcP2 on top of the 4 month delay on it being released over the planning window; requiring extra training and consultancy for key elements that didn’t align with deployment desires; having hardware only available for a much shorter period of time than anticipated to use for development, before it was taken “into production” and unable to continue our research work; and more, have led to our struggling to get a working system up in place that truly reduces the amount of human effort needed to take a podcast from capture to publication. And as these unforeseen hurdles and recursive problems have just started to reduce, I find myself without the time to devote to actually implementing the work I’ve written about, designed, trialled and all but solved.
Frustrating doesn’t begin to cover it.
So now, I’m away from the technical development and faced with blank sheets of paper.
I’m looking at how to gather together the 1000+ physical outputs (ranging from blog/wiki posts, to reports and handbooks, to audio and video podcasts, and more) into a semblance of order.
I need to find a way to express what I consider the biggest achievement and asset of the project, our community, in a report that would normally read like a science dissertation.
I am searching for an engaging narrative to tell the story of the Steeple project in such a way that I don’t miss anything, yet make it readable and in under 20 pages.
18 months ago, the project plan read like masters level science project. Research X,Y,Z, do some background reading, perform an experiment or two to prove your hypothesis, and then write a report detailing the methodology and results.
Today, I’m faced with a blank page and a wealth of material and experiences that barely resembles that science project. I know we’re richer for it all, but how to express it.
On reflection, I need to find a way to show this project as what you needed, but maybe not what you expected.
Carl.
I was recently reminded about a book I enjoyed reading a few years back by John Maeda called The Laws of Simplicity. For those of you who haven’t seen it, much of what you need to know can be found on the website (http://lawsofsimplicity.com/category/laws?order=ASC) or if you want the short version, try his 2007 TED talk:
In short, these laws are:
If you’re thinking that sounds very Zen like, then perhaps you’re seeing a link between simplicity and enlightenment…
Why do I mention this now? Well, this reminder prompted a few thoughts on what Steeple was originally premised to address – the streamlining of enterprise level podcasting activities. What’s streamlining? Making things simpler – through automation, reduction, understanding and design. In effect, we’re talking about applying the laws of simplicity to podcasting processes within an institution.
This obvious spawns many many thoughts, and some contradictions. We tend to preach through our training that podcasting is a simple three step process: Capture your content, Process the file to improve quality and reduce size, then Publish the output via the web and through RSS. However, we’ve countless examples of how this is far from the situation – and to be blunt, we’ve got very very few examples of how simple it is in practice.
Capture is perhaps the biggest nightmare – one that needs a complete socio-technical solution. The people involved in creating content need to understand their material; How to effectively present their points so as to be understood by a wide and varied range of viewers via the plethora of devices and environments they could be using (the curse of podcasts – they can go almost anywhere); How to use the myriad technologies available in their presentation space (and that can be anything from a street corner, to an office, to a lecture room, to a studio and more); and then they actually have to get all these aspects working at the same time (not forget what they’re saying, to not wander out of camera shot, not rub the microphone, to press record at the start and stop at the end, etc).
Clearly this is not a simple activity. And we’re just beginning.
If we are talking about a single person’s perspective (and this is assuming the content generator’s perspective, let alone that of a service manager) on the start-to-finish process then they also need to understand how to review their recording, how to edit for improved audience experience, to know how and where to transcode the file into the multiple formats that a wide audience want to have access to, to add the surrounding metadata (titles, descriptions, categorisations, related material, etc), to know how and where to put these files and data and then who to notify about there availability for review. I could go on…
But the topic was simplicity, and by now you’re already realising that a key here is to understand that the picture I paint is partly one of many situations combined and looked at as a whole. The problem of looking at a forest, when you’re really only interested in one tree.
So, to borrow that analogy for a moment longer – the academic sees these trees of podcasting scenarios and says, aha! Let’s simplify and what we find is that trees all feature common elements: they have roots, a trunk, and leaves – and all of a sudden, our complex world starts to resemble a child’s finger painting. Clearly we’ve over-simplified – but with cause. I mentioned our training and I nod to law #4 above – to introduce new ideas to most people, you have to start with a simple concept, so we talk about trees and podcasting like they’re finger paintings, all the while knowing that the devil is in the detail.
Thus we need to organise, and address podcasting and processes as a collection of trees, and that each tree may be a specific scenario – the lecturer in a theatre delivering their normal lecture to a class; the teacher with a specific topic to present in detail to a small class; the presenter out in the field bringing the remote areas back to you; the researcher talking about his exciting discovery; the admissions officer giving a flavour of their institution to strangers; and so on.
The paths and activities that these scenarios encompass from a distance (and squinting) can look similar, but really are not. The skill in setting up a camera and microphone for outdoor use to capture an interview is not the same as that of walking into a lecture theatre and pressing start on the lectern recorder, for example. In effect, the capture scenarios are as varied as the roots in a tree. The similarities get closer when we get to the point of having a file that encompasses that recording, so now we reach the trunk of the tree.
I’ll detour slightly again, just to highlight that you can’t over-simplify even at this stage – the experienced amongst you will have seen the reference to “a” file and realised that for a range of setups, there can be two, three, four files created – perhaps an audio recording or several from different microphones; two or more video cameras in a single shoot; two or more screens or projections to combine and incorporate. So our tree might actually have several large roots that feed into the trunk above ground. I can’t even say that in all situations that you’ll even come to a point where you have “a single file” – though I would suggest that for 95% of the situations, you’ll find that single point in the middle.
So, our content goodness travels up the trunk and here it is refined down, moved between systems (the presenter’s laptop, the lectern computer, the media centre capture system, the digital recorder, etc through to hosting servers and more). And I use “refined” as a euphemism for edited (cropping, cutting, reordering, colour corrected, sound levels adjusted, etc) and processed (titles applied, metadata written to the files, trailers and/or bumpers added, watermarks inserted, transcriptions created, language tracks added, transcoded to multiple codecs and file formats, etc). Yet more complexity, and all from one simple line…
Now we have the myriad of locations that this content could appear – and this is where my already overstretched and abused tree metaphor suffers further (suggestions for a better metaphor wanted in the comments below!). Whilst work is being done to standardise the technologies, data and processes related to publishing your content, the actual steps still have some variation. Are you creating an actual podcast (hosted file for download and accompanying RSS metadata pointing at that file), or a webcast (publishing the file online for direct download or playback) or streaming (not allowing a file to be downloaded, but only sending out the parts needed to play back the section under the playhead), or something subtly different. We’ve already mentioned that the file formats needed to support the range of playback software and devices is more than 1, so is your hosting of these files all in the same place? Odds are they’re not (especially if you support streaming media). And then there’s the likes of YouTube who want to host the file for playback, contrasted with iTunes U who want you to host the file for download, but they’ll point people to your systems. Does this look like the same steps for publishing in both instances?
Law #9 – Failure – is the important key here. There are some situations where a degree of simplicity can be achieved – you only have to see an Apple presentation on Podcast Producer to see what scenarios they see as being simple and the level of complexity they have been able to reduce the process down to – and then to realise that this is only a subset of what you are likely to face when running a podcasting/multimedia service for your institution.
Now, don’t get me wrong, I’m not saying give up or admit defeat – far from it. Law #5 needs to be understood here, and to quote Maeda “nobody wants to have only simplicity. Without the counterpoint of complexity, we could not recognize simplicity when we see it. Our eyes and senses thrive, and sometimes recoil, whenever we experience differences.” What I want to emphasise here is that there are situations where we can deliver simplicity in a complex process, and acknowledging this contrast between these situations and the variability of the rest of the world is about being honest with ourselves and those we wish to enlist in helping us. To continue the quote: “Simplicity and complexity need each other. The more complexity there is in the market, the more that something simpler stands out. And because technology will only continue to grow in complexity, there is a clear economic benefit to adopting a strategy of simplicity that will help set your product apart. That said, establishing a feeling of simplicity in design requires making complexity consciously available in some explicit form.”
If I was to conclude here, based on a degree of realism (some would argue cynicism, I know ), that the complexity is too much, then you would have to think we’re mad to even try to tackle this area. However, we do believe that, like a forest, with time the trees we’re discovering, creating, planting, developing, can enable a beautiful foliage of unique and fascinating to bloom. And like evolution, this is a slow process with many errors and dead-ends, but that the results are worth the while. If they weren’t, we wouldn’t be here now
Carl