Replies: 9 comments
-
Just to experiment with the idea, below is an example of how we might embed podcast namespace tags in the plain old description when using hosts that don't directly support thee podcast namespace tags. If we can standardise this, then more podcasters will be able to start using podcast namespace tags without having to wait for the hosts to catch up. Approach 1Podcasting 2.0 for April 29th 2022 Episode 83: "Pushin' Paper"Check out the podcasting 2.0 apps and services newpodcastapps.com Support us with your Time Talent and Treasure Positioning ShowNotesPut us in your value split 03ae9f91a0cb8ff43840e3c322c4c61f019d8c1c3cea15a25cfc425ac605e61a4a Two very tired men Live item fuck ups Boostbot TOS hell Sovereign feeds kicking ass Hypecatcher studio ramping up Maps.fm email Podcast Standard conversation The Zen TV Experiment - adam.nz Elon Twitter authentication AVB & fire Spotify launches new fund to support independent open source projects | TechCrunch Announcing the Spotify FOSS Fund : Spotify Engineering Agora project Podcast namespace tags
Approach 2Embedding links anywhere in the description with recognisable keywords as the hypertext:
|
Beta Was this translation helpful? Give feedback.
-
It's an interesting idea, but I think it creates more problems than it solves. Podcast "show notes" are already a mess with wasted space, unhelpful information, and redundancies. I think this would only increase that. Plus, I think it would only slow down adoption. Hosting providers could easily think, "Why should we support that new tag when we could do nothing any let our users insert the HTML?" |
Beta Was this translation helpful? Give feedback.
-
On the contrary, I think there are many variables we want to consider rather than only one. We want:
We should measure success by the totality of these. Indeed, a machine with this many cogs will operate at peak capacity only if there are no blockages or bottlenecks in any part of the machine, and we currently have a serious bottleneck in the hosts.
There is a clear bottleneck here, so just think about the impact on the total efficiency of the machine if you provide a fallback mechanism for those hosts that don't support the tags, and indeed those hosts that may never support the tags for their own strategic or philosophical reasons (which some hosts have the luxury to do because of their market power). I see it growing to the point where podcasters can at least get an initial taste of what these tags are like on their legacy hosts, and then after a while they might have more motivation to go shopping for an alternative host that directly supports the XML namespace tags because that will make their authoring process less time consuming. So in the long term, I think we will arrive in the same place, but with this there will benefits in the short term as well. But I think even independently of the growth curve, providing a fallback option is the-right-thing-to-do (TM) simply out of fairness to those podcasters who are stuck with no other options. I spoke to one podcaster who is on a hosting provider that doesn't support these tags, and that provides no option to even export an RSS feed of any episodes beyond the most recent 100 episodes. Since the other hosting companies just provide a way to import your podcast from the RSS feed, this makes migrating from his current host impractical. Of course if only we could convince the hosts to support the XML namespace here and now, but if you have ever tried to actively spread the word (I have), it is not that easy. These companies have a lot on their plates, and it is much harder for them to build authoring tools for the tags than it is for a podcast player app to simply display what is in the tags. And as mentioned earlier, some of these larger companies may end up never supporting these tags for their own strategic or philosophical reasons. Larger companies also tend to be the hardest to reach because of their scale and bureaucracy, while smaller companies may be more eager to adopt features and be competitive. If there is something inherent in large companies that makes them difficult targets, that is also a problem for adoption because that is where most podcasters are hosting their podcasts. |
Beta Was this translation helpful? Give feedback.
-
I agree that this will only muddy the waters and make show notes even more of a mess. I can only imagine the formatting would be wildly inconsistent. |
Beta Was this translation helpful? Give feedback.
-
Well that was a fully fledged example with approach 1, but approach 2 allows chapters and transcript links anywhere in the description, with recognisable keywords as hypertext. e.g.:
This is a self-correcting problem, because this legacy option is specifically for people who really want to publish transcripts and chapters but are hampered by their hosts. Just as with anyone who publishes a website and finds that it doesn't render properly in the web browser, or doesn't show up in the search engines, the kind of person who REALLY wants to publish a transcript and chapters will be self-motivated to fix a broken link so that it gets picked up by the apps and search engines. In general, yes of course the fallback option is not as elegant as the native namespace tags, but remember who this option is for:
True, it is easy to notice that the fallback option is not as elegant as the native tags, but there is still a problem to solve. If you have a better solution to the problem, let's brainstorm on it and help to prevent the listeners waiting years for it to happen. |
Beta Was this translation helpful? Give feedback.
-
How does this increase adoption though? You can already link to those things in your feed. As someone who builds applications that ingests RSS feeds, nothing would do more to push me away from a standards group than it advocating for non-standard methods of implementing new tags. It certainly wouldn't encourage me to implement their "fallback" standards, let alone their new tags. |
Beta Was this translation helpful? Give feedback.
-
I am proposing this to be included as part of the standard. I did say that up front in the original proposal.
If at least one podcast app supports the legacy standard, that's a win for adoption because now those podcasters who really want to offer transcripts and chapters to their audiences but were previously hampered by their legacy hosts, will now be able to do that. Without such an option, these podcasts may not be able to publish transcripts and chapters for years yet, if ever, and that hurts the listeners. Of course simply adding links to things in a description in a non-standard way is not going to increase adoption because no app will ever be able to pick up and then display them to the user. If it's non-standard, though podcasters publish chapters and transcripts, the listeners won't actually benefit from them showing up in their podcast player. A standard is necessary to make that possible, and all it takes is one app to support the legacy option for the listeners who, for example, really need the transcripts, to be served. It is also not unusual to have fallback options. I see them all over the place, and they are offered for good, practical reasons. I suspect we are going to end up doing the same thing for feed ownership verification, where an entirely new system of verification is currently being proposed. Now because legacy hosts will be very slow to adopt this new standard, we would still need to have an option for them, in the form of verifying the email address publicly listed in the feed, because that's something that the rest of the hosts will support. You don't want to be so strict about "only" supporting the brand new, one ideal way, if 95% of podcast feeds can't support that new way. There is nothing wrong with having a new recommended way for the 5% and growing, AND also having a legacy way for the other 95% and shrinking. (Speaking of fallback options, my local supermarket also has a ramp for people who use a wheelchair or otherwise have difficulty using stairs. Although in an ideal world, it would of course be great if we could make stairs work for all people, perhaps free spinal cord or hip surgery for all. But until then, we provide multiple ways of accessing the supermarket so that all users are served fairly.) |
Beta Was this translation helpful? Give feedback.
-
When I bring back The Audacity to Podcast in September, one of my first return episodes will be about Podcasting 2.0. And I plan to push it as the new litmus test for podcast-hosting providers, alongside IAB v2 measurement compliance. The reason to move hosting providers seems to be to get features that your current provider doesn't offer. And I wonder if the legacy providers who aren't already working on Podcasting 2.0 support are so legacy that they wouldn't even allow this kind of fallback. I really appreciate your idea and motive behind it, I just can't see this working well or helping further the standard. |
Beta Was this translation helpful? Give feedback.
-
Creators will find the best deal for the features they need. The problem is that transcripts are not a feature that creators need, they are a feature that listeners need. In my mind, transcripts are something that creators will generally not be motivated to offer unless:
If, hypothetically, you were to make it your mission to serve the listeners by maximising the availability of podcast transcripts as quickly as possible, and in the climate we have, how would you go about it? (I am personally taking up challenge number 2, and this proposal would go a long way in helping make it possible to leverage existing free platforms like Anchor where, incidentally, most of my favourite podcasts are hosted, and from which the creators won't budge. I hope someone also takes up challenge number 3.) |
Beta Was this translation helpful? Give feedback.
-
UPDATE
In this proposal I tried to generalise my own problem of transcripts into a rather broad proposal that could support any tag. Since what I really care about is universal access to transcripts, I have written a new proposal in discussion 549 that should be a bit more straightforward to adopt. I am closing this in favour of 549.
The namespace adoption chicken-and-egg problem
The key point is that "most" podcast creators will not be able to add these tags to their podcasts via their hosting providers, and it will be a long time (if ever) before they can.
An interim solution
What if we have an alternative (and "standard") way to embed this same metadata into plain old HTML in the channel and item descriptions, as a fallback option for hosts that don't support these tags. Now keep in mind that Spotify supports only a limited subset of HTML. Within these limitations, one way it could be done is to have a specially-named heading, followed by an unordered list of specially-formatted metadata. In the case of chapters and transcripts, the list item could simply be a hyperlink with the label indicating chapters or transcript. For simple key/value metadata, it could be represented by
key: value
. If the value is a list, that list can be represented asvalue1, value2, value3
.Another potential way to handle chapters and transcripts is to just allow a hyperlink to the chapters or transcript file to occur anywhere within the episode description, but require the hyperlink label to be formatted in a special way that can be recognised by the apps.
I think with the second approach, there's certainly the appeal that all a podcast creator needs to do to publish their transcript or chapters for an episode is to simply add a link to it in the description. Certainly podcast creators I've spoken with have been happy to publish their transcripts that way given that they aren't currently able to implement the namespace tags. And indeed, some were already doing it that way before the advent of this namespace. If people are in fact doing that, it would be nice to standardise it.
My hope is that this can help to speed up the adoption of this podcast metadata in a way that doesn't depend on the hosting companies, because if the feedback loop is shorter, the effects should iterate faster.
Edit (simplifying for my current use case)
My own goal is to provide a frictionless option to podcasters who are stuck on hosts that don't support the transcript tag, to say "well, there is still no excuse for you to not offer transcripts to a segment of your audience that relies on them, you can simply add the link in your item description".
All we need for this to work is for the link, or the URL of the transcript, to have an extension that can be mapped to a MIME type. In the case of SRT, we already have this, and so I can go to a podcaster and say "here, I've created an SRT file for you, just stick this link in your description and modern podcast apps will be able to pick it up and the listeners who depend on this will be able to benefit from it." This approach will not work with generic JSON extensions which is why I have also proposed #452 .
Beta Was this translation helpful? Give feedback.
All reactions