In my efforts yesterday attempting to get 'the simple' podcast online I have subsequently spotted a few errors. I'm not too concerned about this as my project is based around looking at the impacts of fitting podcasting into existing workloads.
So what happened?
You'll have spotted that given the various meetings and other commitments that I was working around yesterday the episode log reveals that it went live without a final check. The final check that I do do is to listen to it from my subscription to the feed itself - ie once it's gone public. I caught mistakes at this stage before and I believe it's a reasonable approach as long as the publisher listens to the podcast before its use becomes critical. It seems unprofessional compared to other approaches we might take, especially when problems do emerge and I'm still forming a view about testing podcast productions.
The export from Propaganda for episode #25 was incomplete. The intro and signature music got shunted forward along the timeline so that it wasn't exported. I lost the 10 seconds or so where I say "This is the Learning, Teaching and Assessment podcast from Sheffield Hallam University" etc. Not the end of the world.
So this morning (the next day - a Saturday!) I went into Propaganda and re-exported the file, reassigned the embedded meta information into the file and changed the relevant metadata in the XML feed file. On doing that I spotted other slap-dash mistakes. I hadn't validated the feed file (even though it worked for me in iTunes).
Despite what I said above, as I think this through I think I do need to introduce a testing and validation procedure that may look like,
- Listen to the audio file on export
- Check the embedded metada
- Use an XML validation tool to validate the feed file (if handcoding XML), then
- Check your published episode on the device of your choice (as I do)
To make it more rigorous it would be better to involve an objective eye and ear. For example, podcasters could agree with a fellow-podcaster or colleague to test each other's episodes.
More problems
I publish my podcast using two methods as you may be aware. One is by producing the XML feed file myself and the second is by using a more automated approach using Blogger and Feedburner.
I'm not convinced this second approach is working reliably either. I noticed that I had not used the right mp3 file name on episode #24.
I copy and paste as much info as I can because I don't trust my typing. However it looks as though in my speed I hadn't selected the whole file name. I've rectified that now and hopefully the Blogger episodes are coming through as intended.
I find it quite difficult to trace and rectify errors in this automated approach, especially as there is a time delay. The time delay, supposedly, can be overcome by 'pinging' the feed from Feedburner (this automatically updates their record of the feed), but I don't feel confident about this.
The moral of this tale, whichever way you look at it, has to be 'more haste, less speed, greater impact on publisher's time'.
2 comments:
An XML validation tool isn't enough - you need to be ensuring the feed itself is valid using http://feedvalidator.org
I guess there's also the issue of how critical is it, in this format, to get it right first time?
Thanks Pip. A useful validation tool to note and a good question. As I've subsequently posted, if the primary audience is one self (and I believe that is increasingly likely! and still valuable) perhaps it's not so critical. Nevertheless one of the opportunities for edupodding and edublogging students is understanding and practicing appropriate presentation methods. Validating a feed is an excellent example of how presentation preparation and production skills can be practiced.
Post a Comment