Konzepte der Touch-optimierten Benutzeroberfläche von Adobe Experience Manager

Adobe Experience Manager (AEM) verfügt über eine Touch-optimierte Benutzeroberfläche mit responsives Design für die Autorenumgebung, die sowohl für Touch- als auch für Desktop-Geräte entwickelt wurde.

Die Touch-optimierte Benutzeroberfläche umfasst Folgendes:

• Suite-Kopfzeile:
  • Zeigt das Logo an.
  • Enthält einen Link zu „Globale Navigation“.
  • Enthält Link zu anderen generischen Aktionen; wie Suche, Hilfe, Experience Cloud-Lösungen, Benachrichtigungen und Benutzereinstellungen.
• Leiste auf der linken Seite (Anzeige bei Bedarf, kann ausgeblendet werden):
  • Zeitleiste
  • Verweise
  • Filter
• Die Navigationskopfzeile, die ebenfalls kontextabhängig ist und Folgendes anzeigen kann:
  • Gibt an, welche Konsole Sie derzeit verwenden, oder Ihren Standort oder beides in dieser Konsole
  • Auswahl für die linke Leiste
  • Breadcrumb
  • Zugriff auf geeignete Aktionen vom Typ Erstellen
  • Anzeigen von Auswahlen
• Der Inhaltsbereich, der:
  • Listet die Inhaltselemente auf (z. B. Seiten, Assets, Forumsbeiträge usw.)
  • Kann nach Bedarf formatiert werden, z. B. Spalte, Karte oder Liste
  • Nutzung eines responsiven Designs (Größe der Anzeige wird je nach Gerät bzw. Fenstergröße automatisch angepasst)
  • Scrollen unendlich (keine Seitennummerierung mehr, alle Elemente werden in einem Fenster aufgelistet)

Die Touch-optimierte Benutzeroberfläche wurde von Adobe entwickelt, um die Konsistenz des Benutzererlebnisses über mehrere Produkte hinweg zu gewährleisten. Er basiert auf:

• Coral-Benutzeroberfläche (CUI) eine Implementierung des visuellen Stils der Adobe für die Touch-optimierte Benutzeroberfläche. Die Coral-Benutzeroberfläche bietet alles, was Ihr Produkt/Projekt/Ihre Webanwendung benötigt, um den visuellen Stil der Benutzeroberfläche zu übernehmen.
• Granite-Benutzeroberfläche -Komponenten werden mit der Coral-Benutzeroberfläche erstellt.

Die Grundprinzipien der Touch-optimierten Benutzeroberfläche sind:

• Mobilgeräte zuerst (mit Blick auf Desktop)
• Responsives Design
• Kontextbezogene Anzeige
• Wiederverwendbar
• Einschließen der eingebetteten Referenzdokumentation
• Einschließen eingebetteter Tests
• Bottom-up-Design, um sicherzustellen, dass diese Prinzipien auf jedes Element und jede Komponente angewendet werden

Einen weiteren Überblick über die Struktur der Touch-optimierten Benutzeroberfläche finden Sie unter Struktur der AEM Touch-optimierten Benutzeroberfläche.

AEM

AEM verwendet die Granite-Plattform als Basis und die Granite-Plattform umfasst unter anderem das Java™ Content Repository.

Granite

Granite ist der Open-Web-Stack der Adobe und bietet verschiedene Komponenten wie:

• App-Starter
• Ein OSGi-Framework, in dem alles bereitgestellt wird
• Mehrere OSGi-Kompendium-Dienste zur Unterstützung von Bauanwendungen
• Ein umfassendes Protokollierungs-Framework mit verschiedenen Protokollierungs-APIs
• Die CRX-Repository-Implementierung der JCR-API-Spezifikation
• Das Apache Sling Web Framework
• Zusätzliche Teile des aktuellen CRX-Produkts

Granite-Benutzeroberfläche

Die Granite-Engineering-Plattform bietet außerdem ein Framework für die Foundation-Benutzeroberfläche. Die wichtigsten Ziele sind:

• Bereitstellen granularer UI-Widgets
• Implementieren Sie die Benutzeroberflächenkonzepte und illustrieren Sie die Best Practices (Rendern von langen Listen, Filtern von Listen, CRUD von Objekten, CUD-Assistenten usw.).
• Bereitstellung einer erweiterbaren und Plug-in-basierten Verwaltungsoberfläche

Diese erfüllen die Anforderungen:

• Respektieren von "mobile first"
• Erweiterbar
• Überschreiben einfach

GraniteUI.pdf

Datei abrufen
Die Granite-Benutzeroberfläche:

• Verwendet die RESTful-Architektur von Sling
• Implementiert Komponentenbibliotheken zum Erstellen inhaltsorientierter Webanwendungen
• Bietet granulare UI-Widgets
• Bietet eine standardmäßige, standardisierte Benutzeroberfläche
• Ist erweiterbar
• Wird sowohl für mobile als auch für Desktop-Geräte entwickelt (berücksichtigt zuerst mobile Geräte)
• Kann in jeder Granite-basierten Plattform/jedem Produkt/Projekt verwendet werden; Beispiel: AEM

• Granite-Benutzeroberfläche – Foundation-Komponenten Diese Bibliothek mit Grundlagenkomponenten kann von anderen Bibliotheken verwendet oder erweitert werden.
• Granite-Benutzeroberfläche – Verwaltungskomponenten

Client-seitig und Server-seitig

Die Client-Server-Kommunikation in der Granite-Benutzeroberfläche besteht aus Hypertext, nicht aus Objekten. Daher ist es nicht erforderlich, dass der Client die Geschäftslogik versteht

• Der Server ergänzt die HTML mit semantischen Daten
• Der Client reichert den Hypertext mit Hypermedia (Interaktion) an

Clientseite

Dabei wird eine Erweiterung des HTML-Vokabulars verwendet, vorausgesetzt der Autor kann seine Absicht zum Erstellen einer interaktiven Webanwendung zum Ausdruck bringen. Dies ist ein ähnlicher Ansatz wie WAI-ARIA und Mikroformate.

Sie besteht in erster Linie aus einer Sammlung von Interaktionsmustern (z. B. asynchrones Senden eines Formulars), die von JS- und CSS-Codes interpretiert werden und clientseitig ausgeführt werden. Die Rolle der Client-Seite besteht darin, das Markup für Interaktivität zu verbessern (das vom Server als Hypermedia-Angebot angegeben wird).

Die Client-Seite ist unabhängig von jeder Server-Technologie. Solange der Server das entsprechende Markup bereitstellt, kann die Client-Seite seine Rolle erfüllen.

Derzeit werden die JS- und CSS-Codes als Granite bereitgestellt clientlibs unter der Kategorie:

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

Die Bereitstellung erfolgt im Rahmen des Inhaltspakets:

granite.ui.content

Serverseitig

Dies wird durch eine Sammlung von Sling-Komponenten gebildet, die es dem Autor ermöglichen, zusammensetzen eine schnelle Webapp. Der Entwickler entwickelt Komponenten, der Autor stellt die Komponenten zu einer Webanwendung zusammen. Die Rolle der Server-Seite besteht darin, dem Client das Hypermedia-Angebot (Markup) zu geben.

Derzeit befinden sich die Komponenten im Granite-Repository unter:

/libs/granite/ui/components/foundation

Dies wird als Teil des Inhaltspakets bereitgestellt:

granite.ui.content

Unterschiede zur klassischen Benutzeroberfläche

Die Unterschiede zwischen der Granite-Benutzeroberfläche und ExtJS (für die klassische Benutzeroberfläche verwendet) sind ebenfalls interessant:

Foundation-Komponenten der Granite-Benutzeroberfläche

Die Foundation-Komponenten der Granite-Benutzeroberfläche stellen die grundlegenden Bausteine bereit, die zum Erstellen einer beliebigen Benutzeroberfläche erforderlich sind. Dazu gehören unter anderem:

• Schaltfläche
• Hyperlink
• Benutzer-Avatar

Die Foundation-Komponenten finden Sie unter:

/libs/granite/ui/components/foundation

Diese Bibliothek enthält eine Granite-UI-Komponente für jedes Coral-Element. Eine Komponente ist inhaltsgesteuert, wobei sich ihre Konfiguration im Repository befindet. Dies ermöglicht die Erstellung einer Granite-Benutzeroberflächen-Anwendung, ohne dass manuell HTML-Markup geschrieben werden muss.

Zweck:

• Komponentenmodell für HTML-Elemente
• Komponentenkomposition
• Automatische Tests von Einheiten und Funktionen

Implementierung:

• Repository-basierte Komposition und Konfiguration
• Verwenden der von der Granite-Plattform bereitgestellten Testeinrichtungen
• JSP-Vorlage

Diese Bibliothek mit Foundation-Komponenten kann von anderen Bibliotheken verwendet oder erweitert werden.

ExtJS und zugehörige Granite-UI-Komponenten

Bei der Aktualisierung von ExtJS-Code zur Verwendung der Granite-Benutzeroberfläche bietet die folgende Liste einen praktischen Überblick über ExtJS-xtypes und Knotentypen mit den entsprechenden Granite-UI-Ressourcentypen.

Granite-Benutzeroberfläche – Verwaltungskomponenten

Die Verwaltungskomponenten der Granite-Benutzeroberfläche auf den Foundation-Komponenten aufbauen, um allgemeine Bausteine bereitzustellen, die von jeder Administration-Anwendung implementiert werden können. Dazu gehören unter anderem:

• Globale Navigationsleiste
• Leiste (Skelett)
• Suchbereich

Zweck:

• Einheitliches Erscheinungsbild für Verwaltungsanwendungen
• Rad für Anwendungen zur Administration

Implementierung:

• Vordefinierte Komponenten mit den Foundation-Komponenten
• Komponenten können angepasst werden

Coral-Benutzeroberfläche

CoralUI.pdf

Datei abrufen
Die Coral-Benutzeroberfläche (CUI) ist eine Implementierung des visuellen Stils der Adobe für die Touch-optimierte Benutzeroberfläche, die eine konsistente Benutzererfahrung über mehrere Produkte hinweg bietet. Die Coral-Benutzeroberfläche bietet alles, was Sie benötigen, um den visuellen Stil der Authoring-Umgebung zu übernehmen.

Die Coral-Benutzeroberfläche ist eine Sammlung von Bausteinen für die Entwicklung von Web-Anwendungen.

Sie ist vollständig modular konzipiert und jedes Modul stellt basierend auf seiner primäre Rolle eine eigene Ebene dar. Obwohl die Ebenen so konzipiert wurden, dass sie sich gegenseitig unterstützen, können sie bei Bedarf auch unabhängig voneinander verwendet werden. Dies ermöglicht die Implementierung des Coral-Benutzererlebnisses in jeder HTML-fähigen Umgebung.

In der Coral-Benutzeroberfläche ist es nicht erforderlich, ein bestimmtes Entwicklungsmodell und/oder eine bestimmte Plattform zu verwenden. Hauptziel von Coral ist die Bereitstellung eines einheitlichen und sauberen HTML5-Markups, unabhängig von der eigentlichen Methode, mit der dieses Markup ausgegeben wird. Er kann für Client- oder Server-seitiges Rendering, Vorlagen, JSP, PHP oder auch Adobe Flash-RIA-Anwendungen verwendet werden, um nur einige zu nennen.

HTML-Elemente - Markup-Ebene

Die HTML-Elemente bieten ein einheitliches Erscheinungsbild für alle Elemente der grundlegenden Benutzeroberfläche (einschließlich Navigationsleiste, Schaltfläche, Menü, Leiste usw.).

Grundsätzlich ist ein HTML-Element ein HTML-Tag mit einem dedizierten Klassennamen. Komplexere Elemente können aus mehreren Tags zusammengestellt werden, die ineinander geschachtelt sind (auf spezifische Weise).

Das CSS wird verwendet, um das eigentliche Erscheinungsbild bereitzustellen. Um das Erscheinungsbild einfach anzupassen (z. B. beim Branding), werden tatsächliche Stilwerte als Variablen deklariert, die durch die WENIGER Präprozessor während der Laufzeit.

Zweck:

• Grundlegende Benutzeroberflächen-Elemente mit einem gemeinsamen Erscheinungsbild bereitstellen
• Standardrastersystem bereitstellen

Implementierung:

• HTML-Tags mit Stilen, die von Bootstrap
• Klassen werden in LESS-Dateien definiert
• Symbole werden als Schriftspritzen definiert

Beispiel für verwendeten Markup-Code:

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

Darstellung:

Das Erscheinungsbild wird in LESS definiert und es besteht eine Bindung an ein Element nach dem dedizierten Klassennamen (der folgende Auszug wurde gekürzt):

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

Die tatsächlichen Werte werden in einer LESS-Variablendatei definiert (der folgende Auszug wurde gekürzt):

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

Element-Plugins

Viele HTML-Elemente müssen eine gewisse Dynamik aufweisen, z. B. das Öffnen und Schließen von Popup-Menüs. Dies ist die Rolle der Element-Plug-ins, die solche Aufgaben durch Manipulation des DOM mit JavaScript ausführen.

Ein Plug-in ist entweder:

• Für den Betrieb mit einem bestimmten DOM-Element entwickelt. Für ein Dialogfeld-Plug-in wird beispielsweise DIV class=dialog erwartet.
• Es ist generischer Art. Über einen Layout-Manager wird beispielsweise das Layout für eine Liste mit DIV- oder LI-Elementen bereitgestellt.

Das Plug-in-Verhalten kann mit Parametern angepasst werden, indem Sie:

• Übergeben der Parameter mit einem JavaScript-Aufruf
• Verwenden von dedizierten data-*-Attributen, die an den HTML-Markup-Code gebunden sind

Entwickler können für jedes Plug-in den besten Ansatz wählen, aber die Faustregel lautet:

• data-*-Attribute für Optionen, die sich auf das HTML-Layout beziehen. So legen Sie beispielsweise die Anzahl der Spalten fest
• API-Optionen/-Klassen für Funktionen im Zusammenhang mit Daten. Beispiel: Erstellung der Liste der anzuzeigenden Elemente

Dasselbe Konzept wird für die Implementierung der Formularüberprüfung verwendet. Für ein Element, das validiert werden soll, müssen Sie das erforderliche Eingabeformular als benutzerdefiniertes data-*-Attribut angeben. Dieses Attribut wird dann als Option für ein Validierungs-Plug-in verwendet.

Zweck:

• Dynamisches Verhalten für HTML-Elemente bereitstellen
• Bereitstellung benutzerdefinierter Layouts, die mit reinem CSS nicht möglich sind
• Formularüberprüfung durchführen
• Erweiterte DOM-Manipulation durchführen

Implementierung:

• jQuery-Plug-in, gebunden an bestimmte DOM-Elemente
• Verwenden von data-*-Attributen zum Anpassen des Verhaltens

Ein Auszug aus Markup-Beispiel-Code (beachten Sie die als Daten-*-Attribute angegebenen Optionen):

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

Aufruf des jQuery-Plug-ins:

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

Dies zeigt Folgendes:

Die cardLayout -Plug-in legt die im UL -Elemente basierend auf ihren jeweiligen Höhen und unter Berücksichtigung der Breite des Elternteils.

HTML-Elemente-Widgets

Ein Widget kombiniert ein oder mehrere grundlegende Elemente mit einem JavaScript-Plug-in, um UI-Elemente auf "höherer Ebene"zu bilden. Dadurch können komplexere Verhaltensweisen sowie ein komplexeres Erscheinungsbild implementiert werden, als ein einzelnes Element liefern könnte. Gute Beispiele hierfür sind die Tag-Auswahl oder Leisten-Widgets.

Ein Widget kann benutzerdefinierte Ereignisse sowohl auslösen als auch darauf lauschen, um eine Kooperation mit anderen Widgets der Seite zu ermöglichen. Einige Widgets sind native jQuery-Widgets, die die Coral-HTML-Elemente verwenden.

Zweck:

• Implementieren von UI-Elementen auf höherer Ebene mit komplexem Verhalten
• Auslösen und Verarbeiten von Ereignissen

Implementierung:

• jQuery-Plug-in + HTML Markup
• Kann Client-/Server-seitige Vorlagen verwenden

Beispiel-Markup:

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

Aufruf des jQuery-Plug-ins (mit Optionen):

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

Das Plug-in gibt HTML Markup aus (dieses Markup verwendet grundlegende Elemente, die intern andere Plug-ins verwenden können):

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

Dies zeigt Folgendes:

Dienstprogrammbibliothek

Diese Bibliothek ist eine Sammlung von JavaScript-Helper-Plug-ins und/oder Funktionen, die:

• Benutzeroberflächenunabhängig
• Entscheidend für die Erstellung von Web-Anwendungen mit vollem Funktionsumfang

Dazu gehören die XSS-Handhabung und der Ereignisbus.

Die HTML-Element-Plug-ins und Widgets können zwar auf Funktionen der Dienstprogrammbibliothek beruhen, die Dienstprogrammbibliothek kann jedoch keine feste Abhängigkeit von den Elementen und Widgets selbst aufweisen.

Zweck:

• Bereitstellung von allgemeiner Funktionalität
• Implementierung des Ereignisbus
• Clientseitige Vorlagen
• XSS

Implementierung:

• jQuery-Plug-ins oder AMD-konforme JavaScript-Module

Ressourcen für Business.Adobe.com

Content Insights Cms Cloud Mobile Forms Version History Dynamic Media Digital Asset Management