Proposal for "up next" attribute in <liveItem>

[SpencerPearson]

Bear with me as this is my first proposal, but I've been thinking:

It would be a wonderful feature if the <liveItem> had a way to pass in some sort of "up next" attribute that pointed to another <liveItem> either in the same or in a separate feed. This would ask the apps to switch the user (perhaps automatically, or perhaps via a pop-up prompt) to this next <liveItem> once the podcaster flips their current <liveItem> status from "live" to "ended."

Not sure the best way to write it, as you'd need an optional feed attribute (assume item is in the same feed if no feed attribute is present) plus a guid element. This could dovetail with the functionality Alecks has discussed with playlists in the namespace. Maybe have an upNextFeed="" and an upNextItem="" with GUIDs in each spot?

[theDanielJLewis]

I suggest looking to Twitch for suggestions on terminology as “upNext” makes me think it’s merely the next scheduled event (which could be some time away), not passing the audience to somewhere else.

Maybe this should be rolled into some kind of “redirect” option, that would trigger an optional redirect when the live event ends (but should probably not force a redirect—though that could be an additional option). This could redirect to someone else’s live event, or to any other kind of after-event call-to-action.

[SpencerPearson]

On twitch they call this behavior a "raid" where a streamer can dump their audience into another stream in progress.

Meh, I don't like the "raid" term. The "raid" is a function that you can choose at a whim and the "upNext" I'm going for is more a scheduling use-case. For instance, on Monday nights Hog Story comes on at 7 central, then Behind The Sch3m3s comes on at 9:30. With an "up next" tag, Hog Story can use a set-it-and-forget-it reusable attribute to build the cross-community audience and reinforce the Monday night scheduling flow.

Another use case I thought of was if there was a public radio station feed with all their shows in <liveItem> tags and could "upNext" the shows throughout their schedule. The individual shows could have their own sovereign feeds simultaneously that use the "upNext" to point to the next scheduled show in rotation.

I really am hoping we start thinking about this tag in a much bigger sense of radio/television programming history; I think we can do much better creatively than "What Would Twitch Do" mind traps for the development of all this tag could achieve.

[theDanielJLewis]

That's what it was! Yeah, I don't like that, either. I think "redirect" is general and descriptive.

The tag inside a live block could look like this:

<podcast:redirect target='{URL here}' force='true'>Text for the redirect banner/button.</podcast:redirect>

[SpencerPearson]

<podcast:redirect target='{URL here}' force='true'>Text for the redirect banner/button.</podcast:redirect>

I am not sure about the force being a namespace decision, that seems better to be left up to the apps as it's their decision whether to enforce anything that happens in the namespace. What would be a reason for me to ever use force='false' for instance?

I do like the idea of a potentially new tag altogether like this, but also an attribute might be easier/quicker to implement. I'm sort of back-and-forth on that lol

[SpencerPearson]

Actually on second thought, <podcast:redirect> isn't live-specific, so I think it falls outside of the scope of what I'm proposing.

I am talking about something Live-specific that solves a programming/scheduling experience need.

There is the <podcast:recommendations> tag already proposed #205 that could handle a "soft" or "suggested" redirect for recorded shows where time is not a factor for the listener, but I'm just spitballing from my experience so far using <liveItem> this past week.

[theDanielJLewis]

Putting <podcast:redirect> in the live tag makes it live-specific. 😃

Here are some reasons to force or not force:

• Don't force so the community can stay chatting among themselves after the event has ended.
• Don't force so the host can have an unofficial after-show, even though something else could be happening (think of followup Q&A from a conference session).
• Force when you don't want the chat to continue going.
• Force when you need to redirect to a different platform (either because of a problem or for a different kind of after-show, like everyone can join on Zoom).
• Force when there's a strong call to action, whether financial or social.
• Force to take the audience back to the podcaster's website, or to a page with the live schedule, or a thank-you page.

As for how the apps handle it, I suggest they all respect the "force" option. But a non-forced redirect could have a visual "countdown" that will automatically redirect unless canceled/dismissed, or simply display the redirect without any automated action.

[SpencerPearson]

Interesting! I'll have to take some time and think about that, I like the examples

[SpencerPearson]

Having had some time to think this over, I still am not convinced there's any need for a "forced" attribute because the use cases you give for using force="false" can be achieved just by keeping the status as "live." The notion of "forcing" an app to take an action is already presumptive in the first place IMO.

As for the separate tag issue, I don't want to ever redirect a listener from a recorded episode to some episode outside my feed. There is a good argument for sending people to related/friendly shows via the <podcast:recommendations> tag proposed in #205 but if one of my recorded shows ends I would prefer the user keep listening to my own stuff, or be shown the <podcast:recommendations>

The only time I would want to redirect listeners to a different item is when it's a time-sensitive redirect at the end of my stream to another <liveItem> in progress. There may be other use cases for this that others would be interested in, but personally I still see the easiest way to implement it with the smallest change to the spec would be adding two simple attributes to the <liveItem> pointing to a new <liveItem>