Proposal: <podcast:contact> #770
Replies: 7 comments 7 replies
-
|
Cool idea, but could we not use the txt tag, its already supported by so many apps, and was designed to be versatile for situations like this. |
Beta Was this translation helpful? Give feedback.
-
|
Updated my proposal to show how the |
Beta Was this translation helpful? Give feedback.
-
|
I like this a lot Daniel. Thank you for the UI examples. This is really helpful. |
Beta Was this translation helpful? Give feedback.
-
|
I'd love discussion on the terminology for the standard
I think that list is the shortest and least ambiguous. If we switched them all to nouns, that creates some ambiguity or more potential for error (even though a UI should standardize these without the user's having to worry). For example:
Even though I don't like having a non-parallel list, I think the mix of nouns and verbs is the simplest. But I'd love it all to be parallel if possible to do without creating ambiguity. Any additional values that should be considered? |
Beta Was this translation helpful? Give feedback.
-
|
I think that it could be helpful to have a machine readable boolean value for whether or not the podcast accepts guests so that all podcasts that don't accept guests could easily be filtered out. This is one thing that the |
Beta Was this translation helpful? Give feedback.
-
|
This is brilliant... I'm in full support of it! |
Beta Was this translation helpful? Give feedback.
-
The grammarian in me also likes the parallelism, but I think you may be hemming and hawing about it for good reason. A truly parallel setup is longer. I would also add something that you may have been thinking about too, which is the people who do not speak English. One, they may not appreciate the work that goes into parallelism, even if they know some English for computer science and programming. Two, the more letters, the greater the chances of error. If you do not know Korean, for example, and are just copying line after line of some documentation in Korean, it would be trivial to miss a typo such as 뭐을 or 무엇를 instead of 뭐를 or 무엇을. (It is like writing an napkin instead of a napkin.) I know I am worrying over a tiny edge case and engaging in the bigotry of low expectations, but if it causes even one app developer in Bangladesh or Poland to screw up with
Oh dear, yes—plus, the usage of reveal instead of revelation. As much as it makes us sigh or groan, we may want to accept the noun usage of invite. For what it’s worth, I am still fighting the losing battle of using data as the plural of datum, so the data are. However, I flip on media as a singular thing nowadays or the plural of medium. If we analogize, we could assume that in computer lingo (and just look at Discord etc.) the word invite can be a noun. To make things even shorter, how about In any case, for consistency, wasn’t camelCase baked into RSS from day one? Thank you for the forward thinking with this. I do wonder if the absence of such a tag is the explanation for the widespread persistence of the officially deprecated |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
What do you think of this proposal for a new podcast RSS tag as part of Podcasting 2.0?
(Nods to #10, #474, and #245, #769)
I suggest we pick up the conversation about adding properly formatted and more usable optional contact details to podcast feeds, using the tag
<podcast:contact>. This would solve providing contact information, as well as booking information (#769) in a simple, readable, parsable way.Similar to WHOIS/RDAP records for a domain, this tag can be repeated for multiple purposes.
Examples
This tag is simple in design, but still flexible.
Attributes
rel(optional): like a normal<a>tag, this accepts one of several standard relationship indicators. These could include, but not be limited to,feedback,pitch-guestto pitch a guest to this podcast,invite-interviewto invite this podcaster as a guest,sponsor, and maybepress(for press/media inquiries). If therel` attribute is omitted, the link is considered a general contact destination.href(required): this can link to anything that a normal<a>tag can link to: URLs, email addresses, telephone/SMS numbers, etc. This can be easily parsed by an app for possible design decisions. For example, displaying a mail icon for anymailto:links.Value (optional)
The value allows the podcaster to define the label for the contact method, which can be displayed by an app. But the value can also be optional and the app can fall back to an icon or generic text like "Contact."
Display in podcast apps
Since the tag can have multiple instances, podcast apps could display a single "Contact" button that opens a tray to display the list of contact options, like this:
Alternatively, if the podcast app detects only a single
<podcast:contact>tag, it could link directly to it and skip the tray.How this addresses the "booking" need
I don't think we need yet another single-purpose tag for booking information. This proposed
contacttag can handle that and address the other needs podcasters have for presenting contact information, especially if it's something other than an email address.Publishing workflow
In a podcast-hosting provider or publishing tool, it would let podcasters add multiple contact rows, choosing the type (
feedback,pitch-guest,sponsor, etc.), entering a URI with schema (the UI should detect if a URL, phone number, or email address is pasted and format appropriately), and an optional label.It's that simple.
Plus, building on @Alex-Sanfilippo's
bookingidea (#769), the UI for populating booking information could actually be the same:But instead of going into a
<podcast:booking>tag, it would create and populate the correct booking options of a<podcast:contact>instance—accepting guests or being available as a guest.Addressing the spam problem
Instead of existing RSS tags intended for sharing email addresses (and with no purpose or label), this tag can link to anything an
<a>tag can link to, including email addresses, contact forms, SMS phone numbers, and more. Thus, the podcaster could link to anything but an email address.Smarter features
Since this would follow the format of an
<a>tag, that means smarter features can be added to thehrefattribute, including prepopulated emails or text messages, URL parameters, and such.For example (courtesy of W3Docs):
Would send an email to
email@example.com, CCsecondemail@example.comandanotheremail@example.com, BCClastemail@example.com, set the subject toPodcast feedback, and prepopulate the email body withSome body text here.The way forward
Instead of multiple single-purpose tags all doing essentially the same thing, this tag unifies the ideas, adheres to common conventions, is simple to implement and support; and yet it is also future-friendly, extensible, and highly versatile.
Beta Was this translation helpful? Give feedback.
All reactions