---
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


1. Extract standards for components and themes from existing UIs


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


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


### 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