Concepts de l’interface utilisateur tactile d’Adobe Experience Manager concepts-of-the-aem-touch-enabled-ui

Adobe Experience Manager (AEM) dispose d’une interface d’utilisation tactile en responsive design pour l’environnement de création conçue pour fonctionner sur les appareils tactiles et de bureau.

L’interface utilisateur tactile se compose des éléments suivants :

L’interface utilisateur tactile a été conçue par Adobe pour assurer la cohérence de l’expérience client entre plusieurs produits. Elle repose sur les éléments suivants :

Les principes de base de l’interface utilisateur tactile sont les suivants :

Pour une vue d’ensemble plus détaillée de la structure de l’interface utilisateur tactile, consultez Structure de l’interface utilisateur tactile d’AEM.

Pile technologique AEM aem-technology-stack

AEM utilise la plateforme Granite comme base et la plateforme Granite comprend, entre autres, le référentiel de contenu Java™.

Granite granite

Granite est la pile web ouverte d’Adobe, fournissant divers composants, notamment :

IU Granite granite-ui

La plateforme d’ingénierie Granite fournit également un framework d’interface utilisateur de base. Les principaux objectifs de celui-ci sont les suivants :

Ceux-ci répondent aux exigences suivantes :

GraniteUI.pdf

Obtenir le fichier
L’IU Granite :

Côté client et côté serveur client-side-vs-server-side

La communication client-serveur dans l’interface utilisateur Granite se compose d’hypertexte et non d’objets, le client n’a donc pas besoin de comprendre la logique commerciale.

Côté client client-side

Celui-ci utilise une extension du vocabulaire HTML, fournie pour que la personne chargée de la création puisse exprimer son intention de créer une application web interactive. Il s’agit d’une approche similaire à WAI-ARIA et aux microformats.

Il s’agit principalement d’un ensemble de modèles d’interaction (par exemple, la soumission asynchrone d’un formulaire) qui sont interprétés par des codes JS et CSS, exécutés côté client. Le rôle du côté client est d’améliorer le balisage (donné comme capacité hypermédia par le serveur) pour l’interactivité.

Le côté client est indépendant de toute technologie de serveur. Tant que le serveur donne le balisage approprié, le côté client peut remplir son rôle.

Actuellement, les codes JS et CSS sont fournis sous forme de bibliothèques clientes Granite dans la catégorie :

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

Elles sont distribuées dans le cadre du package de contenu :

granite.ui.content

Côté serveur server-side

Cela est formé par un ensemble de composants Sling qui permettent à la personne chargée de la création de composer rapidement une application web. Le développement consiste à développer des composants, la création à assembler les composants pour constituer une application web. Le rôle du côté serveur est de donner la capacité hypermédia (balisage) au client.

Actuellement, les composants se trouvent dans le référentiel Granite à l’adresse :

/libs/granite/ui/components/foundation

Il est distribué dans le cadre du package de contenu :

granite.ui.content

Différences avec l’IU classique differences-with-the-classic-ui

Il est aussi intéressant d’examiner les différences entre l’IU Granite et ExtJS (utilisé pour l’IU classique) :

Composants de base de l’IU Granite granite-ui-foundation-components

Les composants de base de l’interface utilisateur Granite fournissent les éléments de base nécessaires à la création de n’importe quelle interface utilisateur. Ils comprennent entre autres les éléments suivants :

Les composants principaux se trouvent dans :

/libs/granite/ui/components/foundation

Cette bibliothèque contient un composant d’IU Granite pour chaque élément Coral. Un composant est piloté par le contenu, sa configuration résidant dans le référentiel. Cela permet de composer une application IU Granite sans écrire manuellement de balises HTML.

Objectif :

Mise en œuvre :

Cette bibliothèque de composants de base peut être utilisée ou étendue par d’autres bibliothèques.

ExtJS et composants d’interface utilisateur Granite correspondants extjs-and-corresponding-granite-ui-components

Lors de la mise à niveau du code ExtJS pour utiliser l’IU Granite, la liste suivante fournit une vue d’ensemble pratique des xtypes ExtJS et des types de nœuds avec les types de ressources équivalents dans l’IU Granite.

Composants d’administration de l’IU Granite granite-ui-administration-components

Les composants d’administration de l’IU Granite dépendent des composants de base pour fournir les éléments génériques que toute application d’administration peut implémenter. Il peut s’agir, entre autres :

Objectif :

Mise en œuvre :

IU Coral coral-ui

CoralUI.pdf

Obtenir le fichier
L’interface utilisateur Coral (CUI) est une implémentation du style visuel d’Adobe pour l’interface utilisateur tactile. Elle a été conçue par Adobe pour garantir une expérience client homogène entre plusieurs produits. L’IU Coral fournit tout ce dont vous avez besoin pour adopter le style visuel utilisé dans l’environnement de création.

L’IU Coral est un ensemble de composantes de base destinées au développement d’applications web.

Conçu pour être modulaire dès le départ, chaque module forme une couche distincte en fonction de son rôle principal. Bien que les couches aient été conçues pour se soutenir mutuellement, elles peuvent également être utilisées indépendamment si nécessaire. Cela permet d’implémenter l’expérience client de Coral dans n’importe quel environnement compatible HTML.

Avec l’interface utilisateur Coral, il n’est pas obligatoire d’utiliser un modèle et/ou une plateforme de développement en particulier. L’objectif principal de Coral est de fournir un balisage HTML5 unifié et propre, indépendant de la méthode réelle utilisée pour émettre ce balisage. Cela peut être utilisé pour le rendu côté client ou serveur, les modèles, les applications JSP, PHP ou même Adobe Flash RIA, pour ne nommer que ces éléments.

Éléments HTML - Couche de balisage html-elements-the-markup-layer

Les éléments HTML offrent une apparence commune pour tous les éléments d’interface utilisateur de base (y compris la barre de navigation, les boutons, les menus, le rail, etc.).

Au niveau le plus bas, un élément HTML est une balise HTML avec un nom de classe dédié. Les éléments plus complexes peuvent être composés de plusieurs balises, imbriquées les unes dans les autres (d’une manière spécifique).

Le code CSS est utilisé pour définir l’apparence réelle. Pour qu’il soit possible de personnaliser facilement l’apparence (dans le cas d’une valorisation de marque, par exemple), les valeurs de style proprement dites sont déclarées en tant que variables qui sont étendues par le préprocesseur LESS lors de la phase d’exécution.

Objectif :

Mise en œuvre :

Par exemple, le balisage suivant :

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

s’affiche sous la forme :

L’apparence est définie dans un fichier LESS et liée à un élément par un nom de classe dédié (l’extrait suivant a été raccourci dans un souci de concision) :

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

Les valeurs réelles sont définies dans un fichier de variables LESS (l’extrait suivant a été raccourci dans un souci de concision) :

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

Plug-ins d’éléments element-plugins

De nombreux éléments HTML doivent présenter une sorte de comportement dynamique, tel que l’ouverture et la fermeture de menus contextuels. C’est le rôle des plug-ins d’éléments, qui accomplissent de telles tâches en manipulant le DOM à l’aide de JavaScript.

Un plug-in est soit :

Le comportement du plug-in peut être personnalisé avec des paramètres, de l’une des manières suivantes :

Bien que le développeur puisse choisir la méthode la mieux adaptée à chaque module externe, le principe de base consiste à utiliser les éléments suivants :

Le même concept est utilisé pour implémenter la validation de formulaire. Pour un élément qui doit être validé, vous devez spécifier le formulaire de saisie requis sous la forme d’un attribut data-* personnalisé. Cet attribut est ensuite utilisé comme option pour un module externe de validation.

Objectif :

Mise en œuvre :

Extrait de l’exemple de balisage (notez les options spécifiées sous la forme d’attributs data-*) :

<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>

Appel au module externe jQuery :

$('.cards').cardlayout ();

Cela se présente comme suit :

Le plug-in cardLayout dispose les éléments UL entre crochets sur leurs hauteurs respectives, en tenant également compte de la largeur du parent.

Widgets d’éléments HTML html-elements-widgets

Un widget combine un ou plusieurs éléments de base avec un plug-in JavaScript pour former des éléments d’interface utilisateur de « niveau supérieur ». Ceux-ci peuvent implémenter un comportement plus complexe ainsi qu’une apparence plus complexe qu’un seul élément ne pourrait offrir. Le sélecteur de balises et les widgets de rail constituent deux bons exemples.

Un widget peut se déclencher et écouter des événements personnalisés pour coopérer avec d’autres widgets sur la page. Certains widgets sont des widgets jQuery natifs qui utilisent les éléments HTML Coral.

Objectif :

Mise en œuvre :

Voici un exemple de balisage :

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

Appel au plug-in jQuery (avec options) :

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

Le plug-in émet un balisage HTML (ce balisage utilise des éléments de base, qui peuvent utiliser d’autres plug-ins en interne) :

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

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

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

Cela se présente comme suit :

Bibliothèque d’utilitaires utility-library

Cette bibliothèque est un ensemble de fonctions et/ou de plug-ins d’assistants JavaScript qui ont les caractéristiques suivantes :

Ceux-ci incluent la gestion XSS et l’eventBus.

Bien que les plug-ins et widgets d’éléments HTML puissent s’appuyer sur des fonctionnalités fournies par la bibliothèque d’utilitaires, la bibliothèque d’utilitaires ne peut pas dépendre fortement des éléments ni des widgets eux-mêmes.

Objectif :

Mise en œuvre :