Indholdselementer: blokkene som hver side er bygget af
Brug et styret bibliotek af definitioner, svar, trin, sammenligninger, evidens, notifikationer, navigation og konverteringsblokke, så hvert afsnit bevarer sin funktion på tværs af forfattere, sider, maskiner og CMS'er.
Et element er en indholdskontrakt
En navngiven, typiseret, parameteriseret blok definerer, hvad der hører indeni, hvor meget den må indeholde, hvor den må optræde, og hvad systemer må gøre med den.
- ✓Navngivet efter formål — definition, advarsel, sammenligning, kilde og CTA beskriver job frem for visuelle stilarter.
- ✓Afgrænset af parametre — etiketter, emner, citater, varianter og grænser forhindrer improviserede strukturer i at drive.
- ✓Placeret efter regel — et åbningssvar, advarsel i flow, afsluttende kildeblok og næste-trin CTA optager forskellige dele af et dokument.
- ✓Gengivet efter kanal — ét element kan blive semantisk HTML i Hugo, en native WordPress-blok, strukturerede data eller en feed-post.
Hvad et indholdselement er
Fri tekst gemmer sætninger. Et indholdselement gemmer sætninger plus en eksplicit redegørelse for, hvad disse sætninger gør.
En forfatter tilføjer en H2 kaldet "Hvad er churn?", følger op med et afsnit og giver måske den første sætning fed skrift. En læser kan udlede, at det er en definition. Indholdssystemet ser kun en overskrift og prosa.
Intet registrerer, om definitionen er kanonisk, om den skal være tæt på åbningen, hvilket begreb den definerer, hvor lang den må være, eller om en anden kanal må genbruge den.
Forfatteren indsætter et definition-element med et term, en kortfattet body og en valgfri kvalifikator. Elementkontrakten styrer placering, tilgængeligt markup, længde og præsentation.
En skabelon kan gengive det, en revision kan finde det, en migrering kan kortlægge det, og et svar-system kan skelne definitionen fra omgivende forklaring.
Et element er en navngiven, typiseret, parameteriseret indholdsblok. "Navngiven" giver det en stabil identitet. "Typiseret" forbinder det til adfærd. "Parameteriseret" betyder, at dets meningsfulde dele er felter i stedet for en udifferentieret klump. Det bærer også placeringsregler, indholdsgrænser, varianter, tilgængelighedskrav, skemakortlægninger og QA-tjek.
Dette eliminerer ikke prosa. En definition, advarsel eller kilde-bemærkning kræver stadig præcis skrivning. Det eliminerer tvetydighed om prosadens job. Sprog kan variere, mens kontrakten overholdes, ligesom forskellige poster indeholder forskellige data, mens de deler ét skema.
Hvorfor elementer slår indholdsbriefs
En prosabrief kan beskrive den ønskede side. Typiserede elementer bevarer dens vigtige beslutninger, efter briefen forlader redaktørens skærm.
Målet er ikke, at hver side ser identisk ud. Det er, at gentagne funktioner opfører sig forudsigeligt. En case study- og en ordbogsside kan have forskellige stemmer og layouts, mens deres kilder forbliver forespørgelige, og deres relateret-indhold-blokke forbliver styrede.
Elementets prioritetsregel
Hvis et elements formål matcher, hvad sektionen gør, er det element obligatorisk—selvom en overskrift og et afsnit kunne vise de samme ord. Fri tekst er nødløsningen, ikke standarden.
Søg ikke kun efter etiketten i dispositionen. "Kliniske overvejelser" kan skjule en advarsel. "Med ét blik" kan betyde vigtige pointer. Navngiv læserens opgave: definer, opsummer, advar, sammenlign, instruer, bevis, naviger eller konverter.
Tjek derefter formålserklæringer. Et matchende formål har forrang over en tilpasset overskrift, fordi typen bevarer funktion uden for den synlige side.
Fri tekst er rigtigt til analyse, overgange, eksempler og forklaringer uden genanvendelig kontrakt. Det skal forbinde elementer og udvikle argumentet, ikke efterligne en eksisterende komponent.
Hvis et fri-tekst-mønster gentager sig, registrer det til biblioteksgennemgang. Gentagelse kan afsløre et manglende element, men forfattere bør ikke oprette uofficielle komponenter side for side.
| Dispositionsordlyd | Formål | Påkrævet valg | Hvad prosa mister |
|---|---|---|---|
| "Hvad er X?" | Giv én afgrænset betydning | definitionsboks | Definitionen kan ikke skilles pålideligt fra kontekst. |
| "Hvornår skal man søge hjælp" eller "kontraindikationer" | Angiv risiko, konsekvens og sikker handling | advarselsboks | En stopbetingelse har ingen advarselssemantik. |
| En praktisk sidebemærkning | Tilbyd valgfrit udførelsesråd | tip-boks | Sidebemærkningen konkurrerer med eller forsvinder i påkrævede trin. |
| Opsummeringen øverst | Fremhæv underbyggede konklusioner | vigtige pointer | En løs liste har ingen placering, grænse eller opsummeringsbetydning. |
| En tjekliste | Spor fuldførelsesstatusser | Tjeklisteelement | Punkttegn adskiller ikke handlinger fra observationer eller status. |
Tjeklisteeksemplet er uden link, fordi dets detaljerede specifikation tilhører en senere biblioteksbølge. Prioritetsbeslutningen gælder stadig: brug en godkendt tjeklisteimplementering, hvor CMS'et tilbyder det; forklæd ikke fuldførelsesstatusser som dekorative punkttegn.
Typiserede blokke vs ren tekst
Den synlige sætning er identisk. Den typiserede version bevarer identitet og felter, som downstream-systemer kan bruge uden at gætte.
Kundefrafald er tabet af kunder eller abonnenter i en målt periode.
Gem som
{ "heading": "What is customer churn?",
"html": "<p>Customer churn is…</p>" }Maskinoutput: overskrift og generisk HTML. Definitionens status, term, placering og genbrug er ukendte.
Kundefrafald er tabet af kunder eller abonnenter i en målt periode.
Gem som
{ "type": "definition",
"term": "customer churn",
"body": "Customer churn is…",
"position": "opening" }Maskinoutput: en kendt definition med adresserbare felter, validering, semantisk gengivelse, skemakortlægning og feed-berettigelse.
Forskellen er funktionel, ikke kosmetisk. Erstat komponenten med en overskrift og et afsnit, og læseren bemærker måske intet, mens systemet mister validering, analyser, skemakortlægning, migreringslogik og porteføljeforespørgsler. At bytte et typiseret element med fri tekst er et tab af funktion.
De elleve elementgrupper
Hvert live-kort spejler børnesidens playbookFamily-metadata. Antal beskriver det udgivne elementbibliotek planlagt til senere bølger.
Læs først — prioritetsreglen, der styrer alle andre elementer.
Posten, der driver identitet, opdagelse og skema.
Den første skærm: svar, opsummering, definition, orientering.
Definitionsboks · Blok til direkte svar · Friskhedsstempel · Introduktionshook · Boks med vigtige pointer · Indholdsfortegnelse · Hvem er dette til? Regler for målgruppeblok
Blokkene, der bærer argumentet.
Accordion · Punktlister · Tjekliste · Tilpassede lister · Beslutningstræ · Gør og lad være · Regler for fri-tekst-afsnit · Overskriftssystem · Ikonboks · Billedboks · Infobox · Infobox · Trinlister · Faner / Personaskifter · Tidslinjer · Zigzag-sektioner
Strukturerede fakta, som både en læser og en maskine kan bruge.
Integrerede regnemaskiner · Diagramblokke · Sammenligningstabeller · Prisskemaer · Fordele og ulemper-blokke · Scorekort · Specifikationstabeller · Statistikbånd
Tips, noter og advarsler — brug sparsomt eller slet ikke.
Billeder, video, diagrammer og deres teksteækvivalenter.
Annoterede skærmbilleder · Integreret lyd og podcasts · Diagrammer og illustrationer · Billedgalleri · Inline-billeder · Inline-video · Videointegrering
Produkt, pris, tilgængelighed og sammensætning.
Tilgængelighedsblokke · Sammensætningsblokke · Tilbudsbokse · Produktkort · Produktslidere
Forfatterskab, gennemgang, citat og social proof.
Forfatterbiografiblok · Ansvarsfraskrivelsesblok · Udtrækscitat og ekspertcitat · Gennemgået af-blok · Anmeldelsesblokke · Kilder og referencer · Udtalelser · Tillidsmærker og certificeringer · Opdateringslog
Links, ankre og næste handling.
Ankerlinks · Brødkrummer · CTA-blokke · Ordbogsterm-links og tooltips · Inline CTA-knap · Interne linkmoduler · Mini-banner · Nyhedsbrevsindfangning · Relateret indhold-blokke
Åbningstider, adresse, kort og booking.
Bookingblokke · Åbningstider og kontaktblokke · Kortblokke · NAP-blokke
Hvordan en side slutter, og hvad den spørger om næste gang.
Ét element, tre formater
Hvert element har én konceptuel kontrakt og adaptere til portabel Markdown, Hugo og WordPress.
Overvej et tip med en titel og brødtekst med valgfri rådgivning. Dets formål, tilladte indhold, tilgængelighedsrolle, placering og QA-regler forbliver konstante. Kun notationen ændres.
:::tip{title="Keep the query stable"}
Change one variable at a time.
:::Læsbart i kildekode og uafhængigt af sidetema.
{{< callout type="tip" title="Keep the query stable" >}}
Change one variable at a time.
{{< /callout >}}Adapteren kortlægger navngivne felter til den godkendte komponent.
<!-- wp:amicited/tip
{"title":"Keep the query stable"} -->
<p>Change one variable at a time.</p>
<!-- /wp:amicited/tip -->Native redigeringskontroller bevarer samme type og felter.
Portabilitet er ikke at kopiere gengivet HTML. Hver adapter accepterer det samme meningsfulde input, håndhæver tilsvarende begrænsninger og producerer kanalpassende output. Hvis et felt ikke kan kortlægges sikkert, skal adapteren fejle synligt eller dokumentere en kontrolleret nødløsning; den må ikke kassere betydning lydløst.
Hvad er der på hver elementside
Hver detaljeside er offentlig vejledning og en produktionsspecifikation. Den fjerner gætterier, der ellers vender tilbage i hver implementering.
| Område | Spørgsmål besvaret | Fejl forhindret |
|---|---|---|
| Formål og ikke-formål | Hvilket job udfører det, og hvilket lignende job hører til andetsteds? | Et tip, der bærer et påkrævet trin, eller en definition, der bliver en mini-artikel. |
| Parametertabel | Hvilke felter er påkrævede, valgfrie, typiserede, gentagelige og begrænsede? | Adaptere, der accepterer forskellige data, eller flere ideer gemt i ét felt. |
| Placeringsregler | Hvor må det optræde, hvor ofte og ved siden af hvad? | Pointer begravet midt på siden eller kilder løsrevet fra påstande. |
| Variantgalleri | Hvilke navngivne variationer findes, og hvornår er hver passende? | Visuelle engangsløsninger, der udgiver sig for at være officielle varianter. |
| Godt versus dårligt | Hvad gør et overholdende eksempel, som et plausibelt fejltrin misser? | Teams, der kopierer syntaks, mens de misser formålet. |
| Skemakortlægning | Hvordan kortlægges felter til HTML, tilgængelighed, skema, API'er og feeds? | Synligt indhold, der er uenig med maskinoutput. |
| QA | Hvad kan automation håndhæve, og hvad kræver dømmekraft? | En gyldig blok, der udgives med vagt, falsk, forældet eller fejlplaceret indhold. |
Automation kan tjekke påkrævede felter, antal, længder, placering, identifikatorer, URL'er og adapterunderstøttelse. Redaktionel QA må tjekke nøjagtighed, anvendelighed, evidenskvalitet, proportional vægtning og om elementet er rigtigt til læserens opgave.
Hvilke elementer er påkrævede
Obligatorisk betyder, at systemet forventer funktionen i stort set alle komplette indlægstyper. Det betyder ikke, at hver blok skal være stor eller identisk.
- Frontmatter etablerer identitet, ejerskab, opdagelse og sammenkoblinger.
- Introduktion bekræfter omfang og læser-match.
- Vigtige pointer fremhæver underbyggede konklusioner på væsentlige sider.
- FAQ besvarer reelle resterende spørgsmål.
- Kilder gør faktuel understøttelse sporbar.
- Relateret indhold tilbyder næste læringsvej.
- CTA tilbyder én passende handling.
- Brug en definition, når et begreb har brug for en afgrænset betydning.
- Brug et direkte svar til et klart primært spørgsmål.
- Brug trin til en ordnet procedure og verificerbart resultat.
- Brug sammenligninger, når læsere vurderer alternativer på konsistente kriterier.
- Brug et tip til valgfri forbedring og en advarsel til væsentlig risiko.
- Brug annoterede medier, når det visuelle kommunikerer noget, som prosa ikke kan lige så effektivt.
Undtagelser betyder noget. En kort ordbogsdefinition har måske ikke brug for separate pointer. En side uden eksternt understøttet faktuel påstand har måske ikke brug for synlige referencer. En FAQ med opfundne spørgsmål er værre end ingen. Indlægstype-specifikationer sætter standarder; forfattere dokumenterer begrundede udeladelser i stedet for at udfylde pladser mekanisk.
Start med den relevante indlægstype-specifikation, som bestiller de sædvanlige elementer til læserens opgave. Anvend derefter prioritet afsnit for afsnit. Resultatet er hverken en blank side eller en rigid form: det er styret sammensætning med plads til originalt argument, evidens, eksempler og stemme.
Typiserede elementer lader en agent samle i stedet for at opfinde
Elementbiblioteket er, hvor et indholdssystem holder op med at være et dokument og bliver noget, en maskine kan udføre. En blok med erklærede felter har enten hvad den har brug for, eller også har den det tydeligvis ikke.
En sammenligningstabel har brug for sammenlignelige muligheder, en angivet dimension pr. række og en verifikationsdato. Når en af disse input ikke eksisterer, giver en typiseret blok agenten et sted at fejle højlydt.
Fri prosa har ingen sådan egenskab. Bedt om en tabel uden data bagved, producerer en agent alligevel en tabel, og den opfundne celle ser nøjagtig ud som en undersøgt.
Tjek biblioteket efter formål, før du skriver en overskrift. Den instruktion følges langt mere pålideligt af en agent end af en person under deadline, fordi en agent virkelig vil genlæse hele biblioteket hver gang.
Dette er et tilfælde, hvor agenten er den bedre operatør: reglen er mekanisk, og mekanisk er hvad agenter er til for.
Hvert element defineres én gang og udtrykkes som et portabelt Markdown-direktiv, en Hugo-shortcode og en WordPress-blok. Agenten arbejder mod den portable form og behøver aldrig at vide, hvilket CMS outputtet lander i.
Det betyder også, at skift af CMS ikke ugyldiggør indholdssystemet eller kræver genoplæring af agenten.
Fordi elementer er typiserede, kan korpus forespørges. Hvilke sider mangler en kildeblok. Hvilke sammenligningstabeller har ingen verifikationsdato. Hvilke direkte svar overskrider deres bånd.
Du kan kun køre den revision på indhold sammensat af navngivne blokke. Prosa er ikke forespørgelig, så prosabaseret kvalitetskontrol skalerer ikke ud over det antal sider, en person kan læse.
Hver elementside bærer en parametertabel med påkrævede felter, minimums- og maksimumsgrænser, placeringsregler og en QA-tjekliste. Det er det præcisionsniveau, en agent har brug for at bygge uden at gætte — og samme præcision gør outputtet gennemgåeligt af et menneske på en brøkdel af tiden.
Indholdselementer FAQ
Et indholdselement er en navngiven, typiseret, parameteriseret blok med et defineret formål, tilladte felter, placeringsregler, længdebegrænsninger, gengivelsesadfærd og kvalitetskontroller. Det gemmer indhold og funktion.
Brug fri tekst, når intet bibliotekselement matcher formålet. Analyse, fortælling, overgange og unikke forklaringer forbliver ofte prosa; etablerede definitioner, advarsler, sammenligninger, kilder og CTA'er gør ikke.
Nej. Kontrakten standardiserer struktur og funktion, ikke konklusioner eller stemme. Forfattere vælger stadig argumenter, evidens, eksempler og ordvalg.
Ja. Den portable kontrakt er uafhængig af præsentation. Adaptere kortlægger de samme felter til native syntaks og markup, mens validering og semantik bevares.
Byg én side af blokke, du kan styre i stor skala
Gratis tjek · 7-dages prøveperiode · kreditkort påkrævet