AEM | Touch UI – What and Why?


Adobe introduced a new touch-optimized UI with AEM 5.6 for the author environment. This differs considerably from the original classic UI as it is designed to operate on both touch and desktop devices. The basic principles of the touch-optimized UI are:

  • Mobile first (with desktop in mind)
  • Responsive design
  • Context relevant display
  • Reusable
  • Include embedded reference documentation
  • Include embedded tests
  • Bottom-up design to ensure these principles are applied to every element and component

Classic UI versus Touch UI

ExtJS Granite UI
Remote Procedure Call State Transistions
Data transfer objects Hypermedia
Client knows server internals Client does not know internals
“Fat client” “Thin client”
Specialized client libraries Universal client libraries

Are we going away from Classic UI?

AEM is gradually migrating existing layouts/modules to Touch UI, but at the current point in time some UI’s are still on classic (original) UI (eg. design dialog). Adobe will continue supporting Classic UI in near future.

Configuring which UI to use

AEM provides you with the capability to configure your account and certain aspects of the author environment to set default Authoring mode ie. Classic UI or Touch UI. Please see

Will there be any change for Authors/Testers?

Yes. Touch UI is more editor friendly UI, easy to navigation, easy to use, responsive and touch supported. S0 Basic workflow will change for authors to adapt to new Touch UI.

Will there be any change for developers?

Developer needs to make sure that their components are using Touch UI dialog along with Classic Dialog. If you are trying to enable existing components to support Touch UI, then follow following practice:

  1. Use Dialog Conversion tool to convert existing EXTJS dialogs to Touch Dialogs.
  2. For any customization you did in Classic dialog (custom xtypes) you need similar widget for Touch UI.
  3. It’s not necessary that Claasic UI & Touch UI dialog is always same (classic ui dialog can have multiple tabs, but for touch ui, you can have all fields in same tabs), but in ideal case they should be.
  4. Unlike Classic UI, Touch UI build complete dialog in single request (all cq:include) and return complete dialog html.
  5. Use/Create Datasource to dynamically populate any element value in Touch UI dialog.
  6. Show/Hide rules in touch ui is simplified, can be done by adding some class name in dialog’s attribute property, and is managed by Jquery. Please see
  7. Custom Show/Hide rules can be easily created and used by creating clientlibs.
  8. If a component dont have Touch dialog, then classic dialog will be used in Touch UI.
  9. Limitation: Design Dialog’s still use EXT dialog in Touch mode.
  10. Issue: EditConfig’s actions is a known issue in touch ui (confirmed with AEM Team also). They have not defined action in any touch supported component :(. editannotate action do not work in touch.
  11. It will take some time to adopt Touch UI, but once u get used to of it, you will love Touch UI.

Touch UI Components

AEM 6 OOB provide several components created to support Touch UI. These components are located at /libs/granite/ui/components/foundation

EXTJS v/s Touch UI Components vs matching Granite UI components



2 thoughts on “AEM | Touch UI – What and Why?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s