Changes Coming to Component Extensions and How to Update

[jbulava]

Update (2019/05/28): Here is @Diogee from last week’s Monthly Developer Update to talk more about the updates.

Following a recent RFC, there are significant changes coming to the way streamers and viewers install, find, and interact with component Extensions. In short, we are standardizing where component Extensions live on the channel and how viewers will interact with them.

Starting on July 15, 2019 in late July, components will live inside of an Extensions Sidebar on the channel page. For more details about these changes and why they are being implemented, please see our RFC linked above. For more details as to what actions Extensions developers should take to update their existing component Extensions, please read the rest of this post, which acts as a guide to explain how to test and design for the upcoming new component Extension user experience.

1. Developer Rig

The Twitch Developer Rig will be the first place that you are able to test your Extension with a demo version of the new component Extension UI. To get started, download and install the native Developer Rig from the Twitch Developers website. If you haven’t already, create a new project for your Extension by following these directions.

If your Extension supports the component anchor, there will be a new type of view that you can create titled “Component (New Design).” This view will continue to load the HTML file specified as the “Video - Component Viewer Path” in your Extension manifest.

When creating the view, you will have the option to define the size of your component in the view. These size fields will later be added to the extension manifest, but we present them here for you for ease of testing.

If these fields are left blank, the rig will compute a size for your component that most closely resembles the current size you have specified in your extension manifest, but applying our new constraints to component size (component Extensions can now consume > 50% of the player width when open, but can no longer occupy the space behind the player control overlays at the top and bottom of the player frame).

You will be able to click your extension’s icon in the new dock as well as the “X” button in the Extension top nav in order to toggle the visibility of your Extension and trigger any onVisibilityChanged callback you may have registered in the Extension helper.

If you create a view using the old component type, your Extension will now be passed a url query parameter legacyComponentDesign=true. If your component needs to render a different appearance when presented in the new design, it is expected that you render that appearance when this query parameter is absent, and render your current design when it is present.

2. Twitch Beta Client + Manifest Updates

On June 14, 2019 June 19, 2019, we will launch an update to the Twitch web client that will enable the new component Extension design by creating the flag “useNewComponentDesign”“useNewExtensionComponentDesign” in your browser’s local storage for twitch.tv and setting it to true. After enabling this flag, you will see all component Extensions on the site render with the new “Sidebar” design.

At the same time, we will launch an update to the Twitch Developers site that will allow you to specify your new sizing properties “Target Height” and “Aspect Ratio” (alongside the old ones). These properties will be automatically populated with values that are calculated based on your Extension’s current sizing properties, but you may wish to change them to fit better in the new framework.

You will be able to submit a new version of your Extension that supports the new “Sidebar” design at any point between June 14 June 19 and the consumer rollout of the update in mid-July. More details about this phase of the rollout will be communicated as we get closer to the June 14 June 19 date.

3. Updating the design of your component Extension

There are several changes in the new component Extension user experience that will impact how you design your new component. This design guide highlights those key changes and provides guidance on how to update your component Extension in order to work well with the new designs.

3.1 Close button

Your Extension no longer needs a close or minimize button as this behavior is now handled by the parent frame around the component.

3.2 Minimize and Maximized states

Your Extension will no longer need to support a minimized state. Users will maximize and minimize your component Extension by clicking on your Extension icon in the sidebar.

3.3 Component sizing, space utilization, and opaque background

Due to the elimination of a need for minimized states within component Extensions, component content is now required to fill the entire size of the request iframe. Components will no longer have a transparent background – a default opaque background will be applied to any unused or unstyled area of your component. Your component experience must fill the full space generated by your sizing parameters.

Recommended:

Avoid:

3.4 Extension icon

The new Extension sidebar has increased prominence and visibility to all viewers, making the design of your Extension icon of increased importance. We recommend your Extension icon to be fully distinguishable at a 30x30 px on a solid color background in order to provide maximum visibility.

Recommended:

Avoid:

4. Updating the design of your overlay Extension (if applicable)

With the creation of the Extensions sidebar and updates to component user experience, some overlay Extension may also require minor updates.

4.1 Video player safe zones

The video Extension navigation bar is now placed on the right side of the screen. In order to avoid overlap with your overlay thumbnail, it is recommended to align any thumbnails or buttons on the left side of the screen or allow a 75px padding on the right side of the screen.

Recommended:

Avoid:

[Breci]

I have a big problem with your design choice here. In my opinion it will create a bad experience and make extension looks like pop up spam.

Opaque background and full space

@jbulava

Components will no longer have a transparent background – a default opaque background will be applied to any unused or unstyled area of your component. Your component experience must fill the full space generated by your sizing parameters.

My extensions are made to not always take the full space of the iframe to provide a better UX to the viewers. If I can take less space I will so I don’t cover too much of the stream
For example, I can display up to 3 cards for stuff that can be requested by the viewers. But if the streamer only create one potential request I will just display one card and leave the rest transparent to be as less intrusive in the stream as possible

On my second extension I display quests, same system the limit is 4 but if there is only 2 created I only display 2 quests and leave the rest transparent

Examples

I do not agree on having a full opaque background for all the space. Extensions should be secondary, not something that covers the stream. We should leave as much visibility to the stream as possible: transparent background, semi-opaque background, space between component, etc

In my opinion, we can force having a transparent background that will cover the current content of the extension. I wouldn’t mind having a transparent black background behind my extension so viewers can clearly see the limits of it. But I refuse to have a full opaque background because it will just create the opposite effect and be too intrusive and looks like a spam pop up.

The top bar

Also, I noticed that there is a black “top bar” on top of an extension when it’s opened. It’s super ugly and intrusive.
It will just force extension to be like panel extension but put on top the stream. It really defeats the point of video components and forces a huge step back in term of UX for video component extensions

A final Note and question

So I just have a question for the team behind the design of the update:
Why would I design something different than a panel extension for a video component with this update?

Because right now it just feels like we will have to create a webpage on top of a stream. Exactly like a panel extension because the format is the same. And not something meant to be part of the stream and interactive.

I know I can seem a little too “French” here by complaining, but I really think it’s a mistake to go that way because extensions are an amazing opportunity to create interactive experiences and they should be part of the stream as much as possible and not just “on top”.

[Camille]

Salut Breci,

I’m Camille, the Product Designer for Extensions. Thank you for your comment! It’s always good to see Developers passionate about design.

To address your first question, the background of component extensions is now semi-opaque, not a solid color. That is to clearly illustrate the space being used by the extension, as various studies showed that viewers were confused when overlay extensions wouldn’t work because transparent components were placed on top of them.

As a side note, component extensions will be hidden by default, which actually reduces the amount of interfaces visible over the stream. From numerous studies, viewers expressed that extensions being visible at all time and at different locations on the stream, reduced the quality of their viewing experience. Providing better control when they want to view and interact with an extension and a consistent positioning increased the ease of use.

Secondly, regarding the top bar. We wanted to standardize key extension actions like accessing setting options and closing the extension. This is a familiar pattern with any windowing system and viewers will appreciate clarity in how to control extensions in a consistent way.

About the type of extensions to build. Overlay and component extensions have different uses than panels. Video extensions are generally related or complementary to the stream content vs panels which are generally static content that can is accessible when the broadcaster is live and offline, such as social media, schedules, and so on.

Hope this helps! I’m happy to answer any additional questions you may have, here or on TwitchDev Discord.

[Breci]

Hi Camille, welcome to the forum \o/

I totally see the point of grouping the video component extensions in one place. And I agree that there is a problem with having multiple extensions displayed at the same time and using buttons to open/close them.

Background

The problem I have with having a forced background that takes all the space is that it just seems to an “easy way” and not a “smart way”. As I said, I wouldn’t mind to add myself a semi-opaque background that matches the content of my extension to mark the limit of the space used at a given time but forcing it to the full size will limit a lot the possibilities of an extension because it won’t be flexible at all.
For example, a potential breaking point here would be customization for streamers. Let’s say I want a display with cards and another with lines. But I want to let the streamer choose to fit their stream style. The card type would be more horizontal while the list style more vertical. But I would need a bigger space to have both options available but with this update, it would not be possible to offer such customization since I can’t have a different space.

I really feel like the problem of having a click on a video overlay extension blocked by a video component extension should not be solved by extensions developers but by Twitch developers because it’s dependent on the architecture created by Twitch. And yes I know it’s not easy.
An idea for a potential solution would be to allow multiple fixed sizes for an extension.
For example,

• 30% height and a 1:1 ratio
• 30% height and a 2:1 ratio
• etc

With it, we could always take the space we need but be flexible since we can determine the different extension sizes. Since we will have a fixed place, changing the size of an extension during the runtime would not be a real problem if we still indicate to the viewers the size it takes with a background.

Top bar

For the top bar, my problem is that I don’t see video component extensions as “windows”. For me, video component extensions are not typical webpages they are made for interactive video and live with the stream.
If I want to make a webpage in a window I will not design it the same way I would design something for interactive video.
So applying a windowing system is, in my opinion, going against the immersion in the stream because it will really feel like a pop-up and not something that is made to be there.
On the other hand, panels extension should be designed as webpages, because they are living on their own space, can be popped out, and are meant to be informative even if we see some interactive extension there too.

The question

The point of my question was not about the type of extension I should build. but the design approach of the different extension types. Why should I design a video component the same way I design a panel extension? As you said they don’t serve the same purpose, and as I pointed they don’t live in the same place, so they should have different UX/UI codes and not be aligned in a similar windowed way.

Some thoughts other stuff about this update

• After this update, you will see a “war” to get the video overlay place. Not because people want to use all the space, but because they will need to have information displayed at some point depending on the action of other streamers or viewers. For example notification or community actions.
• I noticed the purple dots but we still don’t know what they are used for is it possible to have a bit more information ?
• Where will the bits transaction pop up appears now ?

[Firesplash]

We are currently developing an extension that was planned as component.
In short wording the streamer has a game client running and at some points community can interact with the running game.
For that reason the extension needs to be able to pop up some controls to a user when his reaction is required.
In your latest approach that means the user has to activate the extension when he wants to participate and needs to keep it open to allow the extension to do its work (alerting etc).

Thats the point where the always displayed background and the header get disturbing to the viewer.

Your latest approach is kind of “panels can now overlay the stream” like a call to “develop interactive censor bars”

I hope you can understand what the frustration is about. Basicly it might be an improvement for usability for people not aware of how those extensions worked before but it’s a huge restriction in how devs can utilize the overlay extensions.

For us that means we will now need to develop the extension as a full overlay and additionally as panel as well as non-recommended component v2 to have some alternatives.

Edit from Barry the Moderator: BASICALLY, the same thing as the Rage2 Extension (when installed as a componenet)

[instafluff]

I like the idea of making components easier and more organized but it seems like these changes seem to address a clutter issue that comes not from issues of the extensions themselves but from the streamer not being able to organize and properly preview how the component will look and interact as a viewer. These are a lot of changes and work on the developers and they limit the value of video components that I had been led to believe were trying to blur the lines between what is part of the stream and what isn’t so that Twitch could frontier the next level of interactions with live streams.

For example, when installing a video component and placing them over the stream, right now it’s done through dragging a little white box inside a rectangle without seeing how the extension looks in its normal size, and how to place it so that it doesn’t overlap or become messy with other components. On top of that, as streamers, we can’t even interact with the video components (or as developers, live test them) without being live on-stream, and I would have thought that part of the extension configuration process would be what’s updated before making any large organizational and design changes to video components.

I really love the potential of extensions and hope the video components don’t suffer in potential from what seems more like a configuration and preview problem than an inherent design issue.

[AlbericoD]

There is also the fact that you have to spend a part of the configuration page to explain where the person controls the extension (live config tab), what twitch features it uses and etc, what actions are necessary for the viewer and streamer (the rest is discovered over time), that’s the main point, about using the @Breci configuration made a topic suggesting some idea, I think it would have to be something along those lines.

[Suggestion] Add a button to pop out the Live configuration on the configuration page

After talking to some streamers I noticed that some of them don’t know they can manage extensions from their dashboard or where to find the extensions on the dashboard. This lead to some streamer thinking an extension doesn’t work because they don’t know they can access the management tool. I thought that adding a button to the live configuration from the configuration page could ease the work on the streamer to find where to manage the extension. This would also easily engage the people usin…

Suggestion : Markdown for Extension description

Hello! When creating an extension we have to enter a description to present it to the people who visit the extension page. But the problem right now is that we will have a big block of text without a decent presentation because newlines are treated as spaces. Having a way to properly organize extensions’ description would be really useful to organize the information about the extension and have a more efficient communication with the streamers. For example just use this markdown : Twitch Mark…

Improve activation flow for extensions

The activation flow for extensions is a bit messy in my opinion. One of the key point to have a user trying a new tool is to have it easy to install. Right now if a streamer wants to install, configure and activate a new extension he needs to go to the extension store, install it, configure it (if needed) and then go to his extension manager, find the extension in his installed extension list and then activate it. The segment where the user has to leave the configuration to go the extension ma…

[Diogee]

Hello all, I’m the Product Manager on this project and would like to help explain some of the decision making process that went into this update.

I can share with you that we spent considerable time looking into each of the problems and suggested solutions outlined above (and many more) to find a path forward that satisfies the needs of all three of the customers of Extensions - developers, streamers and viewers. It is critical that the Extensions framework provides not just power and capabilities to developers but also creates reliably and consistently good user experience for streamers and viewers because we know that if we do not, the quality Extensions built by everyone here will not end up getting used.

The current framework is not solving for the needs of streamers and viewers wanting access to multiple Extensions in the video - only 11% of streamers using a video Extension are using more than one and no single third-party developed component Extension is active on greater than 1% of HW on Twitch.

This update is the result of months of research to understand how streamers and viewers understand and interact with Extensions and how we can make components Extensions something both groups are more eager to utilize. The feedback we received was clear - components needed to significantly change to really enable streamers to utilize video Extensions in an effective way. Having multiple video Extensions all presenting visual content or calls to action was one of the major themes that repeatedly came up as a negative in our research.

The solution we’ve outlined here reflects the research mentioned above and we believe the end result of this update will be more streamer adoption and usage of components which ultimately results in more of your creations getting used on Twitch. While this update does change what a component can do to be different from an overlay Extension, our ultimate goal is (and always will be!) to empower our community to create new experiences on Twitch that get adoption and change the experience of watching.

I will be on the May dev update stream next Wednesday talking through some of this research and the feedback that went into crafting this update - I hope as many of you as possible can make it as I think it will help answer some of your questions. And for any questions the update doesn’t answer, I am always happy to take time to do Q&A and address your concerns directly.

[instafluff]

Thank you for taking the time to provide insight into the decision making process and it completely makes sense that multiple video components showing different calls to action would be a negative experience, which is why a simpler and more organized experience seems great, but the current solution limits the potential for more unique extensions that previously could be one of three video component slots now compete for the single overlay extension slot that is often taken by games like Twitch Sings and it makes lesser-known / 3rd party extensions even less likely to succeed, and that is my biggest concern about this change.

Would users really click an icon of an unrecognized brand / extension? And if every interaction with the component needs an additional click (could this be a hover please?) it adds more barriers for the user to interact with an extension, especially in this 1-click ordering world. Extensions haven’t been around for all that long and even as a developer, I’ve just been getting into extension development in the past couple months since TwitchCon of last year and getting more used to what works and what doesn’t for components vs. panels and been able to start brainstorming better and more ambitious ideas for them and have been absolutely loving the updates to the Dev Dashboard and tools and all that has been going into Extensions, so to have a really big and limiting change like this so quickly when it still feels like Extensions are in the early “I’m rich-app” stages of an app store and developers are just starting to understand what’s possible, is honestly kind of a bummer. If the ultimate goal is to empower the community with new experiences, we need a chance to experiment and try more things before getting literally sidelined, in the same way that indie game developers create new experiences that compete with large titles for their ability to push boundaries in other ways.

Those numbers do seem low with most streamers using just one component extension but it’s not as if they have tons and tons of Extensions competing for that space yet and good component Extension experiences are certainly tougher to design than panels which serve a clear informational purpose, but that’s why I believe they have a much greater potential and that we’ve yet to start to see what can really come from them.

[Breci]

Hi Dieogee

I apologize in advance, this message will be more direct than the previous ones.

First, let me tell that the base idea of this update is great. I love the idea of having the sidebar, it will be super useful and finally bring a better experience for viewers. It’s something that was missing and this part here is on the right direction for everyone. I hated seeing buttons to open extensions.

But for me Twitch is publishing a half finished job here.

The research

It’s great to know that this research has been conducted for several months, but the dev community also had to learn how to design extensions.

I spent months working with a UX designer friend to refine our extension design, to have a design that is as less intrusive as possible and as flexible as possible to create a great experience for both viewers and streamers.

And now I’m being told I need to throw all these months of work away, because it’s meant to be flexible and the update is not meant to create flexible extensions.

Let’s take an example

Right now there is a lot of problems in term of UX and it’s great to see some ideas to solve them. But I still think this should be done also in the review process

For example, the Rage2 extension should never have passed the review process.

The UX is horrible and is just a pain as a viewer to have the big bar in the middle of the screen.
And instead of making sure extension have a proper UX experience by giving simple rules for the review process, this update is just saying “we don’t trust developers to bring a great experience so you will just do basic webpages”.

Review Process

The review process should include a design review too. We need to improve the quality of extension, not make them all the same. An extension got a shitty UX? It doesn’t pass the review. Period.

With this update, you take away all the innovation, creativity potential and new great ideas that can be done with video component extensions and throw it into a fire without looking back.

The delay

To make it worst you only give us 2 months for these changes. Most of the small devs have a job on the side and redoing the design of several extension in a good way will take way more than 2 months because this is not the same design rules AT ALL.
I spent 2 weeks deciding how to design a horizontal menu for my configuration page and it took me around 6 months to have a design I’m satisfied with for the video component.
I now have a full-time job, and a second extension to update too. I can’t possibly update both my extension in only 2 months

This update would have been a great first step to introduce video component, not to “improve” them. We are going backward here. You are just removing possibilities without giving anything in return to the dev community to create a great experience for the community.

Also, you say it’s the result of several months of research, but we never heard of it before, did you even ask the indy dev community? Nothing was posted on the dev discord, nothing from extension partner manager, nothing from the newsletter, nothing from other members of the extension teams.
The community is willing to help, we already build tools and help people who want to create extensions, we help streamers to understand extensions. Just ask us, don’t tell us “we decided for you”.

What is missing

• The design itself should be improved and don’t feel like a pop up on top of the stream. I got complain that a button to open an extension was like a “spam pop up” imagine how people will react if we put a window on top of the stream.
• Give guidelines more than forcing a specific type of design
• Add tools for developers, give us a way to notify viewers, maybe a way to control what extension should be displayed, Improve the extension activation flow, etc
• Give more control to the streamer. Allow a “displayed by default” extension, give the streamer the possibility to force an extension to be visible by all the viewers, so they don’t have to say “hey click on the extension … , it’s on the right of the stream, there is 3 square, click on the 3rd one” for start a poll, or any live event using an extension

TL;DR

Pros:

• Finally we get a standardized display for extension
• The base idea with a sidebar on the right is really great, it’s the perfect place for interactivity next to the chat
• The end of extension buttons mess is finally here

Cons:

• With this update, you are forcing us to create “pop up” extensions, not extensions that live with the stream.
• You are destroying most of the creative potential of video component extension
• There is no flexibility with the design, you need a constant size.
• You push arbitrary design rules that are valid only for a part of video component extension and don’t offer a solution for the others
• You did not ask the indy dev community their opinion and just give us your decision
• This update is not a finished one. Take more time to polish it.

What I think you should do for this update:

• Delay it, refine it more.
• Add more functionalities to include all the different kind of video component extensions
• Ask the dev community directly we will help you

And a final word: Trust us.

[Diogee]

Hey Breci -

I hear and appreciate your passion. It’s awesome to hear about the time and energy you have put into your Extension, stories like yours are exactly why we started the Extensions program in the first place. A big part of why we want to move quickly with this update is because we want to prevent too many developers from going down a path creating components that will need to change and cause even more future frustration. You are right in saying this should have been what component Extensions were to start - we are much more confident that this design will actually enable streamers and viewers to have a better experience with components than what is currently in the wild.

The suggested path forward if your Extension needs to be default-visible is to support it in the overlay anchor point. The functionality of overlays is not changing in that they are still visible by default on channel load and now will have no risk of being obscured by component iframes.

[Breci]

Wow. So basically… you are just telling me "deal with it, you just lost months of work’. Did you even read my propositions? My questions? I have several of them on this thread.

Did you just skip the message of @instafluff too?

I will be direct here: it just feels like you avoid our questions or don’t even care about our concerns.

I already explained why I can’t move to a video overlay here: RFC 0012 - Component Extension Redesign .
I even talked about it with my extension partnership manager and he agrees that my extension Quests can’t compete as an overlay because it’s not meant to fight with an extension like streamlabs, op.gg stats, game specific extension. Streamers will ALWAYS choose a game-specific overlay extension than a small extension that only use 20% of the width.

[instafluff]

Okay I’m actually getting quite annoyed because it doesn’t seem like you’re listening to us and just pushing these changes no matter what so let me take a step back and try to understand why this change is absolutely necessary so immediately and share my own thoughts on the motivations for this change…

• Viewers struggle to understand what elements of a stream are – and aren’t – Extensions. - Why is this a bad thing?? A great extension should blur these lines but in a clean and seamless way

• Viewers have difficulty comprehending an Extension’s purpose or how to interact with it. - This is from bad/early Extension design and UX, not an inherent Twitch component design

• Extension positioning is different from channel to channel. - Okay, organizing components better might be great but streamers use the screenspace differently so shouldn’t the most effective positioning be up to the streamer? If only we could preview this positioning properly…

• Broadcasters are unsure how Extensions will appear on their stream and how viewers will be able to interact with them. - I explained this before about how we can’t preview components properly unless we go live on-stream to see it and then have to refresh the stream each time we move the little square on a separate configuration page that’s supposed to represent the component of whatever shape/size

• In 2017 (Extension launch) everyone wanted multiple components but 2018, only 11-12% of streams had multiple components - How many truly, really great and innovative components have even been developed so far?!

All of these motivations seem to boil down to components still not being used effectively and properly by both the developers and streamers, and therefore making it a bad experience for viewers, but it isn’t as if streamers are forced to use these extensions, and maybe the reason most streamers still only use one component is because they still only feel comfortable with familiar names like Twitch Prime or Streamlabs, but if that’s not the case then I’d also love to hear more about that. Basically, it seems like as developers, we’re still noobs with Extension development and haven’t made good use of Video Components yet and rather than guidelines and best practices / examples for what is working and what isn’t for components, you’re trying to do more work on Twitch’s side to cripple components’ potential and create more work for developers that are already invested in Extensions, and this doesn’t make any sense to me. And sure, you’ll be having a dev update Q&A next Wed but we already have less than 2 months from this launching so by Wed, that Q&A would just be a “here’s what we’re doing” and not a “here’s what we’re proposing”. Could you please help me understand better why you’re trying to make more work for both your team and for the rest of us where the reasons aren’t because streamers can’t properly place & configure the component or because we haven’t made compelling enough component Extensions yet for streamers to want as many cool and helpful components as they originally wanted at launch?

[Dist]

I thought I’d throw some of my thoughts into this. My perspective is as a small extension developer with a niche game-specific extension, but I’ve also been doing Twitch analytics for the last 4+ years and have talked with broadcasters/viewers of sizes ranging from just starting out to 15k sub partners through many events like Twitch London.

Styling of the unused area of component screen space
My extension is a type of song selection addon, so when looking at a playlist with only 1 or 2 items it simply doesn’t require a lot of space, but when there’s 10 items it takes up more height (and eventually uses pages if there are lots of items). As well as using only the size I need, my extension also lets the broadcaster change the colour/opacity to choose whatever is best for their specific stream and current theme.

Currently I display as much as I need, with this change you’re telling me that any ‘list’ type extension will now need to either take up all the space and just have huge unused portions of their extension filling the player, or alternatively using just what we need (leaving room to expand as the list grows) but now we have the unused area covered by a background from the extension frame now. So overall this design change will be more invasive to the viewing experience as it takes up more space which is unused. The background will also make it difficult to have parts of the extension have variable opacity, or broadcaster chosen colours as there’s the background which will change how things look beyond broadcaster/dev control now.

Shift in component design
These changes seem to be pushing a different design choice onto component developers, forcing what seems to be a panel view but over the player. Some design choices are no longer viable as a component which will force extension developers to either redesign as an overlay, or to deprecate and their extension entirely.

As has been previously said in this thread, going to an overlay isn’t an option for the vast majority of developers, they’re often made to work in conjunction with things like Streamlabs which many broadcasters use, not work in competition with them. While I have no issue with more competition for the overlay spot, because there is just 1 spot per channel it encourages a consistent stream experience and broadcasters often pick 1 overlay and stick to it, making game-specific extensions non-viable as an overlay.

Extension adoption stats
There has been stats mentioned such as only 11% of streamers using a video extension use more than one, and while I’m sure that data is completely accurate I don’t believe your interpretation of the data is.

The issue with extension adoption is not one that can be solved through design changes alone, as while there are design issues that could use improvement there is also a more fundamental issue which hampers extension adoption and growth and that is a lack of Twitch educating broadcasters and viewers.

Ask most non-devs what the broadcaster/developer split is for in-extension purchases, the majority have no clue, or wrongly assume the broadcaster receives everything from transactions they make.

Ask most broadcasters about video extensions. Many know there is a difference between overlay and component but they often don’t know the specifics, or that the limit is 1 overlay and 2 components. Or from a positioning point of view (which is a VERY important area considering some of these upcoming changes are because of extensions not playing nicely together) they don’t realise components cover up overlays.

There are many areas which broadcasters and viewers have simply no idea, and to some degree they don’t need to know every aspect of extensions, but a lot of the basic things they don’t know because Twitch isn’t making any attempt to educate the either viewers or broadcasters. If you want to increase overall adoption stats of extensions (which will hopefully lead to a growth in extensions being made, and in-extension transactions) you have to make an effort to show what is possible and why extensions can benefit the broadcasters brand and the viewers experience of a stream. If this is an area that will continue to be neglected then you will continue to see hampered analytics.

Release roadmap
Awesome for an RFC to have a release roadmap.

Sadly it’s a shame for it to be prioritised over RFC 0011 which is a much more important change, adding things such as transaction security through EBS being able to get those events rather than requiring client to send them (which has very limit fault tolerance).

As for the actual timing. 2 months is insufficient for many devs so will lead to a poor user experience when this goes live. I only have 2 extensions so will hopefully be okay but there are many devs who are more extension focused with many extensions that need updating.

This 2 months also gives no room for consultation with devs (which there seems to have been none) and force through at a rate which leaves no time for changes to meet that schedule.

tl;dr

• Design changes are needed yes, but some of these changes aren’t the way to go about it.
• Rushing the release of this will lead to poor broadcaster and viewer experience for every component that hasn’t had time to update.
• Neglecting proper education to go along with extensions is harming extension growth too, but I see no attempts to remedy that.
• There seems to be a misunderstanding by the devs who worked on this that overlays are a suitable replacement for components that wont work in this new design. Simply suggesting ‘make an overlay’ is not helpful, and it seems like you’ve designed these changes in a vacuum without really understanding what you’re suggestion or the issues involved in that.

[Born2Phil]

Those changes will definitely improve end user experience by removing clutter and streamlining the interaction. One suggestion, I think it would be very useful to add in the size properties (manifest) max values for width and height in pixels. In my case I have fixed dimensions so that I can reuse assets (styles/images) between video component and panel and I don’t really need to take/fill more real estate from the stream.

[xzion]

For what it’s worth, I’ll be taking down my two live component extensions once these changes go through in July. I agree that component extensions need some changes to make them more user friendly and uniform across the platform, however I think what’s proposed here is the wrong direction.

In my opinion, one of the best use cases for components is alerts/alert style feedback, where viewers can trigger something that is displayed to all viewers of the stream. I made simple, single purpose, monetized extensions that do exactly that. Now there’s basically no incentive to use them because the vast majority of viewers will not display the extension (ignoring the fact that the style doesn’t work anymore because I can’t have a blank area that only displays something when an alert fires). Also, the primary method of discovery for viewers to interact with the extension was through them seeing other viewers trigger it, as well as a small call to action from my ‘minimized’ states. Neither of those will be effective any longer.

The only way I can get similar functionality to what’s live now will be to convert the ‘alert’ display part of the extension to an offsite browser source that the streamer will have to add to their scenes in OBS. And then reduce the extension to a dialog for triggering outputs/alerts. In my opinion that’s:
a) a non-trivial amount of work
b) even less clear to viewers what is/isn’t an extension
c) a higher barrier to entry for streamers to install and
d) unlikely to increase the fairly mediocre traction/earnings that the extensions currently see (not Twitch’s problem to be fair)

For those reasons, I’ll be taking the extensions down since they don’t seem worth it from either an economic perspective, or a labor-of-love perspective given the constant changes to the platform that are often announced with little/no notice and require significant rework of the extensions each time.

If it were up for discussion, my ideal change-list would be:

• Add the new icon block as a central point for viewers to interact with component/overlay extensions
• Keep component extensions visible by default
• Put a little eye icon next to each extension icon to completely show/hide extensions (like the visible toggle does now)
• Give us a callback from users hovering/clicking the icon that we can use to trigger our active/minimized states (make it toggle an opaque background for the extension area if you must)
• Give us a function to trigger a notification bubble from our icon in the block so we can tell the viewer when something interactive is happening

But by the look of things it’s not up for discussion any longer. So be it.

[Breci]

Hi @Camille & @Diogee,
I took some time to write an article about all this to summarize the changes and point the problems linked to them. It regroups what is great about the update and what is bad about it.
You can find it here : The future of video component extensions

[jbulava]

We’re putting some finishing touches on the developer testing environment. We’ll be making twitch.tv developer testing available on June 19 and sharing a finalized timeline for full launch (Late July) in further communications on that date. Don’t worry – we will be providing additional time to build and test before full launch, testing time isn’t being cut short. The original post has been updated to reflect these dates.

[Francesco_Bovoli]

@jbulava

We’re putting some finishing touches on the developer testing environment. We’ll be making twitch.tv developer testing available on June 19 and sharing a finalized timeline for full launch (Late July) in further communications on that date. Don’t worry – we will be providing additional time to build and test before full launch, testing time isn’t being cut short. The original post has been updated to reflect these dates.

Hi there jbulava, it’s not late July, is there an updated timeline for launch?

[BarryCarlyon]

As per

Updating your Component Extension: Twitch Client Beta

Testing the new Extension Sidebar and component Extension user experience is now available on Twitch.tv! By following the steps below, you can now develop and test your video Extension within the new video Extension UI framework. You can manage the updated component sizing fields in your dev.twitch.tv console and you may submit an updated version of your Extension at any point ahead of the July 31 full roll out of the updated experience to all users. More information about what is changing and …

Later today is the current timeline (US West Coast)