Diagrammer og illustrasjoner: Forklar hvordan en mekanisme fungerer

Et diagram viser hvordan navngitte deler henger sammen, hva som beveger seg mellom dem, og hvilket resultat disse relasjonene produserer. Bruk det når lesere trenger flere relasjoner samtidig, mens du holder forklaringen tilgjengelig som tekst.

Hvordan en side blir hentbar: kilde-sider går gjennom ekstrahering og normalisering før deres nyttige passasjer når en svar-indeks.

1. Kilde-sider tilbyr HTML, overskrifter, bilder og strukturerte felt.
2. Ekstraher og normaliser fjerner presentasjonsstøy mens den bevarer tekst, hierarki, entiteter og relasjoner.
3. Svar-indeks lagrer hentbare passasjer som kan matches med et senere spørsmål.
4. Den første pilen bærer siderepresentasjonen inn i behandling; den andre bærer normaliserte, søkbare passasjer inn i indeksen.

Tegningen gjør flyten synlig på et øyeblikk. Bildeteksten og den nummererte forklaringen bærer samme mening uten bildet. Denne to-kanals-kontrakten skiller et forklarende diagram fra dekorativ kunst.

Hvorfor dette elementet betyr noe

Prosa kan tvinge lesere til å huske flere deler før den avslører hvordan de henger sammen. Et diagram eksternaliserer den modellen: noder viser deler, koblinger viser relasjoner, og grenser viser omfang. Det er mest nyttig når rekkefølge alene ikke er tilstrekkelig. En setning kan si at en crawler henter en side, en parser ekstraherer innhold, og en indeks lagrer passasjer; et diagram kan også vise feilpunkter, parallelle ruter og tilbakemelding. Det reduserer rekonstruksjonsinnsats, ikke behovet for presis ordlyd.

Et diagram kan også villede raskere enn prosa. En umerket pil kan bety årsakssammenheng, overføring, sekvens eller assosiasjon; en løkke kan falskt implisere automatisk tilbakemelding. Hver relasjon trenger en eksplisitt, forsvarbar betydning.

Maskinuttrekkbarhet er evnen programvare har til å isolere en innholdsenhet uten å miste dens betydning. Søkesystemer, oversettelsesverktøy, skjermlesere og AI-hentingssystemer kan ikke forventes å rekonstruere en mekanisme fra piksler. Optisk tegngjenkjenning kan gjenopprette etiketter, men ikke hva en pil eller grense betyr. En tittel, bildetekst, strukturerte noder og koblinger, og en synlig tekstekvivalent gjør mekanismen uttrekkbar uten datasyn.

De felles skrivereglene for elementer setter presedensregelen: velg et element basert på jobben passasjen utfører, ikke basert på overskriften eller utseendet. Denne siden har forrang for diagramspesifikke felt, tetthetsgrenser, krav til tekstekvivalent og tilgjengelighetsatferd. Hvis innholdets jobb er å forklare en mekanisme visuelt, bruk diagramelementet fremfor et generisk bilde med en improvisert bildetekst.

Når du skal bruke det

Bruk et diagram når konklusjonen avhenger av å se minst to relasjoner sammen. Sterke bruksområder inkluderer en prosess med forgreninger eller tilbakemelding, et system hvis komponenter utveksler data, en livssyklus som returnerer til en tidligere tilstand, en årsakskjede med en mellomliggende faktor, eller en konseptuell modell der grensene betyr noe. Leseren bør kunne svare på et konkret spørsmål fra tegningen, for eksempel «Hvor kan denne prosessen feile?» eller «Hvilken komponent sender den normaliserte posten?»

Bruk prosatesten først: skriv mekanismen i tre til åtte setninger. Hvis den ikke har noen kryssreferanse, forgrening, løkke eller romlig relasjon, er prosa sannsynligvis bedre. Et diagram fortjener sin plass når en nøyaktig tekstekvivalent er kognitivt kostbar å sette sammen.

Nære bom er vanlige:

• Bruk en trinnliste for utførbare handlinger; piler kan ikke erstatte forutsetninger, suksesskontroller eller gjenopprettingsinstruksjoner.
• Bruk en sammenligningstabell for gjentatte attributter på tvers av alternativer. Et umerket to-akset bilde skjuler kriterier.
• Bruk et beslutningstre for ruter valgt basert på eksplisitte betingelser. En generell flyt forklarer bevegelse, ikke en beslutning.
• Bruk et annotert skjermbilde for å lokalisere kontroller i et virkelig grensesnitt. En nyttegning mister den beviskraften.
• Bruk et diagram når kvantitativ skala koder verdier. En dekorativ stigende pil må ikke implisere målt vekst.
• Bruk et innebygd bilde for å avbilde et objekt, sted eller resultat snarere enn en mekanisme.

Ikke bruk et diagram som dekorasjon eller bokset gjentakelse. Merk hypotetiske, omstridte, betingede eller forenklede relasjoner i både bilde og tekst.

Hvor du skal plassere det

Plasser diagrammet etter avsnittet som introduserer mekanismen og spørsmålet. Følg det med den synlige tekstekvivalenten, deretter tolkning, bevis, begrensninger eller handlinger.

Hold tittel, bilde, bildetekst, nøkkel og tekstekvivalent i én figurregion. Ingenting kan skille bildet fra forklaringen. Plasser en lengre ekvivalent rett etter det under «I tekst».

Et diagram må ikke sitte direkte ved siden av et annet fullbredde-diagram, diagram, video, bildegalleri, tett tabell eller skjermbilde. Sett inn forklarende prosa før den neste tette visuelle enheten. Ikke plasser det inne i en tabellcelle, listeelement, accordion, callout, klikkbart kort eller figur.

For prosedyrer, sett en oversikt før den første handlingen, ikke mellom koblede trinn. I argumentasjoner, plasser det etter mekanismepåstanden og før bevis. På produktsider, plasser det etter kapasitetsforklaringen, aldri over det direkte svaret bare for å se teknisk ut.

Anatomi

Anatomi beskriver mening, ikke styling. Boks-skygger, illustrasjonsstil, piltykkelse, hjørneradius og bakgrunnsfarge tilhører gjengiveren eller den kunstneriske retningen.

1. Tittel: Navngir mekanismen eller spørsmålet på tre til ti ord.
2. Omfangserklæring: Definerer hva diagrammet inkluderer, ekskluderer eller forenkler i én setning.
3. Node: Representerer én komponent, tilstand, aktør, inndata eller utfall.
4. Nodeetikett: Bruker en konkret substantivfrase, ikke en uforklart forkortelse.
5. Kobling: Representerer én deklarert relasjon mellom to noder.
6. Koblingsetikett: Navngir relasjonen med et verb eller overført objekt, som «sender hendelser» eller «produserer passasjer».
7. Retningsmarkør: Viser lese- eller overføringsretningen uten å stole på plassering alene.
8. Grense: Grupperer elementer som deler eierskap, fase, miljø eller omfang.
9. Nøkkel: Definerer ethvert linjemønster, symbol eller farge som endrer betydning.
10. Bildetekst: Angir hovedkonklusjonen i stedet for å gjenta tittelen.
11. Kildenote: Identifiserer beviset eller eieren når modellen er utledet fra forskning, retningslinjer eller et proprietært system.
12. Tekstekvivalent: Gjengir hver meningsbærende node, kobling, retning, betingelse, grense og unntak i lesbar rekkefølge.

Designeksempler

Hver variant krever en tittel, bildetekst, tekstekvivalent og eksplisitte koblingsbetydninger. Velg den enkleste varianten som svarer på spørsmålet.

Lineær prosessflyt

Bruk tre til syv trinn når mekanismen hovedsakelig beveger seg i én retning. Merk hva som beveger seg mellom trinnene; ikke stol på piler alene. Hvis leseren må utføre trinnene, par oversikten med en separat trinnliste.

Systemkart

Bruk tre til ni komponenter når eierskap, grensesnitt eller datautveksling betyr mer enn kronologi. Grenser identifiserer miljøer eller team; kryssende linjer signaliserer et behov for å omgruppere eller dele visningen.

Årsakskjede

Bruk dette for en årsak, mellomliggende mekanisme og utfall. Merk betingelser og usikkerhet. Piler må aldri gjøre korrelasjon til årsakssammenheng; prosa og kilder må støtte ethvert årsakskrav.

Livssyklusløkke

Bruk en løkke bare når utdata blir en senere inndata. Nummerer trinnene og angi utløseren for omstart; en dekorativ sirkel gir falskt inntrykk av gjentakelse.

Oversikt med detaljinnfelt

Bruk ett innfelt når en komponent trenger detaljer, men avhenger av systemkontekst. Gjenta etiketten. Mer enn ett innfelt trenger vanligvis et separat diagram.

På mobil, stable lineære diagrammer i leseretning. Et systemkart kan bli en forenklet oversikt pluss nummererte relasjoner. Krev aldri horisontal side-rulling eller zoom for forståelse.

Parametere

Innholdsmodellen lagrer mekanismen. Koordinater, farger, skriftstørrelser, ikonvalg, koblingsruting og responsive bruddpunkter tilhører gjengiveren eller kildeillustrasjonen.

source er påkrevd for ekstern forskning, standarder, regulerte prosesser eller tilpassede modeller. Hver node og kobling må vises i tekstekvivalenten; prosa kan kombinere gjentakelse.

Syntaks og kodeeksempler

De tre mappingene bevarer de samme feltene. Eksempel-aktivastier beskriver produksjonskontrakten; de må ikke vises som levende bildereferanser før disse filene eksisterer.

Bærbart Markdown-direktiv

:::diagram{variant=process src="/cdn-assets/seo-playbook/examples/content-pipeline.svg" alt="Tre-trinns flyt fra kilde-sider gjennom ekstrahering og normalisering til en svar-indeks"}
## Hvordan en side blir hentbar

Modellen dekker innholdsbehandling etter at en side er hentet.

::item{id=source-pages}
### Kilde-sider

Tilbyr HTML, overskrifter, bilder og strukturerte felt.
::
::item{id=extract-normalize}
### Ekstraher og normaliser

Bevar nyttig tekst, hierarki, entiteter og relasjoner.
::
::item{id=answer-index}
### Svar-indeks

Lagrer passasjer som kan matches med et spørsmål.
::
::relationship{from=source-pages to=extract-normalize label="sender siderepresentasjon" kind=flow}
::relationship{from=extract-normalize to=answer-index label="produserer hentbare passasjer" kind=flow}

Normaliserte passasjer når svar-indeksen bare etter at nyttig struktur er bevart.

### I tekst

Kilde-sider sender sin siderepresentasjon til ekstrahering og normalisering. Det trinnet bevarer nyttig tekst, hierarki, entiteter og relasjoner, og produserer deretter hentbare passasjer for svar-indeksen.
:::

Den første overskriften mappes til title; neste avsnitt mappes til scope; elementdirektiver definerer noder; relasjonsdirektiver definerer koblinger; avsnittet etter dem mappes til caption; og delen «I tekst» mappes til textEquivalent.

Hugo shortcode-mapping

{{< diagram variant="process" src="/cdn-assets/seo-playbook/examples/content-pipeline.svg" alt="Tre-trinns flyt fra kilde-sider gjennom ekstrahering og normalisering til en svar-indeks" >}}
## Hvordan en side blir hentbar
{{< diagram-node id="source-pages" label="Kilde-sider" >}}Tilbyr sideinnhold.{{< /diagram-node >}}
{{< diagram-node id="extract-normalize" label="Ekstraher og normaliser" >}}Bevarer nyttig struktur.{{< /diagram-node >}}
{{< diagram-node id="answer-index" label="Svar-indeks" >}}Lagrer passasjer.{{< /diagram-node >}}
{{< diagram-relationship from="source-pages" to="extract-normalize" label="sender siderepresentasjon" kind="flow" >}}
{{< diagram-relationship from="extract-normalize" to="answer-index" label="produserer hentbare passasjer" kind="flow" >}}
### I tekst
Kilde-sider sender innhold for ekstrahering og normalisering, som produserer passasjer for svar-indeksen.
{{< /diagram >}}

Navngitte parametere brukes utelukkende. Dette er en bærbar adapter-spesifikasjon, ikke en påstand om at disse shortcodene er registrert i det gjeldende temaet. Inntil en godkjent gjengiver eksisterer, publiser en semantisk figur gjennom den etablerte bilde-pipelinen og behold tekstekvivalenten i normalt sideinnhold.

WordPress-blokk

<!-- wp:amicited/diagram {"variant":"process","src":"/cdn-assets/seo-playbook/examples/content-pipeline.svg","alt":"Tre-trinns flyt fra kilde-sider gjennom ekstrahering og normalisering til en svar-indeks"} -->
<figure>
  <h2>Hvordan en side blir hentbar</h2>
  <img src="/cdn-assets/seo-playbook/examples/content-pipeline.svg"
       alt="Tre-trinns flyt fra kilde-sider gjennom ekstrahering og normalisering til en svar-indeks">
  <figcaption>Normaliserte passasjer når svar-indeksen bare etter at nyttig struktur er bevart.</figcaption>
  <div class="diagram-text-equivalent">
    <h3>I tekst</h3>
    <p>Kilde-sider sender innhold for ekstrahering og normalisering, som produserer passasjer for svar-indeksen.</p>
  </div>
</figure>
<!-- /wp:amicited/diagram -->

Lagre noder og koblinger som blokkattributter. Eksport må beholde dem og tekstekvivalenten; et flatt bilde er ikke bærbart innhold.

Eksempler

Bra: tegningen og prosaen fremmer samme påstand

Den gode versjonen svarer på ett spørsmål: hvordan et innsendt spørsmål blir et støttet svar. Fire konkrete noder følger en tydelig retning. Koblingsetiketter skiller ruting fra henting og komponering. En stiplet tilbakemeldingssti er definert i nøkkelen som valgfri manuell gjennomgang, så den impliserer ikke en automatisk løkke. Bildeteksten angir konklusjonen, og den tilstøtende teksten navngir hvert trinn og overføring.

Dette gir visuelle lesere en rask modell samtidig som tekst bærer samme mekanisme og kvalifikasjon. Maskiner mottar navngitte relasjoner uten å måtte gjette ut fra koordinater.

Dårlig: en overtalende floke uten deklarert betydning

Den dårlige versjonen setter «AI» i sentrum og omgir det med vage substantiver som innhold, data, brukere, tillit, inntekt og vekst. Umerkede piler peker begge veier, men leseren kan ikke avgjøre om de betyr årsakssammenheng, utveksling, sekvens eller assosiasjon. Farge virker meningsfull, men har ingen nøkkel. Vekstpilen impliserer forbedring uten data. Små etiketter blir uleselige på mobil, og ingen prosa forklarer den påståtte mekanismen.

Reparer det ved å velge ett spørsmål, fjerne irrelevante noder, navngi koblinger, skille årsaker fra assosiasjoner, og legge til omfang, bildetekst, tekstekvivalent og kilder. Hvis bare fordeler gjenstår, skriv en liste.

Schema-markering og tilgjengelighet

Et diagram har ingen dedikert Schema.org-type eller uavhengig kvalifisering for rike resultater. Et meningsfylt diagram kan fylle Article.image eller et ImageObject med nøyaktig URL, bildetekst, dimensjoner, skaper, kreditering, opphavsrett og lisensdata. Ikke oppfinn metadata eller et relasjonsvokabular; noder og koblinger forblir synlig innhold.

Bruk <figure> for bilde og bildetekst. Alternativtekst identifiserer mekanismen og konklusjonen i stedet for å transkribere den. Sikt på 40–180 tegn og unngå «diagram av». Eksempel: «Tre-trinns flyt fra kilde-sider gjennom ekstrahering og normalisering til en svar-indeks.»

Den synlige tekstekvivalenten inkluderer hver meningsfylt node, kobling, betingelse, tilbakemeldingsutløser, grense, nøkkel og unntak. Ikke skjul den i ARIA, hover-tekst, metadata eller en lukket accordion.

Par farge, ikoner, mønstre, form og posisjon med tekstetiketter. Oppretthold kontrast, synlige pilspisser og en leseretning som matcher tekstekvivalenten. Ekte SVG-tekst er nyttig, men erstatter ikke synlig prosa.

Ved 320 CSS-piksler, stable, forenkle eller gjengi et mobilbilde fra de samme dataene. Fjern aldri noder, beskjær koblinger eller endre leseretning. Nærliggende tekst må beholde all essensiell mening uten zoom.

Skriveregler

Skriv og verifiser teksten først, tegn deretter bare relasjoner den inneholder. Dette forhindrer at visuell glans introduserer påstander.

• Gi diagrammet ett spørsmål eller én mekanisme. Ikke kombiner arkitektur, arbeidsflyt, fordeler og veikart i ett lerret.
• Bruk 3–9 primære noder, med 12 som maksimum. Del en overbelastet modell i oversikts- og detaljfigurer.
• Merk noder med 1–6 konkrete ord. Definer forkortelser ved første gangs bruk i sidetekst og unngå interne teamnavn som lesere ikke kan tolke.
• Merk hver meningsbærende kobling med en verbfrase eller overført objekt på 1–6 ord. «Sender hendelser» er tydeligere enn «integrasjon».
• Hold bildeteksten på 8–30 ord og la den angi konklusjonen eller relasjonen leseren bør huske.
• Hold omfangserklæringen til én setning. Angi ekskluderinger eller forenklinger når utelatelse av dem kunne endre tolkning.
• Hold tekstekvivalenten på 50–250 ord med mindre nøyaktighet krever mer.
• Bruk en forklarende, nøytral tone. Skill hva systemet gjør fra hva det kan gjøre, bør gjøre, eller antas å gjøre.
• Merk usikkerhet med ord som «kan», «betinget» eller «foreslått», og definer stiplede eller prikkede stier i nøkkelen.
• Plasser aldri avsnitt, sitater, rå-URL-er, salgsfremmende slagord, presise bevis eller fullstendige instruksjoner inne i illustrasjonen. Plasser dem i valgbar sidetekst.
• Bruk aldri ikoner uten etiketter, farge uten en andre ledetråd, eller piler uten deklarert betydning.
• Impliser aldri skala, kvantitet, årsaksstyrke, sikkerhet eller målt vekst gjennom størrelse eller retning med mindre beviset og nøkkelen støtter den kodingen.
• Publiser aldri en ikke-eksisterende aktivasti; hold pågående kunstverk som en opptaks-kommentar med screenshotsPending = true.

Innleggstyper som bruker det

postTypes-frontmatteren er den registrerte koblingen. Hver listede innleggstype bruker samme diagramkontrakt, men ved en annen terskel.

QA-sjekkliste

• Formål: Én mekanisme eller flyt er lettere å forstå visuelt enn fra prosa alene.
• Tekst først: Den gjennomgåtte forklaringen er eldre enn illustrasjonen; ingen u understøttet relasjon ble lagt til.
• Omfang: Tittel og omfang gjør grenser, forenklinger og ekskluderinger tydelige.
• Noder: Det er vanligvis 3–9, hver konkret og nødvendig.
• Koblinger: Hver har retning og en etikett; stiler og farger har en nøkkel.
• Påstander: Årsakssammenheng, automasjon, skala, styrke, sikkerhet og vekst vises bare når bevis støtter dem.
• Tekstekvivalent: Synlig tekst inkluderer hver node, relasjon, betingelse, grense, nøkkel og unntak.
• Bildetekst: Den angir konklusjonen på 8–30 ord.
• Tilgjengelighet: Farge er ikke den eneste ledetråden; kontrast, pilspisser, alternativtekst og leseretning fungerer.
• Mobil: Mening overlever ved 320 CSS-piksler uten side-nivå rulling eller påkrevd zoom.
• Plassering: Introduksjonskontekst går foran diagrammet; bildeteksten og tekstekvivalenten forblir tilknyttet; konkurrerende tette visuelle elementer sitter ikke ved siden av det.
• Kilde: Forskning, standarder, regulerte prosesser og tilpassede modeller har en nøyaktig synlig kilde- eller eiernote.
• Bærbarhet: Alle mappinger bevarer tittel, noder, koblinger, bildetekst og tekstekvivalent.
• Aktivastrekk: Filen eksisterer før en aktiv sti blir publisert, rettigheter er dokumentert, og pågående kunstverk forblir en SCREENSHOT-kommentar.
• Presedens: Blokken er typet som et diagram fordi formålet matcher dette elementet, ikke fordi et generisk bilde tilfeldigvis så likt ut.

FAQ

Akademi-malen gjengir de fem gjennomgåtte spørsmålene som er lagret i denne sidens [[faq]]-frontmatter. De dekker terskelen for å bruke et diagram, den obligatoriske tekstekvivalenten, alternativtekstens omfang, strukturerte data og nodegrenser.