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.
Just to address the naming issue — we (myself and the other engineer, that comprise the entire Screen team) honestly have not used GNU Screen for more than 5 years, and didn’t even remember it existed until today’s post. I’m sorry for the oversight, but this is the point of a public beta — to help us unearth issues we may have overlooked ourselves!
I’m open to finding a new name — in fact, a few days ago, I had reached out to Slack to see if they’d be open to letting us use the Screenhero name since they’re not using it. If that doesn’t work out, and and there’s still significant distaste for the name, we’ll change it. 99.9% of the time we’ve spent to get here has been on the product, getting it to work on all the platforms it supports, and making sure it’s performant and fast. The 0.01% of time we’ve spent on getting our name and domain is something I’m happy to revisit before our GA release.
The name is great, as is the slack command /screen, just keep using it. Saying this as a user of GNU Screen. It's OK, approximately nobody is going to be confused by this in the real world.
I first expected a "screen -x" tutorial (which attaches multiple clients to the same session; screen sharing, if you will) when skimming HN titles, but yeah the "by the cofounder of X" tipped me off when I read a little closer. Going to be hard to google, though. For reasons unrelated to GNU screen, I dislike product names that appear in a dictionary with the most common words. Not saying that /screen would be a bad Slack alias or whatever, so long as that isn't taken why not, but as a product name there might be a nice thing to tack on that you can abbreviate to Screen but still allows you to google for the right thing or clarify when someone is confused.
When I have issues like this when searching my next search is usually "slack chat" or "zoom video." Now that they're popular, you don't need these qualifiers. What would someone add to "screen"? "screen sharing"?
I don't know if I'm a weirdo but I am so interested in learning about TurboScreenMaster 3000, but it needs to be inherently at least as good as BattleChess 3000 and Class of 3000
Don't bother, the people who you are going to sell this product to have never heard of the GNU utility and they do not care the least about it. You'll be just fine.
One thing I hated with GNU screen was how hard it was to google. I knew there was a certain fix for a special edge-case but the generic name made it hard to search for.
This project don't even have the GNU keyword to help.
I guess this is an aspect where search engines are much better today, to get the context. But still, the issue remains.
You are right, it is odd (at least I think of it is), people don't really care about the name, though to be fair some people really think it is important, .com is so important, ok it is true for you, but reality is nobody cares, just focus on the product capabilties.
Congratulations on the launch! The product page looks great as does the native Mac app.
Regarding the name / domain name i wanted to let you know that www.BrowserMeeting.com is available.
I was holding on to this domain for a future screen sharing & web browser based virtual meeting project.
If you or any HN readers are looking for a category killer keyword rich premium .com that is PERFECT for a "Browser Meeting" project please send an email to:
sales AT browsermeeting.com
It’s a common and disappointing trope on HN to complain about the name of something when someone shares something new here. Take note and move on and if it becomes an issue later, address it then.
There was a company we used that had to do a massive re-branding after they realized they couldn't trademark their company name. Doubt it helped their brand visibility to do such a switch.
Hey, so I can’t imagine you’ve never used or heard of GNU’s Screen: why did you choose to use a conflicting name for software that’s essentially in the same space?
PS edit: this isn’t glib. I’m genuinely curious why, who and how this choice was made.
I honestly don't get why people are getting so caught up on the name. The number of people who use screen is so small compared to the target market (which encompasses anyone doing work on a computer) that I highly doubt any significant number of people will be confused.
If you're intelligent enough to use screen, surely you're intelligent enough to understand the difference between a terminal app and an app that shares your screen.
Because it sticks out like a sore thumb, and has trademark problems irrespective of its reuse. And you know, everyone deals with naming things, so we can all relate and pull from our own experiences.
Again, the number of people who this impacts is so small that it's hardly significant. Sure, here on HN I'm sure it seems that everyone is confused, but we're hardly a representative sample here.
> has trademark problems
Honestly I don't buy this. When you trademark something, you do so in a very specific manner, and I think Screen's market is specific enough as to defend a trademark in the screen sharing/collaboration segment _should they even choose to trademark the name_, which they can easily choose not to do.
To be honest, I’ve never considered trademarking the name. We just want to build a product that works and is loved by its users. It’s really quite simple! :)
Until this post, I hadn’t thought of GNU Screen at all. It isn’t a tool that I’ve used in more than 5 years, and is not top of mind for me at all.
Also, no one in our private beta ever raised this concern.
Screen just switched to public beta today, and the idea is for us to get feedback on issues we may not have seen before. This is a great example of such an issue! And as I’ve said elsewhere, if this continues to be an issue, we will change it. It’s not in our interest to have customer confusion either.
Why would it "stop" being an issue? GNU screen is not going anywhere. Maybe you'll stop hearing complaints once all initial grievances are aired and it's obvious that you don't care, but it will continue to cause confusion in the workplace.
Just today I was recommending (GNU) screen to a coworker to address transient outages with a remote connection. It would get pretty annoying to constantly clarify which screen I mean, as they are both used in the same circumstances.
Probably 99% of their users will either have never heard of gnu screen, or don’t care. It’s such a common word that it’s silly to think one thing “owns” it any more than the next.
That's a little bizzare, but ok. Gnu screen has low latency, works well on Linux and bsds, works well with vim and emacs, works well for pair programming? I'm not sure how good the mouse support/sharing is - but I think selection and cursor is shared fine?
Don't get me wrong, I've got lots of colleagues who use various other editors, like vs code - but... This isn't just a case of pre-existing software with a similar name - combined with ssh, gnu screen is arguably superior for pair bugfixing in production, for example (multiple ppl can ssh into the same server).
I get that this is "like gnu screen, but for xorg/Wayland - and without any support for resuming remote sessions" - just sounds like an odd pitch - as you say you especially want to target Linux support...
Thanks for the reply. What kind of market analysis did you do before building this, err, again (and better)?
You support Linux (well!), I’m surprised your beta testers didn’t say anything. That’s an interesting problem —I wonder what other blind spots like this can be avoided.
Heh. I use gnu screen daily. Saw this and immediate downloaded it (I missed screenhero so much) and got coworkers to use it with me, and never considered the name collision. I'm surprised by the number of comments about it.
I would seriously consider renaming this. Many of us have been using GNU screen for very similar tasks of terminal sharing and pair programming.
The name you have chosen requires an explanation just to discuss this with my coworkers. Perhaps it is a generational thing, but in a quick survey asking around "Have you heard of the new tool screen?" the response was 100% "screen isn't new and yes I've heard of it... have you heard of tmux?"
One of the main audiences he's pitching this to is developers (for pair programming etc.) so it's more of an issue than it would be for a pure consumer tool.
This is the same reason why HNers at the time failed to see why Dropbox succeeded and curl + git + sftp on Linux isn't sufficient for end users to solve their problem [0]. They just don't care about your GNU tools, even if it does better at SEO.
That analogy doesn't hold. People aren't saying that you should just use GNU Screen instead, they're saying that the name creates confusion. Totally different.
Well that 'confusion' is between developers and there are many other business tools out there with similar names which from the perspective of an average customer, they will still use it and won't care about a name clash with a decades old developer tool used only by software engineers.
For the majority of businesses looking at 'Screen' now, they won't bat an eyelid and will use it along as it 'just works' no matter the name conflict. If they saw GNU Screen they'll just say 'What's that' and forget about it.
"People here are saying..." is the parent's argument. The situation is very similar: people here, on this forum, aren't a representative sample of the market, outside. That statement holds even when said market is comprised of developers.
We’re a 2 person team, and neither of us uses Screen (the last time I used it was more than 5 years ago, and until HN’s response, had completely forgotten about it).
Also, nobody in our private beta mentioned GNU Screen.
A public beta helps us get feedback on issues that we have missed before, and this is one of them!
I'll throw my voice in that "screen" 100% refers to GNU screen in my friend circle. Tmux and dtach still don't quite supplant the specific slot that screen has occupied for decades.
> I'll throw my voice in that "screen" 100% refers to GNU screen in my friend circle.
> 1M Developers: GNU Screen exists you know.
> 90M+ Customers and Businesses: Take my money now! Let's use 'Screen' to screen share!, Yay!
I'm pretty sure that 'Screen' would appeal to businesses and customers who really just want to get on and instantly collaborate with who ever rather than to know that something called GNU Screen exists and would be less likely to be confused by the conflict anyway.
Yeah, I can totally see how in some circles, "screen" is synonymous with GNU Screen, and that our choice of name would be confusing. Sorry about that! I’ve posted a top-level comment about the naming issue, in case more context is helpful.
I think it's generational, knowledge domain, and probably also sort of being jerks in that if their response is "screen isn't new and yes I've heard of it... have you heard of tmux?"
it sounds like typical programmer one-upmanship.
I mean either they think you are significantly less informed than them and you actually think GNU screen is new, or they are using the chance to make a quick joke of not particularly startling originality.
Because if they do think you know what GNU screen is then they must think this new tools you're referring to isn't it.
In our department everyone has had the debate of tmux vs screen with just about everyone else (most of us have moved to tmux). The question was interpreted more like "(hey tmux user) have you heard of the new tool screen?"
yes, but, that means your quick impromptu survey of what people thought of the new tool Screen wasn't that useful for determining if another name would be better.
Unless Screen hopes to build a business targeting clients that are unique.
I think there are the common places: most places you can work on software and systems engineering, and the special places: highly experienced and deeply capable teams in a fun and nurturing environment.
I don't think we are unique but I like to think we are the kind of place where most people would prefer to work. Uncommon but hardly unique and definitely in the target market for this tool.
Everyone seems to be talking about the name, and for the life of me I can't figure out why. I'm well aware of GNU screen, but it hadn't come to mind until I saw all the comments. Keep the name—or don't; maybe ask someone who know more about marketing than most engineers ;)
Now I've been doing it as well... What I really wanted to say is thank you for launching this product in a time where it's desperately needed by many people and making it free. You said elsewhere that you're bootstrapped and I really don't want to think of the server costs coming your way, so I seriously do commend you.
One thing I always do first with products like this is take a look at the privacy policy: I probably care more than the average person, but I feel like people, or at least companies and institutions, also care quite a lot in Germany. The policy mentions that video data is transferred through third parties and not stored, but as far as I can tell it doesn't say anything about whether the data is analyzed in real time nor about the privacy policies of the third parties applying (or not). I want to assume the best and I understand that legalese can be a kind of a pain, but it would be wonderful to get some clarification here.
It’s exactly as you described — no one in the chain is analyzing the content of the data being transferred. Both our infrastructure providers (Daily is our primary, Twilio is an opt-in secondary) care deeply about security, and both are used even in healthcare settings.
If you have suggestions of what we can say and do to make this better, please let me know. I will be looking into improving the language before we do our GA launch.
Wonderful to hear, thank you for the reply! Given this I'll be sure to pitch this at work, I think it looks like a wonderful solution.
While I do take a lot of interest in law, I am by no means a lawyer. Personally, I would feel good about: "Neither Screen nor these third parties store or record media data as part of the Service, nor process it other than necessary to provide the Service to you."
I'm sure corporate will have opinions on this when I propose it, and I'll be sure to pass those on. As an additional point of feedback, it would be wonderful if you listed payment options somewhere. Although maybe it's an artefact of your early launch or by design that you don't.
EDIT: changed "our Service" to "the Service" above for consistency
Thank you! I’ve just pushed the following change to the site (will be live in <10 mins):
>Neither Screen nor these third parties store or record media data as part of the Service, nor process it other than for the purpose of providing the Service to you.
Just tried this out, really cool concept and something we want at our 100% remote company. Sadly it didn't work out for us on the first test.
Here's our experience in case it's helpful:
Signup:
- There's no concept of user provisioning or inviting users, so when I first signed up and started a session in slack everyone was a little confused about if they needed to individually sign up or if they should be expecting an invite to their corp email.
- I'd also like some degree of user management at a corp level if for no other reaosn consolidated billing and basic auditing.
Screensharing:
- One of our cofounders is on linux and tried to do a screenshare. He has 3 monitors hooked up and even though screen asked him which monitor to share, it still shared all 3 at once.
- On my side from a macbook as a viewer the app wedged all 3 of his monitors into view on my tiny 13" monitor and this completely destroyed the aspect ratio of each of his monitors (ha, it's really hard to write this without using the word screen), also the resolution was super low, likely because one of his monitors was showing a twitch video and the screen app was trying to keep up.
- I tried zooming in on the one monitor where he had code open and it was super pixelated.
- I tried drawing and there was a very noticeable delay for both of us even though we're both on high speed connections.
- I tried to take screenshots of all this but every screenshot I took just resulted in a grey image (not sure if screen intentionally blocks screenshots but they're pretty important for us).
...sadly there was no way for us to do anything like remote debugging under these conditions. Will keep an eye out for updates since this is something we really want!
Looks like a bug in our Linux multi-monitor code. I'm going to look into this right now! It’s been a while since we touched that code, and it’s likely that bugs may have crept in since then.
Also, corp level user management is something we’ve got in the works, but we wanted to get the product out so that people could start using it, and then add admin tools on top of that. For instance, if you’re on G Suite, everyone should be able to OAuth in. But I hear you on the need for better tooling around users.
Were you able to try screen sharing from your Mac to his Linux computer?
This was my immediate thought as well. The obvious benefit, and the thing that I think holds Tuple back the most - is that Tuple only supports macOS. That, and they don't seem to have taken the pandemic as an opportunity to lower prices at all.
Because when the barrier to entry is getting your company to spend more money to try a product that you've never used before, it might help to sacrifice a little bit of revenue up front in order to keep them as a customer in the future.
I can’t speak to other products and their performance, but we’ve worked hard on performance and wide platform support (Mac, Windows, Linux apps to host screen shares, and web support for joining meetings). Do try Screen and let us know what you think!
I've just tried this, and by far the biggest issue I've found so far is a lack of ability to turn off remote control while sharing. This is important for lots of reasons - not least if you want to step away from a machine for a second without signing everything out without remote users having the ability to do whatever they like. Other than that, the experience is quite nice.
A simple fix for the specific issue you mentioned is to stop sharing your screen for however long you want, while still staying in the meeting. You can then turn it back on whenever you’d like.
Having said that, I’ve heard this request a few times now, and we will likely get to this soon. But I am curious whether the workaround would work for you for the time being.
This issue was my immediate though as well. I was expecting a dialog saying that a user was requesting control, asking if I would allow it. A simple toggle for allowing others to take control would perhaps work too.
Honestly, no, since that is not fail-safe. Ideally remote control could be set to be disabled by default. Until that feature is available I'll probably continue to use Zoom screen sharing.
Sounds like this isn't the app for you then... The whole purpose of this app is working with someone else on the same screen. Why should you have to turn on a feature that is the purpose of the app?
That might well be the case, in which case I'll keep using something else.
Suggesting the "whole purpose" of an app that does video, audio and screen sharing is to let someone else control your computer seems strange though - it's one of many features, not a purpose in and of itself.
The audience that you posted this at will never get over that unfortunate product name, as I bet they are heavy users of the real screen program, (or tmux)
Has there been no real research that your chosen name is already taken?
I’ve posted a top level comment addressing this issue since it’s probably best to have the discussion in one place.
But yes, we didn’t hear from anyone in our private beta that there was any confusion regarding our name, and we ourselves completely missed the fact that GNU Screen exists with this name. I’m sorry for the confusion, and we will revisit our naming decision.
I love this idea, this is a wonderful thing you're doing. Really clean design, great featureset. I genuinely think it has the potential to be a powerhouse.
I think it's perfect for businesses, and large companies, but might not be something suited towards somebody like me.
TeamViewer is the current tool of choice as I do volunteer work remote-teaching art to students and I'd just be a little worried about migrating everything over while it's free, only to suddenly not be able to afford it.
This is of course no fault on your end, and I just think while this is aimed at a certain demographic, others might be more suited to working elsewhere as 'Free' and 'Free for a period of time until we decide to start charging' is a little intimidating.
Brilliant program, brilliant work, and I wish you the absolute best of luck <3
Our plan is to charge $10/u/mo for unlimited use. If you’re using Screen for educational purposes, we’ll likely be able to work out a non-profit / educational discount down the line too.
Thank you for putting this out there. 10 a month per user puts me in the 'likely never' category.
I suppose people that use it a lot will benefit and those who have big budgets won't think about the price.
I loved screenhero and bemoaned it's disappearance into the slack neververse. Glad to see you are able to bring something back that was good before an aquihire gone blank.
If there's ever a version where I could pay a hundred bucks to use the code on my own servers for as much as the servers can handle, I would jump on it.
I like the way the privacy policy it put together. With my bit of research into webrtc, am I assuming that "In 1:1 meetings with two participants, media data is sent peer-to-peer" - would mean a direct connect shares each person's ip address with the other person's system - and this does not happen when going through the third party servers(?)
No big deal when screen sharing with friends, creates an issue for some people who don't know about these things and they get stalked by someone who suddenly knows what city and internet provider you are using, for some people.
Could you post this as a feature request on https://support.screen.so, along with some context to your use? That way we can follow up with more questions, others can vote for it, and we can update you on our progress. Thanks!
Congrats on reinventing your baby (again) and props for making it free during this pandemic.
Can you shed any light on what WebRTC server you use? ie. Jitsi, Janus, etc.
This is HN after all - be great to get a nutshell description of the tech stack and after all your experience at iTeleport, Screenhero, Slack, etc. the things you've learned from a technology and even bootstrapping/product market fit standpoint?
WebRTC server: Daily (primary), and Twilio (secondary)
There’s no shortcut to the performance side of things, so we had to do a lot of custom work on Mac, Windows and Linux to get screen sharing to be super fast. The high level bit there is the boring-but-correct advice: measure everything, start with the biggest bottleneck, optimize, repeat.
The desktop apps follow a Slack approach (with a slight twist). Like Slack, we use Electron, but in our case, we’ve heavily modified it to make screen sharing super fast. We then use the standard Electron model to have main & renderer processes. The renderer process fetches the UI from our website (hosted on Firebase).
Almost everything (other than our custom node module) is in a monorepo. Even our modifications to Electron are stored as patch files, which just makes it easy to keep things aligned between our app and our modifications to Electron.
Our website/webapp (they are one and the same) are built on Ionic/Angular (we started before Ionic supported React). We used Ionic because I didn’t want to have to create new different UIs for each platform — I think the user is served by having a low cost product where the effort is spent mainly on performance and quality, rather than a slightly different UI for each different platform (which has significant cost). We’ve tried to maximize code re-use wherever possible, which is how a 2 person engineering team was able to build this product (granted, it took almost an entire year, or more if you count the project we pivoted from).
This is really exciting. I loved screenhero and I thought the screenhero acquisition was going to play out differently at Slack. However, the features they adopted never worked as well in slack as they seemed to before the acquisition.
Were there any issues from slack corporate with you launching this? Seems like it competes pretty directly with the features they already bought from yall...
I only decided to re-enter this space after Slack announced it was sunsetting interactive screen sharing. It ended up being too expensive a feature for Slack to support for a niche audience.
I can’t speak for the company, but I imagine they’d be happy that another collaboration tool has launched that integrates with their platform to give their customers even more choice in how they work.
Hey, LOVE to see it! Screenhero was an amazing tool, and I absolutely loved using it for pair programming and desktop support.
I waited with bated breath for the features to show up in Slack, and when they did I was basically satisfied until they shut it down, where I was crushed again.
Here's hoping the lawyers don't beat you up!
Guess what color I'd paint a bike shed? Any color at all if it worked!
Very cool. Obviously your website is getting the HN hug-of-death right now, but still got signed up and poked at it a bit.
Suggestion: (rather than complaint about the name), it'd be nice to have a little faster/easier method of changing the audio/video devices. Like the device arrows in zoom. I happen to have multiple of both devices (on my desktop) and sometimes apps get confused on which to use - so a quick way to change it back is always preferred.
Suggestion #2: Everyone seems to be killing for their whiteboards back right now. So a mode to have more strictly a digital multiplayer whiteboard would be cool.
Bug (Windows 10 x64): When I left my first meeting, the app didn't release the camera (light stayed on) & microphone (windows said it was in use) until I exited the application (from the tray). Relaunched the app and created a new meeting and it didn't happen again, so I'm not sure why. Just fyi.
A/V set up: good point. We can definitely improve this, although we’d need to be mindful to not add too much clutter to the already-dense minipanel.
Digital multiplayer whiteboard: we sort of do. You can draw even outside of a screen share — just draw during a video call (or even voice (or even no media at all!)). But I’m curious if you meant something else? There are a number of websites that do digital whiteboards, and we didn’t want to reinvent the wheel.
Bug: this is an intermittent bug we’ve heard about from some users but have had a hard time reproducing. Thank you for letting me know — we’ll try to figure out a better way to log the error to help us reproduce and solve it.
Just tried it out and it works great! It seems to be fast enough so pair programming can work and gettinf started was straightforward. I would maybe like to see a feature where you could disable someone's access (kind ok f like silence, but for yhe multiplayer control). Can't wait to try it out for real this week.
1) GNU Screen exists and people use it everyday to do something similar.
2) Why do you mention that started Screenhero and that Slack acquired that company in the banner? That’s great for you, it just comes off a little haughty, because it’s pretty irrelevant to a new user reading about this product imo
This is day 1 of our public beta, and we’re looking for feedback on things we may not have considered. The name is one such thing — based on the response, we’ll think about changing it.
The point of the intro is to convey that I’ve built a similar product before, and have experience in the videoconferencing space, and that this product builds upon the ideas of the previous products I‘ve worked on. Sorry if it came across as haughty, I didn’t mean it that way.
Something I've done before to share a screen with coworkers is to work in tmux and start a web tty service like gotty (https://github.com/yudai/gotty). After you resolve the standard network issues (port visibility and whatnot) you just need to configure it with `tmux attach` as the starting command. tmux already supports shared sessions if multiple terminals attach to the same session, the session window size simply shrinks to the minimum of all clients. If you've established trust then you can use --permit-write with gotty to actually work in the same terminal. Hop into a voice chat and you've got pair programming.
If text editing is all you need, and both sides are comfortable with the tools, then what you’ve suggested is definitely faster than Screen (tmux sends text, we send pixels).
But if the guest needs to see something else on the host’s computer (if you’re working together on a webpage, or a desktop app), then whole-desktop screen sharing is the best approach.
Screen definitely isn’t the best tool for every job. But it’s great for when you want everyone on the same page, seeing the same thing, and able to talk about the content of your screen and even control it together.
I guess I should have qualified my post, I did look at Screen (OP) and it definitely does more than just sharing a terminal. It also just reminded me of something I've done before (Screen -> screen -> tmux -> gotty, the mind is so good at connections) which I thought was apropos and worth sharing.
Can you please update the default keyboard shortcut to change between pointer and pencil.
Ctrl + Opt + Command, commonly known as "mash" are three keys commonly set by devs. In my case used for moving my displays around using SizeUp. Mash + left arrow (move window to left) etc.
Command + Options + some letter would be fine.
It's making the app unusable for pairing right when I want to be able to use it without issue, as you're not affecting just one keyboard shortcut BUT ALL shortcuts that use Mash as a base.
Better yet, option to set keyboard shortcuts, but Im sure that's low on your priorities right now. Or maybe just add.. turn on/off keyboard shortcuts, this would also solve it.
I'm surprised by how much attention the name is getting. I don't think I personally know anyone who would use GNU Screen over tmux. And disambiguation doesn't seem hard in this case anyway.
One thing that does mildly concern me is the prospect of Screen just turning out to be another Screenhero in terms of being acquired and then neglected or discontinued. But hopefully that won't happen based on the lessons learned in the founder's post[1].
FWIW, I believe life’s too short to be doing the same thing over again. I’m building Screen because I want to see where we can take it independently, as I think we had some great ideas that weren’t able to see the light of day. Screen is already a far more useful product IMO than Screenhero was.
Having experienced an acquisition, there’s not much value in going through the same experience again.
What’s personally interesting to me is: can we make something that helps all knowledge workers work together remotely in a way that they couldn’t before? We were onto something with Screenhero, and I’m excited at the chance of following that thread again, and seeing where it takes us!
Having said that, I know trust takes time to build, and I hope to prove this to you with actions rather than words.
This is cool. I've been searching for a better screensharing tool but it always seems to be an afterthought in the conferencing tools we've tried so far. I usually couldn't care less about seeing the other person/people on the call but i usually care a lot about being able to see their screen.
Gave it a quick spin immediately and looking forward to using it more in future. Pricing looks about right for us too.
My feature request would be to make it easier to have it always on. For us friction to initiate is one of our biggest annoyances, if the whole team can have it on then knock (like sneek) to get the attention of the other(s) that would be great.
Check out our roadmap, with the two items for virtual office. One has a small screenshot, and the other has a Figma prototype that walks you through the idea. Please post any feedback there so we can have it in one place, and so you can be updated as we make progress.
It’s built on a private fork of Electron, but the UI is all web-based. Electron handles most of our native needs, and where it doesn’t, we have a node module to connect into the OS. A lot of our secret sauce is on the native side, but honestly, there’s a lot of complexity across the product.
Does your solution allow for Administrator Escalation assistance on Windows?
Over the past few days we've been transitioning our higher ed staff to working remotely and are able to use Microsoft Teams or Zoom already to see another staff member's screen and walk them through basic things, but if the user needs to install a program, which would normally require admin rights on the machine, it appears that neither of those two solutions allow for that type of assistance from our IT staff.
Does Screen provide a solution for that situation? If so, we can give it a shot with our IT staff ;-).
You may be able to install and run Screen on Windows, although to be 100% honest, we haven’t spent a lot of time outside the assumption that the user has the access they need. If you can drop us an email at team@screen.so, one of us will make sure to follow up with you once we try it out.
> *Free, so you can stay healthy & productive during the coronavirus outbreak
As a former and early Screenhero adopter, I'm not sure why they had sold to Slack and have now come back with the same, if not a worse reincarnation of Screenhero.
At least they have Linux support this time since Screenhero and Slack repeatedly refused to port Screenhero to Linux. But again, having no web support would reduce the friction for new users having to install something rather than downloading a specific electron app.
Could you elaborate on why you think this is a worse reincarnation of Screenhero? Are there specific features we’re missing?
Also, there is no way to make a web app that does what Screen does. If there were, we’d have built a purely web-based app.
With Screen’s desktop app, you can share your screen TO someone on the web, but they need the app to share their screen, since multiplayer drawing and control can’t be done otherwise.
As a freelancer on Upwork I share my screen to my customers and they share their screen to me in parallel solely using Upwork web based application. Allows us to view each other screens, talk and share camera - all of this just by web. So there is a way to do that, you might want to look at them to see this is possible from web
I have the same problem and my colleages share these worries as well. Any tips for open-source alternatives? We tried a couple of WebRTC things with screen sharing but the image quality is bad (which is expected when using a lossy codec meant for photos/movies to compress screen with tiny details like fonts etc.). Now we're using VNC tunneled through SSH but the setup is a little difficult.
I'd love to try something better but running a closed-source app with complete access to my screen, mouse and keyboard connected to the Internet is really not an option. And it's really difficult for me to understand how so many people have no problem trusting it. What am I missing?
I don't think you're missing anything, except maybe just that closed-source is the default on macOS and Windows so the marginal loss of safety from one more closed-source privileged app isn't so high there.
For the moment maybe the best we can do is trying to use apps with screen sharing support included, e.g. Visual Studio Code's sharing.
Congrats on launching! I am a big fan of ScreenHero and sorely miss it in Slack.
Question: I am looking to build a remote development environment and would love to license this to see if possible to develop on a cloud machine to avoid issues with rdp/nomachine etc. Any interest in that idea? Congrats again and looking forward to trying it out!
What do you mean by "Works with every IDE, text editor and app. Perfect for remote pair programming, live debugging, and even code review."? I screen share and pair program/design/etc. pretty much all day on Zoom without video, so I'm tempted to try this and figure out what I might be missing.
Short answer: we have no intention of ever getting acquired. We are 100% bootstrapped, and we plan to become and stay sustainable, so we can be in it for the long haul.
Also, regarding acquisitions, I’ve been there, done that, and I wouldn’t be building this company just to do the same thing again (life’s too short for that).
I love Slack as a company and as a product (I spend many hours in it daily). However, in hindsight, it’s not possible to integrate one complex piece of software into another complex piece of software. We ended up with a union of two separate sets of constraints (from each product) which made it impossible to make it all work. We didn’t know this when we started. I really value my experience at Slack, and it was through that experience that I learnt this lesson, along with many others, that have helped us make Screen what it is today.
For Screenhero users, I feel that with Screen being publicly available today, the Screenhero -> Slack -> Screen transition has been one step forward, two steps back, and three steps forward again. I’m committed to continuing the forward steps from here on in.
Ok, I will bet this is true! Sorry you weren't given more latitude in Slack. Anyway you have my support. Starting tomorrow we will be giving a full try to screen.so.
Why not making a Slack-like chat system as well? It seems a natural expansion. (I am the CEO of SerpApi. Feel free to email me at julien at serpapi.com)
We don’t want to reinvent the wheel. Slack is great for what it does! And if you read through https://screen.so/about, I have lived the experience that it’s impossible to do two things well. So in an ideal world, Slack continues to innovate on the messaging side, we continue to innovate on our side, and we mindfully integrate with each others’ platforms to give our users the best possible experience.
I was a Screenhero customer for about 3 years. I used it daily for pair programming and it was far and away the best screen sharing tool I have experienced. Being able to have both people use the mouse and type on the same screen was a game changer. I’m extremely excited to try out this new product.
Congrats on the launch! The user experience for this is amazing. Picture-in-picture remote co-working is going to change the world.
We built a crappy version of this for our team about a year ago. This is the first tool that solves all of our remote / distributed team pain-points in a really elegant way.
We’ll look into this! Please post a bug report on https://support.screen.so so we can follow up with you with questions and update you on our progress to fix it.
Tried it out - really good! It's fast enough that it may actually work for pair programming and was super easy to use. Thanks and can't wait to test this with my team mates this week.
I'm really glad to see you back in action! I was so sad when ScreenHero shuttered. May I ask what makes this time different from ScreenHero in terms of running a sustainable business?
Summary: we were sustainable ($1MM ARR), but chose to join Slack since we felt we could get to our goal (have everyone use our product) faster. We didn’t foresee our product getting dropped.
This time around, the company is 100% bootstrapped, and I have no intention of taking any investment. We just want to be able to keep our burn rate low, build a product people love, and stay independent forever. I believe we can do that as long as we continue to make something people want.
At work we use USE Together but it's not too tolerant of intermittent internet connection issues (ie: WiFi in any congested area). I wonder if Screen is any better on that front.
Screen has worked really well for us and a handful of companies that use us daily in our private beta. If you do have any issues, let us know and we’ll fix them asap!
I’ve been wishing for a ScreenHero replacement for years. It seems odd to me that no one came out with a replacement earlier, but I’m super excited to try this out now!
We’d ideally like to create one or two distributions that are most widely useful, instead of having to support every single option out there — we picked Snap for this reason. Slack also supports Snap + Debian as their only two options, from what I understand.
Could you please post this as a feature request on https://support.screen.so so we can follow up with you and update you on our progress?
As long as you can make a network connection between the two hosts (either directly or mediated via a server in the middle), you should be fine. We haven’t tested specifically between China and the US, though.
We worked REALLY hard to make sure we had Linux support this time around! It’s in beta, and there will likely be issues. Please report them to us, and I promise we will try to solve them asap!
Yes! We’ve been laser focused on getting the product right, so the discount model hasn’t been fully fleshed out, but you can expect something similar to what other SaaS companies do in this space, but leaning to the more-generous side of that spectrum. I don’t know exactly what other companies do just yet, but that’s the philosophy we’ll use when we get to this. For now, it’s free for everyone, of course.
I'm going to get downvoted for this but the corporate folks that will eventually pull out their credit cards and pay you for this service have never heard of the screen command much less used a command line interface. I think you should stick with the name.
Speaking from my own experience as a founder, it's hard to change your name once you have an ounce of traction. If you're just launching and anticipate a problem I would recommend considering taking advantage of the opportunity now.
It will also be very hard for you to trademark your name.
IANAL, but in most legislations you do not have to register a trademark for it to be valid. It is important that you defend you trademark, and you will lose your right to a trademark if you fail to do so.
I do agree with those saying that in the wider audience, GNU screen does not mean anything, including (probably) the large armies of Windows developers. Besides that you should use tmux anyway ;).
the issue is that you can't easily trademark a common word. It's possible (e.g. Apple for computers) but you run into problems. Apple ran into some notorious trademark problems.
Trademarks don't need to be officially filed to be real in common law -- you just have to use a distinguishing mark for a certain period of time. so the GNU/FSF screen would have rights to Screen in the computer program industry even if they haven't officially filed. Filing just helps you defend a trademark, it's not strictly necessary.
The HN crowd is not a representative sample of the market. People here on HN will hate for a day or two, then they will turn their anger and cynicism to another cause, therefore that name will stop being a source of confusion :) Seriously, a few days from now noone will complain anymore.
The HN crowd is a fairly representative sample of a significant portion of the product's potential users. Otherwise, this would not have been a Show HN.
No it's not.. I am a developer but my god it seems that 90% of the people here are of the extreme privacy + low level programmers who think that any programmer outside of a phd in computer science isn't doing it right because they doing dissertation type work everytime they code.
This is basically slashdot with a different color scheme..
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!