Académique Documents
Professionnel Documents
Culture Documents
With AEM 5.6 Adobe has introduced a new touch-optimized 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.
The touch-optimized UI includes:
the suite header or global navigation bar that:
shows the logo
provides a link to the Marketing Cloud
indicates which console you are currently using
the left-hand rail, which is context sensitive and can show:
navigation between the various consoles
a powerful search dialog with various criteria
access to workflows
the content header / action bar, which is again context sensitive and can show either:
information about the current page or asset that you are viewing
icons to represent actions that can be taken on the current/selected page or asset
the content area that:
lists the items of content (be they pages, assets, forum posts, etc)
can be formatted as requested, e.g. 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 ine one window)
NOTE
Although all functionality is available, at the current point in time some still reverts to the classic
(original) UI.
The touch-optimized 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 their touch-optimized UI. The Coral UI
provides everything your product / project / web application needs to adopt the UI visual style.
2012 Adobe Systems Incorporated.
All rights reserved.
Page 1
Created on 2015-01-09
Granite
Granite is Adobe's Open Web stack, providing various components including:
An application launcher
An OSGi framework into which everything is deployed
A number of 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 we draw 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
2012 Adobe Systems Incorporated.
All rights reserved.
Page 2
Created on 2015-01-09
be easy to override
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
Page 3
Created on 2015-01-09
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
ExtJS
Granite UI
State Transistions
Hypermedia
"Fat client"
"Thin client"
Page 4
Created on 2015-01-09
Purpose:
Unified look-and-feel for administration applications
RAD for administration applications
Implementation:
Pre-defined components using the foundation components
Components can be customize
Coral UI
Coral UI (CUI) is an implementation of Adobe's visual style for their touch-optimized UI, that has been
designed to provide consistency in the user experience across multiple products. The Coral UI provides
everything you need to adopt the visual style used on the authoring environment.
CAUTION
Coral UI is a UI library made available to AEM customers for building applications and web
interfaces within the boundaries of their licensed use of the product.
Use of Coral UI is only permitted:
When it has been shipped and bundled with AEM.
For use when extending the existing UI of the authoring environment.
Adobe corporate collateral, ads, and presentations.
The UI of Adobe-branded applications (the font must not be readily available for other uses).
With minor customizations.
Use of Coral UI should be avoided in:
Documents and other items not related to Adobe.
Content-creation environments (where the preceding items might be
generated by others).
Applications/components/web pages that are not clearly connected to Adobe.
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 Corals 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.
Page 5
Created on 2015-01-09
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-andfeel (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:
Provide basic UI elements with a common look-and-feel
Provide the default grid system
Implementation:
HTML tags with styles inspired by bootstrap
Classes are defined in LESS files
Icons are defined as font sprites
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
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:
designed to operate on a specific DOM element; for example, a dialog plugin expects to find DIV
class=dialog
generic in nature; for example, a layout manager provides layout for any list of DIV or LI elements
Plugin behavior can be customized with parameters, by either:
passing the parameters by means of a javascript call
using dedicated data-* attributes tied to the HTML markup
Though the developer can select the best approach for any plugin, the rule of thumb is to use:
data-* attributes for options related to HTML layout (for example, to specify the number of columns)
API options/classes for functionality related to data (for example, constructing the list of items to display)
2012 Adobe Systems Incorporated.
All rights reserved.
Page 6
Created on 2015-01-09
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.
NOTE
HTML5-native form validation should be used whenever possible and/or expanded upon.
Purpose:
Provide dynamic behavior for HTML Elements
Provide custom layouts not possible with pure CSS
Perform form validation
Perform advanced DOM manipulation
Implementation:
jQuery plugin, tied to specific DOM element(s)
Using data-* attributes to customize behavior
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 cardLayout plugin lays out the enclosed UL elements based on their respective heights and also taking
the parents width into consideration.
Page 7
Created on 2015-01-09
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:
Implement higher level UI elements exhibiting complex behavior
triggering and handling events
Implementation:
jQuery plugin + HTML markup
Can utilize client/server side templates
Example markup is:
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">
UTILITY LIBRARY
This library is a collection of javascript helper plugins and/or functions that are:
UI independent
Yet crucial for building full featured web applications
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:
Provide common functionality
Event bus implementation
Client-side templates
XSS
Implementation:
jQuery plugins or AMD-compliant JavaScript modules
Page 8
Created on 2015-01-09