Mobile Webview & Responsive Layout Improvements
Implementation in progress
Important Links
While working on these global layout updates, we will be taking the opportunity to improve the responsive layout and mobile experience in the browser.
Touch device experience vs. non-touch device (desktop) experience
In order to accommodate for less-fine pointers (e.g. fat fingers ), below a certain screen width threshold, we will need to have UI changes to type sizes, button sizes and other touch target sizes. This means we will have two slightly different experiences when the product is accessed through mobile/tablet devices or on desktop devices below 1200px.
Popover Menus
As outlined below, menus behave differently depending on the screen width:
For breakpoints below 600px, menus behave as bottom sheets.
For breakpoints 600px+, menus behave as popovers
Max-heights for menus
Menus should have a maximum height that follows these rules. Beyond these heights, the menu will scroll.
Popovers
If menu opens above trigger, the max-height is
trigger y position - 48px
If menu opens below trigger, the max-height is
viewport height - trigger y position - trigger height - 48px
Bottom sheets
have max-height =
viewport height - 132px
<600px (mobile)
Non-touch devices
Touch devices
The layout is largely the same for touch vs. non-touch devices, but text sizes are increased, icon sizes are increased, button sizes are increased and menu items are increased.
Menus for <600
For devices in this breakpoint range, popover menus behave as bottom sheets. Submenus slide in from the right as bottom sheets with back buttons to the parent menu.
600-899 (tablet portrait)
Non-touch devices
Touch devices
Menus for 600+
For devices in this breakpoint range, menus behave the same as standard popovers. Touch devices get larger tap areas.
900-1199 (tablet landscape + desktop)
With this width, the sidebar is always visible and the RHS (when open) overlaps the main content area of a channel.
Non-touch devices
Touch devices
1200-1679 (desktop)
For viewports larger than this width, it is assumed that users are not on touch devices and we default to non-touch UI and will not support the two UI experiences above this width.
With this width, when the RHS is open, it will split the main content view rather than overlapping/obscuring it.
1680+ (desktop large)
The only real difference with viewports this wide is the fact that the RHS now becomes 500px wide rather than the standard 400px.