I was the co-founder and CEO of Screenhero, and after its acquisition
by Slack in 2015, I led the team that built Slack Calls (voice, video
and screen sharing in Slack), and left Slack in 2018.
Today, we (myself and another engineer) are launching Screen, which is in
many ways a successor to Screenhero. Our goal is to help you work with
others like you’re in the same room.
Like Screenhero, it supports low-latency screen sharing with
multi-mouse control. How low? It has the lowest screen sharing latency
of any product we’ve tested: 30-50ms best-case end-to-end latency
between screen capture and render, vs. 100ms-150ms in regular WebRTC.
This means it’s great for remote pair programming, which was
Screenhero’s biggest use case.
We have voice, video, multiplayer drawing and control, and ephemeral
messaging, and we integrate with GCal and Slack.
We have native apps for Mac, Windows, and Linux (Screenhero’s
top-requested feature was Linux support). We use custom native code to
make multiplayer control work, and a heavily-modified custom fork of
Electron to minimize latency. It's WebRTC-compliant, so you can share
meeting links that anyone can join with a WebRTC-compliant desktop or
mobile browser — no download required. Daily.co is our primary
WebRTC-infrastructure provider (they’ve been amazing to work with!).
We're hoping Screen will be useful for engineers (pair programming,
live debugging), designers (review with stakeholders - they can draw
on your screen to give feedback), students and teachers, and anyone
collaborating remotely.
You can view a 1-minute demo video by clicking the
play button at https://screen.so, and there's a longer article
at https://screen.so/about, if anyone's interested.
I’ll be around to answer questions and welcome any feedback.
I hope you'll find Screen useful, especially during these times!
> - Speed matters. The main reason why Screenhero was loved was because it was fast. We did a lot of work to reduce latency and increase responsiveness — which is critical when working remotely. We weren’t able to bring the speed improvements over to Slack (because of the constraints described in the previous point), which made it far less useful.
This resonates with me, and is definitely why I loved Screenhero so much, it felt VERY fast, and visually looked crisp. Even the initial connection speed was fast, while Slack takes about 3–8 seconds to connect. And also why I was so disappointed with Slack's product, now it's back to the same level as Google Hangouts.
It's surprising that having the same lead, and access to the same source code, that the product was unable to achieve the same level of quality & performance. What would you say the culprit is? And if I may lead the question... Bureaucracy inside Slack? Managing a new team? Having to rewrite on presumably a new language & software stack? Rushing to meet deadlines?
Anyways, awesome to see your back at it again, and that you have such care about latency, people do notice & care!
This is a really good question, and the simple answer is that Slack uses an unmodified version of Electron, and it’s not a good idea to make custom modifications to that project for such a small, niche feature. The cost/benefit just doesn’t make sense for Slack, neither to me, nor to Slack management. But Electron didn’t even exist when Screenhero was acquired, and so the constraints we eventually faced were not possible to predict when we got acquired.
In 2015, when we joined, Slack’s Mac app was using "MacGap" (i.e. the PhoneGap/Cordova model but for Mac). Electron was being used for Windows only, and it was a lot later that it became the platform for Slack’s Mac, Windows and Linux apps.
Do you perceive this to be a direct competitor to Tuple? I recall Ben Orenstein saying on his podcast that he reached out to you about creating a "successor" to Screenhero and you were all for it. (FWIW I think more competition in the space is good.)
I believe Ben spoke with my co-founder Faraz, not with me.
Screen’s goal is to support remote work of any kind — including engineering & pair programming, for sure, but extending to many other uses cases, such as creative review, education, and beyond. And yes, I agree competition is good! :)
I was a paying customer of Screenhero, and disappointed that Slack left out so many features, so excited to see this.
Curious: I assume you can't just sell your company and rebuild it in most cases. Was there an embargo on the amount of time before you could build this?
We had a non-compete for 2 years (which expired in late 2016), and I left Slack in 2018. The reason I decided to re-enter the space was after Slack sunset interactive screen sharing, since my earlier hope was to see it thrive within Slack. Once that wasn’t possible, I decided to build it myself!
Congrats on the exit (money helps live life on easy mode), but after being left to hang out to dry with the acquisition and losing access to Screenhero (which was absolutely essential at the time at a fully remote org), I would never consider a non OSS solution again for this use case.
I would absolutely pay for any open source competitor to this type of product, preferably one that integrated with Jitsi (which itself is open source). Fool me once.
Today, we're launching Screen, which is in many ways a successor to Screenhero. Our goal is to help you work with others like you’re in the same room.
Question for clarity sake, have I read this properly that you all still are with Slack, does this mean Screen.so is "A Slack Company" or just leveraging that relationship for tightly coupled/efficient integration as a wholly separate company?
I left Slack in 2018, and Screen has no formal relationship with Slack outside of the fact that it uses the Slack API. Screen is a heavy user of Slack, though!
The specifics of the speed gains are our secret sauce, I’m afraid! But at a high level, we reduced the time taken in every step of the pipeline between capture > encode > send > receive > decode > render that we could, while still remaining WebRTC compliant.
I was the co-founder and CEO of Screenhero, and after its acquisition by Slack in 2015, I led the team that built Slack Calls (voice, video and screen sharing in Slack), and left Slack in 2018.
Today, we (myself and another engineer) are launching Screen, which is in many ways a successor to Screenhero. Our goal is to help you work with others like you’re in the same room.
Like Screenhero, it supports low-latency screen sharing with multi-mouse control. How low? It has the lowest screen sharing latency of any product we’ve tested: 30-50ms best-case end-to-end latency between screen capture and render, vs. 100ms-150ms in regular WebRTC. This means it’s great for remote pair programming, which was Screenhero’s biggest use case.
We have voice, video, multiplayer drawing and control, and ephemeral messaging, and we integrate with GCal and Slack.
We have native apps for Mac, Windows, and Linux (Screenhero’s top-requested feature was Linux support). We use custom native code to make multiplayer control work, and a heavily-modified custom fork of Electron to minimize latency. It's WebRTC-compliant, so you can share meeting links that anyone can join with a WebRTC-compliant desktop or mobile browser — no download required. Daily.co is our primary WebRTC-infrastructure provider (they’ve been amazing to work with!).
We're hoping Screen will be useful for engineers (pair programming, live debugging), designers (review with stakeholders - they can draw on your screen to give feedback), students and teachers, and anyone collaborating remotely.
You can view a 1-minute demo video by clicking the play button at https://screen.so, and there's a longer article at https://screen.so/about, if anyone's interested.
I’ll be around to answer questions and welcome any feedback. I hope you'll find Screen useful, especially during these times!