Layout

The App Layout foundation defines the shared structural vocabulary for how enaio® and yuuvis® apps arrange navigation, workspace, and supporting content on screen. It is based on the yuuvis® MOMENTUM shell’s documented viewport architecture (Bars, Panes, Sections, Columns), cross-checked against enaio® Webclient screens (Desktop, Workflow Admin, Object Definition editor). The result is one shared model both product lines already follow in practice, expressed with one shared terminology.

Core Structural Elements

Element	Definition	enaio®	yuuvis®
App Bar	Persistent vertical area for global navigation or app-level actions. Always visible, not collapsible in the way panes are.	Application Bar (app switcher) in Shell applications Toolbar (app/module switcher), embedded per-pane toolbars (filter, refresh, sort), Application Toolbar (global actions)
Toolbar
Pane	Vertical content division representing one functional or semantic unit (navigation, workspace, or supplementary detail). Panes can be collapsed or resized; each has its own scroll context.	Navigation pane, Master pane, detail panes, preview panes, dashlet panes, context pane
Section	Semantic subdivision within a pane that groups related content, usually with its own heading.	Grouped elements/sections within panes
Column	Optional column-based layout for structured alignment within a pane.	Grid/table columns in list views (e.g., Recycle bin), column layouts within panes
Drawer

Layout Patterns

When designing a new screen, start by identifying which pattern to use, rather than inventing a new arrangement.

Master-Detail

Two panes: a master (list or tree) controls what appears in the detail pane. Use for browsing a set of items and drilling into one.

• enaio®: Workflow Admin, “Aktive Modelle” list (master) drives the “Prozesse von Modell” table (detail).
• yuuvis®: Any two-pane list-to-content screen per shell documentation.

Master-Detail-Context

Three panes: master, a primary detail pane, and a tertiary Context pane that is bound to the current selection (occasionally sticky or independent, but always visually subordinate to the detail pane).

• enaio®: Desktop view. Tree panel (master) selects a folder or document, the item list is the detail pane, and “Details preview” (index data, properties) is the context pane, bound to the selected row.
• enaio®: Object Definition editor. Object tree (master), catalog editor canvas (detail), “Field” / “Flags” property panel (context, bound to the selected field).
• yuuvis®: Shell documentation’s Master-Detail-Context pattern. The Context pane “is always tertiary, regardless of its binding mode” (bound, sticky, or independent).

Focus-Supporting Pane

Panes coexist without a hierarchical or selection-based dependency, e.g., an editor next to a dashboard widget or configuration panel. Used for editors and configuration views where no pane strictly “controls” another.

• yuuvis®: Dashboards, editors, configuration views per shell documentation.
• enaio®: No strong example in the reviewed screens; flag for follow-up if such a screen exists.

Floating Pane Extension

A temporary overlay panel, subordinate to the main workspace, for tools or assistants. Not one of the up-to-three persistent panes counted in the composition rule below.

• enaio®: The Object Definition editor’s bottom “Validation” panel (tabs: Validation, Comparison, Protocol), dockable and independent of the current field selection.
• yuuvis®: Floating Pane Extension per shell documentation, e.g., navigation, tools, or an assistant overlay.

Composition Guidelines

• Maximum three non-floating panes in one view. If a screen needs a fourth persistent pane, reconsider the design or move one pane to a Floating Pane Extension.
• Visual hierarchy must reflect pane role: The primary detail pane gets the most space and the strongest typography; the context pane is narrower and visually lighter. Do not give a context pane equal visual weight to the detail pane it supports, even if their content areas are similar in width.
• The context pane is always tertiary. This holds regardless of whether it is bound to the current selection, stays sticky across selections, or shows independent/global content, e.g., a help panel.
• Panes should be collapsible where screen space is constrained (see the Desktop tree panel’s collapse control, or a Master pane collapsing to icon-only).

Bars vs. Per-Pane Toolbars

yuuvis® documents a single, global Application Toolbar in addition to the Application Bar. enaio® screens instead embed toolbars locally, inside the relevant pane (e.g., filter/refresh/menu icons at the top of a list, or undo/redo/save icons at the top of the editor canvas). Both approaches are valid within this shared model:

• Use a global Application Toolbar for actions that apply across the whole app, independent of which pane or item is focused.
• Use a per-pane toolbar for actions scoped to that pane’s content (e.g., list filtering, canvas editing).
• Do not duplicate the same action in both a global toolbar and every pane’s local toolbar.

Quick Reference for Reviewing a Screen Design

Question	Why it matters
Which layout pattern is this? (Master-Detail, Master-Detail-Context, Focus-Supporting, or a screen with a Floating Pane Extension)	Naming the pattern surfaces whether the design is reusing an established structure or introducing a new one that needs justification.
Does the context pane stay visually subordinate to the detail pane?	Prevents a supplementary panel from competing for attention with the primary workspace.
Are there more than three persistent panes?	Signals the screen may need simplification, or that one pane belongs in a Floating Pane Extension instead.
Is every action’s toolbar placement (global vs. per-pane) consistent with where the same action lives elsewhere in the product?	Avoids the same action appearing in different toolbar tiers across the app.

Open Questions

• No pixel dimensions or breakpoints are documented in the yuuvis® shell viewport architecture source; enaio® screenshots reviewed were desktop-only. Responsive/mobile behavior for both product lines needs its own follow-up.
• Confirm whether enaio® has (or should adopt) a dedicated global Application Toolbar, or whether per-pane toolbars remain the intended pattern.
• Focus-Supporting Pane needs a confirmed enaio® example before it can be documented with a concrete reference screen.

Sources

• yuuvis® shell viewport architecture
• yuuvis® shell introduction
• enaio® screenshots reviewed: Webclient Desktop view, Workflow Admin, Object Definition editor