source-git-commit | workflow-type | source-wordcount | ht-degree |
---|---|---|---|
abe5f8a4b19473c3dddfb79674fb5f5ab7e52fbf |
tm+mt |
739 |
3% |
Adobe Experience Manager-gebruikers werken in zeer concurrerende omgevingen en streven naar het creëren van digitale ervaringen die hen onderscheiden van hun concurrenten. Daarom is het van essentieel belang dat wanneer de Adobe geavanceerde nieuwe hulpmiddelen in AEM levert, deze hulpmiddelen met nauwkeurige en duidelijke documentatie worden aangevuld om de klant toe te staan om hun AEM investering onmiddellijk te gebruiken en ROI te maximaliseren.
Het doel van de AEM is zo snel mogelijk documentatie in de handen van AEM gebruikers te plaatsen. Het AEM documentatieteam geeft daarom prioriteit aan nauwkeurige, bruikbare documentatie en streeft ernaar deze voortdurend bij te werken en te verbeteren.
Met het oog op de voortdurende verbetering van AEM documentatie is de hele gemeenschap van AEM gebruikers welkom om bij te dragen aan de documentatie. Of het door trekkingsverzoeken of kwesties, de verbeteringen van de documentatie kunnen correcties, verduidelijkingen, uitbreidingen, en extra voorbeelden zijn.
Hoewel het documentatieteam van de Experience Manager de bijdragen aan de documentatie van de Adobe toejuicht, moet elke bijdrage aan de AEM-documentatie - hetzij in de vorm van een pull-verzoek, hetzij in de vorm van een kwestie - in overeenstemming zijn met de bijdrage- en documentatienormen van het team.
Bijdragen die niet aan deze normen voldoen, kunnen worden afgewezen.
AEM documentatie behandelt standaardgebruikscenario's. Gebruiksgevallen die buiten het bereik van de standaardinstallatie en het standaardgebruik van het product vallen, maken geen deel uit van AEM documentatie.
Het documentatieteam van de Experience Manager documenteert over het algemeen geen insecten of hun aanraakpunten.
AEM documentatie behandelt standaardgebruikscenario's. Daarom zijn bugs, effecten die door bugs worden veroorzaakt, en de tijdelijke oorzaken van bugs niet gedocumenteerd.
De uitzonderingen op deze regel zijn op de versienota's van toepassing waar de bekende kwesties met mogelijke oplossingen kunnen worden vermeld die door AEM Beheer van het Product zijn goedgekeurd.
Alle ideeën die u eventueel nodig hebt om AEM documentatie te verbeteren, zijn welkom als bijdragen. Opmerkingen, problemen en intrekkingsverzoeken zijn echter bedoeld voor bijdragen alleen. Ze zijn niet bedoeld om u te helpen uw vragen te beantwoorden over het gebruik van AEM, het implementeren van uw AEM-project of het oplossen van technische problemen.
Eventuele vragen over het gebruik van AEM of technische fouten moeten via het normale supportproces via het Experience Manager Support Portal of in de Experience Manager.
AEM bijdragen in de documentatie zijn geen vervanging voor de klantenondersteuning van de Adobe en dergelijke bijdragen die vragen om antwoorden op ondersteunende vragen worden afgewezen.
Als u een probleem maakt om verbeteringen in de documentatie voor te stellen, moet u koppelingen naar de betrokken pagina's opnemen. Als u een probleemmelding maakt met de koppeling Deze pagina bewerken op een documentatiepagina, wordt de probleemmelding automatisch gemaakt met een koppeling naar de pagina.
Dit is niet van toepassing op pull-aanvragen, omdat pull-aanvragen door hun aard verwijzen naar de betrokken pagina's.
Eventuele bijdragen aan AEM documentatie moeten aan bepaalde stijlrichtlijnen voldoen.
Met deze richtlijnen wordt de revisie van uw bijdrage gemakkelijker en daarom is de integratie in de AEM documentatie sneller.
- AEM documentatie is geschreven en onderhouden in het Engels van de VS.
- Zin zo eenvoudig mogelijk houden.
- Houd de taal duidelijk en beknopt.
Alle lezers van AEM documentatie zijn wereldwijd en kunnen niet verwachten dat ze native of vloeiende Engelstalige luidsprekers zijn. Vermijd colloquialisme en houd de taal zo duidelijk en eenvoudig mogelijk.
De Microsoft®-handleiding is een vrij beschikbare gids van de documentatiestijl die zich op softwaredocumentatie en AEM documentatie concentreert waar mogelijk deze gids volgt.
Item | Stijl |
---|---|
UI-element of -optie | vet |
Bestandsnaam, pad, gebruikersinvoer, parameterwaarden | monospaced |
Code, opdrachtregel | Code Block |
Schermafbeeldingen moeten met de nodige voorzichtigheid worden gebruikt en alleen wanneer een tekstbeschrijving niet volstaat.
Gebruik geen markeringen of andere annotaties in schermafbeeldingen (zoals rode kaders, pijlen of tekst). Op deze manier zijn de schermafbeeldingen gemakkelijker te hergebruiken of in gelokaliseerde versies van de documentatie te herhalen.
Probeer zo veel mogelijk directe verwijzingen naar een specifieke versie in de documentatie te voorkomen. Dit maakt de documentatie flexibeler en verlengbaar voor toekomstige versies.
Het product moet altijd met de volledige naam worden aangeduid Adobe Experience Manager voor het eerst in een artikel en kan daarna worden verwezen naar AEM.
Gebruik geen Day, Day Software, CQ en CRX, tenzij dit onvermijdelijk is, bijvoorbeeld in klassenamen of met verwijzing naar de geschiedenis van AEM.