3 ms·
Being following for a while, looks very interesting. Key thing is what the pricing structure is will be. We've had the Enterprise Teamviewer for some time, I li
by davidjgraph 13y ago
Being following for a while, looks very interesting. Key thing is what the pricing structure is will be. We've had the Enterprise Teamviewer for some time, I like it, but I'm very open to finding an alternative, for various reasons.
I need to test this out, also. I'm wondering how it compares against having real-time collaboration natively in web applications. From the video it looks like other cursors are disabled while text editing is in progress, i.e. one at a time editing. Although, it's not the same as everyone being able to edit concurrently, having people edit at the same time as you is pretty off-putting, this looks like it might actually be a better solution in that regard.
The advantage is, of course, is if it works OK it's a generic solution to giving all web applications real-time collaboration.
At a technical level I wonder whether it'll be able to properly detect when to disable the other cursors correctly for applications more complex than text editing, maybe an API is needed to signal the correct behaviour where the sharing couldn't realistically work it out for itself.
- dgoodman 13y agoThe nice thing about having a native client is that we (Screenhero) have full control over latency (well, outside of network issues of course!) and responsiveness, as well as those deep hooks into the hardware to make the multi-mouse magic happen. Our goal is to make /any/ app collaborative, without requiring developers hook into our API. I am curious what kind of apps you have in mind that might need to give hints to Screenhero? Give it a try, we think you'll find our active-cursor algorithm quite good—and if you don't, we want to hear your feedback!