Fluent Blocks

Most app ecosystems have a problem: how do you raise the bar for quality? Often the first solution is to release a component library that adheres to the design system’s spec. This gets developers part of the way there, but even then developers are tasked with assembling these lower-level components together, which is another pitfall in each developer’s journey toward delivering a quality app.

One solution to this problem can be found in Slack’s Block Kit. In order to create an app for Slack, developers must interact with an HTTP API that makes structured requests of the Slack app’s UI. This has the benefit of being able to enforce specific UI patterns across native and web platforms, but comes with a major caveat: any design patterns from outside the canonical system are simply impossible.

While I worked for Microsoft Teams (starting at the height of the pandemic, when the app became a critical tool for teams with an Office 365 account), I sought to bring to the ecosystem a more flexible approach that could be used in the framework already on offer, but which could eventually act as the foundation of a rendering service which could provide an experience like Block Kit for developers of Teams apps.

Working in close collaboration with the Fluent design system team, Microsoft Teams’ design system team, and Visual Studio Code’s developer relations team, we identified a set of patterns app developers already used and would need most often, then I built-out a system which could provide those interactive experiences through basic JSON: developers would just need to provide a global handler and the content JSON to a View component, and Fluent Blocks would do the rest.

This created the walled garden, but since developers still needed to use Fluent Blocks in a stack that already rendered experiences in React, would developers use it if they couldn’t provide experiences which we hadn’t anticipated? To help encourage use of the highest-level components a developer would find helpful, I applied Fluent Blocks’ philosophy recursively down the tree of components. Developers could opt into the design system at any point in their UI’s tree, giving them an avenue to progressively move parts of their apps to Fluent.

In order to validate Fluent Blocks, I then began using it to resolve accessibility bugs in Teams Developer Portal (TDP), the web app used by all app developers for Microsoft Teams to upload and manage their apps. This had the effect of simplifying-away much of the complexity in TDP’s own codebase, as well as helping to guide the continued development of Fluent Blocks to handle a broader set of patterns and improvements to the developer experience.

Creating Fluent Blocks involved building a shared ontology & vocabulary for design patterns, which I wrote about in the project’s readme on Github. To explore more about Fluent Blocks, check out that link or explore the Storybook.