Build collaborative apps with Teams Live Share

Teams has always been on track to be an important part of Microsoft’s productivity platform, but the COVID-19 pandemic has pushed it to the top of Redmond’s agenda. Its importance became apparent when Microsoft and much of its customer base first moved away from the office to suddenly work from home, and are now adapting to a more planned approach that has become a work-from-home/office hybrid.

Although Teams has largely focused on its conferencing and collaboration features, its main differentiation from the competition draws on Microsoft’s heritage as a platform company. From its inception, it was as much a place for building apps as it was for communication and collaboration, providing much of the scaffolding and plumbing needed to deliver near real-time collaborative apps, as well as another endpoint for the line of business systems as part of a low-code workflow that houses the many small tasks that are integral to modern work.

Introducing Teams Live Share

Once you think of it as another platform, it’s no surprise to see Teams getting its own track at Microsoft’s Build conference. This year’s event was no different, with several major announcements including the general availability of a new JavaScript SDK and some major API releases. Perhaps most interesting, however, was a new set of tools that merge Teams’ own collaboration and conferencing features with Microsoft’s Fluid Framework real-time application development platform.

The result is the Live Share SDK, a way to build collaborative apps that mix meetings with apps that can share status among many different users and devices. We’ve already seen what this approach offers with Visual Studio’s Live Share collaborative coding. Different editors on different platforms can share editing space, extending pair programming beyond the desktop.

The Teams Live Share SDK lets you use Microsoft’s Fluid Framework to relay state between instances in a many-to-many mesh. You can then encapsulate your code and meetings in a Fluid container, adding collaborative functionality with minimal code. This way you can use Teams tools with your own, for example, sharing code and wireframes in a hybrid meeting review, allowing people in a conference room to annotate on a big screen and people at home to use their own screens. Interactions are near real-time and shared among all users, with Teams controlling the voice and video portions of the meeting. Like many recent tools from Microsoft, it is open source and can be found on GitHub.

From Fluid to Live and vice versa

Much of the Live Share SDK will be familiar to you if you’ve experienced the Fluid Framework. Live Share is a collection of JavaScript packages and installs via npm or Yarn, with dependencies on Teams JavaScript and Fluid Framework packages. If they are not installed, the SDK installer will install them. If you already have them, you’ll need to make sure you have the correct versions to avoid issues. Currently, you need both version 2.0.0-experimental.0 of the Teams JavaScript package and version 0.59.0 of the Fluid Framework.

There are other limitations at this stage of the preview. Probably the most important is that Live Share is only available for scheduled meetings; you cannot participate in it on an ad hoc basis in other types of meetings. All participants must be on the invitation; before they can access a Live Share application, they must accept the meeting invitation and add it to their calendars. Hopefully this is just a preview issue, as the ability to use Visual Studio Live Share for spontaneous collaborations is one of its strengths, and it’s easy to see how a similar approach could help turn a call into a shared workspace.

Creating a Live Sharing Application

A Teams Live Share app is like any other Teams app. Since it’s not yet part of the Teams dev tools, you’ll need to manually add additional permissions in the app manifest in order to use the new features, starting with the scope and context of your host URL. app with support for group chat with meeting. panel and stage. Next, you need to add delegated permissions for the Live Share session and the Meeting step of the app. As the platform matures, it should become part of the Teams SDK, with support for auto-generated manifests.

Now you can start adding live share functionality to your code. Apps need to join a meeting, so each instance of the app will start with the meeting in each user’s Teams session. The code will need to initialize the Teams SDK, then create a Fluid Framework container to handle synchronization between clients, configuring the distributed data structures needed to synchronize content. Fluid Framework has many different data structures, so choose the ones that are necessary for your application.

Most likely is a SharedMap, which is a basic key-value store for JSON objects. With a SharedMap you send, for example, coordinates that have been drawn on a shared image. This can be combined with a SharedString structure for collaborative text editing. These Fluid Framework data structures can persist between sessions, create post-meeting reports, and provide content that attendees can use offline.

Live Share brings new features not in Fluid Framework with what it calls ephemeral objects. This is a new form of shared object that is not stored in a Fluid container but is still accessible in your application. You would use them to manage user attendance or to add presentation tools like a pointer to a session. These are shared using the same real-time Fluid tools, but they don’t exist beyond a meeting unless you explicitly save their contents in a Fluid data structure.

A useful feature is the EphemeralEvent data structure. This can send messages between clients in a meeting, for example, indicating whether someone has joined or left. Be sure to add code to listen for notifications and run it asynchronously. In fact, much of the code used for both Fluid data structures and Live Share ephemeral structures must be asynchronous, as your code looks for and responds to events that may occur at any time during a meeting.

Working with media in Live Share

Although Live Share is perhaps best used for wrapping textual content using Fluid Framework’s collaboration tools, it offers a set of extensions in a separate package that supports multimedia synchronization. This adds a separate ephemeral object to support controls and media state, as well as a way to synchronize playback within an HTML media element. If you’re doing a video presentation in a meeting, you can have a Live Share app that allows approved users to pause playback to have a chat or annotate view.

Live Share can also give us a useful way to use Teams to broadcast live events, as it has tools for users to pause streams and skip them if necessary. There’s a nice option here if you’re using Live Share to host a training: you can allow users to pause to take a quiz or give feedback and only resume reading when all users resume. Such coordination is a handy feature as it ensures no one is left behind and everyone’s opinions are heard.

Live Sharing in Visual Studio is a powerful tool, so it’s good to see similar functionality coming to Teams. However, it’s important to realize that building real-time collaboration tools isn’t easy, and while Teams Live Share makes it easy to create and manage shared data structures, you still need to create a set of asynchronous event management tools to ensure that changes in shared data are reflected in user experiences. With a tool like Fluid Framework, it’s tempting to go all out, but that can lead to complex and unmanageable event parsing code.

So how should you use Teams Live Share? It’s best to start with a simple app: a tool that shares an easy-to-understand data structure, like a Kanban board with text and audio chat and basic editing features that allow a hybrid team to run a meeting daily standing, manage project backlogs so that project managers can quickly see and understand how a project is progressing.

Once you understand how Live Share works with a unique shared data structure, you can start developing your application, adding new features to support new requirements and respond to user requests. The result should be code that works well on meeting room screens and individual desktops, helping to bridge the hybrid working gap. This is the right time for Microsoft to release such a tool. We now need to create the Teams code that takes advantage of these new features.

Copyright © 2022 IDG Communications, Inc.

Comments are closed.