Show Menu
TOPICS×

Migration to the Touch UI

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 Marketing 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 you will need to take action to migrate your instance. This page is intended to act as a springboard by providing links to individual resources.
Such a migration project may have significant impact on your instance. See Managing Projects - Best Practices for recommended guidelines.

The Basics

When migrating you should be aware of the following (major) differences between the classic and touch UI:
Classic UI Touch-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 porting 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 will provide a solid basis:

Migrating Page Authoring

Dialogs are a major factor when migrating your components:

Migrating Consoles

You can also costomize the consoles:

Further Resources

For full information on developing AEM see the collection of resources under:
AEM Modernization Tools are a community effort and are not supported or warrantied by Adobe.