Rss

Podblathering

Author and speaker Daniel Steinberg always keeps his talks fresh, revising them and making changes every time he gives them. CocoaConf DC 2013 was at least the third time I’d heard his keynote “A Pocketful of Patterns” (whose framing device is based, in part, on my own skepticism about design patterns), but he caught my attention with this little pattern, showing a problem and a good solution:

What do you hate about most Cocoa Podcasts? They tend to be way too long, rambly, unfocused, self-indulgent. Therefore, if I were to produce a podcast it would be focused on the audience.

OSEG, so true. So I tweeted it right then and there:

Tweet from invalidname: "Yay. @dimsumthinking finally told the truth about most developer podcasts: they're too long, unfocused, and unedited. #cocoaconf"

Take a look at the tweet details and you’ll see a long trail of reactions, including those from Cocoa podcasters Saul Mora of NSBrief and Wolf Rentzsch and Andrew Pontious of Edge Cases.

So what’s the beef that Daniel and I have? Actually, it starts back at CocoaConf Chicago, and a flippant question I asked as the moderator of “Reverse Q&A”, where we take a panel of speakers and have them ask questions of the audience instead of the usual way around. Shifting topics with a segue, I asked “what’s the deal with all these developer podcasts anyways? why do we have so many?”

And the answer I got back was: “it’s easier than blogging.”

Skyping It In

That answer kind of floored me, but in the past few weeks, it actually seems to make a certain somewhat cynical sense. Let me give you an example:

Driving from CocoaConf back to the Baltimore airport (yes, CocoaConf DC was right next to Dulles, but getting a nonstop from Grand Rapids to BWI was actually easier and much cheaper), I listened to the Accidental Tech Podcast with iOS/Mac luminaries Marco Arment, Casey Liss, and John Siracusa, in part because I saw that they were covering Michael Tyson’s revolutionary Audiobus. The gist of the discussion was that it is rather surprising that Apple not only approved of Audiobus’ enabling of real-time inter-application audio communication on iOS (in contrast to iOS’ usual locked-down, single-app mindset), but that Apple even updated GarageBand to add Audiobus compatibility.

OK, so far so good. But then they got into the topic of how Audiobus can even work. There are two good ways to answer this question:

  1. With a correct answer
  2. By saying “I don’t know”

There is also a very bad way to answer this question:

  1. By pulling a wrong answer out of thin air

Of course, I wouldn’t be writing this if they hadn’t gone with option #3, speculating that Audiobus probably opened a network port and communicated with sockets. It’s not an unreasonable answer, but it should be suspicious because of its obviousness: that approach to inter-process communication has been used on Unix for decades (we did it at Pathfire in the mid-90’s), and is prominently featured in the classic Beej’s Guide to Unix Interprocess Communication. And the reason listeners should be suspicious was that if it were that easy on iOS, it probably would have been done a long time ago.

The right answer, for what it’s worth, is that Michael discovered a novel way of using MIDI to send arbitrary blocks of data across the MIDI bus, which is accessible by all background applications. @flunkwerx pointed me to Michael’s blog post where he spells out this key discovery, and how it led to creating Audiobus.

OK, so long story for one mistake, but I think it’s unfortunately typical of the norm for the structure Cocoa podcasts. We have a regular set of personalities who expound on their thoughts in a group conversation, which is then converted as-is into an MP3 file and posted to the podcast feed. If they were blogging, any of them could have taken a few minutes to research and possibly find Michael’s blog. If they were livestreaming, an audience member in the chat room might well have corrected them, as often happens on shows like MacBreak Weekly. But with no time for upfront research and planning and no feedback loop, giving wrong answers that stay wrong is likely inevitable.

For what it’s worth, Daniel edits a podcast where every once in a while one of the hosts needs to pause to research something more before giving an opinion or providing a reference – “Hold on,” they say. And then while the recording runs they do whatever research they need to. “OK”, they say when they find it. They reset their answer and go on. The gap is easily edited out later, and the podcast is much more useful to the listener because it’s actually correct. Problem solved.

The Man Without A Plan

But Daniel’s slide quoted above doesn’t say anything about being wrong. He’s got a completely different set of complaints: length, self-indulgence, and rambling. Those are probably endemic to the format that most Cocoa podcasters have chosen. Which begs an even more important question: why did they choose that format?

Or… did they even make a choice at all?

In creating media, it’s common to talk about three phases of production:

  1. Pre-production – Coming up with the original idea, planning how you’ll accomplish it, writing, budgeting, hiring, etc.
  2. Production – The actual making of the thing: recording, filming, acting, performing.
  3. Post-production – Additional work done after the production stage: editing, mixing, fixing, effects, titles, re-encoding, etc.

When so many podcasts are following the same format — a set group of personalities discussing the topics du jour — it’s fair to ask whether the first step has been skipped entirely. Is there any plan involved at all, any specific result that is meant to be achieved? Or does the next Cocoa podcaster do his podcast this way because all the other podcasts he listens to do it this way?

On And On And On

And the last step is commonly skipped as well. Back on my original tweet, you’ll notice that several of the objections raised involve how difficult it would be to edit the recorded discussion. Overwhelmingly, Cocoa podcasts seem to be taken as-is and posted to the internet. Every sidetrack, every corny joke (seriously, when a product is mentioned as being “not dead yet”, you really don’t have to go into a Monty Python and the Holy Grail bit… you’re not that funny), every dead-end conversation gets equal prominence as the gems of insight if the whole thing is just dumped on listeners.

The result is that these podcasts are commonly 90 minutes long, sometimes two hours, sometimes longer. How is it that these things are as long as a movie, yet don’t deliver nearly as much value? Might I suggest that if David Lean can tell the life story of Lawrence of Arabia in three hours, you should need a lot less than that to tell me why Apple would never make a flat-screen TV.

You’re Right! We’re All Individuals!

The other problem with these unstructured pundit-fests is that they’re contributing to a sort of groupthink in the Cocoa developer community. If someone were to go back to step 1, pre-production, and say “I’m going to make a podcast that challenges conventional wisdom about iOS development”, I’d want to listen to that. If someone set out to make an iOS podcast about that was entirely postmortems of successful or failed projects by interviewing their developers, I’d want to listen to that. If someone wanted to create a podcast featuring female and minority developers that are absent from all these other podcasts (notice my deliberate use of “he” three paragraphs ago), I’d subscribe. Those would probably bring some new ideas to the fore.

But another podcast where authors or other personalities speculate about rumors, rant against skeuomorphism, ascribe every mean-spirited Apple decision of the last five years to Scott Forstall (or the absurdly unfair and misguided caricature that’s been made of him), and spout conventional wisdom about “how Apple works”? Pass.

The Macintosh Way

Guy Kawasaki got a whole book out of “The Macintosh Way”, meaning “the right thing, done the right way”. I like podcasts a lot, and I like Cocoa development. I think these are all the right thing, but so many of them are done the wrong way. So what would help?

First off, there really ought to be a genuine interest and passion for the concept and craft of podcasting itself. It is a remarkable irony that pundits on these shows can go on about the rigor and polish required to make great apps, and then insist on minimal-effort, uninspired, unpolished podcast production to actually create the podcast. If your users deserve great apps, why don’t your listeners deserve great podcasts?

Greatness requires beginning with the end in mind. Podcasts should start with a vision of what you want to accomplish. And there are a lot of metrics to consider:

  • Genre – Entertainment, academic, business development, community building, some combination of these, or something new altogether.
  • Idiom – How does the listener experience the content? Interviews with different people, round table of the same personalities, a single speaker off the top of her head, a single speaker answering questions from listeners, one or more speakers working from a script, etc.
  • Structure – How long should it be? Should it be broken in to specific segments (e.g., old news, upcoming announcements, feedback)?

Great, that’s pre-production. What about production? How do you make that good? Here it’s more a question of craft, which means there are common best practices that can be followed:

  • Use good microphones. The value of “good” varies: you don’t have to use Daniel’s $300 microphone, but you definitely shouldn’t use your laptop’s built-in mic, since it’ll pick up room noise and possibly the laptop’s fan. In a pinch, the handheld USB mic from your Rock Band game is better than nothing.
  • Try not to sound like Skype. It’s disorienting to have the full dynamic range of the locally-recorded speakers paired with the compressed, tinny, and sometimes flange-y sound of someone on Skype. We’ve become accustomed to it from old TV and radio where people would call in on their phones, but if all participants record themselves locally with something like Audio Hijack Pro, we can fix it in post.
  • Watch your levels. If you clip (i.e., your signal goes over 100%), you can’t really fix it in post.

Finally, post production. The step everyone seems to think they can skip, either because it’s too hard or because they don’t care (the first is untrue, and if the second is true I don’t think you should be podcasting at all). Audio editing software is not hard to use, and get you results quickly. Among the things you can do:

  • Mixing. If all participants recorded on separate mics (or hijacked their local audio so you didn’t have to rely on the Skype version), here’s where you bring them all into the same room. Dick Wall of the Java Posse subtly moves each speaker a little bit right or left in the stereo field to create a sense of relative space. This is a trivial 10-second task in Audacity or GarageBand.
  • Normalize. Recorded too low? Have one speaker who was far away from his or her mic, such that either you can’t hear them, or you have to turn up the volume so loud that the rest of the speakers are uncomfortably loud? A quick trip through The Levelator fixes that.
  • Music. Having an opening theme, and music between segments, is immensely comforting to listeners. It’s a perfect framing device, and there are lots of royalty-free loops in iLife and on the web.
  • Introduce your episodes. Hands-free listeners will thank you for giving an episode number, name, and/or date right at the top of the show.
  • Tagging. iPod/iPhone users will see your podcast as a list of episode titles, usually cut off after 20 characters or so. If every episode’s title starts with “The Awesome Amazing Apple Podcast…”, users won’t be able to tell which is which.

Don’t Listen to That, Listen to This!

So I’ve done a lot of complaining. Now it’s time to hand out some plaudits. Here’s a look at my podcasts window in iTunes:

My Podcasts window in iTunes

Yeah, pretty telling that there are three Cocoa developer podcasts that I subscribe to that iTunes has stopped downloading because I haven’t listened to them. But scroll down and we’d find some good ones (at least given my own personal tastes… your mileage will of course vary based on your own interests):

  • Skeptoid is probably the best one-person podcast I listen to. Host Brian Dunning puts in a lot of time upfront to research and write a script, which lets him be witty, thorough, and most importantly of all, accurate, which is crucial for his cause of debunking silly and sometimes dangerous pop culture beliefs.
  • Rear Vision is kind of a cheat to include on this list (it’s a weekly radio program from Australia) but it’s a great place to take inspiration. They have a gem of an idea — seeing current events through the perspective of the decades of history that led up to them — and narrate the show with the help of experts from around the world. Maybe you and I couldn’t do this without making it our day job, but it’s at least another way to think about bringing together multiple perspectives and having a point. In a related vein, a college professor friend of mine is trying his hand at podcasting by turning his lectures into a History of the United States podcast that starts not with Henry VIII and the Puritans (like my 8th grade class did), but with prehistory, archeology, and anthropology.
  • ANNCast gets high marks for longevity, having been podcasting regularly since 2009. Their preferred format is an interview with one or more professionals in the anime industry, and they noted in a recent show that they’ve unwittingly been creating an oral history of anime in America, getting recollections from some of the people who brought the form to the US (and some of whom, like Robotech producer Carl Macek, have since passed on). Saul Mora’s interview-driven NSBrief may be doing the same thing for Cocoa development, and deserves our admiration for that.
  • Reisen Goes To School By Bus / Eroge Podcast is an example of a fan-made, low-tech podcast with high aspirations and unique content. Host Greg (@thedigitalbug), has a deep knowledge of Japanese visual novels and eroge (“erotic games”… think “Choose Your Own Adventure” with porn and tragedy). He splits his show into distinct segments — last month’s news, a game review, upcoming releases — broken up by music he probably doesn’t have the rights to but that’s awesome nonetheless. He’s got a bit of an accent but is a very conversational and idiomatic speaker, well-versed in the in-jokes and jargon that his audience appreciates. This show is the very epitome of “there’s nothing else like it.”
  • Who says podcasts can only be non-fiction? Anime reviewer JesuOtaku has been producing the Fruits Basket Audio Drama, in which she’s adapting the manga Fruits Basket as an old-style radio show, complete with original music, sound effects, foley, and an extensive voice cast, all amateurs or semi-pros. The quality is truly outstanding. While it’s technically not a podcast — owing to her experience as a reviewer for That Guy With The Glasses, she initially posts new episodes as a video <embed> — she also posts regular MP3s that I’ve manually assembled into an unofficial-but-OKed-by-JO podcast feed XML of the show. (Full disclosure: I appear three times in the show as an extra, most recently as the bus driver that takes Tohru to Momiji’s vacation home)

Extra bonus disclosure: I used to have a podcast of my own. The Annotated Alchemist ran from 2005-2008. I pod-faded because 2008 got busier than I could handle (switching career to iPhone development, co-writing a book about it, dealing with a child’s ASD diagnosis, moving to Michigan). The show was an episode-by-episode critical analysis of the anime series Fullmetal Alchemist, based on the idea that there were too many anime podcasts consisting of “a bunch of kids talking crap into a laptop mic in the basement” and that I wanted to go way deep on one topic that I was really focused on. I split the show into specific segments: a summary of the episode, a discussion of the themes and craft of the show, listener feedback (I had a SkypeIn number that listeners could call with comments and questions… this gave me a variety of vocal tones that as a one-man show I couldn’t otherwise achieve), and a closing list of upcoming conventions with appearances by the show’s voice actors. The show’s site is gone but I still have the old episodes… they’re not great, but I could put them up on my Dropbox now, I suppose? Anyways, I had a specific goal in mind, and while it was a significant workload (2-3 hours to write each episode, 2 to record, 2-3 in post to mix in audio from the show or listener calls where I tossed to them), I was more or less able to realize my initial vision in some ways (the quality of the episodes themselves) if not others (keeping up with the weekly [adult swim] broadcast, finishing all 51 episodes).

But maybe there’s a simple rule at work when it comes to podcasts: anything worth doing is worth doing right. Hopefully, the quality of Cocoa podcasts will soon catch up with their quantity.

Comments (3)

  1. improvnerd

    Thanks for saying this. I was feeling guilty about not keeping up with the iOS podcasts. I now realize it’s not me, it’s them.

  2. […] blog about discovering the potential uses of MIDI SysEx messages — something I cited in an earlier blog entry — they have apparently switched to Mach ports for performance reasons. Surprising to me, […]

  3. Raxivace

    Hi there.

    I used to listen to The Annotated Alchemist back in the day, and I’d love to be able to hear it again. Is there any chance that you could put the old files up for download again somewhere? I’d really appreciate it.

Leave a Reply to Raxivace Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.