The AEM Touch UI has been available since the release of AEM 5.6. Since AEM 5.6, the majority of the Classic UI feature set has been and will continue to be phased out. At the time of this article (current AEM version 6.5), Adobe’s recommendation is to use Touch UI as the default authoring experience.
Our project had used the AEM Classic UI from its inception in 2015. Our migration path to Touch UI included 150 components and 80 page templates, which required the creation of Touch UI dialogs—no small undertaking!
The Initial Plan
Initially our plan was to:
- Create a separate bundle for migrated components
- Copy the existing components to a separate bundle and migrate them individually
- Make any necessary code changes (bug fixes or features) in both Classic and Touch versions of a given component
- After all the Classic components had their Touch counterparts, use the AEM Bulk Editor or a similar tool to change their sling:resourceType property value to point to the Touch version of a component
- Configure the Touch UI as the default authoring experience in user preferences
After further consideration, we identified several disadvantages with this approach:
- It would take far too long. It would have been necessary to wait until our component library had all of its Touch UI copies before we could switch the default authoring experience.
- It would be far too costly to maintain both Classic and Touch versions, especially in an environment with constant feature changes.
- The AEM Bulk Editor runs on Author. We needed the resource type switch to target Publish. Simple activation of all the pages containing modified components was risky because some in-progress pages might have unexpectedly leaked to Publish.
Discovering a Better Answer: Hybrid Mode
Fortunately, we stumbled upon an excellent AdaptTo 2018 video called Migrating a Large AEM Project to TouchUI (the most valuable part of the talk for us was from 21:40 to 27:46). The discussion inspired us to take an entirely different approach. We discovered that AEM allows Classic authoring dialogs to be opened in the Touch authoring mode. Using this approach, we decided to call Hybrid Mode (see picture 1).
The Hybrid Mode approach enabled us to switch the default authoring experience to Touch UI immediately, without waiting for the lengthy component migration process to be completed. Each development sprint, the Engineering team would release a pack of migrated Touch UI components. Meanwhile, the Authoring team would continue authoring non-migrated components using Hybrid Mode and take advantage of many of the new Touch UI features like Omnisearch, the new Sites console, etc.
The advantages of that approach were clear:
- We could start using Touch UI immediately!
- There was no need to maintain two versions of a component’s authoring dialog during migration. Additionally, we wouldn’t need to use the Bulk Editor tool to substitute the sling:resourceType property. Each development sprint, we could release a fully-migrated component in a controlled and expected manner, which would be immediately available to the Authors. Over several sprints the entire library could be migrated with very little impact on day-to-day publishing operations.
The Devil in the Details
Unfortunately, this approach had some quirks that needed to be addressed with custom workarounds prior to the initial migration of components. We discovered that some pure Classic UI features didn’t work well, if at all, in the Hybrid Mode:
- Image drag-and-drop functionality into the authoring dialogs from the “Side Panel, Assets” tab, didn’t work at all—this was our biggest challenge.
- We ran into several issues with “Page editing” in scaffolding mode.
With a few tweaks and workarounds, we were able to push through the migration process, prioritizing those components which were impacted most by the quirks of the Hybrid Mode. Some of these solutions will be highlighted in future blog posts.
Authors: Denis Glushkov, Matthew Yankelovich