Playback order
farski opened this issue · comments
eg: a daily/weekly news show, where listening to the back catalog has very little value
eg: a serialized show that must be listened to in order
eg: an entirely evergreen catalog that could be consumed in any order, but the producer suggest some episode (or episodes) to begin with, or has some preference for brand new episodes over older episodes.
Is having some separate indicator/tag for this better than just recommending that content providers just put their episodes in the recommended order in the RSS?
Is having some separate indicator/tag for this better than just recommending that content providers just put their episodes in the recommended order in the RSS?
Yes, and here's my argument.
We could recommend that publishers use <itunes:order> to override the usual default client sorting, which is newest to oldest <pubDate>. A couple drawbacks: (1) Creators would have to cheat by numbering episodes in reverse order — i.e. the latest episode would always be <itunes:order>1</itunes:order>. (2) The client would still not know that this is serialized content.
Something like <sm:serialized> would make it clear that the content was serialized. That enables not only obvious features like better default sorting for serialized podcasts, but new ones we can't predict. For example, maybe clients can alert users if they inadvertently start listening to a new episode even though they only made it part way through the previous one.
itunes:order already has a specific purpose, which is to indicate the order episodes should appear in the iTunes Store, so it's not a good candidate for use in a wider context. I think it's good to find existing elements when they're out there, or to have an opinion on something that is currently used in several ways when the purpose is ambiguous, but itunes:order (and most itunes tags) are not. It's also a tough sell to other private vendors to say "the community has decided you all have to respect a proprietary decision Apple made.
…it's not a good candidate for use in a wider context.
Absolutely, I just used that as an example of what not to do and why in my response to @azpeters.