UI for linear advertisements #429
Replies: 15 comments
-
|
We talked about this in Video Dev Slack, but a 3rd proposal is to mix the two a bit more. I like the higher level goals in Proposal 1, but I agree that having sibling elements with this much of an effect on each other feels a little awkward. My 2 cents would be that we go towards something like: <media-controller>
<media-ad-controller>
<video slot="media"></video>
<media-control-bar>
<media-play-button />
<media-mute-button />
<media-volume-range />
<media-time-range />
<media-pip-button />
<media-fullscreen-button />
</media-control-bar>
<media-ad-control-bar>
<media-play-button />
<media-mute-button />
<media-volume-range />
<media-time-range />
<media-pip-button />
<media-fullscreen-button />
</media-ad-control-bar>
</media-ad-controller>
</media-controller>The only special feature of the Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I'm liking the general idea and conversation direction here. 👍 With custom elements, can a slotted element (media) be inside a child or does it need to be a direct descendent? I couldn't find a quick answer, but that's obviously a key detail here. Hypothetically, we could have Ads...so much to wrap your brain around. Does this approach apply equally to
Does it matter? Are all of those still a concern? |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't appear slots in children work today. So in the first few examples, either But that's pushing me to want to explore wrapping media-controller with media-ad-controller. <media-ad-controller>
<media-controller>
<video slot="media"></video>
<media-control-bar>...</media-control-bar>
</media-controller>
<!-- ad control bar -->
<media-control-bar>...</media-control-bar>
</media-ad-controller>What are the downsides of that? Feels a little odd to not have An upside is |
Beta Was this translation helpful? Give feedback.
-
|
But wouldn't that approach make the event bubbling stuff a bit weird? What if we did something similar to what I proposed for |
Beta Was this translation helpful? Give feedback.
-
Can you say more about weird?
Yeah that's definitely an option too. A sub class that bolts on ad functionality to the controller. We'd still need to distinguish between control bars in that case. |
Beta Was this translation helpful? Give feedback.
-
Doesn't it feel weird that a parent element would affect the bubbling of events to a child? I'm not even 100% sure how we'd even handle that, but just looking at that markup and thinking of the implication makes me squint a little.
Totally, I think I'd still fall back to the special |
Beta Was this translation helpful? Give feedback.
-
I'm probably not seeing the whole picture but I'm not sure why the parent element (ad controller?) would need to affect bubbling. I think the ad controller would listen to the events it needs from media-controller, but wouldn't need to do anything with the other events. Relationship-wise, it seems like the ad controller needs to know about media events, but the media-controller doesn't need to know about ad events. The media-controller gets controlled by the ad-controller as needed, maybe similarly to how the IMA ad plugins work with the video element. The video element does its thing, and the ad framework works around it. It's pretty much exactly like when you wrap optimus prime in bigger optimus prime. |
Beta Was this translation helpful? Give feedback.
-
|
@heff Good catch with the child slots issue. Proposal 2 will not work as written. The
If the ad controller only wraps the ad specific controls (proposal 1), it would be able to intercept the If the ad controller wraps the entire UI, there would need to be a new set of controls that fire ad specific events so that the ad controller could differentiate between the content actions and ad actions. This wouldn't be too difficult as the new ad controls could simply extend the existing controls and override the event emission with the new ad specific events. All this being said, I think the much bigger problem is: Where does the ad SDK integration live, and how do the web components interact with it. Let's use |
Beta Was this translation helpful? Give feedback.
-
|
Got it, I see now. Thanks for clearing that up. One thing I'm feeling through all of this is media-controller probably needs a set of defined ad events, to at least be able to proxy ad state. But otherwise, I think we might need to break up the different ad situations into their own problem sets, because they might need to be solved differently. Let me try to enumerate them... Server-side adsThe media element itself needs to be able to emit standardized ad events at minimum, if not other functions like blocking scrubbing, handling clicks on the ad, and sending ad click reports. Client-side adsClient-side ads via an ad-supporting media element, e.g.
|
Beta Was this translation helpful? Give feedback.
-
Had more thoughts on this one, incase UI level integrations are still a direction we need to go. I don't know that we would need ad specific UI events here. The ad-controller could add event listeners to There does seem to be a key long term implication to consider here, which is whether or not (this is very complicated... sorry for the all the long exploratory comments) Pulling from various ideas, here's a proposal... 1. Add first-class ad states to
|
Beta Was this translation helpful? Give feedback.
-
|
Thinking about the overall design again with @heff, another approach that doesn't require new elements or DOM hierarchy would be: The The custom media element would need to fire a new event signaling the start/end of ad playback, an <style>
media-controller[media-ad-break] media-progress-range {
pointer-events: none;
background-color: #FFCC33;
}
</style>
<media-controller media-ad-break>
<player slot="media" />
<media-control-bar>
<media-progress-range />
</media-control-bar>
</media-controller>The display of ad data could be handled in a couple of different ways. For a "YouTube style" display, when the ad break starts the custom media element would fire a For a "Hulu style" display, the custom media element would need to provide additional pieces of state to allow for a separate rendering of ad time:
It would be the custom media element's responsibility to determine if The last piece would be a single new API method on the custom media element for |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Casey, this all sounds good. I think we could handle both cases and let the UI dev choose, if we provide the details of the adbreak, and always rely on media-duration/currentTime to represent the current time.
After a
With then some added ad-specific details
Most cases I think would just choose the simple 1-ad path. It does seem to be a key decision whether we always split the ad metadata from the primary video metadata. Including things like, does media-duration get updated before or after |
Beta Was this translation helpful? Give feedback.
-
|
I think we will have to provide the ad metadata separately. In addition to the time info, metadata about whether the ad is skippable and clickable can vary from ad to ad. Furthermore, for live streams the total number of ads in a break isn't always known at the beginning of the break. This would leave us with the following list of changes needed for a production ready ad UI: MethodsCustom Media Element
EventsCustom Media Element
Media controls
AttributesCustom Media Element
Media controls
SlotsWe will need at least one new slot, or perhaps a specific custom element, that acts as the container for ad rendering. Most ad SDKs require this element to be passed in to ad manager. |
Beta Was this translation helpful? Give feedback.
-
|
I like this.
Here's a question...do we need a We'll need something additional to know how many ads are in the break, when we can know that. e.g. This is feeling really good. 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I'm open to any naming changes, and I would go with |
Beta Was this translation helpful? Give feedback.
-
Requirements
Provide a set of components for displaying and controlling linear advertisements. The controls layer would provide functionality to:
Proposal 1
Create a
<media-ad-controller>element which bootstraps the ad SDK and act as a wrapper element for a separate set of ad controls. The ad ui would use the standardmedia-*controls, i.e. buttons like play and fullscreen, and the<media-ad-controller>would intercept theMEDIA_X_REQUESTevents and perform any ad specific logic.Pros
<media-ad-controller>instead of having each component be aware of what type of media is playing and switching its logic accordingly.<media-ad-controller>. With a single control bar for both modes, the playback mode would need to be made available in a way that CSS and JS could be written to customize the control for the given mode.Cons
<media-ad-controller>the reference would need to be injected some how:Proposal 2
Similar to the first proposal but with the
<media-ad-controller>wrapping the entire UI.Pros
Cons
<media-ad-controller>would need to have amodeattribute that could be used to create CSS selectors, i.e:Other considerations
The current set of web components revolve around a stable public API:
HTMLMediaElement. There is no similar standard for ad playback. When using a raw playback engine likehls.jsordash.jsthe ad implementation would need to be done separately. This could easily be encapsulated using<media-ad-controller>as a base class, and creating a ad-vendor specific element such as<ima-ad-controller>. For full featured players likeShakaandVideo.js, ad APIs are provided directly by the SDK, or via a plugin. In those cases there would need to be a element that translates the player specific APIs into a normalized API that<media-ad-controller>could use. Similar to the way<youtube-video>provides an API to mirrorHTMLMediaElement.Beta Was this translation helpful? Give feedback.
All reactions