RFC 0001 - Dynamic Anchors

RFCs
1

Dynamic Anchors

Summary

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:

  1. Enable extension developers to offer multiple anchor point activation options.
  2. Offer a migration path for existing extensions to convert to upcoming extension anchor types.

Motivation

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.

Detailed Design

Extension Manager

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.

Dynamic Anchor States

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.

Activating

Activating

Active

Active Dynamic Anchor

Deactivate or Edit

Deactivate or Move Dynamic Anchor

Component extensions are a new anchor type we’ll be talking about in the new year

Developer Site

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.

Rollout Considerations

Scope

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.

Upgrading Existing Extensions

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.

For Broadcasters With Extensions Installed

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.

Drawbacks

Complexity for Broadcasters

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.

May Lead to Subpar Experiences

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.

Alternatives

Multiple Extensions for Multiple Anchors

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.

1 Like
3

Sorry removed previous comment as I saw this after reading a second time. I do think you’re underestimating the ability of streamers though. If a broadcaster is looking into extensions they are typically a little more technical than other users.

4

I respectfully disagree.

And Extensions should be accessible to all users regardless of technical ability.

5

ExtensionPanelAndOverlay

This is what I was thinking of when I wrote the comment, it may be a little over simplified, but something like on the Details page for and extension you could have a Feature section (up to dev to fill in) where they give the user the Features for the Panel and Overlay

@BarryCarlyon You’re right I do sometimes forget that some just aren’t technically minded, it’s a bad trait of mine.

6

Agreed, this would be a good way to accomplish this if we decided to go down this path, perhaps with a bit more information around where the extension is active without having to go into the dropdown.

We’re not opposed to adding that functionality long term but it’s additional design and development work to modify UIs on the developer end (to choose valid combinations of active anchors – a problem that becomes larger as we add more anchor points) and adds cognitive load to the broadcaster.

If you have thoughts on compelling use cases for having an extension active in multiple anchors simultaneously, we’d certainly reevaluate the prioritization of that work.

7

@splatwes Sorry just one question on the way you were thinking of implementing this, were you thinking of allowing at the moment up to 3 different viewer html pages? so I would have viewer-panel.html, viewer-overlay.html and viewer-component,html (if that’s the use case for components). Or were you thinking one viewer.html and the developer has to distinguish between the two?

To answer your question however I think for example I am building an extension for my Twitch Chat bot, this extension is going to have things like a “casino” and other features. I would like a “click map” section to the overlay extension but I only want the “broadcaster schedule” part of the bot to be on the panel. So although they are the same extension, integrated into the same EBS and are part of the same twitch bot. I would have to have a specific Panel and Overlay Extension as the “single” extension with multiple anchors wouldn’t be a viable option as I would like both.

8

@LuckyNoS7evin Yep, you will be able to specify separate viewer HTML for each anchor type. If you prefer to handle everything in one file that’s fine too – you’ll just reference the same file for each anchor type. We expect most people will want distinct HTML for each anchor type, however.

Thanks for the example! In this case, since the functionality is so different between the two anchors, why wouldn’t you release these as two separate extensions?

9

@splatwes Okay, the issue is it’s part of one Bot solution, so for example the broadcaster can pick what shows in the panel and what shows in the overlay. They can also enable and disable particular features in both.

It’s a case of with multiple extensions:

  1. Having to deal with multiple secrets, and the rotation of those
  2. Multiple review processes if I want to release one change to both panel and overlay
  3. The broadcaster would have to change the configuration twice (if I was to use the configuration page)
10

This makes a huge amount of sense, I am all for it.

My only feedback is that some scenarios I would appreciate if the same extension could anchor to multiple spots at once. For example I may wish to show some on screen information on the video overlay but for more detailed stats should refer to the panel.

Cheers

1 Like