Migration to the Touch UI

Last update: April 17, 2024

CREATED FOR:

  • Developer

Starting with version 6.0, Adobe Experience Manager (AEM) introduced a new user interface referred to as the touch-enabled UI (also known simply as the touch UI). It is aligned to the Adobe Experience Cloud and to the overall Adobe user interface guidelines. This has become the standard UI in AEM with the legacy, desktop-oriented interface referred to as the classic UI.

If you have been using AEM with classic UI, take action to migrate your instance. This page is intended to act as a springboard by providing links to individual resources.

NOTE
Such a migration project may have significant impact on your instance. See Managing Projects - Best Practices for recommended guidelines.

The Basics

When migrating, be aware of the following major differences between the classic and touch UI:

Classic UITouch-Enabled UI
Is described in the JCR repository as a structure of nodes. Every node that represents an element of the UI is called an ExtJS widget and rendered on the client-side by ExtJS.Also described in the JCR repository as a structure of nodes. However, in this case, every node refers to a Sling resource type (Sling component), that is in charge of its rendering. So the UI is (basically) rendered server-side.

sling:resourceType

  • not used

sling:resourceType

  • used
  • for example
    cq/gui/components/authoring/dialog

Dialog nodes:

  • Name: dialog
  • jcr:primaryType: cq:Dialog

Dialog nodes:

  • Name: cq:dialog
  • jcr:primaryType: nt:unstructured

JavaScript location:

  • Imperative parts are directly embedded using listeners or managed in clientlibs.

JavaScript location:

  • Imperative parts cannot be embedded in dialog definition; separation of responsibilities.

Event handling:

  • Dialog widgets directly reference JavaScript code.

Event handling:

  • JavaScript observes dialog events.

Rendering done by the client:

  • Client dynamically creates the UI components.
  • Client requests (Pull) component definition (as JSON) from server.

Rendering done by the server:

  • Client requests pages together with the related UI.
  • The server sends (Push) the UI as HTML documents; using Coral UI components.

In other words, migrating a section of your UI from the classic UI to the touch UI means to port an ExtJS widget to a Sling component. To ease this, the touch UI is based on the Granite UI framework, which already provides some Sling components for the UI (referred to as Granite UI components).

Before you start, check the status and related recommendations:

The basics of developing the touch UI provides a solid basis:

Migrating Page Authoring

Dialogs are a major factor when migrating your components:

Migrating Consoles

You can also customize the consoles:

Although not directly related to a migration to the touch UI, there are related issues that are worth considering at the same time, as they are also recommended practice:

NOTE

Further Resources

For full information on developing AEM see the collection of resources under:

CAUTION
AEM Modernization Tools are a community effort and are not supported or warranted by Adobe.

Experience Manager


B2B Reimagined: Transforming Go-to-Market Strategies for Profitable Growth

Online | Strategy Keynote | General Audience

B2B brands are facing a digital revolution. Buyers expect hyper-relevant content and self-service, while internally AI is transforming...

Wed, Mar 19, 1:00 PM PDT (8:00 PM UTC)

Register

Rapid Feature Releases with AEM Cloud: Telegraph Media Group’s RDE Strategy

Online | Session | Intermediate

Hear how Telegraph Media Group, the award-winning publisher of The Daily Telegraph, The Sunday Telegraph, The Telegraph Magazine,...

Wed, Mar 19, 3:30 PM PDT (10:30 PM UTC)

Register

Connect with Experience League at Summit!

Get front-row access to top sessions, hands-on activities, and networking—wherever you are!

Learn more

Register now