Designing Custom Widgets for AEM Touch UI Dialogs

Strong authoring tools let content teams publish without wrestling with unfamiliar forms. This guide examines AEM Touch UI Dialogs: Designing Custom Widgets for Content Authors from both sides of the screen: the interaction an editor sees and the components, client-side behaviour and APIs behind it. A useful widget reduces friction while preserving governance and technical control.

At the platform level, a Touch UI dialog is more than a form. It is a JSON-defined interface built from Granite UI and Coral patterns, with fields supplied by component structure and enhanced through client-side code. A custom widget is a product component with a visible contract, dependencies, failure states and a maintenance owner, not merely a script added to a dialog.

Australian implementations add constraints. Publishing teams are distributed across Sydney, Melbourne and Brisbane, so dialogs must remain quick on varying devices and connections. Authors expect Australian English, day-first dates such as 08/04/2026, decimal points and familiar address formats. Canberra public-sector and enterprise projects also bring accessibility, procurement and audit expectations into design and release governance.

CIRCUIT is valuable because it treats AEM as an engineering ecosystem rather than a back-office tool. Sessions connected dialog design with Sightly, integrations, microservices, analytics and mobile delivery, while workshops exposed trade-offs behind polished demonstrations. The same mindset helps teams test a field before committing to it and establish shared language between authors, front-end developers, architects and support engineers.

Why author experience is a technical concern

The cost of poor dialog design rarely appears as one defect. Authors abandon unfamiliar controls, enter dates wrongly, publish incomplete metadata or open support tickets when validation is vague. Each workaround consumes editorial time and creates cleanup. Treating these moments as signals turns usability feedback into engineering data rather than an argument between business stakeholders and the development team.

That connection appears in the archived CIRCUIT session agenda, where AEM architecture, integrations and front-end practice sit alongside developer workflows. For a custom-dialog project, trace one author action through the system: where the option list comes from, when it refreshes, which service validates it and what the editor sees if that service cannot respond.

Local content cycles sharpen this point. Australian teams coordinate campaigns for Australia Day, ANZAC Day or Christmas across states, while teams in Perth and Adelaide may update the same asset after eastern-state deadlines. A fixed date order, hidden approval field or forced full refresh can slow that work. Clear labels, sensible defaults and non-destructive validation make cross-city publishing more predictable.

Designing clear Touch UI interactions

Design each field around one author decision. Start with a plain-language label, add help only where it changes behaviour, and make required or conditional states visible before submission. Group related fields into meaningful sections, use consistent controls for similar data and reserve summaries for information reviewed together. Placeholders can show an example, but they should not carry labels or instructions that disappear during typing.

Conditional workflows need careful feedback. If a campaign type changes available channels, update dependent fields immediately and explain what happened. Moving focus unexpectedly, clearing valid entries or revealing a new required field only after submission creates distrust. Test keyboard order, focus visibility, error association and screen-reader announcements as rigorously as layout, especially where Australian Government and regulated-sector buyers expect WCAG-aligned experiences.

Localised formatting belongs in the design, not a final translation task. An Australian date field may accept 08/04/2026 while storing an unambiguous ISO value; phone and suburb fields may need country and state context. Preview how entered content will appear, and use plain wording for downstream constraints. Help an author make a correct decision once rather than repairing the result in production.

Building a maintainable custom widget

Implementation should follow extension points rather than the easiest shortcut. Keep dialog definitions and field metadata in the project or application layer, reuse established Granite UI and Coral field types where they fit, and place custom behaviour and styles in a versioned client library. This preserves upgradeability, separates source from production assets and makes ownership visible in code review.

Use Sightly or server-side rendering to prepare safe, stable data, but do not make it responsible for interactions needing instant feedback. For asynchronous options, define authentication, permissions, payload validation and timeouts before wiring the control. Render text through safe DOM APIs, escape supplied values and keep secrets or restricted content out of browser storage. Server-side validation remains authoritative; client checks improve the experience without replacing publish-time controls.

Documentation and reusable examples matter as the widget moves between teams. Cross-event references help engineers compare approaches, and the external programme archive illustrates why retaining schedules and supporting material makes conference knowledge useful after an event. In a component library, include the author purpose, supported field states, API dependencies, accessibility notes and an example payload. That package is often more valuable than another one-off implementation.

Performance, caching and failure handling

Custom widgets run inside an authoring console that already makes network requests. Load custom code only where needed, keep assets small and avoid blocking the dialog while data loads. Virtualise long option lists, debounce search-as-you-type, cancel obsolete requests and provide a stable loading state. These choices help authors on constrained connections or older devices and reduce the chance that a third-party script slows every field interaction.

The same discipline applies to content delivery. The CIRCUIT article on mobile caching strategies is useful because it connects client performance with predictable refreshes; an authoring widget should likewise avoid stale metadata and uncontrolled client-side growth. Cache safe reference data with a defined expiry, refresh it deliberately after configuration changes and expose the timestamp to support engineers.

Distributed operations require explicit failure behaviour. An APAC support rotation may span Sydney, Melbourne and Auckland across several time zones, while a regional service can still be unavailable during an Australian working day. Log useful correlation identifiers, distinguish timeout from permission and validation errors, and show a recoverable message with a retry. Track latency and failure rates by widget version so degradation is noticed before it becomes a stream of publishing complaints.

Checks before a widget reaches production

Before release, use a compact review that connects design decisions to observable author outcomes. These checks suit both a small internal site and a large managed platform:

• Define the author decision, its data source and its fallback before writing the field component.
• Make validation specific, recoverable and available without relying on colour or placeholder text.
• Test the complete workflow with keyboard navigation, screen readers, mobile widths and real editorial content.
• Bound remote calls with timeouts, retries, caching rules and logging that avoids sensitive payloads.
• Release assets through a versioned client-library pipeline and name an owner for defects and dependency updates.

Run this review with an editor, a front-end developer and an operations representative. Australian teams can include remote colleagues in Brisbane or Perth in the same session, but the test should still use representative data and production-like permissions. Record where the widget removed steps, where it introduced errors and which fields remain outside the component’s contract. Those notes become the acceptance criteria for the next iteration.

Turn one dialog into a measurable pilot

Begin with one field that creates measurable friction, such as a complex asset selector, structured metadata editor or location chooser. Capture the current completion time, validation errors and support contacts, then prototype the smallest workflow that could improve them. Involve the author who performs the task daily, but keep the implementation narrow enough to observe what changes and discard an approach that adds complexity without value.

Use the CIRCUIT agenda archive and session recordings to compare technical patterns, then document the chosen implementation in the project’s component library. Publish the widget to a controlled group, gather evidence and expand only when the agreed outcomes are met. Choose one high-friction field, release a time-boxed pilot, and measure author completion time, validation failures and support requests before extending the approach across the content estate.