lostintangent

Thanks for mentioning this use case! We're (the Live Share team) very interested in exploring this moving forward, and so any feedback (using the tracking issue you mentioned), would be greatly appreciated.

We’re still pretty early, and so we have lots of room to improve our network usage, and tolerance to instability. However, it’s absolutely our goal for Live Share to perform well (as well as can be expected?) on lower-bandwidth and volatile network connections (e.g. coffee shop WiFi).

Currently, it’s already very usable in these conditions, especially when compared to screen sharing :)

We’d love to hear your feedback! Ping me and I’ll get you a Live Share preview invite.

Send me an e-mail (address is in my profile) and I’ll get you an invite. We’d love to get your feedback!

PM on the Live Share team here.

In many cases, yes, all collaborating participants would likely be working together in the same file. However, when speaking with folks as part of developing Live Share, we found that there were equally as many cases where developers wanted the ability to take certain actions independently (e.g. look up the definition of a function that’s in another file), without needing to disrupt the other parties, and without losing the ability to re-synchronize their focus once they were done.

With that in mind, our goal for Live Share is to support “opportunistic collaboration” between developers, that supports a broad spectrum of needs/workflows/personal preferences/etc. in a way that potentially feels more natural for folks as they are helping/teaching each other (e.g. sometimes I want to tell you what I’m thinking, and sometimes I want to show you).

Regarding your comment about being able to view the running app while debugging, we actually support the ability to “share local servers”, which allows this exact scenario for web apps/APIs/etc.

https://github.com/MicrosoftDocs/live-share/blob/master/docs...

It’s still early days for us, but it’s our goal that all meaningful editor/application context can be shared between participants, in order to effectively collaborate together (e.g. build output, terminal sessions).

That’s correct. A developer in Visual Studio on Windows can share with a developer using VS Code on macOS/Windows, and vice versa. Enabling the ability to collaborate from the comfort of your favorite (and heavily customized) editor/IDE is one of the core goals behind Live Share.

Very true. We’ll make sure not to unnecessarily imply that it’s only applicable in a business setting. Thanks for the feedback!

This is really great feedback! I’m a PM on the Live Share team, and it’s definitely our goal for the getting started/collaboration experience to be simple enough that it could naturally become part of your workflow (as needed).

If you’re interested in checking out the preview and letting us know how well we’re meeting that goal, I’d love to get your thoughts :)

I love that explaination! I’m a PM on the Live Share team, and like was mentioned, the use case we’re currently focused on is seeking and receiving ad-hoc assistance or feedback from a friend/colleague, in a way that can potentially be more opportunistic, productive and natural, regardless if you’re in the same building, working from home or across the world.

That said, we’ve heard a lot of interest in other use cases as well (e.g. pair programming), and are keen to understand how Live Share might be able to complement them.

Nice work! This looks really awesome, and is another great example of the passion around better collaboration tools for developers. Thanks for sharing this.

With Live Share, we're also looking to extend the collaboration experience beyond real-time editing, and into collaborative debugging, and more, as we continue to learn from the ecosystem what is needed to continue improving team cohesion, regardless of the app scenario/issue at hand.

Thanks for this feedback! We believe that Live Share's ability for developer's to work together in real-time, while choosing to "follow" each other, or temporarily/periodically investigate something independently (e.g. "Let me check out whether this helper function could work here"), will enable it to apply naturally to many collaboration scenarios (e.g. pairing, seeking help/advice, swarming, consulting, mentoring, etc.), without needing to impose any specific opinion on team workflow and/or the practices they've found to be efficient/successful for them.

Code reviews are definitely a scenario we believe can benefit from Live Share, regardless which version control workflow your team is using (e.g. PRs, trunk-based development). In addition to being able to quickly seek help, we want Live Share to enable easily seeking and _providing_ feedback/advice, in a way that makes code reviews something that happen frequently and more naturally bi-directional (e.g. "Hey I have a suggestion about your PR, can I show your something in a quick share session?").

Remote development is definitely an adjacent use case that we believe could be really compelling. Thanks so much for providing the +1 on the scenario, and stay tuned (i.e. sign up :)) for future updates!

Awesome! Thanks for this feedback. Swarming is definitely a scenario we'd love to see Live Share help improve. And no, collaborators wouldn't need to be running admin level in order to participate in a sharing session. We want to make sure collaboration is as accessible/frictionless as possible for everyone :)

Absolutely! Live Share allows developers to quickly/easily collaborate with each other, while continuing to use their pre-configured editor, which includes themes, key maps, extensions, etc. This way, everyone can feel completely at home while working together.

It's really exciting to see the energy being directed at improving developer collaboration!

Great question! The project would be built on the machine of the developer who initiated the Live Share session. That developer is effectively the "owner" of the session, and all developers who join the session are connecting their editor/IDE to theirs, and remoting certain editing/building/debugging operations. This allows the participants to fully collaborate, investigate/explore the project independently, but without incurring additional environment/setup requirements simply to get started.

We want the act of providing feedback/advice/etc. to each other to be as lightweight/frictionless as possible. Ideally, it would be so easy to collaborate, that it becomes harder for teams _not_ to do it :)

That's great to hear! We definitely believe that collaborative debugging is a critical component of being able to demonstrate/reproduce issues, as well as validate changes made during a collaborative/pairing session. We look forward to seeing how folks end up using it :)

We're definitely very serious about Visual Studio Code :)

PM on the Visual Studio Live Share team here. Thanks for posting! We're really excited to hear folks thoughts about this experience, how it can help improve their existing team collaboration workflows, and how we can continue to improve/learn. So please sign up and/or let us know what you think :)

We've heard pretty loud and clear that developers want better collaboration tools, without needing to switch editors, without needing to continuously negotiate control (i.e. look at the exact same thing), and without sacrificing the context/fidelity they would normally get while developing locally (e.g. full auto-completion/navigation, debugging). We think Visual Studio Live Share helps teams get there, and as it evolves, can hopefully become a powerful tool for teams to collaborate, not only more efficiently, but more naturally.

Additionally, we’ve found that successful collaboration needs to include more than just the project’s source files, and real-time edits, which is why we’re excited to also support collaborative debugging (even between Visual Studio and Visual Studio Code!). We’re only just getting started, and look forward to great developer feedback from the community.

We (the CodePush team) would love to discuss what that kind of integration might look like :)

Yep we do! We don't support updating assets on Android yet but we will as soon as the necessary platform support is released (should hopefully be in RN 0.19.0)

I may be misinterpreting you, but I'm taking this as a huge compliment :)

As a team of web devs who love mobile, we definitely wanted to help bring as much of this kind of update experience to client apps as possible. I look forward to hearing any feedback you may have after giving us a try :)

We definitely don't want to encourage "abusing" the service by producing poorly tested updates. We're planning to do some work/docs to help incorporating a CodePush deployment into a CI workflow that can choose to rely on tests to ensure quality, and also use multiple environments to be able to manually test an update in staging before pushing it out to users.

Yep that's true. I'll add this point to our docs so it doesn't seem like we're trying to manipulate the value of the service. Thanks for the feedback!

We have that button on our backlog! ;)

This compelling opportunity is what made us decide to build CodePush!

Thanks for bringing this up! We definitely need to do a better job raising this point in our docs. That said, I hope this limitation doesn't make it "too good to be true". From the many Cordova/React Native devs we've spoken with, being able to update JavaScript, CSS, images and other content assets, enables handling lots of fixes/updates, before hitting the need to update through a store. We look forward to hearing more feedback on this topic though!

We've only just initially added clients for Cordova and React Native, but we plan (and would love to work the community) to build clients for other platforms, so dynamic updates of code and/or content could be easier.