Do's en don'ts: Gecombineerde richtlijnen

Een do’s-en-don’ts-blok koppelt een aanbevolen actie aan een fout met dezelfde reikwijdte en legt uit waarom de fout niet werkt. De waarde komt voort uit contrast: de verkeerde versie toont een verleidelijke faalmodus, terwijl de juiste versie de lezer een directe vervanging geeft.

Dit weergegeven voorbeeld is het productiemodel. Elke rij behandelt één onderwerp op hetzelfde detailniveau. De ‘Don’t’ benoemt een realistische fout en het gevolg ervan; de ‘Do’ biedt een bruikbare correctie. Labels, niet kleur of pictogrammen, dragen het onderscheid.

Waarom dit element ertoe doet

Regels zijn gemakkelijker te begrijpen wanneer lezers de grens kunnen zien die ze moeten respecteren. Een positieve instructie alleen kan abstract aanvoelen: ‘Gebruik specifiek bewijs’ onthult niet wat als te vaag telt. Een negatieve instructie alleen creëert wrijving: ‘Doe geen ongefundeerde beweringen’ zegt wat te vermijden, maar laat de volgende stap onduidelijk. De twee samen plaatsen verandert een grens in een keuze waar de lezer mee kan handelen.

De verkeerde versie is leerzaam omdat deze vaak lijkt op wat een druk persoon natuurlijk zou schrijven. Het tonen van die bijna-misser helpt de lezer deze in eigen werk te herkennen. De reden is net zo belangrijk. ‘Gebruik geen vage taal’ eist gehoorzaamheid op; ‘Schrijf niet ‘snel’ zonder de gemeten taak te noemen, omdat lezers het niet kunnen verifiëren of vergelijken’ leert een principe dat overdraagbaar is naar nieuwe voorbeelden.

Pariteit betekent dat beide zijden gelijkwaardige onderwerpen, aantallen, detail en redactioneel gewicht dekken. Het voorkomt dat een gepolijste ‘Do’-kolom naast een verzameling onsamenhangende waarschuwingen staat. Lezers kunnen één paar scannen, het contrast begrijpen en verdergaan zonder een item van elders op de pagina te moeten onthouden.

Machine-extraheerbaarheid is het vermogen van software om content te isoleren terwijl de betekenis en relaties behouden blijven. Zichtbare koppen, lijststructuur en rij-uitgelijnde paren stellen zoeksystemen en antwoordmachines in staat uitspraken te herstellen zoals ‘Vermeld bij prijzen het abonnement en de datum; vermijd ongedateerde bedragen omdat de reikwijdte ervan niet verifieerbaar is.’ Als de twee zijden onsamenhangende opsommingstekens bevatten of de reden alleen door een pictogram wordt geïmpliceerd, kan extractie het commando behouden terwijl de kwalificatie die het veilig maakt, verloren gaat.

Volg de schrijfregels voor elementen voordat je dit blok selecteert. Doel gaat voor uiterlijk. Content die hoofdzakelijk waarschuwt voor onmiddellijk gevaar blijft een waarschuwing; een reeks blijft een stappenlijst; een eindige set voltooiingscontroles blijft een checklist. Twee gekleurde kolommen maken van die doelen geen do’s en don’ts.

Wanneer gebruiken

Gebruik dit element wanneer lezers een aanbevolen praktijk moeten onderscheiden van een plausibele, consequente fout. Het contrast moet dubbelzinnigheid effectiever verminderen dan een enkele instructie. Geschikte onderwerpen zijn redactionele standaarden, implementatieconventies, kwaliteitscontroles, ontwerpgedrag, gegevensverwerking en proceskeuzes.

Al deze voorwaarden moeten waar zijn:

1. Elke fout heeft een verantwoorde vervangende actie.
2. De reden om de fout te vermijden kan in één korte zin worden geformuleerd.
3. De items zijn onafhankelijke richtlijnen, geen stappen die in volgorde moeten worden uitgevoerd.
4. Beide zijden kunnen dezelfde reikwijdte en specificiteitsniveau gebruiken.

Bijna-misser gevallen komen vaak voor:

• Voor- en nadelen: voordelen en beperkingen evalueren één optie. Do’s en don’ts instrueren het gedrag van de lezer. ‘Bevat onbeperkte projecten’ is een voordeel, geen do.
• Waarschuwing: een ernstig of onomkeerbaar gevolg heeft directe prominentie en een reactie nodig, geen gelijkwaardige begeleidende kolom.
• Checklist: een checklist registreert of vereist werk is voltooid. De niet-aangevinkte status is geen ‘Don’t.’
• Vergelijkingstabel: een tabel evalueert meerdere opties tegen gedeelde criteria. Het schrijft geen correct en incorrect gedrag voor.
• Voor en na: twee voorbeelden kunnen een bewerking tonen zonder een herbruikbare gedragsregel uit te drukken. Gebruik do’s en don’ts alleen wanneer het contrast een algemene praktijk leert.
• Willekeurige huisstijl: als er geen gevolg voor lezer, systeem, naleving of onderhoud kan worden uitgelegd, documenteer de conventie dan als regel in plaats van te doen alsof het alternatief een fout is.

Gebruik het blok niet om tegenstellingen te fabriceren. ‘Schrijf duidelijk; schrijf niet onduidelijk’ herhaalt dezelfde abstractie en leert niets. De verkeerde kant moet verleidelijk genoeg zijn om te herkennen en specifiek genoeg om te diagnosticeren.

Waar plaatsen

Plaats het blok nadat de pagina de taak, het publiek en eventuele termen die nodig zijn om de richtlijnen te begrijpen, heeft gedefinieerd. Het hoort onmiddellijk na de uitleg of demonstratie die het samenvat, of tegen het einde van een sectie als een praktische herhaling voordat de lezer handelt.

Exacte plaatsingsregels:

• Introduceer één onderwerp in de dichtstbijzijnde kop. Elk paar moet logisch zijn onder dat onderwerp zonder reikwijdte te lenen van een verre alinea.
• Zet het blok na het leidende principe en vóór een implementatiechecklist of volgende actie. Lezers moeten begrijpen waarom voordat ze voltooiing verifiëren.
• Gebruik in herhaalde secties dezelfde positie en paarlimieten. Het onvoorspelbaar verplaatsen van het blok maakt het moeilijker om over onderwerpen te scannen.
• Houd de gepaarde lijsten in bronvolgorde en visuele lay-out bij elkaar. Verklarende proza mag het volledige blok volgen, niet de zijden splitsen.

Het mag niet direct naast een ander beslissingselement met twee kolommen staan, omdat aangrenzende rasters onduidelijk maken welke labels en rijen bij elkaar horen. Plaats geen getuigenis, promotionele banner, formulier of call-to-action tussen de ‘Do’- en ‘Don’t’-zijden. Maak het niet de eerste betekenisvolle content op een pagina wanneer de regels afhangen van termen of context die de lezer nog niet heeft ontvangen.

Anatomie

Weergegeven legenda

1. Onderwerpskop: benoemt de afgebakende taak of beslissing die door elk paar wordt gedeeld.
2. Do-label: zichtbare tekst die aanbevolen gedrag identificeert; een pictogram of groene aanduiding is aanvullend.
3. Don’t-label: zichtbare tekst die te vermijden gedrag identificeert; interpunctie gebruikt de gelokaliseerde redactionele vorm.
4. Actieverklaring: één gebiedende of beschrijvende instructie die waarneembaar gedrag benoemt.
5. Reden: één zin die de instructie verbindt met een gevolg, faalmodus of leidend principe.
6. Paarrelatie: bronvolgorde en lay-out behouden welke ‘Do’ bij welke ‘Don’t’ hoort.
7. Optionele bronnotitie: identificeert het beleid, de test, de regelgeving of het bewijs dat feitelijke vereisten onderbouwt.

De auteur levert het onderwerp, de paren en de redenen. De renderer zorgt voor gelijke presentatie, responsieve stapeling, toegankelijke labels en decoratieve pictogrammen waar passend.

Ontwerpvoorbeelden

De volgende varianten zijn de volledige ondersteunde set. Ze veranderen dichtheid en rangschikking, nooit de pariteit of de redeneringsovereenkomst.

Standaard gepaarde rijen

Gebruik drie tot zeven horizontaal uitgelijnde rijen op brede schermen. Elke rij bevat één ‘Do’ en één ‘Don’t’ over hetzelfde onderwerp.

Gestapelde mobiele paren

Houd bij smalle breedtes elk paar bij elkaar: ‘Do’, dan ‘Don’t’, dan het volgende paar. Het stapelen van alle positieve items vóór alle negatieve items zou de correspondentie verbergen.

Voorbeeldgeleide variant

Gebruik wanneer exact taalgebruik, opmaak of interfacegedrag nuttiger is dan een abstract commando. Elke kant toont één kort voorbeeld gevolgd door de reden. Code blijft selecteerbare tekst.

Compacte herhalingsvariant

Alleen gebruiken wanneer de bepalende redenen al direct hierboven zijn uitgelegd. De reden verschijnt nog steeds in elk item, maar in een korte zin in plaats van een aparte alinea.

Maak geen alleen-pictogram-, carrousel-, tab- of onafhankelijk inklapbare varianten. Ze scheiden het paar, verbergen één kant of maken vergelijking afhankelijk van interactie.

Parameters

Het contract modelleert paren in plaats van twee onsamenhangende lijsten. ‘Bron’ beschrijft waar de renderer elke waarde verkrijgt.

De eerste bodykop wijst naar heading. Elk genest pair bevat beide acties en beide redenen. Het bronmodel mag niet alle positieve items apart van alle negatieve items opslaan, omdat dat de rijcorrespondentie afhankelijk maakt van arraypositie en gemakkelijk te breken is tijdens het bewerken.

Syntax en codevoorbeelden

Alle drie formaten behouden hetzelfde onderwerp, dezelfde paarvolgorde, acties en redenen. Ze leiden geen reden af uit de actie en creëren niet automatisch een positief item.

Draagbare Markdown-richtlijn

:::dos-and-donts
## Vergelijkingsclaims schrijven

::item{do="Noem het exacte abonnement en de gecontroleerde datum" dont="Publiceer geen ongedateerde prijs"}
### Do
Commerciële feiten veranderen, dus afbakening stelt lezers in staat de claim te verifiëren en te hergebruiken.

### Don't
Lezers kunnen niet zien welk abonnement of welke periode een ongedateerd bedrag beschrijft.
::

::item{do="Vergelijk beide producten op hetzelfde criterium" dont="Vergelijk geen niet-gerelateerde mogelijkheden"}
### Do
Een gedeelde maatstaf maakt het verschil betekenisvol.

### Don't
Verschillende criteria wekken de schijn van vergelijking zonder een valide keuze.
::
:::

Dit element overschrijft de standaard itemtoewijzing: de bovenliggende kop levert heading; itemattributen leveren de acties; de eerste ‘Do’- en ‘Don’t’-subkoppen wijzen hun volgende tekst toe aan de twee redenen.

Hugo shortcode

Er is momenteel geen productie-Hugo-shortcode die het gepaarde-recordcontract implementeert. Zolang die niet bestaat, render dan semantische HTML zoals het live voorbeeld in plaats van twee niet-gerelateerde lijsthulpen te gebruiken. De beoogde adapter is:

{{< dos-and-donts >}}
## Vergelijkingsclaims schrijven

{{< do-dont-pair do="Noem het exacte abonnement en de gecontroleerde datum" dont="Publiceer geen ongedateerde prijs" >}}
### Do
Commerciële feiten veranderen, dus afbakening stelt lezers in staat de claim te verifiëren en te hergebruiken.
### Don't
Lezers kunnen niet zien welk abonnement of welke periode een ongedateerd bedrag beschrijft.
{{< /do-dont-pair >}}
{{< /dos-and-donts >}}

De toekomstige renderer moet één gelabelde regio met een lijst van gepaarde records produceren. Het mag geen twee arrays maken en deze per index zippen na het renderen.

WordPress-blok of shortcode

[dos_and_donts heading="Vergelijkingsclaims schrijven" variant="standard"]
[pair]
[do action="Noem het exacte abonnement en de gecontroleerde datum"]Commerciële feiten veranderen, dus afbakening stelt lezers in staat de claim te verifiëren en te hergebruiken.[/do]
[dont action="Publiceer geen ongedateerde prijs"]Lezers kunnen niet zien welk abonnement of welke periode een ongedateerd bedrag beschrijft.[/dont]
[/pair]
[pair]
[do action="Vergelijk beide producten op hetzelfde criterium"]Een gedeelde maatstaf maakt het verschil betekenisvol.[/do]
[dont action="Vergelijk geen niet-gerelateerde mogelijkheden"]Verschillende criteria wekken de schijn van vergelijking zonder een valide keuze.[/dont]
[/pair]
[/dos_and_donts]

Een aangepast WordPress-blok moet elk paar als één record bewerken en publicatie voorkomen wanneer een actie of reden ontbreekt.

Voorbeelden

Goed: gelijkwaardig, uitvoerbaar en onderbouwd

De paren delen een onderwerp in elke rij: abonnementsscope, tijdsvenster en bewijsstatus. Beide acties zijn specifiek genoeg om te beoordelen in een concept, en elke reden legt uit wat er mis kan gaan. Een lezer kan het principe toepassen, zelfs wanneer de exacte prijs, product of periode verandert.

Slecht: twee stapels commando’s

Dit faalt omdat de kolommen niet gerelateerd en ongelijk zijn. ‘Wees accuraat’ heeft geen waarneembare voltooiingsvoorwaarde, terwijl ‘Gebruik nooit jargon’ taal verbiedt zonder noodzakelijke termen van onverklaarde termen te onderscheiden. Geen van de negatieve items vermeldt een gevolg, en de lege cel onthult dat de auteur twee lijsten heeft gemaakt in plaats van vier paren.

Herstel het blok door één onderwerp te kiezen en vervolgens gelijkwaardige rijen te schrijven. Voor terminologie zou het paar kunnen zijn: ‘Definieer een noodzakelijke vakterme bij eerste gebruik, omdat de definitie nieuwkomers in staat stelt de argumentatie te volgen’ en ‘Vervang een precieze term niet door een vage alledaagse uitdrukking, omdat de vervanging de betekenis kan veranderen.’ De correctie leert oordeelsvermogen in plaats van een slogan op te leggen.

Schema-opmaak en toegankelijkheid

Schema.org biedt geen algemeen DoAndDont-type. Houd het zichtbare blok binnen de omringende Article, TechArticle, HowTo of andere paginaniveau-gestructureerde gegevens wanneer de pagina daar daadwerkelijk voor in aanmerking komt. Converteer de positieve items niet naar HowToStep-records tenzij ze een geordende procedure vormen, en publiceer de paren niet als FAQPage alleen omdat ze korte uitleg bevatten.

Gebruik native koppen en lijsten. Eén buitenste sectie krijgt zijn toegankelijke naam van de onderwerpskop. Elk paar moet één lijstitem of gegroepeerd record zijn met een zichtbaar ‘Do’-label en een zichtbaar ‘Don’t’-label. Behoud elk paar in bronvolgorde, zodat een schermvoorlezergebruiker de aanbeveling en de bijpassende fout samen tegenkomt.

Kleur en pictogrammen zijn aanvullend. Groen kan niet het enige signaal voor ‘Do’ zijn, en een kruis kan niet het enige signaal voor ‘Don’t’ zijn. Decoratieve pictogrammen krijgen lege alt-tekst of zijn verborgen voor ondersteunende technologie. Maak een statisch blok niet focusbaar. Als horizontale overflow onvermijdelijk is voor een voorbeeldtabel, bevat en label dan de scrollregio; de productiecomponent moet in plaats daarvan paren stapelen.

De samentrekking ‘Don’t’ is acceptabel als zichtbare redactionele tekst. Codevelden gebruiken ASCII-veilige dont waar apostrofs attribuutnamen zouden compliceren. Renderers lokaliseren de labels zonder de opgeslagen acties of redenen te wijzigen.

Schrijfregels

Schrijf de reden voordat je het commando finaliseert. Dit dwingt de auteur om het gevolg voor lezer, systeem, veiligheid, naleving of onderhoud te identificeren. Als er geen verdedigbare reden kan worden geschreven, is het verbod mogelijk eerder een voorkeur dan een richtlijn.

Gebruik drie tot zeven paren. Elke actie moet waar mogelijk één waarneembaar gedrag uitdrukken in 110 tekens of minder. Geef elke kant één redenzin van maximaal 180 tekens. De limieten houden beide zijden scanbaar; langere kwalificaties horen in de omringende proza.

Handhaaf pariteit over vijf dimensies:

• Onderwerp: beide acties hebben betrekking op dezelfde beslissing of hetzelfde artefact.
• Abstractieniveau: een precieze opmaakregel kan niet worden gepaard met een breed motto zoals ‘schrijf goed.’
• Grammatica: gebruik parallelle gebiedende wijs of parallelle beschrijvende zinnen.
• Bewijs: pas dezelfde feitelijke en bronnendrempel toe op beide zijden.
• Visueel gewicht: geen van beide zijden krijgt meer ruimte, nadruk, detail of standaardzichtbaarheid.

Gebruik directe, neutrale taal. Geef de voorkeur aan ‘Publiceer geen niet-geverifieerde prijs’ boven beschamende taal zoals ‘Alleen onachtzame schrijvers vergeten prijzen te verifiëren.’ Vermijd sarcasme, angst en absolute termen, tenzij de regel werkelijk absoluut is en de reikwijdte ervan wordt vermeld.

Plaats nooit het volgende in het element:

• Niet-gerelateerde tips toegevoegd om één kant te vullen of numerieke symmetrie af te dwingen.
• Een verbod zonder gevolg, principe of vervangende actie.
• Geordende procedures, selectievakjes, beoordelingen, uitspraken of productvoor- en nadelen.
• Veiligheidskritische waarschuwingen, juridische disclaimers, noodinstructies of meldingen van onomkeerbare acties.
• Getuigenissen, lange citaten, media, formulieren, calls-to-action, promotieknoppen of couponcodes.
• Geneste accordeons, tabbladen, carrousels, vergelijkingstabellen of een ander do’s-en-don’ts-blok.
• Beweringen over mensen of groepen, geformuleerd als moreel falen in plaats van waarneembaar gedrag.

Wanneer een vereiste afkomstig is van een beleid, regelgeving, test of externe standaard, voeg dan een bronnotitie in de buurt toe. Ken de regel precies genoeg toe zodat een redacteur deze opnieuw kan controleren; laat het blok geen lang citatieapparaat dragen.

Artikeltypen die het gebruiken

De postTypes frontmatter-array stuurt deze gebruikstabel. Opname maakt het element beschikbaar onder de vermelde voorwaarde; het maakt het blok niet verplicht op elke pagina van dat type.

QA-checklist

• Het blok heeft één afgebakend onderwerp dat duidelijk is uit de dichtstbijzijnde kop.
• Het leidende principe verschijnt vóór het blok, zodat de paren de regel versterken in plaats van verzinnen.
• Er zijn drie tot zeven complete paren en exact hetzelfde aantal ‘Do’- en ‘Don’t’-acties.
• Elk paar heeft betrekking op hetzelfde onderwerp, publiek, reikwijdte en specificiteitsniveau.
• Elke ‘Don’t’ benoemt een realistische fout en legt het gevolg of de faalmodus uit.
• Elke ‘Do’ biedt een uitvoerbare vervanging en legt uit waarom het werkt.
• Geen item ontkent slechts zijn partner, herhaalt een slogan of gebruikt cirkelredeneringen.
• Acties bevatten één gedrag en blijven dicht bij de 110-tekendoelstelling.
• Redenen bevatten één zin en blijven binnen 180 tekens.
• Beide zijden gebruiken parallelle grammatica, bewijsstandaarden, detail en visueel gewicht.
• Feitelijke vereisten identificeren waar nodig het beleid, de regelgeving, de test of de bron.
• Het blok bevat geen stappen, checkstatussen, productafwegingen, ernstige waarschuwingen, promotie, formulieren of geneste complexe elementen.
• Zichtbare tekst zegt ‘Do’ en ‘Don’t’; kleur, positie en pictogrammen zijn niet de enige signalen.
• Responsieve output houdt elk paar bij elkaar in plaats van alle positieve items vóór alle negatieve items te stapelen.
• De onderwerpskop en paarstructuur blijven begrijpelijk in platte tekst en wanneer stijlen of scripts niet beschikbaar zijn.
• Gestructureerde gegevens beschrijven alleen de omringende pagina en verzinnen geen do’s-en-don’ts-schematype.
• Screenshotopmerkingen blijven niet-renderende vastleginstructies totdat echte assets bestaan.

Veelgestelde vragen

De academy-sjabloon geeft de vijf vragen weer die zijn opgeslagen in de [[faq]] frontmatter van deze pagina. Ze behandelen paarvolledigheid, numerieke pariteit, redenen, gestructureerde gegevens en itemtelling.