Loops Available Now
The advent of Loop, a new Microsoft application due for availability sometime next year, was a highlight of the recent Ignite conference. The first implementation of the (fluid/live and now loop) components which underpin the application is available in Teams personal and group chats. Over the coming months, updates to other applications (like OWA) will come to support loop components.
Microsoft is busily making loop components for Teams generally available. Tenants should be able to use loop components following server and client updates. Reflecting their heritage and connection to the Fluid Framework, loops in Teams show up as fluid components. A future update will sort that out.
There’s something compelling about the notion of components synchronized very quickly to make it possible for everyone involved in working on tasks to see changes in content as soon as they occur. However, as with any new technology, after the feeling of delight at the new toy passes, some mature reflection should happen to consider how normal users will cope with loop components in the daily grind of work. In this article, I cover some of the issues which Microsoft 365 tenants might need to work through as people get to grips with loop components.
Microsoft tweaks its cloud applications on an ongoing basis to change the way people work. This isn’t a new phenomenon. Clutter, and then the Focused Inbox, are examples of early attempts to help users cope with large volumes of email. Gently nudging people to use cloudy attachments instead of sending files in email is an example of a change in work practice built on top of SharePoint and OneDrive. Online co-authoring is another. And being able to respond to Teams and Yammer conversations direct from a message in Outlook is a change intended to avoid context switching between applications. These changes all make eminent sense, but still took time for users to embrace.
Moving from Phased to Dynamic Activity
What Microsoft is doing with Loop is more pervasive and far-reaching because the use of loop components introduces a new information lifecycle that’s very different from the classic approach used when people collaborate in documents, presentations, and spreadsheets. It’s moving from a phased well-understood process to something a lot more dynamic.
Take the creation of a proposal to do work for a customer. In classic Office, someone might create a Word document, sketch out the outline for the proposal, and share the file with co-workers using a sharing link or by uploading the file to a document library. If permissions allow, those working on the proposal can edit the content, perhaps in a co-authoring session, to develop the proposal into a state suitable for delivery to the customer. The lifecycle depends on features like:
- Comprehensive editing functionality, including author assistance like spell and grammar checking.
- Revision control like track changes and markup. Updates made by different contributors are obvious and the author can accept or reject individual changes.
Above all, someone takes charge of the content and can eventually say “we’re done” and prevent further editing. If they like, they can even apply a sensitivity label to the document to encrypt the content and prevent it being accessible to anyone outside the document’s permission list.
The classic document lifecycle from creation to completion is a well-worn road. All participants know their role.
Some will point to the less powerful nature of the loop editor and conclude that it’s insufficient for any real work. I don’t share this view. The editor will improve over time to a point where it can cope with most office tasks. The loop editor might never be the chosen tool to compose a complex legal document or write a book. These are the kind of scenarios where Word shines, but it’s always important to choose the right tool for a job. Loop seems to be more of a toolbox capable of dealing with text, tables, graphics, lists and more without getting too complicated.
Compared to any current Office application, loop components are more dynamic. Anyone with access to a component can update its content. As soon as a change occurs, synchronization delivers updates to everyone currently connected to the component. If someone involved in a component is offline when changes happen, loop refreshes the component the next time the user accesses the chat. Assuming a reasonable network connection, synchronization works well, and people can work without pausing to wait for loop to catch up.
Tracking Changes in Loops
Loop will tell you who changed something through attribution (Figure 1). You can move through the set of people who have contributed to some text and see who changed what. This is fine, but it is not document markup.
Like any other message in a chat, you can pin a loop to the top of a chat. This is a good way to remind everyone involved in a project about the ground rules, like how you expect to process comments and changes made to Loops (no matter how often I refer to components as “loops.” it still seems wrong).
The physical embodiment of a loop component is a fluid file stored in OneDrive for Business or SharePoint Online. There’s goodness in this approach because all the management functionality, like retention policies, indexing, and backup tools, applicable to these repositories cover the fluid files. Some Microsoft has some work to do to make sure that Data Loss Prevention policies, sensitivity labels, and content search previews cover loops. Again, this work will unfold over time.
Like any other file stored in OneDrive or SharePoint, versions of fluid files accrue over time. This is also an advantage because apart from restoring a previous version of the fluid file for a component, there’s no way to roll back changes to a point in time, or even reverse a single change.
The initial challenge is to choose the correct file to restore (Figure 2). Once that’s done, restoring a previous version has some challenges. First, the restore operation overwrites changes made by users during the restore. Second, restoring a previous version is an all-in affair – the content available when Loop saved the file becomes the current text: you cannot select individual changes. Last, users might see synchronization or display errors after a restore (easily fixed by refreshing the client). All in all, restoring a previous version is not something to do on a whim.
When Employees Leave
The storage of loop components for personal and group chats in OneDrive for Business has a downside in that if an employee leaves the business, the fluid files owned by that employee need to be online and in the same place to allow discussions to continue. If the employee’s OneDrive for Business account is deleted, the fluid components become inaccessible. Clearly, this is an issue for tenant administrators to think through.
It would be nice if Microsoft allowed users to move chats to become channel conversations. This would be an elegant solution to the issue by moving the fluid files into the channel folder in the SharePoint Online document library belonging to the host team. Alas, this isn’t currently possible.
Locking Final Content
After reaching and documenting something in a loop component, you can’t lock the content to prevent further changes without adjusting the sharing link to make it view-only. It is easy to remove the existing sharing link and replace it with a read-only version in a Teams personal chat (Figure 3); it might be just a tad harder when loop components exist in Teams channel conversations and multiple people are involved.
The point is that if you don’t amend the permissions on a loop component, its content remains editable after those working on the component decide a matter. For instance, someone could go back and update a component to introduce a new action item, or increase a budget figure, or assign some new responsibilities to themselves or someone else. Moving from the relatively immutable formal content of a file documenting the results of some work to a dynamic component will take time to figure out in terms of work practice.
People often generate printed copies of documents at the last stage of a decision process. Like the rest of Teams messaging, there’s no print feature for loop components. You can copy and paste content from a loop component (or multiple components) into Word or another format and print there. I assume that when Word, PowerPoint, Outlook, and Excel support loop components, printing will be possible.
People are Key
The biggest challenge for Loop is likely individual resistance to change the way users work. It takes time for people to change their habits. If they have a perfectly good way to get their work done, why should they introduce a new technology? It’s the same argument that has existed around OneNote over the years. Some consider OneNote to be a fantastic method to capture information. Others say that they can do the same in Word. At times, technology can be very personal.
To be successful, I think organizations will have to discover the advantages Loop brings in their environment. It’s possible that zero advantages exist until Microsoft upgrades the application. On the other hand, there could be a killer application just waiting for Loop to arrive. What’s true is that obvious success within the context of the business is a great selling point for a technology. It always has been so.