While responsive scaling is primarily impacted by the width of the screen layout, scrolling behavior is largely determined by the available vertical space.
Unlike screen width, the available window height can vary significantly depending on several factors. Browser toolbars, bookmark bars, operating system menus, and full-screen modes can all change the visible portion of the application screen. When design height exceeds the available vertical space, scrolling occurs.
Fold line and Safe Zone
Screen structure should be planned considering the window's visible area.
The safe zone is the portion of the screen that users can see immediately without scrolling. Content located above the fold line is visible as soon as the screen loads.
While it is not simple to define a universal safe zone height, we can estimate this after accounting for browser, bookmarks bar, platform, system taskbar, and other interface elements. A safe zone height of 864 px for 1920 can be used as a solid reference.
Safe “above the fold” zone
Designers should be aware that only a portion of the screen may be visible when the page first loads. For this reason, the most important elements of the screen should remain within this safe zone whenever possible: Navigation controls, filters and selectors that affect the screen content, important contextual information, KPIs, etc.
When relevant content exists below the fold line, it is recommended to partially reveal it at the bottom of the visible area. This makes the presence of additional content more noticeable and improves discoverability by indicating that scrolling is possible.
Designing with safe zones in mind ensures that users can immediately understand the screen and access its main controls without needing to scroll.
Screen Scroll vs. Object Scroll
Scrolling can occur at two different levels within a Board screen:
- Screen-level scrolling. The entire screen extends vertically and users scroll the page to access additional content.
- Object-level scrolling. Specific objects scroll internally while the rest of the screen remains fixed.
Whenever possible, object-level scrolling is recommended over full screen scrolling.
When the entire screen scrolls, important interface elements may move out of view. Preferring to scroll inside the objects offers the user a consistent placement for navigation bars, side panels, and other UI elements, resulting in a better and more intuitive experience.
Scrolling at object level
For example, it is not uncommon to have data view tables that have several columns and rows on report and detail screens. In these cases, allowing the table to scroll internally is usually preferable to extending the entire screen vertically. This approach preserves context and makes the screen easier to navigate.
Horizontal Scrolling
Horizontal screen scroll is not a desirable user experience that should be avoided whenever possible.
When tables contain many columns, reducing text size to force all columns to fit within the screen is not recommended, as it can significantly reduce readability. Instead, make the data view object fit the available screen width, keep a comfortable text size, and leverage freezing columns while allowing horizontal screen within the table.
Changing the Screen Ratio
The editor uses 16:9 ratio by default. Designers can work with this default by planning the content that should be placed above the fold line, and which elements may be accessed after scrolling on the screen.
However, in some cases, designers may wish to show all content above the fold line, avoiding vertical scrolls. While Fit to single page provides a similar behavior, it may make responsive object sizing less predictable at smaller viewports.
Another possibility is to change the screen ratio in the editor.
Modifying the screen ratio in Board
For example, setting a shorter height in the editor resolution such as 1920 x 864 px, equal to a 20:9 ratio, accounts for the reduced vertical space typically available in browser environments.
With this approach, the application would prevent or reduce vertical scrolling, while maintaining more manageable object sizing.
Scrolling Guidelines by screen type
Different screen types support different interaction patterns and therefore tolerate scrolling differently. Understanding the purpose of the screen helps determine the most appropriate scrolling behavior.
Scroll strategy in different screen types
Home Screens
Home screens primarily provide navigation and orientation within the application.
Scrolling should generally be avoided on home screens. Users should be able to immediately see the available navigation paths and understand where they can go next without needing to scroll.
Dashboard / Overview Screens
Dashboard screens support monitoring and situational awareness. These screens are designed to be quickly scanned to immediately assess performance or status.
For this reason, the most important KPIs and charts should remain above the fold line whenever possible. Excessive screen scrolling can reduce the effectiveness of dashboards by forcing users to navigate the layout rather than scanning key information.
If additional information is required, designers should consider using tabs or drill-downs (see progressive disclosure). These can help maintain a concise and readable overview.
Analytical / Detail Screens
Analytical screens support data exploration and detailed analysis. These screens frequently contain large tables, detailed charts, and extensive datasets. In these contexts, scrolling is often unavoidable.
However, scrolling should typically occur within data objects rather than across the entire screen. For example, tables should scroll internally so that surrounding filters, KPIs, and contextual information remain visible and in place.
