Dos und Don'ts: Paarweise Verhaltensregeln
Erstelle Dos und Don'ts, die gleichwertige Handlungen paaren, jedes Verbot erklären und Lesern sowie Antwortmaschinen klare, praktische und wiederverwendbare Empfehlungen bieten.
Ein Dos-und-Don’ts-Block paart eine empfohlene Handlung mit einem gleichwertigen Fehler und erklärt, warum der Fehler scheitert. Sein Wert entsteht durch den Kontrast: die falsche Version deckt eine verführerische Fehlerart auf, während die richtige Version dem Leser einen unmittelbaren Ersatz bietet.
Vergleichsbehauptungen formulieren
- Do: Nenne den genauen Tarif und das Prüfdatum. Kommerzielle Fakten ändern sich, daher ermöglicht der Geltungsbereich den Lesern, die Behauptung zu überprüfen und sicher wiederzuverwenden.Don't: Veröffentliche keinen undatierten Preis. Leser können nicht erkennen, welchen Tarif oder Zeitraum die Angabe beschreibt.
- Do: Vergleiche beide Produkte anhand desselben Kriteriums. Ein gemeinsames Maß macht den Unterschied aussagekräftig.Don't: Vergleiche nicht die Geschwindigkeit eines Produkts mit dem Support eines anderen. Unterschiedliche Kriterien erwecken den Anschein eines Vergleichs, ohne eine valide Wahl zu ermöglichen.
- Do: Schreibe „Unbekannt", wenn keine Belege verfügbar sind. Eine explizite Lücke unterscheidet fehlende Recherche von einer fehlenden Funktion.Don't: Lasse kein ungeprüftes Feld leer. Ein leeres Feld kann fälschlich als Null, nicht verfügbar oder nicht zutreffend gelesen werden.
Dieses gerenderte Beispiel ist das Produktionsmodell. Jede Zeile behandelt ein Thema auf demselben Detaillierungsgrad. Das „Don’t" nennt einen realistischen Fehler und seine Konsequenz; das „Do" liefert eine nutzbare Korrektur. Beschriftungen, nicht Farben oder Symbole, tragen die Unterscheidung.
Warum dieses Element wichtig ist
Regeln sind leichter zu verstehen, wenn Leser die Grenze sehen können, die sie einhalten sollen. Eine positive Anweisung allein kann abstrakt wirken: „Verwende spezifische Belege" verrät nicht, was als zu vage gilt. Eine negative Anweisung allein erzeugt Widerstand: „Mache keine unbelegten Behauptungen" sagt, was vermieden werden soll, lässt aber den nächsten Schritt offen. Beide zusammenzubringen, verwandelt eine Grenze in eine Wahl, die der Leser umsetzen kann.
Die falsche Version ist lehrreich, weil sie oft dem ähnelt, was eine vielbeschäftigte Person natürlicherweise schreiben würde. Diese Beinahe-Fehlentscheidung zu zeigen, hilft dem Leser, sie in der eigenen Arbeit zu erkennen. Der Grund ist ebenso wichtig. „Keine vage Sprache verwenden" verlangt Gehorsam; „Schreibe nicht ‚schnell’, ohne die gemessene Aufgabe zu nennen, weil Leser sie weder überprüfen noch vergleichen können" vermittelt ein Prinzip, das auf neue Beispiele übertragbar ist.
Parität bedeutet, dass beide Seiten gleichwertige Themen, Anzahlen, Detaillierungsgrad und redaktionelles Gewicht abdecken. Sie verhindert, dass eine ausgefeilte „Do"-Spalte neben einem Haufen zusammenhangsloser Warnungen steht. Leser können ein Paar überfliegen, den Kontrast verstehen und fortfahren, ohne sich an einen Eintrag von einer anderen Stelle der Seite erinnern zu müssen.
Maschinelle Extrahierbarkeit ist die Fähigkeit von Software, Inhalte zu isolieren, während deren Bedeutung und Beziehungen erhalten bleiben. Sichtbare Überschriften, Listenstruktur und zeilenweise ausgerichtete Paare ermöglichen es Suchsystemen und Antwortmaschinen, Aussagen wie „Bei Preisen nenne den Tarif und das Datum; vermeide undatierte Zahlen, da deren Geltungsbereich nicht überprüfbar ist" wiederzugeben. Wenn die beiden Seiten unzusammenhängende Aufzählungspunkte enthalten oder der Grund nur durch ein Symbol angedeutet wird, kann die Extraktion den Befehl bewahren, verliert aber die Qualifikation, die ihn sicher macht.
Befolge die Element-Schreibregeln , bevor du diesen Block auswählst. Der Zweck hat Vorrang vor dem Erscheinungsbild. Inhalte, die hauptsächlich vor unmittelbarer Gefahr warnen, bleiben eine Warnung; eine Abfolge bleibt eine Schrittliste; eine endliche Menge von Erledigungskontrollen bleibt eine Checkliste. Zwei farbige Spalten machen aus diesen Zwecken keine Dos und Don’ts.
Wann man es verwendet
Verwende dieses Element, wenn Leser eine empfohlene Praxis von einem plausiblen, folgenschweren Fehler unterscheiden müssen. Der Kontrast sollte Mehrdeutigkeiten effektiver reduzieren als eine einzelne Anweisung. Geeignete Themen umfassen Redaktionsstandards, Implementierungskonventionen, Qualitätskontrollen, Designverhalten, Datenhandhabung und Prozessentscheidungen.
Alle diese Bedingungen sollten zutreffen:
- Jeder Fehler hat eine verantwortungsvolle Ersatzhandlung.
- Der Grund für die Vermeidung des Fehlers kann in einem kurzen Satz formuliert werden.
- Die Einträge sind unabhängige Empfehlungen, keine Schritte, die in einer bestimmten Reihenfolge abgeschlossen werden müssen.
- Beide Seiten können denselben Umfang und dieselbe Spezifität verwenden.
Grenzfälle sind häufig:
- Pro und Kontra: Vorteile und Einschränkungen bewerten eine Option. Dos und Don’ts weisen den Leser in seinem Verhalten an. „Beinhaltet unbegrenzte Projekte" ist ein Pro, kein Do.
- Warnung: Eine schwerwiegende oder irreversible Konsequenz benötigt direkte Hervorhebung und eine Reaktion, keine gleichgewichtige Begleitspalte.
- Checkliste: Eine Checkliste erfasst, ob erforderliche Arbeiten abgeschlossen sind. Ihr nicht abgehakter Zustand ist kein „Don’t".
- Vergleichstabelle: Eine Tabelle bewertet mehrere Optionen anhand gemeinsamer Kriterien. Sie schreibt kein richtiges und falsches Verhalten vor.
- Vorher und Nachher: Zwei Beispiele können eine Bearbeitung zeigen, ohne eine wiederverwendbare Verhaltensregel auszudrücken. Verwende Dos und Don’ts nur, wenn der Kontrast eine allgemeine Praxis vermittelt.
- Willkürlicher Hausstil: Wenn keine Konsequenz für Leser, System, Compliance oder Wartung erklärt werden kann, dokumentiere die Konvention als Regel, anstatt so zu tun, als sei die Alternative ein Fehler.
Verwende den Block nicht, um eine Opposition zu konstruieren. „Schreibe klar; schreibe nicht unklar" wiederholt dieselbe Abstraktion und lehrt nichts. Die falsche Seite muss verführerisch genug sein, um erkennbar, und spezifisch genug, um diagnostizierbar zu sein.
Wo man es platziert
Platziere den Block, nachdem die Seite die Aufgabe, die Zielgruppe und alle zum Verständnis der Anleitung erforderlichen Begriffe definiert hat. Er gehört unmittelbar nach der Erklärung oder Demonstration, die er zusammenfasst, oder gegen Ende eines Abschnitts als praktische Überprüfung, bevor der Leser handelt.
Genaue Platzierungsregeln:
- Führe ein Thema in der nächstgelegenen Überschrift ein. Jedes Paar muss unter diesem Thema Sinn ergeben, ohne den Geltungsbereich aus einem entfernten Absatz zu entleihen.
- Setze den Block nach dem leitenden Prinzip und vor eine Umsetzungscheckliste oder nächste Aktion. Leser sollten verstehen, warum, bevor sie die Erledigung überprüfen.
- Verwende in wiederholten Abschnitten dieselbe Position und denselben Paarumfang. Den Block unvorhersehbar zu verschieben, macht es schwerer, ihn themenübergreifend zu erfassen.
- Halte die gepaarten Listen in der Quellreihenfolge und im visuellen Layout zusammen. Erläuternder Fließtext kann dem vollständigen Block folgen, nicht seine Seiten trennen.
Er darf nicht direkt neben einem anderen zweispaltigen Entscheidungselement stehen, da benachbarte Raster verschleiern, welche Beschriftungen und Zeilen zusammengehören. Platziere kein Testimonial, Werbebanner, Formular oder Call-to-Action zwischen den „Do"- und „Don’t"-Seiten. Mache ihn nicht zum ersten bedeutungsvollen Inhalt auf einer Seite, wenn die Regeln von Begriffen oder Kontext abhängen, die der Leser noch nicht erhalten hat.
Anatomie
Gerenderte Legende
- Themenüberschrift: benennt die abgegrenzte Aufgabe oder Entscheidung, die jedes Paar gemeinsam hat.
- Do-Beschriftung: sichtbarer Text, der das empfohlene Verhalten kennzeichnet; ein Symbol oder eine grüne Gestaltung ist ergänzend.
- Don’t-Beschriftung: sichtbarer Text, der das zu vermeidende Verhalten kennzeichnet; die Zeichensetzung verwendet die lokalisierte redaktionelle Form.
- Handlungsaussage: ein imperativer oder deklarativer Satz, der beobachtbares Verhalten benennt.
- Grund: ein Satz, der die Anweisung mit einer Konsequenz, einer Fehlerart oder einem leitenden Prinzip verbindet.
- Paarbeziehung: Quellreihenfolge und Layout erhalten, welches „Do" welches „Don’t" beantwortet.
- Optionaler Quellenvermerk: kennzeichnet die Richtlinie, den Test, die Verordnung oder den Beleg, der die sachlichen Anforderungen bestimmt.
Der Autor liefert das Thema, die Paare und die Gründe. Der Renderer sorgt für gleiche Darstellung, responsives Stapeln, zugängliche Beschriftungen und dekorative Symbole, wo angebracht.
Gestaltungsbeispiele
Die folgenden Varianten sind der vollständige unterstützte Satz. Sie ändern Dichte und Anordnung, niemals die Parität oder den Begründungsvertrag.
Standard paarweise Zeilen
Verwende drei bis sieben horizontal ausgerichtete Zeilen auf breiten Bildschirmen. Jede Zeile enthält ein „Do" und ein „Don’t" zum selben Thema.
Gestapelte mobile Paare
Bei schmalen Breiten jedes Paar zusammenhalten: „Do", dann „Don’t", dann das nächste Paar. Alle positiven Einträge vor allen negativen Einträgen zu stapeln, würde die Entsprechung verbergen.
Beispielgeführte Variante
Verwende, wenn genaue Formulierungen, Auszeichnungen oder Schnittstellenverhalten nützlicher sind als ein abstrakter Befehl. Jede Seite zeigt ein kurzes Beispiel, gefolgt von seinem Grund. Code bleibt auswählbarer Text.
Kompakte Überprüfungsvariante
Verwende nur, wenn die leitenden Gründe bereits unmittelbar darüber erklärt wurden. Der Grund erscheint dennoch in jedem Eintrag, jedoch als kurze Phrase statt als separater Absatz.
Erstelle keine reinen Symbol-, Karussell-, Tab- oder eigenständig einklappbaren Varianten. Sie trennen das Paar, verbergen eine Seite oder machen den Vergleich von Interaktion abhängig.
Parameter
Das Vertragsmodell bildet Paare ab, nicht zwei unzusammenhängende Listen. „Quelle" beschreibt, woher der Renderer jeden Wert bezieht.
| Name | Typ | Erforderlich | Min./Max. | Standard | Quelle |
|---|---|---|---|---|---|
| heading | Einfacher String | Ja | 2–10 Wörter; 100 Zeichen | Keine | Erste Überschrift im Body |
| pair | Wiederholter Datensatz | Ja | 3–7 Paare | Keine | Verschachteltes Body-Element |
| do | Klartext mit begrenztem Inline-Code | Ja pro Paar | 1 Aktion; 110 Zeichen empfohlen | Keine | Pair-Attribut oder erstes Do-Feld im Body |
| dont | Klartext mit begrenztem Inline-Code | Ja pro Paar | 1 Aktion; 110 Zeichen empfohlen | Keine | Pair-Attribut oder erstes Don't-Feld im Body |
| do-reason | Einfacher String | Ja pro Paar | 1 Satz; 180 Zeichen | Keine | Body unter Do-Überschrift |
| dont-reason | Einfacher String | Ja pro Paar | 1 Satz; 180 Zeichen | Keine | Body unter Don't-Überschrift |
| variant | Enum | Nein | standard, example-led oder compact | standard | Attribut |
| source-note | Klartext mit optionalen Links | Bedingt | 1–3 Quellen | Keine | Body nach allen Paaren |
Die erste Body-Überschrift wird auf heading abgebildet. Jedes verschachtelte pair besitzt beide Aktionen und beide Gründe. Das Quellmodell darf nicht alle positiven Einträge getrennt von allen negativen Einträgen speichern, da dies die Zeilenkorrespondenz von der Array-Position abhängig und bei Bearbeitung leicht zu beschädigen macht.
Syntax und Code-Beispiele
Alle drei Formate bewahren dasselbe Thema, dieselbe Paarreihenfolge, dieselben Aktionen und dieselben Gründe. Sie leiten keinen Grund aus der Aktion ab und erstellen kein positives Element automatisch.
Portable Markdown-Direktive
::dos-and-donts
## Vergleichsbehauptungen formulieren
::item{do="Nenne den genauen Tarif und das Prüfdatum" dont="Veröffentliche keinen undatierten Preis"}
### Do
Kommerzielle Fakten ändern sich, daher ermöglicht der Geltungsbereich den Lesern, die Behauptung zu überprüfen und wiederzuverwenden.
### Don't
Leser können nicht erkennen, welchen Tarif oder Zeitraum eine undatierte Zahl beschreibt.
::
::item{do="Vergleiche beide Produkte anhand desselben Kriteriums" dont="Vergleiche keine unzusammenhängenden Fähigkeiten"}
### Do
Ein gemeinsames Maß macht den Unterschied aussagekräftig.
### Don't
Unterschiedliche Kriterien erwecken den Anschein eines Vergleichs, ohne eine valide Wahl zu ermöglichen.
::
:::
Dieses Element überschreibt die standardmäßige Elementzuordnung: die übergeordnete Überschrift liefert heading; Elementattribute liefern die Aktionen; die ersten Do- und Don't-Unterüberschriften ordnen ihren folgenden Text den beiden Gründen zu.
Hugo-Shortcode
Derzeit implementiert kein produktiver Hugo-Shortcode den gepaarten Datensatzvertrag. Bis einer existiert, rendere semantisches HTML wie das Live-Beispiel, anstatt zwei unzusammenhängende Listen-Helfer zu verwenden. Der beabsichtigte Adapter ist:
{{< dos-and-donts >}}
## Vergleichsbehauptungen formulieren
{{< do-dont-pair do="Nenne den genauen Tarif und das Prüfdatum" dont="Veröffentliche keinen undatierten Preis" >}}
### Do
Kommerzielle Fakten ändern sich, daher ermöglicht der Geltungsbereich den Lesern, die Behauptung zu überprüfen und wiederzuverwenden.
### Don't
Leser können nicht erkennen, welchen Tarif oder Zeitraum eine undatierte Zahl beschreibt.
{{< /do-dont-pair >}}
{{< /dos-and-donts >}}
Der zukünftige Renderer muss einen beschrifteten Bereich mit einer Liste gepaarter Datensätze erzeugen. Er darf nicht zwei Arrays erstellen und diese nach dem Rendern indexbasiert zusammenführen.
WordPress-Block oder Shortcode
[dos_and_donts heading="Vergleichsbehauptungen formulieren" variant="standard"]
[pair]
[do action="Nenne den genauen Tarif und das Prüfdatum"]Kommerzielle Fakten ändern sich, daher ermöglicht der Geltungsbereich den Lesern, die Behauptung zu überprüfen und wiederzuverwenden.[/do]
[dont action="Veröffentliche keinen undatierten Preis"]Leser können nicht erkennen, welchen Tarif oder Zeitraum eine undatierte Zahl beschreibt.[/dont]
[/pair]
[pair]
[do action="Vergleiche beide Produkte anhand desselben Kriteriums"]Ein gemeinsames Maß macht den Unterschied aussagekräftig.[/do]
[dont action="Vergleiche keine unzusammenhängenden Fähigkeiten"]Unterschiedliche Kriterien erwecken den Anschein eines Vergleichs, ohne eine valide Wahl zu ermöglichen.[/dont]
[/pair]
[/dos_and_donts]
Ein benutzerdefinierter WordPress-Block sollte jedes Paar als einen Datensatz bearbeiten und die Veröffentlichung verhindern, wenn eine Aktion oder ein Grund fehlt.
Beispiele
Gut: gleichwertig, handlungsorientiert und begründet
| Do | Don’t |
|---|---|
| Gib an, welchen Preistarif du geprüft hast. Der Tarifumfang verhindert, dass ein gültiger Preis auf das falsche Angebot angewendet wird. | Schreibe nicht „ab 29 €" ohne Tarifnamen. Die Zahl kann technisch korrekt bleiben, während sie den beabsichtigten Käufer in die Irre führt. |
| Verwende denselben Messzeitraum für jede Option. Übereinstimmende Zeiträume machen Veränderungen und Rankings vergleichbar. | Vergleiche keine Jahressumme mit einer monatlichen Momentaufnahme. Unterschiedliche Zeiträume können einen künstlichen Gewinner erzeugen. |
| Kennzeichne nicht verfügbare Belege als „Unbekannt". Die Kennzeichnung bewahrt den Unterschied zwischen Unsicherheit und Abwesenheit. | Behandle eine ausgelassene Tatsache nicht als „Nein". Fehlende Dokumentation beweist nicht, dass eine Funktion nicht verfügbar ist. |
Die Paare teilen sich in jeder Zeile ein Thema: Tarifumfang, Zeitfenster und Belegstatus. Beide Aktionen sind spezifisch genug, um in einem Entwurf überprüft zu werden, und jeder Grund erklärt, was schiefgehen kann. Ein Leser kann das Prinzip anwenden, selbst wenn sich der genaue Preis, das Produkt oder der Zeitraum ändert.
Schlecht: zwei Befehlshaufen
| Do | Don’t |
|---|---|
| Sei genau | Niemals Fachjargon verwenden |
| Füge Beispiele hinzu | Keine langen Absätze schreiben |
| Halte es einfach | Zu viele Links vermeiden | | Fakten prüfen | — |
Dies scheitert, weil die Spalten unzusammenhängend und ungleich sind. „Sei genau" hat keine beobachtbare Erfüllungsbedingung, während „Niemals Fachjargon verwenden" Sprache verbietet, ohne notwendige Begriffe von unerklärten Begriffen zu unterscheiden. Keiner der negativen Einträge nennt eine Konsequenz, und die leere Zelle zeigt, dass der Autor zwei Listen statt vier Paare erstellt hat.
Repariere den Block, indem du ein Thema wählst und dann gleichwertige Zeilen schreibst. Für Terminologie könnte das Paar lauten: „Definiere einen notwendigen Fachbegriff bei erster Verwendung, weil die Definition Neulingen ermöglicht, der Argumentation zu folgen" und „Ersetze keinen präzisen Fachbegriff durch eine vage alltägliche Phrase, weil die Ersetzung die Bedeutung verändern kann." Die Korrektur lehrt Urteilsvermögen, anstatt einen Slogan durchzusetzen.
Schema-Auszeichnung und Barrierefreiheit
Schema.org bietet keinen allgemeinen DoAndDont-Typ. Behalte den sichtbaren Block innerhalb des umschließenden Article, TechArticle, HowTo oder einer anderen strukturierten Dateneinheit auf Seitenebene, wenn diese Seite tatsächlich qualifiziert ist. Wandle die positiven Einträge nicht in HowToStep-Datensätze um, es sei denn, sie bilden ein geordnetes Verfahren, und veröffentliche die Paare nicht als FAQPage, nur weil sie kurze Erklärungen enthalten.
Verwende native Überschriften und Listen. Ein äußerer Bereich erhält seinen zugänglichen Namen von der Themenüberschrift. Jedes Paar sollte ein Listeneintrag oder ein gruppierter Datensatz sein, der eine sichtbare „Do"-Beschriftung und eine sichtbare „Don’t"-Beschriftung enthält. Bewahre jedes Paar in der Quellreihenfolge, damit ein Screenreader-Nutzer die Empfehlung und den zugehörigen Fehler gemeinsam antrifft.
Farbe und Symbole sind ergänzend. Grün kann nicht das einzige Signal für „Do" sein, und ein Kreuz kann nicht das einzige Signal für „Don’t" sein. Dekorative Symbole erhalten leeren Alternativtext oder werden vor assistiven Technologien verborgen. Mache einen statischen Block nicht fokussierbar. Wenn horizontaler Überlauf für eine Beispieltabelle unvermeidbar ist, begrenze und beschrifte den Scrollbereich; die Produktionskomponente sollte Paare stattdessen stapeln.
Die Verkürzung „Don’t" ist als sichtbarer redaktioneller Text akzeptabel. Code-Felder verwenden ASCII-sicheres dont, wo Apostrophe Attributnamen verkomplizieren würden. Renderer lokalisieren die Beschriftungen, ohne die gespeicherten Aktionen oder Gründe zu ändern.
Schreibregeln
Schreibe den Grund, bevor du den Befehl finalisierst. Dies zwingt den Autor, die Konsequenz für Leser, System, Sicherheit, Compliance oder Wartung zu identifizieren. Wenn kein vertretbarer Grund formuliert werden kann, ist das Verbot möglicherweise eher eine Präferenz als eine Richtlinie.
Verwende drei bis sieben Paare. Jede Aktion sollte nach Möglichkeit ein beobachtbares Verhalten in 110 Zeichen oder weniger ausdrücken. Gib jeder Seite einen Begründungssatz von höchstens 180 Zeichen. Die Grenzen halten beide Seiten überblickbar; längere Qualifikationen gehören in den umgebenden Fließtext.
Halte Parität in fünf Dimensionen ein:
- Thema: beide Aktionen adressieren dieselbe Entscheidung oder dasselbe Artefakt.
- Abstraktionsebene: eine präzise Auszeichnungsregel kann nicht mit einer breiten Maxime wie „schreibe gut" gepaart werden.
- Grammatik: verwende parallele Imperative oder parallele Deklarativsätze.
- Belege: wende denselben sachlichen und quellenbezogenen Schwellenwert auf beide Seiten an.
- Visuelles Gewicht: keine Seite erhält mehr Raum, Betonung, Detail oder standardmäßige Sichtbarkeit.
Verwende direkte, neutrale Sprache. Bevorzuge „Veröffentliche keinen ungeprüften Preis" gegenüber beschämender Sprache wie „Nur nachlässige Autoren vergessen, Preise zu prüfen." Vermeide Sarkasmus, Angst und absolute Begriffe, es sei denn, die Regel ist tatsächlich absolut und ihr Geltungsbereich wird genannt.
Setze niemals Folgendes in das Element:
- Unzusammenhängende Tipps, die hinzugefügt wurden, um eine Seite zu füllen oder eine numerische Symmetrie zu erzwingen.
- Ein Verbot ohne Konsequenz, Prinzip oder Ersatzhandlung.
- Geordnete Verfahren, Kontrollkästchen, Bewertungen, Urteile oder Produktvor- und -nachteile.
- Sicherheitskritische Warnungen, rechtliche Haftungsausschlüsse, Notfallanweisungen oder Hinweise auf irreversible Handlungen.
- Testimonials, lange Zitate, Medien, Formulare, Calls-to-Action, Werbebuttons oder Gutscheincodes.
- Verschachtelte Akkordeons, Tabs, Karussells, Vergleichstabellen oder einen weiteren Dos-und-Don’ts-Block.
- Behauptungen über Personen oder Gruppen, die als moralisches Versagen statt als beobachtbares Verhalten formuliert sind.
Wenn eine Anforderung aus einer Richtlinie, Verordnung, einem Test oder einem externen Standard stammt, füge einen nahegelegenen Quellenvermerk hinzu. Beschreibe die Regel genau genug, dass ein Redakteur sie erneut prüfen kann; der Block sollte keinen langen Zitierapparat tragen.
Beitragstypen, die es verwenden
Das postTypes-Frontmatter-Array steuert diese Nutzungsmatrix. Die Aufnahme macht das Element unter der genannten Bedingung verfügbar; sie macht den Block nicht auf jeder Seite dieses Typs verpflichtend.
| Beitragstyp | Verwendung | Bevorzugte Position | Besondere Regel |
|---|---|---|---|
| How-to-Anleitungen | Empfohlen für risikoreiche oder häufig verwechselte Ausführungsentscheidungen | Nach der relevanten Methode, vor der Überprüfung | Ersetze niemals geordnete Schritte durch Paare. |
| Ultimative Anleitungen | Optional für eine abgegrenzte Praxis mit wiederkehrenden Beinahe-Fehlentscheidungen | Am Ende des relevanten Lehrinhaltsabschnitts | Halte jeden Block auf ein Thema innerhalb der breiteren Anleitung. |
| Dokumentationsartikel | Empfohlen für Konfigurations-, Syntax- oder Workflow-Konventionen | Nachdem das kanonische Verhalten erklärt wurde | Stimme mit der dokumentierten Produktversion und Oberfläche überein. |
| Checklisten-Artikel | Optional als Lehre vor den Kontrollen | Vor der Checkliste, niemals darin | Paare erklären Urteilsvermögen; Kontrollen überprüfen die Erledigung. |
| Beiträge über zu vermeidende Fehler | Empfohlen, wenn jeder Fehler eine konkrete Korrektur hat | Nach der Diagnose des Fehlers und seiner Konsequenz | Presse keine Belege in den negativen Eintrag. |
| Richtlinienseiten | Optional für praktische Interpretation einer formalen Regel | Nach der autoritativen Regel und dem Geltungsbereich | Der Block kann keine Anforderungen schaffen, die in der Richtlinie nicht enthalten sind. |
| Normen- und Regulierungsseiten | Optional für konforme versus nicht konforme Praktiken | Nach der Erklärung der Anwendbarkeit und der genauen Anforderung | Zitiere die maßgebliche Vorschrift und vermeide rechtliche Schlussfolgerungen, die darüber hinausgehen. |
| Framework-Beiträge | Optional für korrekte und inkorrekte Anwendung eines Frameworks | Nach der Einführung des relevanten Framework-Teils | Paare Fehlanwendung mit demselben Framework-Prinzip, nicht mit allgemeinen Ratschlägen. |
QA-Checkliste
- Der Block hat ein abgegrenztes Thema, das aus der nächstgelegenen Überschrift klar hervorgeht.
- Das leitende Prinzip erscheint vor dem Block, sodass die Paare die Regel verstärken und nicht erfinden.
- Es gibt drei bis sieben vollständige Paare und exakt dieselbe Anzahl an „Do"- und „Don’t"-Aktionen.
- Jedes Paar adressiert dasselbe Thema, dieselbe Zielgruppe, denselben Umfang und dieselbe Spezifität.
- Jedes „Don’t" nennt einen realistischen Fehler und erklärt seine Konsequenz oder Fehlerart.
- Jedes „Do" bietet einen handlungsorientierten Ersatz und erklärt, warum er funktioniert.
- Kein Eintrag verneint lediglich seinen Partner, wiederholt einen Slogan oder verwendet zirkuläre Formulierungen.
- Aktionen enthalten ein Verhalten und bleiben nahe am 110-Zeichen-Ziel.
- Gründe enthalten einen Satz und bleiben innerhalb von 180 Zeichen.
- Beide Seiten verwenden parallele Grammatik, Belegstandards, Detailgrad und visuelles Gewicht.
- Sachliche Anforderungen identifizieren bei Bedarf ihre Richtlinie, Verordnung, ihren Test oder ihre Quelle.
- Der Block enthält keine Schritte, Kontrollzustände, Produktabwägungen, schwerwiegende Warnungen, Werbung, Formulare oder verschachtelte komplexe Elemente.
- Sichtbarer Text sagt „Do" und „Don’t"; Farbe, Position und Symbole sind nicht die einzigen Signale.
- Die responsive Ausgabe hält jedes Paar zusammen, anstatt alle positiven Einträge vor allen negativen Einträgen zu stapeln.
- Die Themenüberschrift und die Paarstruktur bleiben in Klartext und bei nicht verfügbaren Styles oder Skripten verständlich.
- Strukturierte Daten beschreiben nur die umschließende Seite und erfinden keinen Dos-und-Don’ts-Schema-Typ.
- Screenshot-Kommentare bleiben nicht-rendering Erfassungsanweisungen, bis echte Assets existieren.
FAQ
Die Academy-Vorlage rendert die fünf in diesem Seiten-[[faq]]-Frontmatter gespeicherten Fragen. Sie decken Paarvollständigkeit, zahlenmäßige Parität, Gründe, strukturierte Daten und die Anzahl der Einträge ab.
Weitere Tutorials in diesem Bereich
Bereit, es in die Praxis umzusetzen?
Kostenlose Prüfung · 7 Tage testen · keine Kreditkarte