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

# Dual-screen support in Fluent UI

### Problem

Microsoft is debuting dual-screen devices this year and we want to position ourselves as the de-facto component library to create web experiences for these devices. However, we currently don't have the correct positioning support in our components for it.

There are two scenarios that current components should support:

##### 1. Self positioned components:

Dual screen devices have a hinge in the middle of the screen. This hinge creates either a vertical or horizontal line, depending on the orientation of the device.

When we position components on the screen they should not be cut in two by the hinge.


##### 2. Screen boundaries

Similarly when a component expands in size it should not do so in a way that renders across the hinge.



### Appetite

From conversations with people with more knowledge on the dual-screen scenario, it seems we should be able to finish this work in two weeks. There are known ways to determine if we are in dual-screen scenarios with which we can work and we have contacts we can ask in case we have questions.

### Solution

Update positioning logic underlying most of the components in v7 to be dual-screen aware with the API provided by the browser.

References to look at when developing the project:
- [Docs](https://docs.microsoft.com/en-us/dual-screen/cross-platform/)
- [Segments api](https://github.com/webscreens/window-segments/blob/master/EXPLAINER.md)
- [Folding device emulator](https://foldables-emulator.netlify.com)
- [PowerPoint deck](https://microsoft-my.sharepoint-df.com/:p:/p/zochahou/EdrbETADYDFMu5dBAAz47kABD0n_t9KQxC3BeZ_vrJGm2A?e=PlYfhf)

The list of components to test our changes again to see if they work includes at least:
1. ComboBox
2. Dropdown
3. Callout (with Calendar Hosted inside)
4. DatePicker
5. People Picker
6. Picker
7. HoverCard
8. ContextualMenu
9. CoachMark
10. MessageBar (Follow up needed on this one)
11. TeachingBubble
12. Dialog
13. Modal
14. Tooltip
15. Overlay

### Risks (Rabbit holes)
*From: [Rabbit hole guidance](https://basecamp.com/shapeup/1.5-chapter-06#ingredient-4-rabbit-holes)*

The potential risks in this project involve the unknown scenarios we might encounter when making these changes:
- It seems there's support for the API to handle these cases correctly, but since the API is still in development we might encounter bugs with it that prevent us from acquiring our objectives here.
- The emulator technologies to test our changes are also in constant development and we might encounter bugs that prevent us from correctly testing our changes.

### Out of scope (No-gos)

There is a third scenario regarding Two Page design pattern support, where applications can target the left or right screens and render different content in each one. Since this project is focused on existing components and solutions and not in engineering a solution for a new pattern this will be left out of scope for the moment.

v0 is using the Popper library for positioning instead of in-house logic in our repo. Since it's harder to implement these changes there updating v0's positioning logic will be left out of scope for this project.

*For more information about dual screen you can read [this document](https://hackmd.io/8pu12TibTzaBEr0aKCkmxg?view)*