This is horrible. Itâs missing the point in a lot of ways⌠I donât want the majority of the participant to switch to âanother video appâ, only 1 of the participants⌠So itâs useless for me I guess.
@Mikron well, itâs simply not the intended use case.
Itâs more or less a Zoom alternative - offered by Zoom.
For us itâs fine, as we need everyone to use it via Browser.
Simply put: think about it, Zoom doesnât earn the money only with the subscription model, but with ⌠uhm⌠big data. If youâre using the FCWS, youâre stripping away a lot of business opportunities for Zoom. Thatâs why itâs a complete separate product where you pay by metered data. That makes sense because EVERYONE, even Zoom, AWS etc are paying for traffic, even if itâs far less than what ISVs pay
The major downside of it is converting users with low technical abilities to yet âanother platformâ⌠if itâs just separate it wonât make it easy on the productâŚ
They can still simply charge per participant if the meeting owner is the one using the SDK. in my opinion itâs a miss.
@meetever-chris I understand their point, but to use FCWS we should rebuild zoom from scratch. As the normal client isnât allowed, are we intended to rewrite all the zoom features?
I would like to just have a better configurable web client, having the possibility to position chat, Q&A, video, and shared screen wherever I want.
Currently, for me itâs very simple to let all panelists and the host connect with the zoom client, and all attendees inside the website. Reprogram all zoom features is not an option for me.
thatâs why I think that compatibility with the zoom app would have been very useful
@alfonso.moscato I fully understand and agree. I actually JUST had a video call showing an important client our event platform - and Iâm afraid they wonât contract us just because of the current limitation that weâre only able to show the active speaker in the web client.
I think Zoom is working on at least this feature for the legacy web SDK, but thereâs no timeline yet AFAIK.
I PERSONALLY tend to think that thereâs a reason for Zoom to keep all the users within the desktop clients. It might be a big data âfeatureâ (worst case) or better optimization capabilities in native clients (best case). But to me itâs obvious that Zoom wants to keep the Desktop Apps as the one & only flagship product and the SDKs are more or less just fallbacks
Happy to clear up the confusion here. The Fully Customizable SDKs are a new product that gives developers the ability to put audio and video streaming inside their own custom applications.
It is a video / audio service utilizing Zooms existing infrastructure. Think Video / Audio streaming as a Service. A good example would be a racing game where you can see and hear the friends you are playing with.
The Fully Customizable SDKs cannot join Zoom meetings or webinars, for that you will want to use the Client SDKs, which we are continuing to improve and allow further flexibility.
You can see more about the differences between the two here:
Thanks @tommy, but I think some more clarification is still required:
what are the pricing details?
as far as I understand the docs, itâs only possible to show a SINGLE stream, is this correct? If so, your example of a poker app wouldnât work if I have more than one friend
@tommy I guess the feedback I have is that the product my company really needs is a fully customizable Web SDK, something as customizable as the Android/iOS SDK. We have no interest in rebuilding the analytics / session signaling that Zoom has already built into their Meeting product. My company just wants a Web SDK that is at parity with the mobile ones (720p, customizable UI, hooks for events like admitting a participant from the waiting room).
Iâm guessing the hints about a fully customizable web SDK that were scattered in the forums many months ago were actually referring to this new product, so: is there any roadmap for adding more customization to the existing web SDK?