I work at a FAANG and have spent the last 5+ years building video conferencing tools. I hacked together a Chrome extension to fix my video colour. I planned to add more features: local recordings, on-device AI transcripts and summaries, and clean screenshots of screen shares. Then my company shut down our in-house tool and moved to Zoom. Around the same time, I joined a new team and had to onboard, which is when I realised I truly needed these features. In technical meetings, I often want to capture a screenshot of a shared screen or record a brief explanation that transcripts miss, with permission, of course.
With Zoom, I'm unable to do any of it because of Admin controls. Many AI notetakers exist, but few run locally, and wiring a Chrome plugin into Zoom is messy. These things are easy & possible, so it frustrates me every time I join a call.
What do you find painful about video conferencing? And if you could design a Zoom/Teams/Google Meet alternative from scratch, what would it do for you?
fuzzfactor•4mo ago
I'm way out of date but I do know what I no longer have.
It would be pretty much the same thing as the video-calling app from the original Intel webcam in 1997.
Where each user installed the app locally and then it simply handled the 1:1 communication over the internet without relying on any remote servers at all. Especially not relying on browsers, even though almost everybody had the same kind of browser back then, it's even worse of an idea now that browsers are such a rapidly moving target.
Except to accomplish conferencing, you need many-to-many not just 1:1 and you're the expert on that. I do know there are a few UIs that have seen OK acceptance so I wouldn't worry about that stuff until there is a high-performance engine under the hood, relying only on processors, hardware, and OS features that have well stood the test of time without being subject to deprecation any time soon.
From the ground up it should be possible to make it backward-compatible with hardware and OS versions much further back than people think, without needing anything fancy, and ideally could also lend itself to better multi-platform ability.
One thing more I remember that was good, since Intel's app was for routine calling not just occasional conferencing, each user built up a "phone book" of everyone they communicated with (or manually entered), and later could just scroll through it when they wanted to call somebody again. One click and it would call the chosen party, if they answered you could start talking over the mic & headset right away while you waited for the video to buffer. Seamless really whether you were calling over the internet or even direct from dial-up to dial-up without the internet at all. You can only imagine how jerky and blurry the cam was over a slow connection, but that's all it was. You could double you processor speed from 100Mhz to 200Mhz and it wouldn't help, but at least the mouse and app response were still snappier than the average W10 PC these days after upgrading to W11. Since that had nothing to do with broadband speed, only programming skill.
Maybe for conferencing have the group select a moderator who sets their app to spawn a working dashboard, who single-handedly clicks on the participants from their list for the event in about the same way. Or punts it over to another participant if they have to leave the session early or take a break.
ud0•4mo ago
fuzzfactor•4mo ago
I don't think overcomplication is the problem. Once the core code is good enough, that could all be smoothed out by UI refinement. I would pick one single computer language to make the entire thing fully functional at least under CLI, then in case any other language was better for UI that could be layered on afterward.
What's really missed badly is something that can stand the test of time on its own, with only the most minimal dependencies, and from the ground up is peer-to-peer without any need for an "account" or reliance on email to do everything that is needed.
Everybody in the meeting should be able to download the same app, populate their "phone" directory manually or from a standard text config file (intial config layout MUST be well standardized to begin with, to withstand any possible update anticipated, and then some). This is where you really get to write the rules from the ground up so take advantage of it. Especially your "standardization" role.
The only reason this is still needed is that nobody else has stepped up to the plate to serve in that role, and it's been since 1997.
There's webcam standards, video standards, audio standards, all which didn't exist back then or were different than today.
Ideally anybody on the internet with a cam, mic and speakers should be able to simply run the app locally without "installation" even, choose the local cam and audio devices they want to use as provided by the OS, then take the position as either moderator or participant. With a phone book built from simple text that could easily be communicated orally over cellphones for small meetings, everyone could actually maintain the same directory at all times, but it would be the moderator or initiator who clicked on each of the intended participants to build the group communication. Then each of the participants would only have to respond-click to that one moderator's "phone" number. Not much different than Intel started out doing, with either person initiating the videocall, and the other party answering. Then "everybody" pops up on everybody's screen at the same time, but there was only a single other party back then.
Or it might make sense for the underlying code to allow for or require participants to click (or autoconfig) their "choice" of other participants they want to allow the peer-to-peer communication with during a particular meeting, and no others.
Until you get going and depend on decorum from there . . .
Edit: I guess worthwhile design criteria I would use is that there should be no need for internet communication between parties to begin with, until the meeting is actually joined, serverless between peers only. Although getting a little private network going from something like Wireguard beforehand might be a good option, after which your app would behave the same way whether it was Wireguard, something else, or nothing at all.