04b - Patterns and anti-patterns

Info: This article is work in progress and subject to change.

Once you have built a few panels, the same shapes appear over and over. Some of them are habits worth copying — small, repeatable structures that make panels easier to use. Others are habits worth breaking — small mistakes that look reasonable in the Configurator but produce panels that confuse users.

This article catalogues both: a short set of patterns to reach for, and a longer set of anti-patterns to avoid. Each entry is concrete, with the trigger (“when you find yourself doing this”), the fix, and a one-line rationale.

This is not a complete catalogue. As your team’s panels grow, you will discover patterns of your own. Add them to a shared internal document and treat that document as a working extension of this page.

Patterns to reach for

Progressive disclosure

When to use it. When a panel has fields that are only relevant after a parent value is set — for example, a Reason for rejection field that only matters once the user has clicked Reject.

How to build it. Set a Disable condition on the dependent field that is true when the parent value has not been set. Pair it with a Disabled message explaining what the parent step is.

Example.

• Parent: a Dropdown field decision with values Approved and Rejected
• Dependent: a Text field rejectionReason
• Disable condition on rejectionReason: NOT decision:Rejected
• Disabled overlay message: Available once the decision is set to Rejected

Why it works. The user is not asked to fill fields they do not need. The disabled state is explained, so the user understands the dependency rather than being puzzled by it.

Confirmation buttons for destructive actions

When to use it. Any time a button changes data on the asset or moves the asset out of the user’s view.

How to build it. Set the button’s Confirmation popup option on, write a clear confirmation message, and put the consequences in the message rather than the button label.

Example.

• Button: an Action with Metadata stamper setting status to Archived
• Display name: Archive this asset
• Confirmation popup: on
• Confirmation message: Archive this asset? It will be removed from the active library and visible only in the Archive folder.

Why it works. The cost of the extra click is small; the cost of an accidental archive is large. The confirmation message also doubles as a low-effort piece of documentation.

Approve / Reject preset

When to use it. Any decision panel that needs a final yes-or-no step.

How to build it. Use a Grid x2 row with two Metadata stamper buttons in it. The Approve button stamps the success values; the Reject button stamps the rejection values, ideally including a timestamp.

Example.

The {user} and {today} substitutions are filled in by the Workflow Assistant at click time.

Why it works. It compresses a multi-step decision into one click per option, and the metadata stamp leaves a clean audit trail.

A leading Notification that names the workflow

When to use it. On every panel, in the top section.

How to build it. Add a Notification of message type Info to the top of the most-used tab. Set its Display condition so it appears only when the user is on the panel for the first time, or when the asset selection does not yet match what the panel is for.

Example.

• Notification text: Image details panel — review and update the credit, then click Show all images by this credit to find related assets.
• Display condition: assetDomain:image
• Applies to: Image, plus No asset so it shows on first load

Why it works. It tells users where they are. New users orient faster. Returning users skim it once and ignore it. The cost is one component; the benefit is every one of them stops asking “what is this for?”

One section per task

When to use it. Always, when designing a tab.

How to build it. Each section solves one user task end-to-end. Give the section a label that names the task and a description that summarises what completing the task involves.

Example. A panel with three sections:

• Research brief reference — read-only details about a brief for photo researchers
• Assign to photo researcher — the only place a packager is selected
• Find related briefs — buttons that run queries against the brief metadata

Why it works. Users learn the panel by reading section labels first. Tasks named clearly become skimmable.

Field hint as living documentation

When to use it. On every Field that has a non-obvious meaning, format, or business rule.

How to build it. Set the field’s Hint to a one-sentence explanation. The user sees the hint on hover.

Example.

• Field: cf_productCode
• Hint: Product code from the project plan — three letters, four digits, no spaces

Why it works. The hint catches users in the moment they need help. It is read more often than any external documentation.

Anti-patterns to avoid

The catch-all “everything” panel

Trigger. A single tab that contains every metadata field your users have ever asked for.

Why it fails. Long tabs are skimmed, not read. Fields buried in a long list are missed. The panel becomes a list view, not a workflow tool.

Fix. Split into multiple tabs by audience or task. The Quick Start panel has one tab on purpose; large panels rarely should.

Mixing audience groups in one tab

Trigger. A tab that contains both editor-facing fields and reviewer-facing fields, both visible to both audiences.

Why it fails. Each audience sees fields meant for the other and either touches them by accident or learns to ignore them — at which point they ignore the wrong ones too.

Fix. Use separate tabs with audience targeting (the groupMapping setting). The reviewer tab is shown only to the reviewer group; the editor tab only to editors.

Relying on disable rather than visibility

Trigger. Every component on the panel is visible, but most are disabled most of the time. The user sees a sea of greyed-out controls.

Why it fails. Disabled controls are visual clutter. They imply “you cannot do this now” instead of “this is not relevant to you.” Long lists of disabled fields make the few enabled ones harder to find.

Fix. Hide what does not apply, using the visibility checklist or a Lucene visibility condition. Disable only when the field is genuinely sometimes-editable for the same user — for example, locked while the asset is in Final review.

Silent regex and silent disable

Trigger. A field with a strict pattern but no pattern message. A disabled button with no disabled message. A required field with no required message.

Why it fails. The user is told something is wrong but not what to do about it. They guess, retry, and eventually open a support ticket.

Fix. Every regex pattern needs a Pattern message. Every disable condition needs a Disabled message. Every required condition needs a Required message. Make the message specific: what is wrong, and what to do.

A non-existent technical field name

Trigger. Pasting or hand-typing a Field name that does not exist in your Assets installation. Most often happens when copying from another configuration without checking the target schema.

Why it fails. The Workflow Assistant errors when an end user opens the panel. The error is not always visible to the admin — it appears in the user’s panel.

Fix. Always pick the Field name from the autocomplete dropdown. If a field you need is not in the autocomplete, the Assets schema does not have it — work with your Assets administrator to create it before referencing it.

A button that always works, including when no asset is selected

Trigger. Setting Always on on every button, including buttons that depend on a selected asset.

Why it fails. The user clicks the button with no asset selected and gets either an error or silent nothing. Both are confusing.

Fix. Reserve Always on for navigation actions and global widgets. For any button that operates on the selection, leave Always on off. Pair the off state with a useful disabled message: “Select an asset first.”

A Notification that fires for every selection

Trigger. A Notification with no display condition, or a display condition that is always true.

Why it fails. Notifications that always show stop being notifications and become decoration. Users learn to ignore them, and the next genuinely important Notification is ignored too.

Fix. Every Notification needs a meaningful display condition. If a message should always be visible, it is probably a section description, not a Notification.

A panel that has not been tested as a non-admin

Trigger. Publishing without ever signing in as a test user.

Why it fails. Many problems are invisible from the admin side: visibility rules that hide nothing because admins are in every group, conditions that always pass for admins, fields that admins can edit even when the panel is meant to disable them.

Fix. Always verify as a test user, in a different browser window, on real assets in a test folder. The Quick Start tutorial walks through this rhythm; make it a habit.

Where to go from here

• 04a — A design methodology — the principles that produce these patterns
• 05c — Notifications reference — the component most often under-used in panels
• 06 — Visibility, disabling, and validation — the technical material behind the silent-regex and silent-disable anti-patterns
• 09 — Testing, publishing, and rollback — the operational habits behind “test as a non-admin” and “use rollback freely”

Revisions

• 8 May 2026: First publication of the manual