Innholdselementer: blokkene hver side er bygget av
Bruk et styrt bibliotek av definisjoner, svar, steg, sammenligninger, bevis, varsler, navigasjon og konverteringsblokker, slik at hver seksjon beholder sin funksjon på tvers av forfattere, sider, maskiner og CMS-er.
Et element er en innholdskontrakt
En navngitt, typet, parameterisert blokk definerer hva som hører hjemme inni den, hvor mye den kan inneholde, hvor den kan vises, og hva systemer kan gjøre med den.
- ✓Navngitt etter formål — definisjon, advarsel, sammenligning, kilde og CTA beskriver jobber snarere enn visuelle stiler.
- ✓Avgrenset av parametere — etiketter, elementer, sitater, varianter og grenser forhindrer improviserte strukturer fra å drive.
- ✓Plassert etter regler — et åpningssvar, advarsel i flyten, avsluttende kildeblokk og CTA for neste steg opptar ulike deler av et dokument.
- ✓Gjengitt per kanal — ett element kan bli semantisk HTML i Hugo, en naturlig WordPress-blokk, strukturerte data eller en feed-post.
Hva et innholdselement er
Fri tekst lagrer setninger. Et innholdselement lagrer setninger pluss en eksplisitt redegjørelse for hva disse setningene gjør.
En forfatter legger til en H2 kalt «Hva er kundefrafall?», følger opp med et avsnitt, og kan gi første setning fet skrift. En leser kan slutte at det er en definisjon. Innholdssystemet ser bare en overskrift og prosa.
Ingenting registrerer om definisjonen er kanonisk, om den må være nær åpningen, hvilket begrep den definerer, hvor lang den kan være, eller om en annen kanal kan gjenbruke den.
Forfatteren setter inn et definition-element med et term-felt, en konsis body og en valgfri kvalifikator. Elementkontrakten styrer plassering, tilgjengelig markering, lengde og presentasjon.
En mal kan gjengi det, en revisjon kan finne det, en migrasjon kan kartlegge det, og et svar-system kan skille definisjonen fra omkringliggende forklaring.
Et element er en navngitt, typet, parameterisert innholdsblokk. «Navngitt» gir det en stabil identitet. «Typet» kobler det til atferd. «Parameterisert» betyr at de meningsbærende delene er felt i stedet for en udifferensiert klump. Det bærer også plasseringsregler, innholdsbegrensninger, varianter, tilgjengelighetskrav, skjematilordninger og kvalitetssjekker.
Dette eliminerer ikke prosa. En definisjon, advarsel eller kildehenvisning trenger fortsatt presist språk. Det eliminerer tvetydighet om prosaens jobb. Språket kan variere samtidig som kontrakten overholdes, akkurat som ulike poster inneholder ulike data mens de deler ett skjema.
Hvorfor elementer slår innholds-briefinger
En prosa-briefing kan beskrive den ønskede siden. Typede elementer bevarer de viktige beslutningene etter at briefingen forlater redaktørens skjerm.
Målet er ikke at hver side skal se identisk ut. Det er at gjentatte funksjoner oppfører seg forutsigbart. En casestudie og en ordliste-side kan ha ulike stemmer og oppsett, mens kildene forblir søkbare og blokkene for relatert innhold forblir styrte.
Prioritetsregelen for elementer
Hvis et elements formål matcher det seksjonen gjør, er elementet obligatorisk — selv om en overskrift og et avsnitt kunne vise de samme ordene. Fri tekst er reservealternativet, ikke standarden.
Ikke søk bare etter etiketten i disposisjonen. «Kliniske betraktninger» kan skjule en advarsel. «Med et blikk» kan bety nøkkelinnsikter. Navngi leserens oppgave: definere, oppsummere, advare, sammenligne, instruere, bevise, navigere eller konvertere.
Merk deretter formålsbeskrivelser. Et matchende formål har forrang fremfor en tilpasset overskrift fordi typen bevarer funksjon utenfor den synlige siden.
Fri tekst er riktig for analyse, overganger, eksempler og forklaringer uten en gjenbrukbar kontrakt. Den skal koble sammen elementer og utvikle argumentet, ikke etterligne en eksisterende komponent.
Hvis et mønster med fri tekst gjentar seg, noter det for bibliotekvurdering. Gjentakelse kan avsløre et manglende element, men forfattere bør ikke opprette uoffisielle komponenter side for side.
| Overskriftsordlyd | Formål | Påkrevd valg | Hva prosa mister |
|---|---|---|---|
| «Hva er X?» | Gi én avgrenset betydning | definisjonsboks | Definisjonen kan ikke skilles pålitelig fra konteksten. |
| «Når bør man søke hjelp» eller «kontraindikasjoner» | Angi risiko, konsekvens og trygg handling | advarselsboks | En stoppbetingelse har ingen advarselssemantikk. |
| En praktisk sidebemerkning | Tilby valgfritt utførelsesråd | tipsboks | Sidebemerkningen konkurrerer med eller forsvinner inni nødvendige steg. |
| Oppsummeringen øverst | Presenter underbygde konklusjoner | nøkkelinnsikter | En løs liste har ingen plassering, begrensning eller oppsummeringsbetydning. |
| En liste å krysse av | Spor fullføringsstatus | Sjekklisteelement | Punktlister skiller ikke handlinger fra observasjoner eller status. |
Sjekklisteeksemplet er ikke lenket fordi detaljspesifikasjonen tilhører en senere bibliotekbølge. Prioritetsbeslutningen gjelder likevel: bruk en godkjent sjekklisteimplementering der CMS-et tilbyr det; ikke masker fullføringsstatus som dekorative punktlister.
Typede blokker vs ren tekst
Den synlige setningen er identisk. Den typede versjonen beholder identitet og felt som nedstrømssystemer kan bruke uten å gjette.
Kundefrafall er tap av kunder eller abonnenter i løpet av en målt periode.
Lagret som
{ "heading": "Hva er kundefrafall?",
"html": "<p>Kundefrafall er…</p>" }Maskinutdata: overskrift og generisk HTML. Definisjonsstatus, begrep, plassering og gjenbruk er ukjent.
Kundefrafall er tap av kunder eller abonnenter i løpet av en målt periode.
Lagret som
{ "type": "definition",
"term": "kundefrafall",
"body": "Kundefrafall er…",
"position": "åpning" }Maskinutdata: en kjent definisjon med adresserbare felt, validering, semantisk gjengivelse, skjematilordning og feed-kvalifisering.
Forskjellen er funksjonell, ikke kosmetisk. Bytt ut komponenten med en overskrift og et avsnitt, og leseren merker kanskje ingenting, mens systemet mister validering, analyse, skjematilordning, migreringslogikk og porteføljesøk. Å bytte et typet element med fri tekst er et funksjonstap.
De elleve elementgruppene
Hvert levende kort speiler metadata for playbookFamily fra undersidene. Antall beskriver det publiserte elementbiblioteket planlagt for senere bølger.
Les først — prioritetsregelen som styrer alle andre elementer.
Posten som driver identitet, oppdagbarhet og skjema.
Den første skjermen: svar, oppsummering, definisjon, orientering.
Definisjonsboks · Direkte svar-blokk · Ferskhetsstempel · Introduksjonskrok · Nøkkelinnsikts-boks · Innholdsfortegnelse · Hvem er dette for? Regler for målgruppeblokker
Blokkene som bærer argumentet.
Accordion · Punktlister · Sjekkliste · Tilpassede oppføringer · Beslutningstre · Gjør og unngå · Regler for frie tekstavsnitt · Overskriftssystem · Ikonboks · Bildeboks · Infoboks · Infoboks · Steglister · Faner / Persona-veksler · Tidslinjer · Sikksakk-seksjoner
Strukturerte fakta som både en leser og en maskin kan bruke.
Kalkulatorinnbygging · Diagramblokker · Sammenligningstabeller · Priseksempler · Fordeler og ulemper-blokker · Resultatkort · Spesifikasjonstabeller · Statistikkbånd
Tips, notater og advarsler — brukt sparsomt eller ikke i det hele tatt.
Bilder, video, diagrammer og deres tekste kvivalenter.
Annoterte skjermbilder · Lyd- og podkastinnbygging · Diagrammer og illustrasjoner · Bildegalleri · Inline-bilder · Inline-video · Videoinnbygging
Produkt, pris, tilgjengelighet og sammensetning.
Tilgjengelighetsblokker · Sammensetningsblokker · Tilbudsbokser · Produktkort · Produktglidere
Forfatterskap, vurdering, sitering og sosialt bevis.
Forfatterbiografi-blokk · Ansvarsfraskrivelse · Fremhevet sitat og ekspertsitat · Gjennomgått av-blokk · Anmeldelsesblokker · Kilder og referanser · Attester · Tillitsmerker og sertifiseringer · Oppdateringslogg
Lenker, ankerpunkter og neste handling.
Ankerlenker · Brødsmuler · CTA-blokker · Ordlistelenker og verktøytips · Inline CTA-knapp · Moduler for interne lenker · Minibanner · Nyhetsbrevfanging · Relatert innhold-blokker
Åpningstider, adresse, kart og booking.
Bookingsblokker · Åpningstider og kontaktblokker · Kartblokker · NAP-blokker
Hvordan en side avsluttes, og hva den spør om videre.
Ett element, tre formater
Hvert element har én konseptuell kontrakt og tilpassere for portabel Markdown, Hugo og WordPress.
Tenk på et tips med en tittel og brødtekst med valgfrie råd. Dets formål, tillatte innhold, tilgjengelighetsrolle, plassering og kvalitetssikringsregler forblir konstante. Bare notasjonen endres.
:::tip{title="Hold spørringen stabil"}
Endre én variabel om gangen.
:::Lesbart i kildekoden og uavhengig av sidens tema.
{{< callout type="tip" title="Hold spørringen stabil" >}}
Endre én variabel om gangen.
{{< /callout >}}Tilpasseren kartlegger navngitte felt til den godkjente komponenten.
<!-- wp:amicited/tip
{"title":"Hold spørringen stabil"} -->
<p>Endre én variabel om gangen.</p>
<!-- /wp:amicited/tip -->Opprinnelige redigeringskontroller bevarer samme type og felt.
Portabilitet er ikke å kopiere gjengitt HTML. Hver tilpasser aksepterer den samme meningsfulle inndataen, håndhever tilsvarende begrensninger og produserer kanaltilpasset utdata. Hvis et felt ikke kan kartlegges trygt, må tilpasseren feile synlig eller dokumentere en kontrollert reserve; den må ikke forkaste mening i stillhet.
Hva som er på hver elementside
Hver detaljside er offentlig veiledning og en produksjonsspesifikasjon. Den fjerner gjetting som ellers kommer tilbake i hver implementering.
| Område | Spørsmål besvart | Feil forhindret |
|---|---|---|
| Formål og ikke-formål | Hvilken jobb utfører det, og hvilken lignende jobb hører hjemme andre steder? | Et tips som bærer et nødvendig steg, eller en definisjon som blir en miniartikkel. |
| Parametertabell | Hvilke felt er obligatoriske, valgfrie, typede, repeterbare og begrensede? | Tilpassere som aksepterer ulike data, eller flere ideer skjult i ett felt. |
| Plasseringsregler | Hvor kan det vises, hvor ofte, og ved siden av hva? | Nøkkelinnsikter begravd midt på siden eller kilder løsrevet fra påstander. |
| Variantgalleri | Hvilke navngitte varianter finnes, og når er hver enkelt passende? | Visuelle engangsløsninger som utgir seg for offisielle varianter. |
| Godt versus dårlig | Hva gjør et kompatibelt eksempel som en plausibel feil går glipp av? | Team som kopierer syntaks mens de går glipp av formålet. |
| Skjematilordning | Hvordan kartlegges felt til HTML, tilgjengelighet, skjema, API-er og feeder? | Synlig innhold som er uenig med maskinutdata. |
| Kvalitetssikring | Hva kan automatisering håndheve, og hva trenger skjønn? | En gyldig blokk som publiseres med vagt, falskt, foreldet eller feilplassert innhold. |
Automatisering kan sjekke obligatoriske felt, antall, lengder, plassering, identifikatorer, URL-er og tilpasserstøtte. Redaksjonell kvalitetssikring må sjekke nøyaktighet, nytteverdi, beviskvalitet, proporsjonal vektlegging, og om elementet er riktig for leserens oppgave.
Hvilke elementer er påkrevde
Obligatorisk betyr at systemet forventer funksjonen i omtrent alle fullstendige innholdstyper. Det betyr ikke at hver blokk må være stor eller identisk.
- Frontmatter etablerer identitet, eierskap, oppdagbarhet og sammenføyninger.
- Introduksjon bekrefter omfang og leserpassform.
- Nøkkelinnsikter presenterer underbygde konklusjoner på omfattende sider.
- FAQ løser genuine gjenværende spørsmål.
- Kilder gjør faktastøtte sporbar.
- Relatert innhold gir neste læringsvei.
- CTA tilbyr én proporsjonal handling.
- Bruk en definisjon når et begrep trenger en avgrenset betydning.
- Bruk et direkte svar for et tydelig primærspørsmål.
- Bruk steg for en ordnet prosedyre og verifiserbart resultat.
- Bruk sammenligninger når lesere vurderer alternativer på konsistente kriterier.
- Bruk et tips for valgfri forbedring og en advarsel for materiell risiko.
- Bruk annotert media når det visuelle kommuniserer noe prosa ikke kan like effektivt.
Unntak betyr noe. En kort ordlistedefinisjon trenger kanskje ikke separate nøkkelinnsikter. En side uten eksternt underbygget faktapåstand trenger kanskje ikke synlige referanser. En FAQ med oppdiktede spørsmål er verre enn ingen. Innholdstype-spesifikasjoner setter standarder; forfattere dokumenterer berettigede utelatelser i stedet for å fylle plasser mekanisk.
Start med den relevante innholdstype-spesifikasjonen, som bestiller de vanlige elementene for leserens oppgave. Bruk deretter prioritet seksjon for seksjon. Resultatet er verken en tom side eller en stiv form: det er styrt sammenstilling med rom for originale argumenter, bevis, eksempler og stemme.
Typede elementer lar en agent sette sammen i stedet for å finne opp
Elementbiblioteket er der et innholdssystem slutter å være et dokument og blir noe en maskin kan utføre. En blokk med deklarerte felt har enten det den trenger, eller den har det tydelig ikke.
En sammenligningstabell trenger sammenlignbare alternativer, en oppgitt dimensjon per rad og en verifikasjonsdato. Når én av disse inndataene ikke finnes, gir en typet blokk agenten et sted å feile høyt.
Fri prosa har ingen slik egenskap. Bedt om en tabell uten data bak seg, produserer en agent likevel en tabell, og den oppdiktede cellen ser nøyaktig ut som en forsket på.
Sjekk biblioteket etter formål før du skriver en overskrift. Den instruksen følges langt mer pålitelig av en agent enn av en person under tidsfrist, fordi en agent faktisk vil lese hele biblioteket på nytt hver gang.
Dette er et tilfelle der agenten er den bedre operatøren: regelen er mekanisk, og mekanisk er det agenter er til for.
Hvert element er definert én gang og uttrykt som et portabelt Markdown-direktiv, en Hugo-shortcode og en WordPress-blokk. Agenten jobber mot den portable formen og trenger aldri å vite hvilket CMS utdataene havner i.
Det betyr også at det å bytte CMS ikke ugyldiggjør innholdssystemet eller krever at agenten læres opp på nytt.
Fordi elementer er typede, kan korpuset spørres. Hvilke sider mangler en kildeblokk. Hvilke sammenligningstabeller har ingen verifikasjonsdato. Hvilke direkte svar overskrider sitt bånd.
Du kan bare kjøre den revisjonen på innhold satt sammen av navngitte blokker. Prosa er ikke spørrbart, så prosa-basert kvalitetskontroll skalerer ikke forbi antall sider en person kan lese.
Hver elementside har en parametertabell med obligatoriske felt, minimums- og maksimumsgrenser, plasseringsregler og en kvalitetssjekkliste. Det er presisjonsnivået en agent trenger for å bygge uten å gjette — og den samme presisjonen gjør resultatet gjennomgåelig av et menneske på en brøkdel av tiden.
Innholdselementer FAQ
Et innholdselement er en navngitt, typet, parameterisert blokk med et definert formål, tillatte felt, plasseringsregler, lengdebegrensninger, gjengivelsesatferd og kvalitetssjekker. Det lagrer innhold og funksjon.
Bruk fri tekst når ingen element i biblioteket matcher formålet. Analyse, fortelling, overganger og unike forklaringer forblir ofte prosa; etablerte definisjoner, advarsler, sammenligninger, kilder og CTA-er gjør det ikke.
Nei. Kontrakten standardiserer struktur og funksjon, ikke konklusjoner eller stemme. Forfattere velger fortsatt argumenter, bevis, eksempler og ordlyd.
Ja. Den portable kontrakten er uavhengig av presentasjon. Tilpassere kartlegger de samme feltene til opprinnelig syntaks og markering samtidig som validering og semantikk bevares.
Bygg én side av blokker du kan styre i stor skala
Gratis sjekk · 7 dagers prøveperiode · kredittkort kreves