Concepts of the Adobe Experience Manager Touch-Enabled UI

Last update: April 17, 2024

CREATED FOR:

  • Developer

Adobe Experience Manager (AEM) features a touch-enabled UI with responsive design for the author environment which is designed to operate on both touch and desktop devices.

NOTE
The touch-enabled UI is the standard UI for AEM. The classic UI was deprecated with AEM 6.4.

The touch-enabled UI includes:

  • The suite header that:

    • Shows the logo
    • Provides a link to the Global Navigation
    • Provides link to other generic actions; such as Search, Help, Experience Cloud Solutions, Notifications, and User Settings.

  • The left-hand rail (shown when needed and hidable), which can show:

    • Timeline
    • References
    • Filters

  • The navigation header, which is again context-sensitive and can show:

    • Indicates which console that you are currently using, or your location, or both, within that console
    • Selection for the left-hand rail
    • Breadcrumbs
    • Access to appropriate Create actions
    • View selections

  • The content area that:

    • Lists the items of content (be they pages, assets, forum posts, and so on)
    • Can be formatted as requested, for example, column, card, or list
    • Uses a responsive design (the display resizes automatically according to your device and/or window size)
    • Uses infinite scrolling (no more pagination, all items are listed in one window)

chlimage_1-79

NOTE
Nearly all AEM functionality has been ported to the touch-enabled UI. However, in some limited cases, functionality reverts to the classic UI. See Touch UI Feature Status for more information.

The touch-enabled UI has been designed by Adobe to provide consistency in the user experience across multiple products. It is based on:

  • Coral UI (CUI) an implementation of Adobe’s visual style for the touch-enabled UI. Coral UI provides everything your product / project / web application needs to adopt the UI visual style.
  • Granite UI components are built with Coral UI.

The basic principles of the touch-enabled 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 that these principles are applied to every element and component

For a further overview of the touch-enabled UI structure, see Structure of the AEM Touch-Enabled UI.

AEM Technology Stack

AEM uses the Granite platform as a base and the Granite platform includes, among other things, the Java™ Content Repository.

chlimage_1-80

Granite

Granite is Adobe’s Open Web stack, providing various components including:

  • An application launcher
  • An OSGi framework into which everything is deployed
  • Several OSGi compendium services to support building applications
  • A comprehensive Logging Framework providing various logging APIs
  • The CRX Repository implementation of the JCR API Specification
  • The Apache Sling Web Framework
  • Additional parts of the current CRX product
NOTE
Granite is run as an open development project within Adobe: contributions to the code, discussions, and issues are made from across the entire company.
However, Granite is not an open-source project. It is heavily based on several open-source projects (Apache Sling, Felix, Jackrabbit, and Lucene in particular), but Adobe draws a clear line between what is public and what is internal.

Granite UI

The Granite engineering platform also provides a foundation UI framework. The major goals of this are to:

  • Provide granular UI widgets
  • Implement the UI concepts and illustrate best practices (long lists rendering, lists filtering, object CRUD, CUD wizards…)
  • Provide an extensible and plug-in based administration UI

These adhere to the requirements:

  • Respect “mobile first”
  • Be extensible
  • Be easy to override

chlimage_1-81
GraniteUI.pdf

Get File
The Granite UI:

  • Uses the RESTful architecture of Sling
  • Implements component libraries intended for building content-centric web applications
  • Provides granular UI widgets
  • Provides a default, standardized UI
  • Is extensible
  • Is designed for both mobile and desktop devices (respects mobile first)
  • Can be used in any Granite-based platform/product/project; for example, AEM

chlimage_1-82

Client Side vs Server Side

The client-server communication in the Granite UI consists of hypertext, not objects, so there is no need for the client to understand the business logic

  • The server enriches the HTML with semantic data
  • The client enriches the hypertext with hypermedia (interaction)

chlimage_1-83

Client-Side

This uses an extension of HTML vocabulary, provided so that the author can express their intention to build an interactive webapp. This is a similar approach to WAI-ARIA and microformats.

It primarily consists of a collection of interaction patterns (for example, asynchronously submitting a form) that are interpreted by JS and CSS codes, run on the client-side. The role of the client-side is to enhance the markup (given as the hypermedia affordance by the server) for interactivity.

The client-side is independent of any server technology. As long as the server gives the appropriate markup, the client-side can fulfill its role.

Currently the JS and CSS codes are delivered as Granite clientlibs under the category:

granite.ui.foundation and granite.ui.foundation.admin

These are delivered as part of the content package:

granite.ui.content

Server-Side

This is formed by a collection of sling components that enable the author to compose a webapp fast. The developer develops components, the author assembles the components to be a webapp. The role of the server-side is to give the hypermedia affordance (markup) to the client.

Currently, the components are in the Granite repository at:

/libs/granite/ui/components/foundation

This is delivered as part of the content package:

granite.ui.content