One linerLayouts organize display on regions, navigation patterns, and platform-adaptive rendering.
Platform → → UI Technology → UI → Canvas vs Dashboards | Real-Time | Client Types | Layouts → Clients | WebAssembly | Symbols | Drawing | Responsive | WebAssemblyLayouts
Layout Architecture
Layouts provide the structural framework for operator interfaces, defining persistent regions (Header, Menu, Footer) that remain stable while the Content area changes during navigation.
This architecture enables consistent navigation patterns, implements server-side responsive design (RESS), and manages rendering engine selection through centralized configuration.
Responsive Design & RESS (Concept):Responsive Design + Server-Side Components(RESS) delivers optimal user experience across all devices:Build-once: share some display configuration for multiple types of devices
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude StepsArchitecture style none
RESS Technology
Responsive Design + Server-Side Components delivers optimal user experience across all devices:
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
Server Side Layouts
Regions Organization
Layouts divide the interface into five possible regions, each with specific purposes and behaviors:
| Region | Purpose | Navigation Role | Platform Adaptation |
|---|---|---|---|
| Header | Branding, title | Primary/major navigation topics | Always visible |
| Menu (Left) | Asset tree, pages | Secondary navigation, asset selection | Hamburger on mobile |
| Content | Working area | Display target (avoid navigation here) | Adapts to available space |
| Submenu (Right) | Tools, filters | Contextual navigation | Hidden on mobile |
| Footer | Status, alarms | Limited navigation, typically status | Often hidden on mobile |
Navigation Patterns
The platform supports three distinct navigation patterns, each serving different operational needs:
Content Navigation
Changes what displays in the Content region while maintaining the layout structure:
- Default behavior when opening displays
- Preserves Header, Menu, Footer continuity
- Ideal for operational workflows within same context
Layout Navigation
Switches the entire framework including all regions:
- Changes Header, Menu, Footer, and Content together
- Enables role-based interfaces (Operator vs Engineer layouts)
- Supports form-factor simulation (Desktop vs Mobile layouts)
- Facilitates task-specific shells
ChildDisplay Navigation
Enables in-page navigation without changing the main display:
- Display region controlled by string variable
- Buttons/controls update variable to switch content
- Perfect for wizards, tabs, drill-downs
- Maintains page context while navigating sub-content
Navigation Best Practices
Navigation Placement
- Header - Major navigation topics, global functions
- Menu - Asset trees, page lists, detailed navigation
- Content - Workspace only, minimize navigation controls
- Footer - Status information, limited navigation
Form Factor Considerations
Industrial applications span from small touch panels to video walls. Navigation must adapt:
| Form Factor | Navigation Strategy |
|---|---|
| Small Touch Panel | Simplified header, no side menus |
| Tablet | Hamburger menu, touch-optimized |
| Desktop Monitor | Full regions, mouse-optimized |
| Video Wall | Minimal chrome, content-focused |
Client-Side Namespaces
Three hierarchical namespaces orchestrate the UI on the client side:
| Namespace | Scope | Access Pattern | Primary Functions |
|---|---|---|---|
| @Client | Session context | @Client.Property | Current layout, user info, session duration |
| @Layout | Available layouts | @Layout.LayoutName | List layouts, open, close, switch |
| @Display | Available displays | @Display.DisplayName | List displays, open in Content (default) or specific region |
This hierarchy enables programmatic navigation: @Client contains session state, @Layout manages frameworks, and @Display handles content.
RESS Implementation
Layouts are where Server-Side Responsive (RESS) technology is implemented. The server identifies the client type at runtime and delivers platform-specific content:
Client Detection
- Desktop Windows (WPF)
- Desktop Web (HTML5)
- Mobile Portrait
- Mobile Landscape
- Tablet
Platform-Specific Delivery
Based on client identification, layouts can:
- Assign different displays per platform
- Hide/show regions based on form factor
- Switch between optimized layouts automatically
- Provide fallback displays when primary isn't compatible
For RESS concepts, see .
Rendering Engine Management
Layouts orchestrate which rendering engine serves each display:
| Engine | Target Platform | Characteristics |
|---|---|---|
| WPF | Windows Desktop | High performance, full .NET access |
| HTML5 | Web, Mobile | Cross-platform, WebAssembly |
The layout configuration determines:
- Preferred engine per client type
- Fallback behavior for incompatible displays
- Engine-specific page assignments
Runtime Behavior
Layout Switching Scenarios
Role-Based:
@Client.OpenLayout(userRole == "Operator" ? "OperatorLayout" : "EngineerLayout");Device-Based:
@Client.OpenLayout(isMobile ? "MobileLayout" : "DesktopLayout");Task-Based:
@Client.OpenLayout(isAlarmActive ? "AlarmLayout" : "NormalLayout");Display Navigation
Standard (to Content):
@Display.Equipment.Motor1.Open();Region-Specific:
@Display.StatusBar.OpenIn("Footer");Key Architectural Decisions
- Separation of Structure and Content - Layouts define structure, displays provide content
- Server-Side Adaptation - Platform detection happens server-side for optimal delivery
- Namespace Hierarchy - Clear separation between client context, layouts, and displays
- Progressive Enhancement - Start with simple layouts, add regions as needed
In this section...
| Page Tree | ||||
|---|---|---|---|---|
|