Who is this for?
This document is relevant for everyone who works on the UI, that includes UX designers, visual designers, and UI engineers. It covers requirements, specs, and foundations for how to make a page responsive.
Requirements
We are required to make our UI completely usable for all screen sizes at 400% zoom from the starting point of 1280x1024px.
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
Vertical scrolling content at a width equivalent to 320 CSS pixels;
Horizontal scrolling content at a height equivalent to 256 CSS pixels.
Standard Breakpoints
The following breakpoints are required as part of our accessibility guidelines. Breakpoints based on screen width are the following:
1440px +
1200px
1024px
770px
640px
480px
320px and below
Summary
These are the main things that needs active definition from design and engineering.
By default, most text will be wrapped, you need to decide if you want it truncated instead
The default tabs variant isn't responsive, you need to turn on the adaptive prop
Breadcrumbs need active definition as it is more of a layout than a component
Widgets mainly just need a minimum width
Input forms need a maximum width
Steps and anchors need to be switched to different variants at specific breakpoints
Non-EBR tables need fixing of the first column when the table width is narrower than the total of all columns.
Any custom layouts needs to be fully tested.
Legend
✅ component is fully responsive out of the box
📏 component or layout needs active definition from design and engineering
Navigation
Header ✅
The header has three responsive elements, app switcher, domain switcher, and the search bar:
When there is not enough space, the app name is hidden from the app switcher
The domain name is always visible, but will middle truncate if there is not enough space
The search bull will turn into an icon + overlay when there’s no space available
Side Navigation ✅
The side menu uses percentage with min and max widths
Below 769px, the side menu cannot be locked and is shown as an overlay
Subnavigation 📏
Tabs 📏
In subheaders with tabs, tabs are expected to be the item that shrinks in narrower screens. Whenever you’re using tabs, you should always use the adaptive variant. Adaptive tabs is a prop that when turned on, automatically truncates all tabs that can’t fit on the screen into one tab.
Breadcrumbs 📏
Breadcrumbs are a lot wider than tabs, even when shrunk and made responsive. Because of that, you will need to set a max width to the entity name at smaller breakpoints. To achieve this you need to set your own breakpoints based on your content.
[Here are some examples you can use]
Side Menu 📏
The side navigation will have an overlay variant that slides in from the left side of the page. You will need to set your own breakpoints.
Dashboards (examples)
Widgets 📏
The widgets layout is based on the minimum width of the widget, which can be customized. An easy way to test the responsiveness of your dashboard layout is:
Set autolayout to wrap
Set minimum width to all widgets
Set widget width to fill
Entity Browser (examples)
Table 📏
All columns will have a minimum width of 100px by default - this can be changed
This is the main part designers need to worry about when designing list views for EBR.
If the table width is less than the sum of all columns’ minimum width, the first column will be fixed, the table will be horizontally scrollable. At the lowest break point, the first column will be unfixed.
Actions ✅
Secondary buttons collapse into the more actions dropdown at lower breakpoints.
Side Panel 📏
When designing side panel content, make sure to test your content for the small and large side panels in all breakpoints.
Small panel: 30%
Large panel: 50%
Minimum width: 400px
At lower breakpoints, the side panel is shown as a full page modal.
Filter Panel ✅
Filter Bar ✅
Full Page Forms 📏
Content Width 📏
Full width: if your content uses the full width of the modal, all you need to test is how it shrinks with the modal
Custom width: If you’re using fixed width, 700px for example
Set the max width to that number
And set the width to fill container, that way it shrinks if there is less than 700px available for the content
Vertical Steps 📏
When using vertical steps you will need to switch to horizontal steps at either of the 1024 or 770 breakpoints depending on the content width.
Horizontal Steps 📏
The horizontal steps component will have a shrunk version that you can switch to at your chosen breakpoint, depending on how long the names are and the number of steps.
Anchor Menu 📏
Just like vertical steps, the anchor menu will have a vertical variant that can be placed as a subheader.
Breakpoints
These are the breakpoints to follow when designing for responsiveness, make sure to apply these on the content area instead of the view port, which can be affected by the navigation side menu.
1441px +
1201p - 1440px
1025px - 1200px
770px - 1024px
769px>
Testing Responsiveness
Make sure to test any custom layouts or any designs you're uncertain of on all of the following screen sizes. An easy way to test all the breakpoints, is to test each breakpoint at its lowest and highest value:
1440
Using the 1440+ breakpoint specs
Using the 1200-1440 breakpoint specs
1200
Using the 1200-1440 breakpoint specs
Using the 1024-1200 breakpoint specs
1024
Using the 1024-1200 breakpoint specs
Using the 770-1024 breakpoint specs
770
Using the 770-1024 breakpoint specs
Using the 770- breakpoint specs
640
Using the 770- breakpoint specs
Handing Off & Annotation
Here are some examples of how to annotate for responsiveness when handing off:
Min, max, fill container, hug content
Breakpoints