Currently each extension is defined with a single, non-adjustable anchor point upon creation. With dynamic anchors, we will enable developers to create front ends for multiple anchor points. This will allow broadcasters to choose which anchor to assign an extension to. Summary:
- Enable extension developers to offer multiple anchor point activation options.
- Offer a migration path for existing extensions to convert to upcoming extension anchor types.
With our existing extension architecture, each extension is defined by the anchor point type that it is assigned upon creation. This anchor point cannot be changed – if the developer of an extension panel wants to also offer the same functionality as a video overlay, they must create an entirely new extension and start from scratch.
This problem is exacerbated as we continue to develop new anchor points – a single extension concept could result in multiple, identical extension listings with the only differentiation being the anchor point the extension can be used in. This creates a confusing discovery and management experience for a streamer, as well as a frustrated extension management experience for a developer as they would have to update and maintain multiple distinct extension listings for each update.
Our solution is one of the most requested developer features to date – dynamic anchor points. Extensions will no longer be defined by their anchor point, they will instead be able to offer multiple anchor point options for streamers to install and activate into under a single extension listing. This provides improved user experience for streamers, drives adoption by adding flexibility and customizability, improves developer extension management experience, and critically enables for future anchor launches to be quickly adopted by existing extension developers.
Extension Manager will need to change to support activating multiple anchors. After an extension is installed, it should, in the activation drop down, list all the possible anchors/slots it can be activated on.
A dynamic anchor shares the same states as the other extensions, inactive and active. The drop down controls the location of the extension and the ability to deactivate or relocate an extension if currently active.
As a note, this change allows one extension to live in different anchors but not simultaneously. We have consciously decided not to go down that route for the time being to lessen complexity for the broadcaster.
Component extensions are a new anchor type we’ll be talking about in the new year
The extension core services will need to be able to store, modify and return the new anchor data. To support this, the flow for assigning anchors in the developer site will be changing. Where today you are given a dropdown to select between panel or video, going forward this will be an interface that allows you to select multiple (at least 1 anchor required).
For each anchor selected, you must enter the following information:
- Viewer html path
- Relevant metadata for that anchor (ie for panel extensions, panel height)
At this time, no other settings can be changed between anchors. Notably, we will not be offering the ability to customize the configuration page per anchor (as the configuration step takes place before the broadcaster has assigned an anchor) or the live dashboard interface.
We will be rolling Dynamic Anchors out to all developers at the same time. When it’s released, developers will see new fields when creating a new version of their extension.
Existing extensions can be upgraded by releasing a new version with the required fields. When releasing a new version of your extension you will see the new fields for the new anchor points. See Developer Site section for more details.
While we recommend that modifications to existing extensions be additive (adding support for new anchors), it is also possible to remove support for previously supported anchors in this process. If support for an anchor must be dropped, a slow deprecation with strong communication with the installed user base is the right, but not required, way to accomplish that.
If streamers have an existing version of an extension installed, it will remain active in its previously chosen anchor. However when the new version is released they will have the opportunity to swap.
If the new version of an extension does not support an anchor that a broadcaster has the extension active in, the extension will be automatically deactivated for that broadcaster when the new version is released.
To date, a single extension could either be a panel or a video extension. This delineation is clear and broadcasters understand it. Switching to a model in which a single extension could exist in different anchors may muddy the waters.
Particularly as the extension library and available anchor points grow, it will become increasingly difficult to adequately represent to the user at a glance how a specific extension can appear on their channel page.
As we reduce the amount of effort required to create experiences in multiple anchors, we are likely to find that many developers will attempt to directly port from one anchor to another which will likely result in a subpar user experience. The appearance of supporting multiple anchor types may end up being seen as more important than actually properly supporting multiple anchors.
We will have to monitor this as it develops and consider alternative measures if we find that over time secondary anchors end up being considerably worse experiences than the primary.
It’s already possible to create an extension for each anchor type. We could lean into that as our officially supported solution. This solution may be more intuitive for broadcasters when configuring their channel; having one extension per anchor point could be easier than activating in multiple places.
Given that this already exists as a possibility today, we’ve heard feedback that this would be an overly laborious setup for developers. This requires developers to create and maintain multiple extensions that essentially do the same thing in different places. They would have to maintain multiple secrets, multiple client ids, multiple build and deploy pipelines – all to create what is essentially a duplicate extension.