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?