CIRCUIT

Building Custom AEM Widgets for the Touch UI Content Finder

Adobe Experience Manager’s Touch UI Content Finder can become much more than a place to browse images and pages. With a carefully designed custom widget, authors can discover structured content, inspect metadata, locate approved campaign assets, or send selected items into a component dialog without leaving the page editor.

For AEM teams in Australia, this is especially useful when content operations span Sydney, Melbourne, Brisbane, Perth and regional offices. A well-built finder can reduce authoring friction across time zones, support local approval workflows and make large DAM repositories easier to navigate for marketing and publishing teams.

The implementation sits at the intersection of Coral UI, Granite UI, client-side JavaScript, Sling endpoints and AEM’s authoring framework. The most reliable approach is to treat the widget as a small product: define its author experience first, then connect it to secure, searchable and version-appropriate back-end services.

Define The Authoring Use Case

Start by identifying what authors need to find and what should happen after they select an item. A media finder may return an asset path, title, rendition or metadata value. A product finder might return a content fragment, SKU, URL and market designation. These outcomes require different search fields, result cards and selection behaviours.

The widget should also have a clear relationship with the current component. A context-aware finder can read the active page, component resource type, locale or campaign identifier. This makes it possible to filter results for a particular site section rather than presenting an unstructured repository-wide search.

Australian organisations often manage separate content for states, territories and national campaigns. A finder that exposes market, language, publication status and rights metadata can prevent a Melbourne promotion from being inserted into a Queensland page or an expired image from appearing in a national campaign.

Use Supported AEM Extension Points

Touch UI customisation should be isolated under /apps and deployed as code, rather than modifying product files beneath /libs. The exact extension mechanism varies across AEM versions and service packs, so inspect the target platform’s authoring APIs before choosing a registration point. A pattern that works in an older on-premise release may require adjustment for AEM as a Cloud Service.

A typical solution combines a client library, a Coral-based interface and a server-side endpoint. The client library registers the finder or rail control with the authoring interface, renders search and result states, and passes the selected value back to the active editor. The endpoint uses Sling Models, QueryBuilder, Oak queries or a dedicated search service to return only permitted results.

Avoid relying on private JavaScript objects simply because they are visible in browser developer tools. Internal namespaces can change during upgrades, and a fragile hook may fail after a cumulative fix pack. Keep the integration layer small, document the AEM versions it supports and test it against the actual authoring shell used by the project.

Build A Clear Coral UI Widget

Coral UI provides the visual language for fields, buttons, icons, overlays, tables and feedback messages in the Touch UI. A custom content finder should look native: use familiar spacing, consistent button placement and the same loading, empty and error states authors see elsewhere in AEM.

A practical layout usually includes a search field, optional filters, a result area and a selection action. Result cards should expose the information needed for a confident choice, such as thumbnail, title, path, last modified date, content type and approval status. If several records share a similar name, display a distinctive identifier rather than forcing authors to open each result.

Accessibility must be part of the component rather than a later repair. Provide keyboard support, visible focus states, meaningful labels and announcements for loading or failed searches. This matters for Australian government, education and enterprise projects that commonly work against WCAG requirements and formal procurement standards.

Connect Search To Secure Data

The front end should call a purpose-built Sling servlet or service endpoint instead of querying repository internals directly. The service can validate parameters, impose result limits, apply user permissions and return a stable JSON contract. Keep the response intentionally small so a search does not transfer unnecessary metadata or binary information.

Search logic should reflect how the repository is governed. Use tags, content fragments, DAM metadata, publication status and business identifiers to narrow results. For larger repositories, consider Oak indexes or an external search platform rather than repeatedly executing broad repository queries from the authoring interface.

Permission handling is essential. A widget must never reveal restricted paths, unpublished records or sensitive metadata merely because the requesting user can access the authoring shell. Test with administrators, ordinary authors, reviewers and users who have access to only one site or region.

Manage Selection And Authoring State

Selection behaviour is where a useful finder becomes part of the editing workflow. Decide whether the widget inserts a path, opens a dialog, populates a multifield, creates a reference or launches a detail view. The selected value should be validated before it reaches the component, and the component should remain usable when no result is selected.

When the author changes pages, switches components or closes the side panel, the widget must clean up event listeners and stale state. Otherwise, a selection made for one component can accidentally be applied to another. This is particularly important when authors work quickly across long pages or use multiple browser tabs during campaign production.

Support empty, loading, failed and permission-denied states with plain language. A message such as “No approved assets match these filters” is more useful than a generic error. Include retry handling for temporary failures and preserve the search term where possible so authors do not have to start again.

Test For Performance And Upgrades

A content finder is used repeatedly, so small delays become expensive across a large publishing team. Debounce search requests, paginate results and avoid loading full-resolution images into the rail. Use thumbnails and lazy loading, while ensuring that the result remains understandable if an image is unavailable.

Test the widget on the browsers and screen sizes used by the organisation, including managed corporate devices and lower-bandwidth connections. This is relevant for Australian teams working between metropolitan offices and regional locations, where network performance can vary. A finder that feels fast in a local Sydney development environment may behave differently over a remote office connection.

Include authoring regression tests in each AEM upgrade cycle. Check registration, search permissions, selection persistence, dialog integration and keyboard operation after changes to the service pack or Cloud Manager pipeline. For teams exploring serverless processing, the conference material on AEM and AWS Lambda offers useful context for separating asynchronous work from the authoring request.

Practical Recommendations

Treat the widget as a governed extension rather than a quick authoring shortcut. Define ownership for its endpoint, client library, index configuration and metadata model. Establish who approves changes when a marketing team in Brisbane needs a new filter or when a Perth team introduces a regional asset taxonomy.

Before production release, document the supported AEM version, repository assumptions, permission model and fallback behaviour. Teams planning an event, workshop or internal technical review can also consult the event FAQ for practical information about the CIRCUIT conference and its AEM-focused sessions.

  • Keep product overlays out of /libs and package custom code beneath /apps.
  • Return a small, documented JSON response with stable field names.
  • Enforce permissions and business filters on the server, not only in JavaScript.
  • Design Coral UI states for keyboard, screen-reader and low-bandwidth users.
  • Measure search latency and review the widget during every AEM upgrade.

Prepare For Australian Delivery

Localisation should cover more than date formatting. Decide how the widget handles Australian English, local time zones, state-based metadata, campaign ownership and asset rights. If a result displays a modified date, make the format unambiguous and consider whether authors need AEST, AEDT or the repository’s server time.

Large Australian organisations may operate separate domains for consumer, government, education and partner audiences. The finder should make the site or market explicit when a shared repository contains material for several brands. It can also display a content owner or approval team, helping authors route questions without searching through separate systems.

Operational planning matters as well. Define a support path for failed searches, stale indexes and permission disputes, and record the extension in the platform’s architecture documentation. Registration and event information can be checked through the CIRCUIT registration page, while recorded technical sessions can help teams compare implementation patterns before committing to a custom framework.

A successful Touch UI widget is quiet, predictable and closely aligned with the repository’s governance. Build a small proof of concept around one authoring task, validate it with users in different Australian offices, then expand the search model only after the selection workflow is reliable. That disciplined path gives AEM developers a maintainable extension that improves content discovery without compromising security, accessibility or upgrade readiness.