| source-git-commit | workflow-type | source-wordcount | ht-degree |
|---|---|---|---|
abe5f8a4b19473c3dddfb79674fb5f5ab7e52fbf |
tm+mt |
739 |
51% |
Adobe Experience Manager-Benutzer arbeiten in extrem wettbewerbsorientierten Umgebungen und streben danach, digitale Erlebnisse zu erstellen, die sie von ihren Wettbewerbern abheben. Daher ist es wichtig, dass Adobe bei der Bereitstellung erweiterter neuer Tools in AEM diese mit präzisen und klaren Dokumentationen ergänzt werden, damit der Kunde sofort seine AEM investieren und den ROI maximieren kann.
Das Ziel der AEM-Dokumentation besteht darin, AEM-Benutzer schnellstmöglich mit der Dokumentation vertraut zu machen. Daher priorisiert das AEM Dokumentationsteam genaue und nutzbare Dokumentation und bemüht sich, diese kontinuierlich zu aktualisieren und zu verbessern.
Zur stetigen Verbesserung der AEM-Dokumentation ist die gesamte Community von AEM-Benutzern herzlich eingeladen, zur Dokumentation beizutragen. Sei es durch Pull-Anfragen oder Probleme, bei den Verbesserungen der Dokumentation kann es sich um Korrekturen, Klarstellungen, Erweiterungen und weitere Beispiele handeln.
Während das Experience Manager-Dokumentationsteam Beiträge zur Adobe-Dokumentation begrüßt, sollte jeder Beitrag zur AEM-Dokumentation - entweder in Form einer Pull-Anforderung oder eines Problems - den Beitrags- und Dokumentationsstandards des Teams entsprechen.
Beiträge, die diesen Standards nicht entsprechen, können abgelehnt werden.
Die AEM-Dokumentation umfasst Standard-Anwendungsfälle. Anwendungsfälle, die über den Umfang der standardmäßigen Installation und Nutzung des Produkts hinausgehen, sind nicht Teil der AEM-Dokumentation.
Das Dokumentationsteam des Experience Managers dokumentiert im Allgemeinen keine Fehler oder ihre Umgehungslösungen.
Die AEM-Dokumentation umfasst Standard-Anwendungsfälle. Aus diesem Grund werden Fehler, durch Fehler verursachte Effekte und Problemumgehungen für Fehler nicht dokumentiert.
Ausnahmen gelten für die Versionshinweise, in denen bekannte Probleme mit möglichen Lösungen aufgelistet werden können, die vom AEM Product Management genehmigt wurden.
Alle Ideen, die Sie möglicherweise zur Verbesserung der AEM-Dokumentation haben, sind als Beiträge willkommen. Kommentare, Probleme und Pull-Anfragen sind jedoch nur für Beiträge vorgesehen. Sie sind nicht zur Beantwortung Ihrer Fragen über die Verwendung von AEM, Implementierung Ihres AEM-Projekts oder zur Lösung technischer Probleme gedacht.
Fragen zur Verwendung von AEM oder zu technischen Fehlern, die möglicherweise bei Ihnen auftreten, sollten entsprechend dem herkömmlichen Support-Prozess über das Support-Portal für Experience Manager gemeldet oder in der Experience Manager-Community diskutiert werden.
AEM Dokumentationsbeiträge sind kein Ersatz für den Adobe-Support und Beiträge, die Antworten auf Supportfragen suchen, werden abgelehnt.
Wenn Sie ein Problem erstellen, um Verbesserungen an der Dokumentation vorzuschlagen, müssen Sie Links zu den betroffenen Seiten angeben. Wenn Sie ein Problem mithilfe des Links Diese Seite bearbeiten auf einer Dokumentationsseite erstellen, wird das Problem automatisch mit einem Link zur Seite erstellt.
Dies gilt nicht für Pull-Anforderungen, da Pull-Anforderungen naturgemäß auf die betroffenen Seiten verweisen.
Alle Beiträge zur AEM Dokumentation müssen bestimmten Stilrichtlinien entsprechen.
Durch Befolgen dieser Richtlinien wird die Überprüfung Ihres Beitrags vereinfacht und die Integration in die AEM-Dokumentation ist daher schneller.
- Die AEM-Dokumentation wird in englischer Sprache verfasst und verwaltet.
- Ausdrücke sollten so einfach wie möglich sein.
- Drücken Sie sich klar und bündig aus.
Denken Sie daran, dass die Leser AEM Dokumentation weltweit sind und nicht erwartet werden können, dass sie fließend Englisch beherrschen oder Muttersprachler sind. Vermeiden Sie umgangssprachliche Wendungen und verwenden Sie eine klare und einfache Sprache wie möglich.
Das Microsoft® Stilhandbuch ist ein kostenloses Stilhandbuch für Dokumentationen, das sich auf die Softwaredokumentation konzentriert und AEM Dokumentation nach Möglichkeit diesem Handbuch folgt.
| Element | Stil |
|---|---|
| Element oder Option der Benutzeroberfläche | fett |
| Dateiname, Pfad, Benutzereingabe, Parameterwerte | monospaced |
| Code, Befehlszeile | Code Block |
Screenshots sollten mit Bedacht und nur dann verwendet werden, wenn eine Textbeschreibung nicht ausreicht.
Verwenden Sie keine Markierungen oder anderen Anmerkungen in Screenshots (z. B. rote Rahmen, Pfeile oder Text). Auf diese Weise können die Screenshots in lokalisierten Versionen der Dokumentation einfacher wiederverwendet oder repliziert werden.
Versuchen Sie nach Möglichkeit direkte Verweise auf eine bestimmte Version im gesamten Dokumentationsinhalt zu vermeiden. Dadurch wird die Dokumentation für künftige Versionen flexibler und erweiterbarer.
Das Produkt sollte immer mit seinem vollständigen Namen aufgerufen werden Adobe Experience Manager zum ersten Mal in einem Artikel und kann anschließend als AEM.
Verwenden Sie Day, Day Software, CQ und CRX nur, wenn dies unvermeidlich ist, z. B. in Klassennamen oder bei Verweisen auf die AEM.