DEV Community

Cover image for Collaboration doesn't come in "One Size Fits All"
Jonathan Carter
Jonathan Carter

Posted on • Updated on

Collaboration doesn't come in "One Size Fits All"

As with many questions in software, the answer to “What’s the best way to collaborate?” depends. Things like situational context, individual preference and team dynamics can differ greatly (and that’s OK!), so it's pretty hard to imagine there being a single "right way" to do it. Collaboration should feel efficient and enjoyable, so if your personal experiences aren't reflecting either of those qualities, then it might be worth re-considering the tools and/or processes you're using.

When we set out to build Visual Studio Live Share, one of the most fundamental things we observed, was an interest in collaboration tools that don't impose specific interaction models, but rather, allow you to choose the most appropriate, and more importantly, natural modality for each task. While screen sharing is great for many circumstances, it isn't ideal for all types of collaborative development, for one reason in particular: participants are inherently mentally coupled, and everyone except the host is acting as a passive observer, who can't perform even simple actions without having to ask for permission or interrupt the group (e.g. hovering over an API to view it's description).

That experience can feel quite restrictive at times (e.g. prototyping, hack-a-thons), and doesn't necessarily foster the level of engagement you might want within educational settings (e.g. classroom lectures, mentoring sessions). So we pondered: what if we could de-couple collaboration, and give each developer their keyboard back, without sacrificing the benefits that screen sharing provides (it's not all bad!)? If we could enable an experience that allowed both synchronized and independent work, for both remote and co-located teams, then maybe, just maybe, we could accomodate the vast landscape of collaborative use cases, without requiring anyone to settle. Let me illustrate what this looks like.

Liquid error: internal

Follow the leader

When you join someone’s Live Share session, you initially start out by “following” them, which has three side-effects:

  1. The file they’re actively editing will be automatically opened in your IDE

  2. As they scroll within that file, your viewport is automatically scrolled too

  3. As they navigate to other files, the target file is automatically opened on your end as well

This behavior allows you to achieve a shared focus with the “host”, and maintain that focus as they move around the codebase. We automatically put you in “follow mode” upon joining a session, based on the fact that most collaboration sessions start out the same way: with the host needing to explain the code in question (e.g. describe the bug they’re asking for help with, fill you in on the work they did since the last time you paired). That way, you can simply click a Live Share link, and then immediately gain the context needed to get started. Nice!


A Live Share guest (left) following the host (right) as they scroll and navigate files

On its own, “follow mode” is effectively equivalent to a screen share, but with the added benefit of retaining your personalized environment, instead of staring at someone else’s. That alone is pretty valuable, but we needed to do better than that, since as I mentioned, we wanted to prevent guests from becoming limited to just “passive observers”. This is where things start to get interesting.

At any time, you can start editing the file the host is in, and as you type, you’ll receive the auto-completion you’d expect. Additionally, you can hover over APIs and/or peek their definition, and once again, receive the language support you’d expect. However, in neither of these cases, does your completion list or peek window appear on the host’s screen. This enables an experience that screen sharing can’t, where you can simultaneously follow along with the host, and contribute independently, without interrupting each other in the process. It’s the beginning of true mental concurrency on top of a shared resource (e.g. the file contents).


A Live Share guest (left) interacting with a file, without interrupting the host (right)

Following is so last paragraph

However, what if you need to deviate from what the host is currently focused on? For example, you might want to read some code in another file in order to give yourself more context. Or you could decide to split up a task with your pair, and work on it entirely in parallel. With screen sharing, that wouldn’t be possible, but with Live Share it’s simple: just open another file. As soon as you do that, “follow mode” is automatically disabled, and you can now operate entirely on your own, but still within the context of a shared codebase that’s synchronized in real-time. Sweet!

Once you’re done and ready to re-focus with the host, you can begin following them again by pressing <CTRL+F>, or by clicking their name in the Live Share tab. Need to deviate from them again? Great! Just navigate to another file or click their name again to toggle “follow mode” off explicitly.


A Live Share guest (left) seamlessly transitioning between following on independent navigation

This ability to focus on the same thing, or operate independently, provides the flexibility needed to perform “true” pair programming, collaborate on tasks with your peers, mentor your team, and everything in between. Everyone gets to choose their own interaction style, which may help prevent the “over the shoulder” effect and/or “pairing fatigue” that can come with purely serialized collaboration. But it gets even better.

Let’s have our code and eat it too

If you right-click a participant’s name in the Live Share tab, and select “Follow to the side”, that will open a new editor tab, and allow you to passively observe them, while simultaneously editing on your own. Even crazier: if there are multiple participants in the Live Share session, you could follow all of them in separate tabs, like it was some kind of real-time collaborative dashboard.


A Live Share guest (left) following the host while also editing their own file

In addition to the “Follow to the side” gesture, you can also “pin” a specific editor tab to a user, by simply clicking the pin icon in its respective tab well. That way, you can setup a completely custom grid layout, and follow any number of participants in whichever configuration you want.

Calling all cursors

Being able to follow anyone at any time, provides each participant with the ability to choose when and how they’d like to collaborate with each other. However, there are times where you want to actively synchronize everyone’s attention, and it would be pretty annoying if you had to ask everyone to individually follow you. To simplify this case, Live Share also enables you to “focus” participants, which automatically causes them to follow you.

To perform a focus, simply switch to the Live Share tab and click the little megaphone icon in the title bar of the “Session Details” view. By default, when someone else performs a focus, you’re automatically moved to their cursor and notified that it happened. However, you can change that by setting the “liveShare.focusBehavior” to “prompt”, which will give you the choice to ignore focus requests, if for example, you’re in the middle of something, and want to finish it before reconvening.


A Live Share guest (left) focusing the attention of the host (right)

We want to focus...on what matters

Hopefully this illustrates just how accommodating Live Share is, when it comes to deciding how your team would like to collaborate. Unlike tools that have inherent interaction models, Live Share is quite flexible, and allows you to seamlessly transition between actively following, independently exploring, simultaneously editing, and passively observing. We’ve found this to be pretty valuable, and scale well across the diverse landscape of collaborative variations.

That said, with great power, comes great complexity, and so we plan to continue improving the discoverability and ergonomics of these features over time. Additionally, we’re keen to hear about other modalities that might be useful, beyond the current feature set. In either case, please don’t hesitate to reach out and let us know any feedback you may have, and how we could ensure that Live Share appropriately fits the needs of your team.

Top comments (3)

jessekphillips profile image
Jesse Phillips

How does this development model relate to version control? Who owns the code?

lostintangent profile image
Jonathan Carter

Version control is still how you manage the project over time, and collaborate across the entire team. Live Share simply provides a way to collaborate on uncommitted code with others in real-time. Once you complete a Live Share session, you would commit the code you worked on to source control and potentially open a PR, so the rest of the team could see what you did.

Regarding code ownership, the code is located on the host’s machine, but Live Share will automatically set the commit message to ensure that everyone is properly attributed:

gusgonnet profile image

great post, thank you for all the details!