---
# System prepended metadata

title: Open UI
tags: [pitch]

---

---
robots: noindex, nofollow
tags: pitch
---

# Open UI

### Problem
Every designer and engineer re-invents a proprietary pattern every time they create a UI component.

- Designers, engineers, and end users alike suffer from incoherent experiences across Microsoft products, even between various areas of the a single product.
- A staggering amount of UI design/engineering time is wasted on duplicated efforts to create and maintain identical UI components across Microsoft.
- UI components and themes cannot be shared between Microsoft's products, even between products using the same technology.
- There is no standard for how to name, structure, or theme UI components, inside or outside Microsoft.
- These inconsistencies are amplified in our accessibility scenarios where they are also harder to overcome by users who use assistive technology.

### Appetite
Leverage Open UI's *research* and *proposal* processes to bring *coherence* and *interopability* to Fluent components across Microsoft.

**Research:** Discover what we *could* do and how industry solves UI problems.

**Propose:** Discover what we *should* do through collaboration on a data-driven cross-platform open source standards process.

**Coherence:** Implement a UI standard across Microsoft and open the open source.

**Interopability:** Share common code, tools, and patterns built on the standard across Microsoft and the open source.

### Solution

1. Identify and normalize differences in UI naming and structure

    ![](https://i.imgur.com/onSvC3X.png)

1. Extract standards for components and themes from existing UIs

    ![](https://i.imgur.com/P1wTm9K.png)

1. Identify design tokens necessary to create sufficiently themable interfaces to allow for interopability

    ![](https://i.imgur.com/ryhNykl.png)

1. Include all frameworks and platforms in the component standard discovery and adoption

    ![](https://i.imgur.com/ofJrmZZ.png)

### Risks (Rabbit holes)

- Crating a ["15th standard"](https://xkcd.com/927/) which is not adopted, opposed to bringing patterns together.
- Simply identifying the "least common denomenator" across components is not helpful to building real-world applications.
- Just because something is common does not mean it is the best option.
- Project is wikipedia-like or dictionary-like, can take an endless amount of work and effort.  Keep focused on what is useful and necessary to Fluent UI.

### Out of scope (No-gos)
- Writing UI component code or a UI component library
- Authoring design or engineering tools