Tidslinjer: Slik presenteres hendelser og faser i riktig rekkefølge

En tidslinje er en ordnet registrering av hendelser, milepæler eller navngitte faser der plassering formidler når noe skjedde eller hvordan et emne utviklet seg. Leseren observerer rekkefølgen; de blir ikke instruert om å gjenskape den.

1. 1
   Mars 2025 — Forskning godkjent

   Teamet fastsatte kohort, spørsmål og sammenligningsmetode før datainnsamlingen startet.
2. 2
   April–mai 2025 — Baseline samlet inn

   De samme målingene ble registrert for hver deltaker i løpet av den definerte innsamlingsperioden.
3. 3
   Juni 2025 — Funn publisert

   Rapporten offentliggjorde resultatene med metoder, begrensninger og neste revisjonsdato.

Dette gjengitte eksemplet beskriver en fullført forskningssekvens. Rekkefølgen forklarer forholdet mellom godkjenning, innsamling og publisering, men ingen av oppføringene ber leseren om å utføre disse handlingene.

Hvorfor dette elementet er viktig

Mennesker rekonstruerer endring ved å stille tre spørsmål: hva skjedde, når skjedde det, og hva førte det til eller muliggjorde det? En tidslinje svarer på disse spørsmålene i ett gjentatt mønster. Datoen eller fasemarkøren skaper orientering, hendelsestittelen gir endringen et navn, og beskrivelsen forklarer betydningen. Lesere kan skanne etter en kjent milepæl, sammenligne avstander mellom hendelser, eller forstå hvorfor dagens tilstand ikke kunne ha eksistert tidligere.

Den visuelle rytmen reduserer også hukommelsesbelastningen. I vanlig prosa kan datoer være adskilt fra hendelsene de kvalifiserer, og en leser må holde flere setninger i minnet før kronologien kan settes sammen. En avgrenset tidslinje holder hver markør knyttet til sin hendelse og gjør utelatelser eller uforklarlige hopp synlige. Den er spesielt nyttig når påstanden i avsnittet avhenger av rekkefølge: et resultat observert etter en intervensjon betyr noe annet enn et resultat samlet inn før den.

Maskinuttrekkbarhet er evnen en crawler, søkemotor, KI-svar-system eller publiseringsadapter har til å isolere hver post uten å miste rekkefølge eller felt. En semantisk ordnet liste med konsekvente dato-, tittel- og beskrivelsesområder gir maskiner en sterkere struktur enn datoer spredt utover avsnitt. Et system kan identifisere den tredje hendelsen som den tredje hendelsen, bevare forholdet mellom «Juni 2025» og «Funn publisert», og sitere beskrivelsen uten ved en feil å knytte den til april.

Bruk element-skrivereglene som prioritetsregel. Hvis formålet med et avsnitt er å registrere endring over tid, bruk den typede tidslinjen selv om en overskrift og flere avsnitt kunne sett like ut. Hvis formålet er instruksjon, sammenligning eller uavhengig verifisering, har det tilsvarende elementet forrang uavhengig av om en designer kunne tegne en vertikal linje ved siden av det.

Når du skal bruke det

Bruk en tidslinje når rekkefølgen er en del av påstanden og hvert element representerer en hendelse, milepæl, tilstandsovergang eller dokumentert fase. Passende emner inkluderer et selskaps historie, et produkts utgivelser, en regulerings innførings- og håndhevingsdatoer, stadiene i en fullført case-studie, eller innsamlings- og publiseringsfasene bak en rapport.

Bruk to tester før du velger det:

1. Byttetesten: bytt om to tilstøtende oppføringer. Hvis fremstillingen blir historisk usann, kausalt misvisende eller tidsmessig forvirrende, bærer rekkefølgen mening.
2. Observatørtesten: spør om leseren lærer hva som skjedde eller blir fortalt hva de skal gjøre. Observasjon indikerer en tidslinje; utførelse indikerer en stegliste .

Nære misser trenger andre strukturer:

• En prosedyre: «Eksporter dataene, rens dem, last dem deretter opp» instruerer leseren. Den trenger handlinger, suksesssignaler og gjenopprettingsbaner, ikke historiske hendelsesbeskrivelser.
• En sjekkliste: «Bekreft eier, dato, kilde og status» inneholder uavhengige verifikasjonspunkter. Deres rekkefølge skaper ikke mening.
• En funksjonsliste: «Lanserte rapportering, integrasjoner og varsler» kan ganske enkelt liste opp egenskaper. Det blir en tidslinje bare når daterte utgivelser og deres konsekvenser betyr noe.
• En før-og-etter-påstand: to tilstander er vanligvis tydeligere som en direkte sammenligning. Ikke legg til et dekorativt midtpunkt for å nå et minimum antall elementer.
• En prosjektplan: planlagte datoer kan bruke en tidslinje bare når de er tydelig merket som planlagt eller prognose. Ikke presentér intensjon som fullført historie.
• En prosessoversikt: navngitte faser kan bruke en tidslinje når siden beskriver hvordan en prosess er organisert. Hvis leseren må utføre disse fasene, bruk en stegliste eller sjekkliste i stedet.

Tilstedeværelsen av datoer er ikke nok. En liste over urelaterte konferansedatoer er en kalender eller oversikt. En tidslinje krever ett emne og en sammenhengende utviklingslinje.

Hvor du skal plassere den

Plasser tidslinjen umiddelbart etter en kort setning som navngir dens emne, omfang og retning. «Milepælene nedenfor går fra stiftelse til dagens produkt» er tilstrekkelig. Lesere skal aldri måtte slutte seg til om det første elementet er eldst, nyest, fullført eller planlagt.

Den nøyaktige plasseringen avhenger av dens oppgave:

• Plasser en historisk tidslinje etter emnets definisjon eller nåværende tilstandsoppsummering og før analyse av hvorfor historien betyr noe.
• Plasser en case-studie-tidslinje etter startsituasjonen og omfanget, men før detaljerte resultater, slik at leserne kan skille baseline, intervensjon og måling.
• Plasser en utgivelsestidslinje etter den nåværende utgivelsessammendrag. Bruk nyeste-først-rekkefølge når oppdagelse av den siste endringen er hovedoppgaven, og merk denne retningen.
• Plasser en implementerings- eller policykronologi etter regelens omfang og før nåværende forpliktelser. Iverksettelsesdatoer må forbli synlige utenfor ethvert skjult grensesnitt.
• Plasser en forskningstidslinje etter metodeoppsummeringen og før funn når innsamlingstidspunkt påvirker tolkningen.

En tidslinje kan ikke plasseres rett ved siden av en stegliste om samme emne uten en overgang som sier hvilken blokk som registrerer historie og hvilken blokk som instruerer handling. Den kan ikke settes inn mellom en påstand og dens støttende kilde, mellom en advarsel og dens konsekvens, eller inne i en sammenligningscelle. Ikke plasser to tidslinjer etter hverandre; kombiner dem når de deler emne og skala, eller separer dem med analyse som forklarer hvorfor den andre sekvensen er distinkt.

Unngå en salgsfremmende handlingsoppfordring mellom hendelser. Det bryter både kronologisk flyt og semantikk for ordnede lister. Plasser promoteringsinnhold etter den fullstendige tidslinjen og dens tolkning.

Anatomi

Den merkede anatomien inneholder syv deler:

1. Omfangsoverskrift: navngir emnet og tidsrommet samlingen representerer.
2. Retningsmarkør: angir eldste-til-nyeste eller nyeste-til-eldste når omkringliggende kontekst ikke gjør det utvetydig.
3. Ordnet spor: kobler poster visuelt mens den underliggende <ol> bevarer rekkefølgen uten styling.
4. Dato- eller fasemarkør: identifiserer når hendelsen fant sted, med den mest ærlige tilgjengelige presisjonen.
5. Hendelsestittel: angir endringen eller milepælen i en kompakt fortids- eller nåtidsfrase.
6. Beskrivelse: forklarer hva som endret seg og hvorfor denne hendelsen hører hjemme i sekvensen.
7. Status: skiller eventuelt mellom fullførte, nåværende, planlagte, forsinkede eller kansellerte hendelser i ord fremfor bare farge.

Linjen, prikkene og ikonene er dekorasjon. Datoene, titlene, beskrivelsene, rekkefølgen og statusene er innhold og må forbli tilgjengelige i tekst, utskrift og utdata uten CSS.

Designeksempler

Hver støttede variant bevarer én ordnet liste og de samme elementfeltene. Varianter endrer tetthet eller vektlegging, ikke mening.

Standard vertikal

Bruk standarden for tre til åtte hendelser med beskrivelser på én eller to setninger. Den gir plass til variabel tekstlengde og fungerer pålitelig på smale skjermer.

Kompakt endringslogg

Bruk kompakt avstand for korte, hyppige poster som utgivelser. Titler leder; beskrivelser holdes til én setning. Nyeste-først-rekkefølge er kun tillatt når overskriften eller retningsmarkøren angir det.

Milepælsbetoning

Bruk milepælsbetoning når to til seks vendepunkter betyr mer enn intervallene mellom dem. En uthevet nåværende milepæl må inkludere det synlige ordet «Nåværende»; størrelse eller farge alene er ikke tilstrekkelig.

Fasetidslinje

Bruk navngitte faser når eksakte datoer ikke er tilgjengelige eller mindre nyttige enn livssyklusposisjon. Fasemarkører må være gjensidig distinkte og konsekvent granulære: «Oppdagelse», «Innsamling» og «Publisering», ikke «Oppdagelse», «12. mai» og «Senere».

Horisontal bredskjerm

Bruk en horisontal presentasjon kun for tre til fem korte milepæler og bare når den blir en vertikal ordnet liste på små skjermer uten å endre kildeordenen. Tillat aldri horisontal rulling for å oppdage en hendelse.

Blandet-status veikart

Bruk denne varianten for et ekte veikart som inneholder fullførte og planlagte hendelser. Hvert element trenger en tekstlig status, og usikre datoer bruker ærlige spenn som «Q4 2026» fremfor oppdiktede dager.

Parametere

Kontrakten skiller samlingsinnstillinger fra gjentatte hendelsesposter. Den første overordnede overskriften gir samlingstittelen; hvert elements første overskrift gir hendelsestittelen.

marker er synlig og kan inneholde en dato med den presisjonen leserne forstår, for eksempel «Mai 2025» eller «Q3 2026». Oppgi date bare når kilden støtter en maskinlesbar kalenderdato. En markør som «Våren 2025» må ikke konverteres til en oppdiktet ISO-dato. I en fasevariant inneholder marker fasenavnet og date utelates normalt.

Syntaks og kodeeksempler

Alle tre formene nedenfor koder den samme fullførte kronologien. Det bærbare direktivet er den kanoniske forfatterstrukturen; plattformadaptere må bevare rekkefølge, felt og synlig ordlyd.

Bærbar Markdown-direktiv

:::timeline{variant=vertical direction=ascending}
## Tidslinje for forskning og publisering

::item{marker="Mars 2025" date="2025-03-01" status=completed id="research-approved"}
### Forskning godkjent

Teamet fastsatte kohort, spørsmål og sammenligningsmetode før datainnsamlingen startet.
::

::item{marker="April–mai 2025" status=completed id="baseline-collected"}
### Baseline samlet inn

De samme målingene ble registrert for hver deltaker i løpet av den definerte perioden.
::

::item{marker="Juni 2025" date="2025-06-18" status=completed id="findings-published"}
### Funn publisert

Rapporten offentliggjorde resultatene med metoder, begrensninger og en revisjonsdato.
::
:::

Området «April–mai 2025» har ingen date-attributt fordi én ISO-dato ville feilrepresentere en flermåneders hendelse.

Hugo shortcode

{{< timeline_with_icon >}}
[
  {"title":"Mars 2025 — Forskning godkjent","description":"Teamet fastsatte kohort, spørsmål og sammenligningsmetode før datainnsamlingen startet."},
  {"title":"April–mai 2025 — Baseline samlet inn","description":"De samme målingene ble registrert for hver deltaker i løpet av den definerte perioden."},
  {"title":"Juni 2025 — Funn publisert","description":"Rapporten offentliggjorde resultatene med metoder, begrensninger og en revisjonsdato."}
]
{{< /timeline_with_icon >}}

Den eksisterende Hugo-gjengiveren aksepterer en JSON-matrise med title og valgfrie description-felt og gjengir postene i kildeorden. Kombinering av markør og tittel i title er dens nåværende adaptertilordning; en rikere gjengiver kan skille disse synlige områdene uten å endre det kanoniske innholdet.

WordPress-blokk

<!-- wp:amicited/timeline {"variant":"vertical","direction":"ascending"} -->
<!-- wp:amicited/timeline-item {"marker":"Mars 2025","date":"2025-03-01","status":"completed","id":"research-approved"} -->
<h3>Forskning godkjent</h3>
<p>Teamet fastsatte kohort, spørsmål og sammenligningsmetode før datainnsamlingen startet.</p>
<!-- /wp:amicited/timeline-item -->
<!-- wp:amicited/timeline-item {"marker":"April–mai 2025","status":"completed","id":"baseline-collected"} -->
<h3>Baseline samlet inn</h3>
<p>De samme målingene ble registrert for hver deltaker i løpet av den definerte perioden.</p>
<!-- /wp:amicited/timeline-item -->
<!-- wp:amicited/timeline-item {"marker":"Juni 2025","date":"2025-06-18","status":"completed","id":"findings-published"} -->
<h3>Funn publisert</h3>
<p>Rapporten offentliggjorde resultatene med metoder, begrensninger og en revisjonsdato.</p>
<!-- /wp:amicited/timeline-item -->
<!-- /wp:amicited/timeline -->

WordPress må lagre postene som én ordnet overordnet blokk med underordnede elementer, ikke som urelaterte visuelle kort hvis rekkefølge kan endres under redigering.

Eksempler

Bra: en regulerings implementeringshistorie

Januar 2024 — Regel publisert. Regulatoren utstedte den endelige teksten og bekreftet organisasjonene innenfor omfanget.

Juli 2024 — Overgangsperiode startet. Berørte organisasjoner kunne ta i bruk rapporteringsformatet mens det forrige formatet fortsatt var akseptert.

Januar 2025 — Krav trådte i kraft. Nye innsendinger måtte bruke det publiserte formatet; overgangsmuligheten opphørte.

April 2025 — Veiledning presisert. Regulatoren forklarte hvordan endrede innsendinger skulle identifisere den opprinnelige rapporteringsperioden.

Dette er en god tidslinje fordi hver oppføring beskriver en dokumentert hendelse, presisjonen er konsekvent, og rekkefølgen forklarer overgangen fra publisering til overgang, håndheving og presisering. En leser kan forstå nåværende forpliktelser uten å forveksle en fremtidig frist med en tidligere hendelse.

Dårlig: en artikkeloptimaliseringstidslinje

1 — Legg til eksempler. Inkluder nyttige eksempler i artikkelen.

2 — Sjekk overskrifter. Sørg for at overskriftene beskriver hver seksjon.

3 — Legg til interne lenker. Lenk til relatert innhold.

Dette er dårlig fordi det verken er en kronologi eller en forsvarlig prosedyre. Tallene har ingen datoer eller faser, og handlingene kan utføres i en annen rekkefølge uten å endre resultatet. Å kalle det en tidslinje dekorerer uavhengige sjekkpunkter med falsk sekvens. Bruk en sjekkliste for uavhengige revisjonspunkter; bruk en stegliste bare hvis avhengigheter gjør utførelsesrekkefølge nødvendig.

Skjemamerking og tilgjengelighet

Schema.org har ingen generell Timeline-type. Ikke utstyr oppfunne egenskaper eller legg til ItemList bare for å få blokken til å virke strukturert. Tidslinjen kan tilby synlige fakta til strukturerte data på sidenivå når et passende vokabular allerede finnes — for eksempel en publisert utgivelsesdato på en programvarerelatert side — men den tilordningen styres av sidens skjemakontrakt, ikke av den visuelle komponenten. Strukturerte data må aldri inneholde hendelser, datoer eller statuser som er utelatt fra den synlige tidslinjen.

Den pålitelige maskinlesbare baselinjen er semantisk HTML: én <ol> i tiltenkt leserekkefølge og ett <li> per hendelse. Bruk <time datetime="2025-06-18">Juni 2025</time> bare når maskindatoen støttes av kilden. Hvis den synlige markøren er et kvartal, årstid, spenn eller navngitt fase, er ren tekst mer sannferdig enn en fabrikkert datetime-verdi.

Tilgjengelighet avhenger av å bevare sekvensen uten å stole på det grafiske sporet. Overskriften navngir emnet og retningen; den ordnede listen gir telling og posisjon; hver hendelse holder sin markør, tittel, beskrivelse og status samlet. Dekorative linjer, prikker og ikoner bruker tomme alternativer eller skjules for hjelpeteknologi. Status skrives som tekst, ikke formidles kun med grønn, gul eller en fylt sirkel.

Tastaturnavigasjon bør ikke være nødvendig for å lese en tidslinje. Hvis individuelle hendelser lenker til dokumentasjon eller detaljer, bruk vanlige beskrivende lenker og en synlig fokustilstand. Horisontale oppsett må flyte om i stedet for å fange tastatur- eller berøringsbrukere i en horisontal scroller. Zoom til 200%, smal visningsflate, utskriftsutdata og utdata uten CSS må beholde samme rekkefølge.

Skriveregler

Bruk tre til tolv hendelser i én tidslinje. Under tre er vanlig prosa eller en direkte før-og-etter-sammenligning tydeligere. Over tolv mister leserne helhetsbildet; grupper hendelser i navngitte tidsperioder eller lag separate tidslinjer med uavhengige omfang.

Skriv hver hendelsestittel på to til ti ord og beskrivelsen på 12–60 ord. Start titler med endringen, ikke fyllstoff: «Krav trådte i kraft» er sterkere enn «En viktig ny fase.» Beskrivelser svarer på hva som endret seg og hvorfor hendelsen betyr noe. Bruk fortid for fullførte hendelser, nåtid for en nåværende tilstand, og fremtidig eller planlagt språk for planlagte hendelser.

Datopresisjon må følge bevisene. Hvis kilden kun støtter et år, publiser året. Hvis den støtter et kvartal, ikke oppfinn kvartalets første dag for visning eller metadata. Bruk én datostil innenfor en tidslinje: «18. juni 2025» må ikke stå ved siden av «06/20/25», og numeriske datoer bør unngås når regional tolkning er tvetydig.

Hold granulariteten konsekvent. En tidslinje som kombinerer «Selskap grunnlagt», seks mindre ukentlige oppdateringer og «Nådde internasjonal distribusjon» gir rutineendringer mer visuell vekt enn strategiske milepæler. Enten registrer utgivelser konsekvent, eller velg milepæler konsekvent og oppgi utvalgsregelen.

Sett aldri disse inne i en hendelse:

• en flertrinnsinstruksjon leseren må utføre;
• en urelatert salgsfremmende handlingsoppfordring;
• en anbefaling brukt som bevis for hendelsen;
• en essensiell advarsel skjult bak utvidelse;
• flere uavhengige hendelser slått sammen for å redusere elementantallet;
• en dato eller status som kilden ikke støtter.

Tonen bør være faktabasert, kompakt og spesifikk. Unngå feirende språk som «banebrytende milepæl» med mindre siden tilskriver det som et sitat og gir kontekst. En tidslinje etablerer troverdighet gjennom verifiserbar sekvens, ikke entusiasme.

Innholdstyper som bruker det

Radene nedenfor styres av postTypes frontmatter og bruker kun registrerte innholdstype-sluger.

Ikke legg til en tidslinje for å tilfredsstille en innholdstype-mal når siden ikke har en meningsfull kronologi. Frontmatteren uttrykker støttede relasjoner, ikke et krav om at hver forekomst må inneholde elementet.

QA-sjekkliste

Før publisering, verifiser alle følgende punkter:

• Hvert element registrerer en hendelse, milepæl, tilstand eller fase i stedet for å instruere leseren.
• Å bytte om tilstøtende hendelser ville gjøre fremstillingen usann, misvisende eller vanskeligere å forstå.
• Innledningen navngir emnet, omfanget og kronologisk retning.
• Tidslinjen inneholder 3–12 elementer eller dokumenterer en tydelig grupperingsbeslutning.
• Datopresisjon og status støttes av en kilde; ingen eksakt dato er oppdiktet.
• Titler inneholder 2–10 ord og beskrivelser inneholder normalt 12–60 ord.
• Hendelser bruker et konsekvent granularitetsnivå og én datostil.
• Fullførte, nåværende, planlagte, forsinkede og kansellerte poster er adskilt i synlig tekst.
• Kilden er en ordnet samling og utdataene bruker én <ol> med ett <li> per hendelse.
• Markører, titler, beskrivelser og statuser forblir samlet i utskrift, utdata uten CSS og smal skjerm.
• Dekorative linjer, ikoner og farge bærer ingen informasjon som mangler i tekst.
• Eventuelle strukturerte data samsvarer nøyaktig med synlige hendelser og bruker kun et side-egnet vokabular.
• Bærbar Markdown, Hugo og WordPress-tilordninger bevarer samme rekkefølge og mening.
• Plassering avbryter ikke dokumentasjon, advarsler, instruksjoner eller den endelige tolkningen.

FAQ

Hva er forskjellen mellom en tidslinje og en stegliste? En tidslinje registrerer hva som skjedde; en stegliste forteller leseren hva de skal gjøre. Observatørtesten avgjør valget.

Trenger hvert tidslinjeelement en eksakt dato? Nei. Bruk den mest presise markøren bevisene støtter, inkludert en måned, kvartal, år eller navngitt fase.

Hvor mange hendelser bør en tidslinje inneholde? Bruk tre til tolv. Grupper lengre historier i navngitte tidsperioder eller separate sekvenser.

Har en tidslinje sin egen Schema.org-type? Nei. Bruk semantisk ordnet HTML-liste og kun strukturerte data på sidenivå som sannferdig samsvarer med et passende vokabular.

Kan en tidslinje gå fra nyeste til eldste? Ja, når nyeste-først-oppdagelse er leserens hovedoppgave. Merk retningen og hold den konsekvent.