Responsive Design and RESS

Dual-layer responsiveness: display-level adaptability combined with server-side platform detection.

Platform → UI Technology→ Clients | WebAssembly | Symbols | Drawing | Responsive | Layouts

Overview

Display Responsiveness

Both dashboards and canvas displays have customizable responsiveness. They can stretch proportionately to the client area, maintaining the spatial relationship of objects, or reposition objects internally.

The configuration of this behavior is defined at the Display-Level using the OnResize property of the displays.

Responsive Design & RESS

Responsive Design + Server-Side Components (RESS) delivers optimal user experience across all devices.

The configuration of this behavior is implemented at the Layout-Level; the internal displays remain the same:

• Build-once: Share display configurations across multiple device types
• Run everywhere: Identifies the client device and delivers content with the proper layout

Server Side Layouts

Display-Level Responsiveness (OnResize)

Every display—whether created with Canvas or Dashboard drawing tools—has configurable resize behavior through the 

OnResize property:

Important: Canvas vs Dashboard is about the drawing method, not responsiveness. A Canvas display can be responsive, and a Dashboard display can use StretchUniform. The drawing tool determines how you position objects during design; OnResize determines runtime behavior.

Recommended OnResize by Display Type

The five modes map cleanly to display purpose. This is the authoritative reference for OnResize selection across the documentation — use it as a decision tree, picking the row that matches the display you are building:

StretchFill is not a sensible default. It is the right choice only for backgrounds and decorative full-bleed art — never for a process diagram, KPI surface, or any display whose elements convey measurements or relative positions.

Docked Header / Footer / Menu use Responsive, not NoAction. A docked region is set to Responsive together with LockedHeight (Header/Footer band) or LockedWidth (Menu/SubMenu rail) so the band stays a fixed thickness while its content still reflows to the available width. Setting a docked Header to NoAction is the wrong knob — it freezes the whole region instead of pinning only the thickness.

Per-Element Locks (Responsive displays)

When a display uses OnResize=Responsive, individual elements decide how they react as the display grows. Four element-level locks control this, set per element in the Properties panel:

Combine them per the element's role:

• Prominent grid / chart / viewer that should fill the display — IsWidthAlign + IsHeightAlign
• Full-width band or row (toolbar, panel that spans the width) — IsWidthAlign only
• Bottom-pinned input row (entry boxes anchored to the bottom) — IsTopAlign + IsWidthAlign
• Right-edge control (button or icon that should hug the right side) — IsLeftAlign
• Small top-left labels and nav icons — no locks; they keep their position and size

These element locks are honored only when the display's OnResize is Responsive. Under StretchUniform, StretchFill, ResizeChildren or NoAction they have no effect — those modes treat the whole display as one unit.

Pinning Docked Regions (LockedWidth / LockedHeight)

Two display-level locks pin a docked region to native pixels while it stays Responsive:

• LockedHeight — pins a docked Header or Footer band to its native height. The band keeps its pixel thickness instead of stretching vertically.
• LockedWidth — pins a docked Menu or SubMenu rail to its native width. The rail keeps its pixel width instead of stretching horizontally.

Use these on the display that is assigned to the corresponding Layout region. They are the correct way to keep a header bar a fixed thickness or a side menu a fixed width while the central content area absorbs all the extra space.

Authoring discipline: set all six locks — the four element locks (IsWidthAlign / IsHeightAlign / IsLeftAlign / IsTopAlign) and the two display locks (LockedWidth / LockedHeight) — through the Designer Properties panel, not by hand-editing display XAML.

Responsive Canvas

When a Canvas display uses OnResize="Responsive", individual elements (via the per-element locks above) can be configured to:

• Maintain fixed margins from edges
• Scale width/height proportionally
• Anchor to specific sides
• Combine fixed and proportional sizing

Example: A sidebar that maintains fixed width while content area expands.

Dashboard Responsiveness

Dashboard displays inherently support grid-based responsiveness:

• Grid cells redistribute based on available space
• Content within cells follows cell boundaries
• Automatic conversion to vertical stack on mobile portrait

Defaults:
- Canvas displays default to StretchUniform - preserving diagram integrity
- Dashboard displays default to Responsive - adapting to screen size

Composition Patterns

Home as a Dashboard with two ChildDisplays

The recommended landing-page pattern is a Dashboard "Home" display that hosts two ChildDisplays rather than a single monolithic screen. The Home Dashboard uses a TGrid with Star columns and a TGridSplitter; each cell embeds one ChildDisplay. The Dashboard itself carries no element locks — the Star grid distributes space, and each embedded display manages its own internal responsiveness.

This keeps each half independently authorable and reusable, and lets the splitter give the operator control over the balance between the two panes.

Splitting a Canvas for mobile

When a Canvas page must also render on a phone, do not try to reflow one wide Canvas into a narrow viewport. Instead split it into two child displays, each its own Canvas, and deliver the pair via RESS layout selection. Each child Canvas is then sized and tuned for the device class it serves, while the desktop layout shows both together.

Worked Examples — Asset Monitor Demo

The shipped Asset Monitor demo solution applies these rules end to end. The table below shows how each display is configured — a concrete reference for the decision tree above.

Server-Side Responsive (RESS)

RESS (Responsive + Server-Side) adds intelligence before content delivery. The server identifies the client type and sends optimized content.

Responsive Design + Server-Side Components (RESS) delivers optimal user experience across all devices:

• Build-once: Share display configurations across multiple device types
• Run everywhere: Identifies the client device and delivers content with the proper layout
• Server Detection: Identifies device class (phone, tablet, desktop)
• Optimized Delivery: Sends appropriate content and resources
• Responsive Behavior: Maintains flexibility within device class
• Reduced Engineering Time: All displays are shared by all layouts
• Result: Fast loading with adaptive layouts

Client Detection

RESS Benefits

• Reduced bandwidth - Only necessary resources sent
• Faster loading - Optimized content for device
• Better UX - Platform-appropriate interfaces
• Single source - One configuration, multiple outputs

How Layers Work Together

The two responsive layers complement each other:

1. Server decides WHAT - Which layout and displays to send
2. Display decides HOW - How content adapts to screen changes

Example Workflow

Configuration Points

Display Level (OnResize)

Set in Display properties during design:

• Choose resize mode per display
• Configure responsive anchoring for Canvas (per-element locks)
• Pin docked Header/Footer/Menu regions with LockedHeight / LockedWidth
• Test with preview at different sizes

Server Level (RESS)

Configure in Layouts:

• Assign platform-specific displays
• Define fallback options
• Set region visibility per platform

Precision note: a Layout region's "Header set to Stretch (spans full width)" refers to the region's HorizontalAlign = Stretch — how the region fills its Layout column. That is a different knob from the display's OnResize mode. Do not conflate region HorizontalAlign with OnResize=StretchUniform; they govern different things.

Details in Layouts and Navigation.

Design Strategies

Progressive Enhancement

1. Design for smallest screen first (mobile)
2. Add complexity for larger screens
3. Use RESS to deliver appropriate version
4. Let OnResize handle minor adjustments

Graceful Degradation

1. Create full-featured desktop version
2. Define simplified mobile alternatives
3. RESS automatically selects based on client
4. OnResize maintains usability during transitions

Best Practices

In this section...