Proposal: podcast:sortOrder for creator-defined episode ordering
#747
nathangathright
started this conversation in
Tag Proposal
Replies: 2 comments 11 replies
-
|
I like more this proposal than #570. Tag adoption it's slow/difficult. I think this one has a good balance between functionality and difficulty to implement. Do the |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
Hi TrueFans offers a sort order for podcast episodes and we also auto label the 'most popular' based on user activity i.e total time listened.
|
Beta Was this translation helpful? Give feedback.
5 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment




Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
At Podcast Movement 2023, Spotify announced their Best Place to Start feature, allowing podcasters to pin a single episode for new listeners. None of the prior RSS-based proposals in this vein found traction, so I wanted to outline an alternative approach and see if it would resonate more.
Purpose
Podcast apps typically sort episodes by publish date, season/episode number, and in some cases, by title or duration. Podcasters have no way to express other orderings (popularity, "greatest hits," "start here", editorial curation) in their feed. The workaround today is changing publish dates, which breaks chronological sort for everyone.
This tag lets podcasters define named sort dimensions at the item level. Supporting apps offer these as additional sort options. Non-supporting apps ignore them.
Relationship to
<podcast:pinned>(#570)#570 proposed a channel-level
<podcast:pinned>tag (implemented by TrueFans) for surfacing featured episodes. This proposal generalizes that idea: pinning is the simplest case, adding this tag to a few episodes, with all other episodes falling back to publish date.Specification
Tag:
<podcast:sortOrder>Parent:
<item>Count: Multiple (one per label)
Attributes
labelrankSorting rules
<itunes:episode>. No direction attribute.<pubDate>descending.That last rule is what makes this work for pin-only feeds: a podcaster who wants to pin 3 episodes out of 500 adds the tag to 3 items. The other 497 flow naturally below.
Examples
Pin a couple of episodes (simplest case)
A show with 200 episodes wants new subscribers to see two entry points at the top. No tag needed on the other 198 episodes.
Popularity ranking
Multiple dimensions on one episode
Design Notes
Tag flexibility does not dictate UX. Hosts and apps have no obligation to expose the full flexibility of any tag. Hosts may choose to present a UX to their users that matches Spotify for Creators and handle the RSS details behind the scenes. Apps may choose to limit the number of episodes or dimensions they support to avoid overwhelming the user. Please remember that you are always the final vote on the best experience for your users, and the shape of an RSS tag is an entirely separate matter.
Item-level, not channel-level. The metadata lives next to the episode it describes (like
<itunes:episode>,<podcast:person>). Hosting platforms can add rank fields to their existing episode editor. No separate GUID list to maintain or fall out of sync. The tradeoff: clients must scan items to discover available labels, the same pattern as<itunes:season>.No direction attribute. "Rank 1 = first" is unambiguous. With a direction attribute, does
ascendingdescribe the rank interpretation or the display order? Not worth the confusion. Clients can offer a flip toggle on their end.Float, not integer. Allows insertion without renumbering (1, 1.5, 2). Useful for drag-and-drop reordering in hosting UIs. Plain integers work fine too.
Non-contiguous ranks are fine. Ranks of 1, 5, 10, 100 leave room for future insertions.
Prior Art
<podcast:pinned>(#570): predecessor, implemented by TrueFans<itunes:episode>: item-level numeric ordering (serial), the pattern this mirrorsBeta Was this translation helpful? Give feedback.
All reactions