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 vs 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 |
Support for 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.
Configure the default UI mode
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
Changes which Author can see
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.
Changes 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:
- Use Dialog Conversion tool to convert existing EXTJS dialogs to Touch Dialogs.
- For any customization you did in Classic dialog (custom xtypes) you need similar widget for Touch UI.
- 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.
- Unlike Classic UI, Touch UI build complete dialog in single request (all cq:include) and return complete dialog html.
- Use/Create Datasource to dynamically populate any element value in Touch UI dialog.
- 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
- Custom Show/Hide rules can be easily created and used by creating clientlibs.
- If a component dont have Touch dialog, then classic dialog will be used in Touch UI.
- Limitation: Design Dialog’s still use EXT dialog in Touch mode.
- 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.
- 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
No comments :
Post a Comment