Thoughts on Desktop Podcast Apps: Looking at Vocal’s Future
I’ve been thinking about podcasts for ages, it seems. Despite every attempt I make to pretend that it’s not already somehow 2017, it’s apparent to me that I have been a podcast listener for over a decade. Through times of great joy and occasional difficulty in my life, they’ve been there providing me entertainment and comfort. As you might imagine, both as someone who has used a podcast client for at least 3,650 consecutive days and as someone actually building a podcast client, I have a lot of opinions on what a great experience on a desktop podcast client looks like.
I’ve also found my priorities and concerns changing quite a bit over the past year. I’ve grown. I’d like to think that, at least in some ways, I’ve gained a bit of wisdom. I’m much more concerned with things like free software and the commons, and more concerned about personal privacy. I also have a special soft spot for going back over things I have seen and listened to in the past, and maintaining a library of special content moving forward that I can appreciate throughout my life. These thoughts are in my head as I write this post, and will indeed be in my mind as I continue to build what I hope will be the best desktop podcast app in the world.
So this is just going to be some thoughts on where we are, where we need to go, and some specific plans to give you an idea about the future of Vocal.
But before we get to all that, I want to begin with an email.
I am thankful for each and every email that I receive from the fine folks that use and contribute to Vocal, but I’d be lying if I said there wasn’t one particular individual that stands out above the rest. Occasionally, as if I were flashing some invisible bat signal, when I need one of his emails the most, I will receive in my inbox a markdown-formatted, profanity-laden email from David Nielsen full of vividly detailed complaints and grievances, and incredibly well-thought-out ideas about how to improve podcasting.
What follows are snippets from David’s emails, complete with (mostly) original section titles. The views expressed in the next session are his, though I’ll be talking in depth about most of them.
Podcasts: lessons in being riddled with awful
Looking at my feeds, a study in misery
I was proud the other day to bring the number of podcasts I subscribe to back under 100 and naturally the question follows.. do I actually listen to all of them? Of course not; in full honesty, I only listen to every episode of 8 of those feeds. So why do I have 98 feeds in my subscription list?
No good way to handle archived and dead podcasts
I have a high number of feeds I keep around for archival purposes, largely podcasts which have ceased to publish episodes or moved their feeds starting essentially a new show. John Gruber’s The Talk Show, which switched podcast networks and left behind a feed of valuable content, is a prime example of this. Old shows have value to me, often as references or context in newer episodes.
Having a section in my Podcast client to hold dead stuff would be great, or some means of exporting these to a different storage container with all their metadata. I’m a big fan of Instapaper and Pocket, so perhaps dropping them in there would be a good option. There’s good search (in at least Pocket, Instapaper should have search which doesn’t make me cry soon), and I suppose that files could be kept around using feed copies, Archive.org (if available) or by me personally using hard drive and my BackBlaze backup.
No good way to sample single episodes
I have a large group of feeds where a single episode has interested me, and podcasting doesn’t have an answer to “just this one, but it was good so maybe in the future there’ll be something interesting here.”
Recommendations and discovery
Social features and single episode uploading such as available for patrons of Overcast and curated recommended episodes (Podcast Rank, Interviewed, also there was an indie Apple developer who did a service to recommend single episodes but I can’t find the link presently) might be a better fit than simply subscribing to feeds blindly.
I understand that back catalogs are difficult, however in most cases they
are limited mostly to avoid the problem of ever growing feed sizes.
There are workarounds for this such as implementing paged RSS support, but
this requires both the application and the feed provider to support it
which is suboptimal especially given that most such users, TWIT.tv being
the most prominent I know of, would need to replace part of their already
tested podcast publishing pipeline.
I suspect one could do something server side to store that information and
make it available but if you plan on using the iTunes API for Vocal without
some of your own server side smarts then that is not an option.
Maybe you could add a feature where such podcasts known to irritatingly cut
their supply short have a badge or some visual tag so users can see that
the full backlog isn’t available?
The problem is most pronounced when e.g. importing an OPML files from an
existing client and then not getting a complete replication of what
episodes available in the original client (not to mention OPML doesn’t
allow for things like importing information regarding which episodes have
been listened to, which have been starred/shared/recommended — people need
to stop using this kind of simple migration hack, it’s like considering
McDonald’s a 5 star meal with accompanying wine selection).
This is why I find it hard to move away from PocketCasts, losing my back
catalog of perfectly downloadable Security Now! episodes is simply not a
good user experience. Especially for a show like SN where previous episodes
are referenced so often, not having them available is undesirable. I know this
is something I should take up with the publisher but that has never really
had the success rate one could hope for. In years of contacting publishers
I have yet to get one to change their ways, typically due to not caring or
having to retool their publishing pipeline rather than actual malice or
concerns for profits (such as your example of selling old episodes). I
think it might be time for podcast clients to work around this problem
somehow (oh hand wavy).
Other awfulness with podcast clients
Feeds automatically publishing only the most recent 20 episodes is awful
A large part of the problem with podcasts is the fact that most feeds automatically only publishes the most recent 20 or episodes. This is presumably done to keep RSS feed sizes down, or in very rare cases to monetize back catalogs.
The latter is easily defeated using services like Backfeed or otherwise crowdsourcing the acquisition of old episodes in some way. If the files have been released on the Internet once there is no way to take them back.
The former is a technical issue which will require adoption of RSS features like Paged Feeds or simply eating the cost of increasing the feed size. The latter seems more likely as getting every podcast client and publishing tool to support something new is.. unreliable as a source of improvement.
Outside making the initial subscription of feeds like Security Now which often references episodes which fall outside the window of published episodes, this makes it extremely painful to migrate from one client to another as the typical workflow for this is exporting and importing OPML which only contains the feed URLs and not back episodes which are no longer published in these feeds.
I predict that until the podcast technology ecosystem is organized better or replaced with a centralized controlled entity, a client with integration of something like Backfeed to stitch together complete feeds will have a powerful stand out feature.
Updates to episodes never happen
A show like Security Now has published transcripts available post release. It would be nice if there was some way for feeds to point to these and fetch them when they become available post release. If anything we would likely see worthwhile features such as Chapters be more widely supported post release. I also predict that in the next couple of years we will see significant improvements in automatically transcribing Podcasts.
Data transfer is awful and unreliable, not to mention costly for podcasters
When on mobile internet here in Brazil I have wasted countless expensive megs of downloads to get podcast episodes only to get files broken on arrival due to connection errors. Files which were then treated as perfectly valid afterwards, this is not just a terrible user experience but a security risk.
I’d like to see Podcasting 2.0 move to a more reliable transfer protocol such as BitTorrent. Using P2P would also lower the entry cost for podcasters in terms of bandwidth. Experimenting with BitTorrent Live on my Apple TV it is also quite suitable for streaming which is likely the most common method of consuming podcasts.
(Now I’m just smoking crack, getting everyone to adopt a new podcast standard before the heat death of the universe would be optimism at best)
Things that aren’t completely awful about podcasts
On valuing my damn time
I really like the Smart Speed hack which Marco Arment introduced in his Overcast app, and I think these days any podcast player should look at doing this. If not familiar with this technology, it analyses the audio file to minimize pauses and subtly speed up the playback, typically this leads to playback at around 1.05–1.10x for me without any noticeable downside. In the most recent release he even managed to make it work for streaming (I suspect he gradually downloads files and analyses parts before playback — at least for supported well formed files this should work).
With many podcasts to listen to it is valuable to have the time to consume them being cut down without degrading listening quality (overly much at least)
The podcasts I subscribe to, and the subset of these I regularly listen to, are quite long, typically 1–2 hours. I don’t mind this but it does mean that on a regular day I can cram in maybe an episode or two doing house chores. The sheer number of episodes which are being put out mean that I am missing content which I might enjoy and thus fitting more listening into the time I have available is highly valuable to me.
The one thing a podcast client like Vocal can do to help in this area is to employ playback technics which minimizes periods of silence and intelligently speeds up playback, thus saving me time.
I posit from experience that expected time savings from smart playback
speed is about 10%, with little if any impact on the audio quality.
Say I listen to podcasts for an hour a day, every week day. You are wasting 30 mins of my time every week. All year around. On a yearly basis you cost me 26 hours. Let’s call that wasting a day of my time a year.
I do not believe any self respecting podcast client these days should ship without an option to apply this kind of playback optimization for audio only podcasts. The return of saving 10% of all your users time makes it the one feature to implement. It also shows you have a tremendous respect for your users time. Nothing you can do in Vocal will similarly benefit your users on anything near this scale. Nothing.
Wide cross platform support
I’d personally not consider switching to a client unless there was a compelling story for my iPhone, iPad and Mac. However I must admit my podcast listening time is 90% on the iPhone and 10% on my iPad (depending on what device is handy really), I only use my Mac in terms of podcasting for archival purposes.
(Note: I realize this is out of scope for your elementary OS player but I think you should design it with a view towards working well with a mobile app.)_
Feeding developers and podcasters
I like an option to pay for the service, I understand that developers need to eat. I also depend on podcasts for my daily entertainment, information and research. I’d like to see the ecosystem stick around. Please consider integrating Flattr Plus to enable payment to you and the podcasters.
Planned Upcoming Features
With that as an appetizer, here is what you can expect from Vocal moving forward (please keep in mind that these are only plans and are subject to change at any time for any number of reasons):
Archiving and Library Management
- A concept of Following vs Spectating. When you subscribe to a feed you will be able to mark it as either a show that you are following or spectating. Following means that Vocal will notify you of new episodes, display the banner containing the new episode count, and automatically download new episodes if the option is selected. Spectating means that the feed is simply available to you in your library. It might be a show from which you just wanted a couple episodes, a show that has since gone away that you are archiving in your library, or a show that you just occasionally want to check back in on.
- Backfeed support (or a similar service). When you add a podcast you should get the entire catalog of episodes from that show, no matter whether or not they only provide n episodes in the feed.
- Better library file management. Select where you want your library to live (normal folder in ~/.local/share/vocal, an external drive, a network share, etc.). Vocal will also make a better attempt to keep the folder structure organized, name the files in a sane, human-readable format, and perform regular integrity checks to make sure that your files are always safe and sound.
- A “New Episodes” view. This view will allow you to quickly and easily locate the latest content from all the podcasts that you are currently following. No need to individually browse to each podcast with new episodes. This will make it easier to add items to the queue and stay on top of new releases.
- Information editor. Your library is your library. Make changes to things like feed names, title names, episode descriptions, and more.
- Save episodes to Pocket and Instapaper. Some additional work will need to be done here, as individual episodes generally don’t include permalinks to stand-alone pages with dedicated show notes and episode information. I imagine that this integration will also require some coordination with archive.org, or perhaps some kind of web service (maybe on our end?).
- Export episode audio files directly. This is a little one, but in the share menu an option will be added that will allow you to export downloaded audio files (or to download and export).
- Built-in Archive.org support*. I’m not entirely sure of the legality or the workflow for this feature, but it would be nice to be able to allow users to contribute to the library of everything by making it easy to upload podcast episodes that it isn’t already aware of (or, at a minimum, to make contributions to fill in missing information).
- Built-in Patreon support. Patreon is quickly shaping up to be the go-to platform for podcasters to receive support from listeners. Vocal will scrape the feed information for links to a show’s Patreon page, and will include a built-in button on the podcast view that takes you straight there.
- Voice enhancement. A simple, one-setting equalizer that boosts audio in the vocal (no pun intended) range to make it easier to hear voices.
- Multiple playback speeds. Almost every podcast app has 1x, 1.5x, and 2x speeds. Vocal should as well.
- A smart playback speed setting. It would be great if Vocal could analyze silences and cut them out in a way that sounds natural (similar to how Overcast does it). I will be the first to admit that I don’t even know where to start on this problem and would greatly welcome community guidance (and code!).
Syncing and Social
- Sync with an online service. I want to do this desperately, but I’m not aware of any good online services to use. gpodder.net seems like the obvious choice, but actual client support for it is low. I’m very interested in hearing from you if you are aware of a good service (with an API) that I could use. Please note that a solution that doesn’t work, at least to some degree, with both iOS and Android would not be considered.
- Personalized podcast or episode recommendations. This would be opt-in in the settings, but it would be nice to get individualized recommendations. This feature would be implemented near the last and probably won’t be in Vocal for a few years, honestly, but I hope to see it.
General Usability Improvements
- Improved HiDPI support. Fixes for blurry artwork, icons, and more on very high resolution displays.
- Improved episode downloads. Partially download episodes when necessary, with the ability to be able to pick back up from the partial download later. Make sure not a single unnecessary bit gets downloaded twice.
- Paginated episode lists in the podcast view.
- Changes to the “only show new episodes” / “show all episodes” button and handling.
I’ll close with a general “state of the union” and a note about how the project will move forward.
From the very beginning Vocal has been free and open source, but it has never been the “super open source” project that it should be. I want to do everything that I can to encourage people to contribute to the project with new features, bug fixes, accessibility improvements, translations, and more. I want to make this a great experience for all fans of open source and podcasting to get together to make a genuinely one-of-a-kind podcast app.
I will be posting all our issues, roadmaps, and more on our GitHub page. You can follow along as I work on Vocal, and also get general suggestions, advice, and more as you make your own contributions. I’ll make it my mission to stay on top of GitHub notifications and respond to everyone that deserves a response (although please note I work a full-time job, so it won’t always be instantaneous).
I will be posting information about our project code-of-conduct in the next few days, as well as things such as code style requirements and expectations.
The largest item on my immediate to-do list is to work on a major code refactoring. I started Vocal just as I was finishing my freshman year in college, and the initial inexperience shows. The code is admittedly spaghetti-ish and awful, which makes it more difficult to contribute to the project. Rest assured, it annoys me too, and will be fixed as soon as I have some real time to dedicate to the task.
But, taking a more general view for a minute, the project will keep moving forward. We’ll keep releasing updates for the 2.x series, which will include both bug fixes and new features. Eventually we’ll get to 3.0, but I’m happy riding on the 2.x train until we can’t go any longer.
I hope you all have thoroughly enjoyed using 2.0 so far, and are as excited about the future as I am. Now let’s make it happen!