Concepts of the AEM Touch-Enabled UI concepts-of-the-aem-touch-enabled-ui

With AEM 5.6 Adobe introduced a new touch-enabled UI with responsive design for the author environment. This differs considerably from the original classic UI as it is designed to operate on both touch and desktop devices.

This touch-enabled UI is now the standard UI for AEM, superseding the classic UI.

The touch-enabled UI includes:

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

The basic principles of the touch-enabled UI are:

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

AEM Technology Stack aem-technology-stack

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

Granite granite

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

Granite UI granite-ui

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

These adhere to the requirements:

The Granite UI:

Client Side vs Server Side 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

Client-Side 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, asyncronously 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 fulfil 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 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 located in the Granite repository at:

/libs/granite/ui/components/foundation

This is delivered as part of the content package:

granite.ui.content

Differences with the Classic UI differences-with-the-classic-ui

The differences between Granite UI and ExtJS (used for the classic UI) are also of interest:

Granite UI Foundation Components granite-ui-foundation-components

The Granite UI foundation components provide the basic building blocks needed for building any UI. They include, amongst others:

The foundation components can be found under:

/libs/granite/ui/components/foundation

This library contains a Granite UI component for each Coral element. A component is content driven, with its configuration residing in the repository. This makes it possible to compose a Granite UI application without writing HTML markup by hand.

Purpose:

Implementation:

This library of foundation components can be used or extended by other libraries.

ExtJS and Corresponding Granite UI Components extjs-and-corresponding-granite-ui-components

When upgrading ExtJS code to use the Granite UI, the following list provides a convenient overview of ExtJS xtypes and node types with their equivalent Granite UI resource types.

Granite UI Administration Components granite-ui-administration-components

The Granite UI administration components build on the foundation components to provide generic building blocks that any administration application can implement. These include, amongst others:

Purpose:

Implementation:

Coral UI coral-ui

Coral UI (CUI) is an implementation of Adobe’s visual style for the touch-enabled UI, that has been designed to provide consistency in the user experience across multiple products. Coral UI provides everything you need to adopt the visual style used on the authoring environment.

The Coral UI is a collection of building blocks for developing web applications.

Designed to be modular from the start, each module forms a distinct layer based on its primary role. Although the layers have been designed to support each other, they can also be used independently if needed. This makes it possible to implement Coral’s user experience in any HTML-capable environment.

With the Coral UI it is not mandatory to use a particular development model and/or platform. The primary goal of Coral is to provide unified and clean HTML5 markup, independent of the actual method used to emit this markup. This might be used for client or server-side rendering, templates, JSP, PHP, or even Adobe Flash RIA applications - to name just a few.

HTML Elements - The Markup Layer html-elements-the-markup-layer

The HTML elements provide a common look and feel for all base UI elements (including navigation bar, button, menu, rail, amongst others).

At the most basic level, a HTML element is a HTML tag with a dedicated class name. More complex elements can be composed of multiple tags, nested inside each other (in a specific manner).

The CSS is used to provide the actual look and feel. To make it possible to easily customize the look-and-feel (e.g. for the case of branding) actual style values are declared as variables that are expanded by the LESS pre-processor during runtime.

Purpose:

Implementation:

For example, the markup:

<button class="btn btn-large btn-primary" type="button">Large button</button>
<button class="btn btn-large" type="button">Large button</button>

Is displayed as:

The look-and-feel is defined in LESS, tied to an element by dedicated class name (the following extract has been shortened for the sake of brevity):

.btn {
    font-size: @baseFontSize;
    line-height: @baseLineHeight;
    .buttonBackground(@btnBackground,
                                @btnBackgroundHighlight,
                                @grayDark, 0 1px 1px rgba(255,255,255,.75));

Actual values are defined in a LESS variable file (the following extract has been shortened for the sake of brevity):

@btnBackgroundHighlight: darken(@white, 10%);
@btnPrimaryBackgroundHighlight: spin(@btnPrimaryBackground, 20%);
@baseFontSize: 17px;
@baseFontFamily: @sansFontFamily;

Element Plugins element-plugins

Many of the HTML elements will need to exhibit some sort of dynamic behavior, such as opening and closing pop-up menus. This is the role of the element plugins, which accomplish such tasks by manipulating the DOM using JavaScript.

A plugin is either:

Plugin behavior can be customized with parameters, by either:

Though the developer can select the best approach for any plugin, the rule of thumb is to use:

The same concept is used to implement form validation. For an element that you want validated, you must specify the required input form as a custom data-* attribute. This attribute is then used as an option for a validation plugin.

Purpose:

Implementation:

An extract of example markup (note the options specified as data-* attributes):

<ul data-column-width="220" data-layout="card" class="cards">
  <li class="item">
    <div class="thumbnail">
      <img href="/a.html" src="/a.thumb.319.319..png">
      <div class="caption">
        <h4>Toolbar</h4>
          <p><small>toolbar</small><br></p>
      </div>
    </div>
  </li>
  <li class="item">
    <div class="thumbnail">
      <img href="/a.html" src="/a.thumb.319.319..png">
      <div class="caption">
        <h4>Toolbar</h4>
        <p><small>toolbar</small><br></p>
      </div>
    </div>
  </li>

The call to the jQuery plugin:

$(‘.cards’).cardlayout ();

This will show as:

The cardLayout plugin lays out the enclosed UL elements based on their respective heights and also taking the parent’s width into consideration.

HTML Elements Widgets html-elements-widgets

A widget combines one or more basic elements with a javascript plugin to form “higher level” UI elements. These can implement more complex behavior and also a more complex look and feel than a single element could deliver. Good examples are the tag-picker or rail widgets.

A widget can both trigger and listen to custom events to cooperate with other widgets on the page. Some widgets are actually native jQuery widgets that use the Coral HTML elements.

Purpose:

Implementation:

Example markup is:

<input type="text" name="tags" placeholder="Tags" class="tagManager"/>

The call to the jQuery plugin (with options):

$(".tagManager").tagsManager({
        prefilled: ["Pisa", "Rome"] })

The plugin emits HTML markup (this markup uses basic elements, which may use other plugins internally):

<span>Pisa</span>
<a title="Removing tag" tagidtoremove="0"
   id="myRemover_0" class="myTagRemover" href="#">x</a></span>

<span id="myTag_1" class="myTag"><span>Rome</span>
<a title="Removing tag" tagidtoremove="1"
   id="myRemover_1" class="myTagRemover" href="#">x</a></span>

<input type="text" data-original-title="" class="input-medium tagManager"
       placeholder="Tags" name="tags" data-provide="typeahead" data-items="6"
       autocomplete="off">

This will show as:

Utility Library utility-library

This library is a collection of javascript helper plugins and/or functions that are:

These include XSS handling and the event bus.

Although the HTML element plugins and widgets may rely on functionality provided by the utility library, the utility library cannot have any hard dependency on the elements nor widgets themselves.

Purpose:

Implementation: