AEM 6 has been released, and with it comes an extension of the thin veneer known as “Touch-optimized UI.” In AEM 5.6, the Touch UI was limited to just the consoles; upon entering a page for content editing, one was greeted with the tried-and-true “Classic UI” interface.
In AEM 6, Touch UI has been extended to provide an entire alternate user interface for authoring content. The “What’s New in AEM 6.0” video released by Adobe shows the ease of editing pages with a tablet thanks to this new UI. Let’s skip altogether the conversation around the merits of what benefits that may provide and just assume that you, the content author, will be performing your AEM content authoring on a desktop operating system. The implementation of Touch UI in AEM 6 is troublesome at best, and we’re calling it out so that those in search of help know that they are not alone and not misusing the tool.
Selecting your preferred UI
Let’s begin by taking a look at the Welcome screen in AEM 6:
This is essentially the same as the default 5.6.1 Welcome screen with a few additional consoles. The “desktop” icon shown when hovering over the Projects or Sites consoles allows you to switch to Classic UI, also a carry-over from 5.6.1.
So far, nothing alarming. Let’s assume you switch to Classic UI right away, and dive into the Web Admin console to open up a page for editing. Here’s what you’ll see:
Despite selecting Classic UI at the console level, AEM 6 reverts to Touch UI for page editing. A few initial notes about this new UI:
- There is no Sidekick.
- The content finder now contains a Components tab to add new content
- The remaining tools available are found in the gray bar across the top in two drop-down menus:
Already you may be feeling handcuffed in comparison to the toolset you’ve grown accustomed to in the Sidekick. What’s more, the tools in the second dropdown are unlabeled and unfamiliar icons, making it even more difficult to discern what your available actions are. Lastly, because it’s irrelevant to touchscreen devices, the contextual (right-click) menu has been eliminated altogether.
“But wait! There’s a Classic UI option right there!”
Thankfully, there is. Unfortunately, the switch only lasts for your interaction with the current page. The next page you open will return you once again to the Touch UI.
“But users can select their preferred UI in User Preferences.”
This is true for 5.6.1. Let’s check it out in 6.0:
The “Authoring Mode” field is available in User Preferences. But not only has Touch UI taken over as the default, it is the only available option.
Let’s give the benefit of the doubt and assume this is either an initial release bug or a minor system configuration, and that users will eventually be able to change their preferred UI. What’s the big deal about switching to Classic UI? How bad can Touch UI be?
What follows are several author interactions in Touch UI that, after half a decade of content authoring, solution design, and author training for AEM/CQ, I struggled to grasp or execute in AEM 6 Touch UI.
Identifying Parsys & Components
At a glance, are you able to discern how many parsys and how many empty components are currently on the page above?
When a new component is added to the page, it takes on the same (ultra-low contrast) styling as a parsys, making the structure of your content difficult to perceive without hovering over elements:
Another issue worth mentioning is that because the contextual (right-click) menu is eliminated from Touch UI, there is no longer the ability to use a parsys to add a new component. This is a subtle change, but an inconvenience nonetheless.
Editing an Existing Component
Because the UI is designed for touch interactions, the contextual (right-click) menu is completely eliminated from the interface. Instead, a single click now enables you to edit a component on the page. The selected component is outlined in blue below:
At a glance, are you able to discern how to edit, cut, copy, paste, or delete this component?
Probably not, because the controls to do so only appear above the component, regardless of your current position on the page. Scrolling up reveals the controls in a gray bar above the component:
Again we’re greeted with a set of unlabeled, unfamiliar icons from which we must infer what our available actions might be.
Working with an Edit Dialog
An edit dialog can have many different levels of complexity, and (depending on the cleverness of the developer who designed it) may require some adjustment by the author in order to comfortably interact with it.
But in Touch UI, a single one-size-fits-all dialog overlay appears, with no ability to click-and-drag the edges (since that interaction would be difficult to impossible for a touchscreen user). Here’s what the initial state of the Page Properties dialog looks like:
Is the thumbnail image the primary reason you’d open Page Properties? And with no visible interface elements to indicate the ability to scroll, would you be certain you’ve opened the Page Properties dialog you’d expected?
The dialog can be expanded to full-screen, however, if you’d like to be completely removed from the context of the page you’re on:
Populating a Pathfield
The pathfield is one of the most ubiquitous edit dialog fields in AEM. It is what allows authors to configure hyperlinks, both internal and external. Let’s see what pathfields look like in Touch UI:
At a glance, are you able to discern the pathfield from the textfields in this dialog?
If you thought the (i) symbol might denote the ability to browse, you’d be mistaken. This is simply the new implementation of field descriptions, which appear on hover/touch of the symbol. Let’s see what the “Link to” field is telling us:
Okay, so no browsing within the dialog, I need to use the content finder now. Fine, I can adapt. Let’s browse the content finder to add a CQ page to the field:
I see Assets. I see the types of items in the system available to me as assets. I see Components. I do not see the ability to browse to pages via the content finder.
As of my writing this, I have no idea of how one might browse to select a CQ page in a pathfield in Touch UI. The only method I could find to link a CQ page at all was to begin manually typing local paths and letting the field show me its child pages:
Why Not Both?
The only way I can see Touch UI becoming adoptable by desktop/notebook users is if certain interactions (i.e. using a contextual menu) remain intact. To me, this is not a “Touch-optimized UI,” it’s a “Touch-only UI.” Eliminating interactions altogether simply because they’re not relevant to touch users is a destructive form of change. If this is how it must be, then the Touch UI should be device-specific, and Classic UI should be the default desktop OS author experience.
If you have questions about authoring in AEM 6, leave them in the comments below and our thought leaders at Six Dimensions will help guide you through the transition brought on by this major release.