Layouts organize display on regions, navigation patterns, and platform-adaptive rendering.

Platform → UI TechnologyClients | WebAssembly | Symbols | Drawing | Responsive | Layouts


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.


Regions Organization

Layouts divide the interface into five possible regions, each with specific purposes and behaviors:

RegionPurposeNavigation RolePlatform Adaptation
HeaderBranding, titlePrimary/major navigation topicsAlways visible
Menu (Left)Asset tree, pagesSecondary navigation, asset selectionHamburger on mobile
ContentWorking areaDisplay target (avoid navigation here)Adapts to available space
Submenu (Right)Tools, filtersContextual navigationHidden on mobile
FooterStatus, alarmsLimited navigation, typically statusOften 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 FactorNavigation Strategy
Small Touch PanelSimplified header, no side menus
TabletHamburger menu, touch-optimized
Desktop MonitorFull regions, mouse-optimized
Video WallMinimal chrome, content-focused

Client-Side Namespaces

Three hierarchical namespaces orchestrate the UI on the client side:

NamespaceScopeAccess PatternPrimary Functions
@ClientSession context@Client.PropertyCurrent layout, user info, session duration
@LayoutAvailable layouts@Layout.LayoutNameList layouts, open, close, switch
@DisplayAvailable displays@Display.DisplayNameList 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:

EngineTarget PlatformCharacteristics
WPFWindows DesktopHigh performance, full .NET access
HTML5Web, MobileCross-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...