Closed theDanielJLewis closed 1 year ago
There is nothing wrong with iTunes:title
system. Why replace something that is not only supported by Apple, Spotify, Overcast etc, it does the function it is meant to do.
A change like this would have a huge harmful effect on the millions of podcasting apps already on the market. It would make each one of them have to add lines of code to support this version of title.
While I understand why you want to change from iTunes to Podcast - it feels more like a branding issue then solving any issue at hand.
For example.
<podcast:title social="Earning #PassiveIncome in #Podcasting, with @theDanielJLewis">
Earning Passive Income in Podcasting, with Daniel J. Lewis
</>
To build this section into a podcast upload script we would need to add another input box for title called social title. This means for the podcaster they would have to input the title twice. It also means that noob podcasters may not understand this and may find it confusing. I write this as a podcast hosting provider that currently support 68 podcasts and we are launching to the public in 2023
For example the code for the above would have to be
<form>
<input type="text" name="title" required/>
<input type="text" name="social_title"/>
</form>
We would then need to in the backend we would need to check if they filled out the social_title
and if so we would than need to add it to the <podcast:title social
section - it is doable but why?
Think about it, Twitter and Facebook already allow you to add a preview image, an embedded player etc. While I get the idea for being able to hashtag and @ a person - which is cool and helpful. I would rather have an AI system in our podcast system that allows us to do this automatically the less work for the podcast owner the better.
I work on thew KISS (Keep it simple stupid) method, if we want a social tag, then why not create <Podcast:socialPost>
this way the social post can be something like.
<podcast:socialpost default="TEXT HERE">
<twitter>(CHAR LIMIT)</twitter>
<fb></fb>
<mastodon></mastodon>
</podcast:socialpost>
It may not be the best way to do it, but from my side I can see advantages from the above. The fact that as social media platforms launch we can add them and those podcast platforms can read it very simple. Of cause this comes down to the social networking site supporting this feature.
Hi again, @redimongo
Why replace something
While I entirely agree that replacing existing tags is a fool's errand, this isn't a replacement for anything: just an additional tag that may offer better functionality. The <title>
tag won't go away. The <itunes:title>
tag is optional, and your customers have no need to use it.
To build this section into a podcast upload script we would need to add another input box for title called social title.
The new podcast namespace makes no recommendation in terms of UX; but typically how podcast platforms already deal with itunes:title
, sometimes it's simply not added to a feed; sometimes it's filled in automatically based on watching for typical patterns; and sometimes it's hidden behind an "advanced settings" pane.
if we want a social tag, then why not create
Good idea - such a good idea, here's podcast:social
. It doesn't seem to have moved forward, possibly because it's also being suggested that it's used alongside a few other tags. Please do give @benjaminbellamy your thoughts over there.
After saying all that: I don't really see the benefit of this separate podcast:title
tag. The podcast:social
tag would do a better job highlighting usernames on different platforms - I'm @james@podcastindex.social on Mastadon, @jamescridland on Twitter, and james@getalby.com on Nostr, probably, so the idea would be that this information was in a podcast:social
tag.
BTW, this reminds me (I had completely forgotten I had done that…): Castopod has been implementing <podcast:social>
for two years. So if you want to see it live you can have a look at any Castopod podcast.
@benjaminbellamy I saw your use of podcast:id
as well which was nice.
Happy to get podcast:social
into the Podnews feed. The more support, the better. I wonder if there's a reason why we can't get social
officially added to the full spec, @daveajones ? It would be very useful for podcast directories.
I think I added podcast:id
even before the very first Podcasting 2.0 tag was validated… Back then I was so impatient that I started implementing WIP tags…
@redimongo, one of the goals of the Podcast Namespace is to be a drop-in replacement for the "iTunes namespace," but then with added functionality on top.
The purpose of this additional title tag is to give more control and enhance the end-user experience for apps that support it, just like a few apps already do with episode numbers, season numbers, and episode titles. Those are three separate tags in the iTunes namespace, and they help split out and better display the data that would otherwise be crammed into the <title>
tag.
Every innovation we're making in Podcasting 2.0 means that developers would need to either implement support or get left behind. If we stick with the status quo, then there would be no innovation—or arrogant companies like Spotify would make proprietary "innovations" that go against the foundational philosophy of podcasting.
In my episode of The Audacity to Podcast next week, I'll be talking about how to put episode numbers in titles and mentioning Podcasting 2.0's superior
<podcast:episode>
replacement for<itunes:episode>
. But we don't have the appropriate<podcast:title>
to go with that!Why we need
<podcast:title>
The obvious reason to have
<podcast:title>
is to offer yet another drop-in replacement for the Apple's namespace.And how the tag is useful is the other reason to offer it in the Podcast Namespace.
The
title
andepisode
tags go together (along with the optionalseason
tag). The additionaltitle
tag is necessary for apps to smartly display an episode (and season) number differently in different contexts.In Apple Podcasts, an episode number from
<itunes:episode>
could display in any of the following places:These different displays depend on the viewing context and how the feed is configured. Note the biggest difference is whether a podcast type is "serial" or "episodic."
But some of the above will work only when the
<itunes:title>
field is populated, even if it's exactly the same as what's in<title>
. I think this is a good thing because it supports backwards compatibility. Old podcast apps can use<title>
, which is fully allowed to have the episode number (despite some myths and misunderstandings about Apple's rules), but new podcast apps can use<itunes:title>
or<podcast:title>
to smartly separate and differently render the episode number from the episode title.Thus, we need
<podcast:title>
since we already have<podcast:episode>
, and we don't want to cause episode-number duplications.How Podcasting 2.0 can make this better
Like everything else, I think a fully Apple-compatible drop-in is necessary, but we can make it better with more capabilities in Podcasting 2.0.
I'm short on ideas for innovation right now, but here's one potential: a
subtitle
attribute that can be used to summarize the episode in extremely short form. (Yes, the subtitle could also be a separate tag.)But I'll admit that's not a high demand.
Another idea is a social-sharing version of the title in a
social
attribute, and this is what would prepulate the message on Twitter, Instagram, Mastodon, etc. For example:This could also be a place to hold "flair," like you see on Reddit. But "flair" could also be a separate tag.
How apps should read
<podcast:title>
Like Apple Podcasts and a couple other apps, any Podcasting 2.0 app should use
<podcast:title>
if it's present instead of<title>
. If missing, fall back to<itunes:title>
. And if that's missing, then fall back to<title>
Since
<podcast:title>
should not include episode numbers, season numbers, or the podcast name, podcast apps can use this as the cleanest version of the title, pretending episode/season numbers when relevant, or similar behavior. This is what Apple Podcasts does, too.