AEM | Touch UI – What and Why?

Introduction

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 https://docs.adobe.com/docs/en/aem/6-1/author/author-environment/user-properties.html

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 http://stackoverflow.com/a/25249218/1033836
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

https://docs.adobe.com/docs/en/aem/6-1/develop/the-basics/touch-ui-concepts.html#ExtJS vs matching Granite UI components