Likewise, thanks for the detailed response! This is pretty much exactly what I’d hoped to hear back. Getting a glimpse of the process behind making Extensions gives me much more confidence in choosing to develop one.
I will say, my original concern still stands. It seems to me that the UX route you and your team have decided on is just as potentially effective as the alternative. Like you say, it’s a bet on user behavior, the reality of which is unknown until Extensions are available on mobile. Still, I respect the process taken to make that decision. My lingering apprehension comes from a couple doubts:
1) How many tabs are reasonably expected to be the norm?
You used the example:
I want to see the extension in tab 6, and then go back to chat - how can I do this quickly?
Is it likely that 5 mobile extensions would be norm, or even more than say, 3 extensions? The speed gains of the presented design are only present if, in the alternate design, the tab being switched to is only accessible by scrolling the menu. If the target tab is adjacent to the Stream Chat tab, switching between them is just as convenient as collapsing the chat would be. The key difference between the two approaches, then, would be what I consider the main advantages of the alternative design: preserving vertical space and reducing visual density.
2) The open-ended possibilities of Extension design
A partial basis for choosing the presented design is that:
…the current batch of extensions where fantastic material to glance at, to have on-hand when needed
Other current and potential future Extensions aren’t necessarily characterizable as reference material, so designing for that type of interaction might cuff other Extensions. In the case of an Extension which accepts keyboard input, I’d argue that it’s best to preserve as much vertical space as possible. Mobile viewports are cramped with on-screen keyboards as it is. Consider also an Extension which does supplant chat, yet still keeps the user engaged with the video content. Wouldn’t a fixed navigation element to return to chat become a distraction?
This is speculative, of course, yet still very possible within the existing constraints. Due to how open-ended the possibilites for Extensions are, my only bid here is to make a case for the following: give Extensions as much space as possible to allow them to fully engage the user and succeed (or fail) upon their own merit. I think the alternative design satisifies those conditions more than the presented design.
All this being said, it’s clear to me that building the Extensions platform is no trivial task. As far as I can tell, configuring a successful platform for Extensions is like trying to solve a multivariate equation, and in this case, none of the variables have settled into even a remotely stable value. I would like Extensions to succeed, so I’m offering my criticism here to increase the chances of that happening.
Tons of gratitude and appreciation are due to you and your team for creating this opportunity in the first place, so thanks!
