--- robots: noindex, nofollow tags: pitch --- For instructions on shaping a project see here: [Shaping a Project](/kX02SXVbS6KzMOQd56i6Cg) # Base Theme & Teams Shell 2.0 ### Problem M365 products do not implement a shared Fluent Design look and feel. The existing themes are also not able to accept Fluent's new design tokens, precluding them from receiving Fluent Design updates. ### Appetite Fluent UI should ship a "base" Fluent theme which captures the critical elements of Fluent Design. This base theme should implement design tokens which enable brand expression without violating Fluent Design principles. Teams is heavily involved with the definition of the latest iteration of Fluent Design's theme and design tokens. Teams is also currently redesigning their product to better capture the Fluent Design principles. Moreover, Teams is also designing their product to allow tenants to express their own brand within the product. This makes the new Teams theme the perfect candidate for co-developing and stress testing the new Fluent UI base theme. The result here is to have real components, with real themes, with real support for compose()ing those into higher value components, vetted in a real, high-traffic, production application scenario (Teams). ### Solution The deliverable here is a base theme. However, this is a multi-faceted solution that needs to touch many places to ensure it is effective. **Base Theme:** Create a Fluent UI base theme with elements applicable to all M365 products through iterating on the Teams themes. **Shell 2.0** Split the current v0 Teams them into a Shell 2.0 theme, Teams default theme, and a Teams tenant theme. Implement the Fluent base theme for this. **Design Tokens** By comparing base theme needs to Teams' "neutral" theme and finally to Teams' tenant themes, we will identify design tokens necessary to allow a single set of styles to express all these levels of variance. **Design:** Engage Fluent Design in a two way converastion and iterative findings as to a pragmatic and functional set of design tokens. These tokens will be proven out on production products and themes. **Open UI:** Collaborate in Open UI to identify and validate Fluent UI token names and structures and drive coherence at Microsoft. **UI Builder:** Collbarorate with Fluent UI Builder to integrate design tokens into a design-to-code build and edit experience. Use this feedback to continue assisting and pushing forward the Figma plugin and Theme Designer efforts. **Style Dictionary** This effort will ensure token values used are applicable to all Style Dictionary needs and use cases. Collaborate with Travis Spomer to confirm tokens can be generated through Style Dictionary, including all platforms we're targeting. **Multi-plat:** Engage other Fluent UI platforms in two-way learning to ensure base theme tokens are satisfactory with other platforms. Ensure design tokens work with web frameworks other than React (Web Components). **Convergence Dependencies:** The base theme is not dependant on convergence of components, transition to CSS Variables, or ancillary items such as Open UI specs. The goal is to identify which style properties are included in which level of theming and which properties need to accept tokens in order to express other themes. #### Theme Packages Here's a sample of expected theme package structure and what we'll be able to accomplish: ![](https://i.imgur.com/zzxPs2A.png) - Themes will live in Fluent UI's NPM scope - Allows us to iterate and prove things out - Prefix/postfix packages to identify theme packages - We will stress test the structure with several themes and levels of composition (e.g. base -> m365 -> teams -> coke). - We will stress test flexibility and utility of the Fluent base theme by including themes outside of M365 and Microsoft. #### Horizontal Focus We will focus on a small set of components (verticals) to keep this project productive over a short period of time. We will focus on the following horizontal concerns that we expect to b able to scale across our entire component set once solved for a handful of components. **Box Model:** Minimal and simple model allowing expression of any theme. **Layout:** Assist design in validating use of ramps for spacing and layout nudging. This is to prevent engineers from needing to make overrides which prevent theme updates in production code. **Color:** Color is confused and difficult and has been slow moving for Fluent UI, especially across platforms. We will take cues from Fluent Design's latest token ideas, FastDNA's color and token system, Windows 10x, as well as our own experience in v0 and v7. Our primary goal is pragmatic and cross-plat here. We believe it is most important to find a solution that is functional in production opposed to one that includes the most ideas from Fluent members. **Motion:** Minimal tokens for motion definition will be included (e.g. animation names, timing functions, durations, etc). **Font:** We will identify tokens assist in developing the font ramp story for Fluent UI **Appearance:** ### Risks (Rabbit holes) - Not managing complexity. A complicated theme is not worth using it. Products will roll their own. Styling is complex and must be managed aggressively. - Over engineering inheritance. Inheriting themes is difficult, avoid boxing ourselves in due to deeply inherited themes. - Deciding on styles and tokens is hard. Prevent stalling or blockers due to indicisiveness. Remember to iterate and include others. - ### Out of scope (No-gos) - Focusing on CSS Variables and web styles only. We will not: - Write Style Dictionary transforms for other platforms - Publish style solutions for other platforms - Figuring out how to deliver styles to the browser (see David Zearing's work on ThemeProvider for this). - Solving issues related to CSS cascading or style resolution. Instead, we're focusing on the tokens and styles themselves, after they are delivered to applications. - Defining font faces and animation keyframes as these are also globals. - A 'reset' or 'normalize' style. Instead, we will use normalizr and strictly focus on component tokens and styles.