Combine podroll, channel, recommendations, and featured into a single tag #508
Replies: 8 comments 6 replies
-
|
I would also suggest adding something so a tag like this could be used for building playlists. |
Beta Was this translation helpful? Give feedback.
-
|
Great idea! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Daniel I like your proposal and will address that below. But firstly what we have done is implement the current Podroll proposal. So we read the RSS feed find the Podroll Tag and we lookup the GUID and display them. Works really well. We have several examples of this working already. What is needed is for hosts to enable podcasters to create a podroll in their UI and add it to the RSS. So a search function to find podcasts and a simple checkbox to add to podroll. This then stores the related GUID in the RSS. At the moment we look for Podroll rel=channel. If the community agreed it would be simple enough for us to look for Podroll:recommend reason=podroll But for now we have a simple Podroll working. We have also just implemented a playlist option inside of Podfans. see image 2 below.
So now we have a button that allows any user to add episodes from any podcast show and save them. Other people can follow them or save them to their own playlists in their profile. We are adding the option for the creator of the playlist to then get a payment when someone plays their playlist. #value4value. along with a split payment back to the podcast host. But in terms of the playlist we are storing them as episode GUID's in the same way as podrolls. So podroll rel=episode for now. We are adding a share/export playlist function so other apps could import them etc. We are also adding a podroll rel=recommend for shows. However, I do like the simplicity of your proposal but will let others jump in to see which direction this features travels.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks! And yes, for the apps out there, they could simply filter the For example, an "About this podcast" page could show off a sort of "Also guested on" section. Podcast apps could also easily parse the tag for "Get more podcasts from [name]." And, of course, the "podroll" (ick at the name!) idea of "The podcast also recommends" (note that it's worded in a way to make clear the recommendations come from the podcast itself, not the app/directory). |
Beta Was this translation helpful? Give feedback.
-
|
This could be like the medium tag with several extensions and apps would treat each state differently. For example with the medium tag if we see music we rename episodes to tracks and transcripts to lyrics. I assume with the podcast: recommend tag we would do the same with the attribute tags. Just got to agree on these attributes. I like podcast:recommend reason=reference t=01:45:20 (for the timestamp). |
Beta Was this translation helpful? Give feedback.
-
|
Right, if done well, this can be a very powerful, very flexible feature and yet still maintain simplicity. |
Beta Was this translation helpful? Give feedback.
-
|
I really like this idea. Many features discussed here amount to a way to link to feeds/episodes so a general linking mechanism would cover them all and maybe more. I know the |
Beta Was this translation helpful? Give feedback.
-
|
I'm disappointed that we wish to complicate this simple feature, and kick any chance of adoption down the road. Specifically, I remain deeply critical of an idea of putting specific episodes in here - that's not what this tag was for, and the suggestion lacks any editorial curation other than a random list of episodes. It's important to tell people why you're choosing a specific episode; which this (and the related Daniel - how does your "reason" code work in practice? Would there be multiple tags with individual shows, or multiple tags with lists? Please could you give us a concrete example of how it might work?
Once again, please could we avoid trying to boil the ocean here? This appears to be a glorified jumble-sale of random links heading all over the place. It will fail - and will deserve to fail - if we try to add the kitchen sink into this proposal. Specifically, I would reject any use of the RSS URL. That is not guaranteed to be permanent. The podcast GUID is guaranteed to be static, and will never change. The process for looking this up is painless; and most podcast directories will/should have this in a database in any case. I'm so disappointed that the simple, straightforward podroll element is being hijacked here by "wouldn't-this-be-nice" complications that appear to have no basis in good UX, nor have any evidence that listeners would use these features. It will kill this simple tag stone dead. Perhaps that's the intention: but I thought we had a simple and well-understood plan for progressing an algorithm-free recommendation tool under the control of creators; instead, we appear to have a whole department store of cruft and unwanted gifts. |
Beta Was this translation helpful? Give feedback.
-
|
@jamescridland I like your idea of some sort of editorial/explanation for why the item was chosen for remoteItem, should be considered in the remoteItem discussion. I tend to lean towards podroll being a recommendation for a channel, and remoteItem being a list of items that point to different items in different channels. I'm not a big fan of multitools. I'd rather have a knife and a pair of pliers that does each job well, over a leatherman multi-tool that does each job mediocrely. Same applies for tags. Podroll should have a narrow focus, in this case, a list of recommend channels. remoteItem has a similar but different narrow focus, a pointer to a recommended item. Different jobs, different tools. I think this makes picking and choosing which tags are supported much easier for an app or hosting company as well. |
Beta Was this translation helpful? Give feedback.
-
|
Agree about the name, it's an anachronism that is not self descriptive to anyone under 30 and isn't also a native english speaker as highlighted here #451 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
I think this is a summary of the separate areas of discussion and how this proposal differs from the original:
I wrote this to help my thinking, if I am misunderstanding please say. From my point of view allowing links to podcasts inside items is the most useful change as I frequently have to search to find podcasts mentioned in episodes. |
Beta Was this translation helpful? Give feedback.
-
|
This is a great and helpful reply. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't caught up with these latest comments, yet. But I realize now I didn't communicate this idea very well, so I'll refine it and let you know when it's finished. But here's the gist: combine "podroll," "recommendations," and such into the same simple implementation, simply with an extra attribute that would allow podcasts to recommend other podcasts for different reasons instead of having so many different tags with so many different methods to populate them. More (or should I actually say, "fewer"?) details to follow. "Keep listening!" … |
Beta Was this translation helpful? Give feedback.
-
Aside from my extreme distaste for the name "podroll," I suggest we merge a bunch of ideas that are doing the same thing but in only slightly different ways.
Consider this. Under what circumstances might someone want to refer to another podcast?
All of these could apply to recommending episodes as well as podcasts. But there are additional circumstances someone might want to refer to another episode:
It seems only two things differentiate these 6 (or more) recommendation circumstances: context and reason.
With this in mind, I propose that we merge all these ideas into a single versatile tag, such as
<podcast:recommended>.This tag would have an attribute for defining the type or reason something is being recommended. For example:
reason="related"(or a better word) would indicate the podcast has a relationship with this one, such as a network.reason="relevant"(or a better word) would indicate the podcast is similar to this one, such as different podcasts about the same TV show, or it's the guest's own podcast.reason="liked"would indicate that the podcast is merely liked by the hostreason="guest"would indicate that someone from this podcast was a guest on the recommended podcastreason="reference"would indicate that the other podcast was somehow referenced in this oneThis
recommendedtag can appear in the channel, referring to only other podcasts; or appear in the item, referring to either other podcasts or other episodes.Even better, this tag could be used to reference other media types, while the default type is "podcast." It could recommend books, movies, music, and more.
This would conquer multiple needs with a single tag, especially "channel" and "podroll"/"recommended."
We could design the tag to accept GUIDs, RSS URLs, URLs (such as to books or movies), or an OPML file to make it easier to maintain a central recommendation list (like for networks so they don't have to update every RSS feed when a new podcast joins the network).
Beta Was this translation helpful? Give feedback.
All reactions