Skip to main content

Information, Navigation, and Labels

This page covers what appears around a view: content, menus, labels, and record structure. These elements give a screen its context and help users find their way through the application. Component options stay in the viewtemplate reference.

Information for the task​

Focus on the fields and related records needed for the task. An entity can contain more information than belongs on one screen; including a field because it exists in the entity rarely makes the task clearer.

Visual design and data presentation helps with selecting a display type. The selected viewtemplate reference then explains its field behavior, visible columns, and data requirements.

Menu groups work well for areas of work. Group contexts where users expect to find them rather than mirroring the technical data model. A single-item group without a grouping purpose, or a large group of unrelated contexts, can make navigation harder to scan.

Clear names help users understand every menu group and context. Icons can support recognition, but text remains important; a standard icon is a useful choice when available.

For context-specific decisions about related information and selectable views, see contexts.

Record structure​

The record header can identify the selected record. Placing the main identifier first helps users confirm their current record at a glance. Secondary information is valuable when it helps distinguish or understand the record; clear groups and headings make related information easier to read.

The task usually provides a useful order for fields, groups, and tabs. When a field, group, or tab represents the same information in comparable contexts, a similar relative order helps users recognise it again.

The same business concept is easier to recognise when its visible label, format, unit, and status representation remain familiar. A different task or role may need a different order or a smaller information set.

Name visible elements consistently​

Purposeful labels make titles, buttons, toggles, and messages easier to understand. Spelling and wording provides the shared conventions.

Handling absent information​

An empty field can be useful information or unnecessary noise. Its meaning in the current task helps determine whether it belongs on the screen. A similar treatment of absent information in comparable screens makes the result easier to understand.

The selected viewtemplate determines whether an empty field and its label may be hidden. The technical behavior of hideEmptyFields describes the available configuration.