Zigzag-seksjoner — Format, regler og eksempler
Bruk zigzag-seksjoner for å forklare parallelle funksjoner med vekslende bilde og tekst, forbedre skanning, bevare ekstraksjon og unngå unødvendig lange sider.
Zigzag-seksjoner presenterer en sekvens av parallelle funksjoner som gjentatte bilde-og-tekst-par, og veksler det visuelle fra den ene siden til den andre på brede skjermer. Bruk mønsteret for å skape tydelige visuelle sjekkpunkter gjennom en gjennomtenkt produkthistorie, ikke for å strekke en kort liste til en lang landingsside.
Se hele innholdsinventaret
Samle alle URL-er, eiere, statuser og ytelsessignaler i én visning før du bestemmer hva som skal beholdes, forbedres, slås sammen eller fjernes.
Prioriter arbeidet som betyr noe
Grupper muligheter etter forretningsverdi og innsats slik at produksjonsteamet kan handle på en gjennomtenkt kø i stedet for en haug med usammenhengende ideer.
Mål resultatet etter publisering
Koble hver endring til en merknad og et stabilt rapporteringsvindu slik at senere bevegelser kan undersøkes i stedet for å gjettes på.
Det gjengitte eksemplet viser rytmen, men de grå områdene er forklarende UI i denne spesifikasjonen. Produksjonsinstanser må inneholde ekte, informative visuelle elementer.
Hvorfor dette elementet betyr noe
En lang side skaper et navigasjonsproblem. Lesere trenger landemerker som forteller dem når én idé slutter og den neste begynner. En zigzag gir disse landemerkene gjennom repetisjon: bilde, overskrift, forklaring; deretter samme struktur med en annen bredskjermsjustering. Gjentatt anatomi gjør hver seksjon lettere å forstå, mens veksling hindrer tilstøtende elementer i å smelte sammen til én kolonne.
Den psykologiske fordelen er sterkest når elementene er genuint parallelle. En leser ser det første paret, lærer mønsteret, og kan skanne påfølgende overskrifter og visuelle elementer før de velger hvor de skal sette farten ned. Det visuelle gir gjenkjenning; overskriften navngir funksjonen; brødteksten forklarer konsekvensen. Veksling tilfører akkurat nok romlig endring til å tilbakestille oppmerksomheten uten å endre informasjonsmodellen.
Denne fordelen har en grense. Hvert par bruker betydelig vertikal plass, spesielt på en telefon hvor kolonnene stables. Hvis forklaringen bare er én setning og det visuelle ikke tilfører bevis, får mønsteret leseren til å reise lenger uten å lære mer. Dekorativ veksling kan også føles som en salgsmal heller enn en gjennomtenkt sekvens. Elementet fortjener plassfotavtrykket sitt bare når hvert visuelle element hjelper leseren med å forstå en distinkt funksjon, tilstand, resultat eller arbeidsflyt.
Maskinekstraherbarhet betyr at programvare kan isolere en innholdsenhet uten å miste konteksten som gjør den nøyaktig. En velskrevet zigzag er en samling av eksplisitte elementer, hver med en overskrift, selvstendig forklaring, visuell beskrivelse og valgfri lenke. Gjenfinningssystemer kan hente ut ett element som en sammenhengende funksjonserklæring fordi betydningen ikke avhenger av å være «den til venstre». Kilde-rekkefølge, ikke CSS-plassering, etablerer sekvensen.
Bruk element-skrivereglene før reglene på denne siden: utkast den fullstendige forklaringen først og bruk det typede elementet i en separat strukturell gjennomgang. Der denne siden setter smalere antall elementer, mediekrav, brødtekstkartlegging eller hekkingsgrenser, har disse elementspesifikke reglene forrang.
Når du skal bruke det
Bruk en zigzag når alle disse betingelsene er oppfylt:
- Siden har tre til seks parallelle funksjoner, egenskaper, resultater eller ikke-sekvensielle arbeidsflytvisninger.
- Hvert element har et reelt visuelt element som forklarer eller demonstrerer emnet.
- Hvert element trenger mer forklaring enn et kort tillater, men mindre enn et helt uavhengig kapittel.
- Lesere har nytte av å skanne sekvensen før de leser hver eneste detalj.
- Rekkefølgen er nyttig, men ikke prosedyremessig; et element forblir forståelig hvis det hentes ut alene.
Sterke bruksområder inkluderer en produktomvisning med ett grensesnittbilde per funksjon, en løsningsside som kobler hvert operativt problem med den tilhørende arbeidsflyten, eller en ultimat guide som viser flere parallelle modeller. Det visuelle kan være et skjermbilde, diagram, kart eller fotografi når mediet bærer informasjon. Bruk et annotert skjermbilde inne i et element når et rått grensesnittfangst vil tvinge lesere til å lete etter den relevante kontrollen.
Nære miss er vanlige. Ikke bruk en zigzag for nummererte instruksjoner: skiftende sider svekker det retningssignalet som steg trenger. Ikke bruk det for en sammenligning, fordi vekslende produkter forhindrer kriterium-for-kriterium-evaluering. Ikke bruk det for tolv fordeler som hver trenger én setning; kort, punktlister eller en oppsummeringstabell bruker plassen bedre. Ikke bruk det for et argument hvor hver seksjon avhenger av den forrige konklusjonen; sammenhengende prosa og overskrifter bevarer den logikken tydeligere.
Den mest avslørende testen er å fjerne bildene. Hvis de gjenværende overskriftene danner et sammenhengende sett av jevnbyrdige elementer og hvert manglende visuelle element etterlater et meningsfullt bevisgap, er zigzag sannsynligvis passende. Hvis teksten blir en generisk fordelsliste og ingenting viktig går tapt, var bildene dekorasjon og elementet er misbruk.
Hvor du skal plassere det
Plasser zigzaggen etter at siden har definert det felles problemet og navngitt gruppen av funksjoner. Lesere bør vite hvorfor sekvensen betyr noe før de møter det første store visuelle elementet. På en produkt- eller løsningsside er dette normalt etter hero, direkte svar eller kort oversikt og før bevis, detaljerte spesifikasjoner, prising eller den endelige handlingsoppfordringen.
Introduser hele sekvensen med en H2 og ett kort innrammingsavsnitt. Ikke legg til en separat H2 før hvert element; hver elementoverskrift er en underoverskrift innenfor den felles seksjonen. Hold alle elementer sammenhengende slik at den vekslende rytmen kommuniserer én samling. Hvis en lang kvalifisering må avbryte sekvensen, avslutt zigzaggen og start en ny seksjon etter den.
En zigzag må ikke ligge umiddelbart ved siden av en annen stor visuell sekvens, bildegalleri, produktglidebryter, tidslinje eller gjentatt kortrutenett. Rygg-mot-rygg-visningsmønstre skaper visuell tretthet og skjuler hvilken samling som er primær. Den må ikke splitte et krav fra beviset, en advarsel fra instruksjonen den kvalifiserer, eller en pris fra kjøpsbetingelsene. Den må ikke vises inne i en ordnet liste, tabelcelle, accordionpanel eller en annen zigzag.
Bruk én zigzag per side som standard. En andre er akseptabel bare når de to samlingene svarer på tydelig forskjellige spørsmål, bruker separate seksjonsoverskrifter, og har prosa eller bevis mellom seg. Aldri veksle justeringen av urelaterte seksjoner bare for å imitere mønsteret; samlingsgrensen er en del av elementets betydning.
Anatomi
- Samlingsoverskrift: Navngir det felles spørsmålet eller kategorien som dekkes av hvert element.
- Samlingsintroduksjon: Forklarer hvorfor elementene hører sammen og hva leseren bør legge merke til.
- Elementbeholder: Holder ett visuelt element og én tekstregion programmatisk og visuelt assosiert.
- Elementoverskrift: Navngir én spesifikk funksjon, ett resultat eller én visning i konkrete ord.
- Elementbrødtekst: Forklarer hva elementet gjør, hvorfor det betyr noe, og eventuelle grenser som trengs for å tolke det riktig.
- Informativt visuelt element: Demonstrerer samme emne som teksten og har nyttig alternativ tekst eller en tilgjengelig bildetekst.
- Valgfri elementlenke: Tilbyr én relevant dybdeartikkel eller handling etter forklaringen.
- Presentasjonsveksling: Endrer den visuelle siden på brede skjermer uten å endre DOM-rekkefølge eller betydning.
Avstand, farge, hjørneradius, bilderbeskjæring og brytepunkt tilhører rendreren. Forfattere oppgir semantisk rekkefølge, fullstendig tekst og tilgjengelig medieinformasjon.
Designeksempler
Følgende er de støttede variantene. De deler én innholdskontrakt; bare startjustering, visuell behandling eller visningsatferd endres.
Media-først: Standard bredskjermsvarianten starter med det første visuelle elementet til venstre. Bruk det når det første visuelle gir umiddelbar gjenkjenning og den omkringliggende siden ikke allerede plasserer et dominerende bilde på den siden.
Tekst-først: Starter med tekst til venstre, deretter veksler. Bruk det når den innledende forklaringen må etablere mening før det første visuelle elementet, eller når det skaper bedre balanse med den foregående seksjonen.
Inneholdt media: Plasserer skjermbilder eller diagrammer innenfor en konsekvent ramme. Bruk det for produktgrensesnitt, diagrammer og grafer der kanter og etiketter betyr noe. Alle elementer bruker samme rammelogikk selv når kildebilder har forskjellige dimensjoner.
Kant-media: Tillater fotografier eller ikke-grensesnittillustrasjoner å fylle sine regioner. Beskjæring kan endres responsivt, men den må ikke fjerne motivet eller noe informasjon beskrevet av teksten.
Mobilstablet: Fjerner venstre-høyre-veksling og bruker én konsistent leserekkefølge for hvert element. Dette er nødvendig responsiv atferd, ikke en valgfri redaksjonell variant.
Det finnes ingen tekst-only, autospill eller karusellvariant. Å fjerne meningsfylte medier fjerner grunnen til å bruke zigzag; bevegelse og skjulte lysbilder introduserer forskjellige interaksjonskontrakter.
Parametere
| Navn | Type | Påkrevd | Min/maks | Standard | Kilde |
|---|---|---|---|---|---|
title | Ren tekststreng | Ja | 3–12 ord; maksimalt 100 tegn | Ingen | Første overskrift i hoveddelen |
intro | Begrenset Markdown | Ja | 20–60 ord; ett avsnitt | Ingen | Hoveddel etter første overskrift og før første element |
items | Ordnet samling | Ja | 3–6 elementer | Ingen | Nøstede item-deler |
item.title | Ren tekststreng | Ja | 3–9 ord; maksimalt 70 tegn | Ingen | Første overskrift i hver elementdel |
item.content | Begrenset Markdown | Ja | 40–120 ord; ett eller to avsnitt | Ingen | Elementdel etter første overskrift |
item.media | Godkjent aktøridentifikator eller bekreftet rot-relativ sti | Ja | Nøyaktig ett bilde, skjermbilde, diagram eller én graf | Ingen | Elementets media-attributt |
item.alt | Ren tekststreng | Ja med mindre en tilstøtende bildetekst fullt ut beskriver det visuelle | 1–2 setninger; 180 tegn anbefalt | Ingen | Elementets alt-attributt |
item.link | URL og anker | Nei | 0–1 per element | Ingen | Siste innebygde lenke i elementdelen |
start | Enum | Nei | media eller text | media | Overordnet attributt |
mediaFit | Enum | Nei | contain eller cover | contain | Overordnet attributt |
Hoveddelen mapper sin første overskrift til title, sitt følgende avsnitt til intro, og hvert nøstet element til ett gjentatt par. Et elements første overskrift mapper til item.title; dens gjenværende del mapper til item.content. Mediereferanser og alternativ tekst forblir på elementet fordi de beskriver det elementet alene. Forfattere kan ikke sette venstre eller høyre per element: rendreren utleder bredskjermsjustering fra kildeplassering og start.
Syntaks og kodeeksempler
Alle adaptere må bevare én overordnet tittel, én introduksjon, ordnede elementer og en stabil kilde-rekkefølge. Eksemplene forkorter samlingen til tre elementer, minimum gyldig antall.
Bærbar Markdown-direktiv
:::zigzag{start=media mediaFit=contain}
## Gjør innholdsbeslutninger til et repeterbart system
Gå fra et komplett inventar til prioritert produksjon og målte resultater.
::item{media="inventory-view" alt="Innholdsinventar gruppert etter status og eier."}
### Se hele inventaret
Samle alle URL-er, eiere, statuser og ytelsessignaler i én visning før du bestemmer hva som skal endres.
::
::item{media="priority-view" alt="Prioritetskø ordnet etter forretningsverdi og innsats."}
### Prioriter verdifullt arbeid
Ordne muligheter etter forretningsverdi og innsats slik at teamet kan handle på en gjennomtenkt kø.
::
::item{media="impact-view" alt="Rapporteringsvisning med publiseringsmerknader ved siden av ytelsesendringer."}
### Mål publisert effekt
Koble hver endring til en merknad og et stabilt rapporteringsvindu slik at senere bevegelser kan undersøkes.
::
:::
Disse identifikatorene dokumenterer den bærbare kontrakten; en produksjonsadapter løser hver enkelt til en godkjent aktør. Forfattere må bekrefte at den løste aktøren eksisterer før publisering.
Hugo-shortkode
{{< zigzag title="Gjør innholdsbeslutninger til et repeterbart system" intro="Gå fra et komplett inventar til prioritert produksjon og målte resultater." start="media" mediaFit="contain" >}}
{{< zigzag-item title="Se hele inventaret" media="inventory-view" alt="Innholdsinventar gruppert etter status og eier." >}}
Samle alle URL-er, eiere, statuser og ytelsessignaler i én visning før du bestemmer hva som skal endres.
{{< /zigzag-item >}}
{{< zigzag-item title="Prioriter verdifullt arbeid" media="priority-view" alt="Prioritetskø ordnet etter forretningsverdi og innsats." >}}
Ordne muligheter etter forretningsverdi og innsats slik at teamet kan handle på en gjennomtenkt kø.
{{< /zigzag-item >}}
{{< zigzag-item title="Mål publisert effekt" media="impact-view" alt="Rapporteringsvisning med publiseringsmerknader ved siden av ytelsesendringer." >}}
Koble hver endring til en merknad og et stabilt rapporteringsvindu slik at senere bevegelser kan undersøkes.
{{< /zigzag-item >}}
{{< /zigzag >}}
Hugo-adapteren bruker bare navngitte parametere. Den utleder vekslende klasser fra elementposisjon og må ikke omskrive kilde-rekkefølge for å oppnå det visuelle mønsteret.
WordPress-blokk
<!-- wp:amicited/zigzag {"title":"Gjør innholdsbeslutninger til et repeterbart system","intro":"Gå fra et komplett inventar til prioritert produksjon og målte resultater.","start":"media","mediaFit":"contain"} -->
<!-- wp:amicited/zigzag-item {"title":"Se hele inventaret","media":"inventory-view","alt":"Innholdsinventar gruppert etter status og eier."} -->
<p>Samle alle URL-er, eiere, statuser og ytelsessignaler i én visning før du bestemmer hva som skal endres.</p>
<!-- /wp:amicited/zigzag-item -->
<!-- wp:amicited/zigzag-item {"title":"Prioriter verdifullt arbeid","media":"priority-view","alt":"Prioritetskø ordnet etter forretningsverdi og innsats."} -->
<p>Ordne muligheter etter forretningsverdi og innsats slik at teamet kan handle på en gjennomtenkt kø.</p>
<!-- /wp:amicited/zigzag-item -->
<!-- wp:amicited/zigzag-item {"title":"Mål publisert effekt","media":"impact-view","alt":"Rapporteringsvisning med publiseringsmerknader ved siden av ytelsesendringer."} -->
<p>Koble hver endring til en merknad og et stabilt rapporteringsvindu slik at senere bevegelser kan undersøkes.</p>
<!-- /wp:amicited/zigzag-item -->
<!-- /wp:amicited/zigzag -->
WordPress bør begrense indre blokker til zigzag-elementer og tilby liste-omorganisering uten å tilby manuelle venstre/høyre-kontroller. Redigeringsforhåndsvisningen og frontenden må bruke samme elementrekkefølge.
Eksempler
Godt eksempel
Overskrift: Forstå hvert stadium av en innholdsoppdatering
- Finn synkende sider — Et trenddiagram viser samme URL over sammenlignbare perioder. Teksten forklarer hvordan man skiller vedvarende nedgang fra vanlig ukentlig bevegelse.
- Diagnostiser årsaken — En spørring-og-sidevisning viser hvilke emner som mistet synlighet. Teksten skiller intensjonsdrift, sterkere konkurrenter, utdaterte fakta og tekniske feil.
- Registrer intervensjonen — En merknadsvisning viser publiseringsdatoen og den nøyaktige endringen. Teksten forklarer hvorfor en registrert intervensjon gjør senere måling troverdig.
- Gjennomgå resultatet — En rapporteringsvisning viser det avtalte observasjonsvinduet. Teksten angir hva suksess, ingen endring og ytterligere nedgang hver utløser som neste steg.
Dette fungerer fordi de fire elementene beskriver parallelle visninger innenfor ett oppdateringssystem, hvert visuelle element gir bevis som prosaen ikke effektivt kan reprodusere, og overskriftene alene gir leserne en nyttig skanning. Rekkefølgen støtter en historie uten å gjøre elementet om til instruksjoner.
Dårlig eksempel
Overskrift: Hvorfor plattformen vår er bedre
- Enkelt — Et dekorativt fotografi av en smilende person følger «Plattformen vår er enkel å bruke.»
- Kraftig — En dekorativ abstrakt form følger «Få kraftige resultater raskere.»
- Fleksibelt — Et arkivfotografi følger «Fleksible funksjoner passer alle bedrifter.»
- Kontakt oss — Et stort skjema ber om syv felt.
- Pålitelig — En logostripe vises uten å forklare hvem logoene representerer.
- Flere funksjoner — Åtte urelaterte kulepunkter fyller en høy siste rad.
Dette mislykkes fordi påstandene er generiske, bildene bærer ingen informasjon, og elementene gjør forskjellige jobber. Det innebygde skjemaet avbryter samlingen, mens det siste elementet skjuler en liste inne i et format ment for én fokusert forklaring. Siden blir lang uten å bli tydeligere. Erstatt de tre første påstandene med bevisbasert prosa eller kompakte fordelskort, plasser skjemaet etter den forklarende seksjonen, identifiser tillitsbeviset, og gi de gjenværende funksjonene en passende liste eller tabell.
Skjemamerking og tilgjengelighet
Zigzag er et presentasjonsmønster, ikke en Schema.org-type. Teksten forblir en del av den omsluttende Article eller WebPage, og produktfakta kan bidra til gyldig Product- eller SoftwareApplication-merking bare når siden og fakta uavhengig oppfyller disse kravene. Ikke send ut ItemList bare fordi elementet gjentar elementer, og send aldri ut HowTo når elementene er parallelle funksjoner snarere enn nødvendige steg.
Bruk en seksjon med en tilgjengelig overskrift for samlingen og en semantisk seksjon eller artikkel for hvert element. Hold DOM-rekkefølgen logisk og identisk på tvers av brytepunkter. CSS-rutenett-ordning kan endre hvor bildet vises visuelt, men tastatur-, skjermleser-, kopier-og-lim- og søkeekstraksjonsrekkefølge må forbli konsistent. Skriv aldri «som vist til venstre» eller «i bildet til høyre», fordi disse posisjonene reverseres eller forsvinner på mindre skjermer.
Hvert informativt bilde trenger alternativ tekst som angir hva bildet bidrar med i kontekst. Ikke gjenta det tilstøtende avsnittet ord for ord. Hvis et komplekst diagram, grensesnitt eller en graf ikke kan beskrives konsist, legg til en synlig bildetekst eller en lang beskrivelse i nærheten. Dekorativ bilder frarådes fordi hvert element er påkrevd å rettferdiggjøre sitt visuelle element; hvis en rendrer legger til dekorative utsmykninger, får de tom alternativ tekst.
Overskrifter må følge sidehierarkiet snarere enn å være hardkodet til en visuell størrelse. Elementlenker trenger beskrivende etiketter som «Gjennomgå inventararbeidsflyten», ikke gjentatt «Les mer»-tekst. Ikke gjør hele tekst-og-bilde-raden til én stor lenke: nøstede lenker og uklare aktiveringsregioner skaper tastatur- og skjermleserproblemer. Respekter reduserte-bevegelses-preferanser og krev aldri rulleutløst animasjon for å avsløre innholdet.
Skriveregler
Skriv samlingstittelen på 3–12 ord og introduksjonen på 20–60 ord. Hver elementoverskrift bruker 3–9 konkrete ord, og hver brødtekst bruker 40–120 ord. Tre til seks elementer er det støttede området. Disse grensene finnes fordi elementet trenger nok substans til å rettferdiggjøre store visuelle regioner uten å gjøre hvert par til et uavhengig essay.
Gjør elementoverskrifter grammatisk parallelle. Hvis den første begynner med et verb — «Finn synkende sider» — bør de andre også gjøre det. Hver brødtekst bør svare på tre spørsmål i en naturlig rekkefølge: hva er dette, hvorfor betyr det noe her, og hva bør leseren legge merke til i det visuelle? Bruk spesifikke substantiv, grensesnittetiketter, betingelser og konsekvenser. Unngå ukvalifiserte superlativ som «best», «kraftig» eller «revolusjonerende».
Hold dybden balansert. Ett element på 110 ord ved siden av to elementer på 40 ord signaliserer at samlingen kan blande abstraksjonsnivåer. Del opp det brede elementet, kombiner grunne elementer, eller flytt detaljer til en lenket side. Lenker er valgfrie og begrenset til én per element slik at sekvensen forblir forklarende snarere enn å bli en navigasjonskatalog.
Sett aldri disse inne i et zigzag-element:
- Et skjema, nyhetsbrevfanging, pristabell, tilbud eller primær handlingsoppfordring.
- En sammenligningstabell, accordion, faner, karusell, galleri, videospiller eller en annen zigzag.
- En nummerert prosedyre der rekkefølgen er nødvendig for suksess.
- Flere urelaterte funksjonskulepunkter lagt til for å fylle den visuelle høyden.
- En udokumentert påstand, attesteringsfragment eller logo uten kilde og kontekst.
- Et bilde lagt til bare fordi layouten har en bildeplass.
Innleggstyper som bruker det
postTypes-frontmatteren er sannhetskilden for dette forholdet. En zigzag er valgfri i hver oppførte type og bør bare vises når siden har en kvalifiserende parallell, visuell sekvens.
| Innleggstype | Typisk rolle | Plassering og begrensning |
|---|---|---|
| Ultimat guide | Vis parallelle modeller, systemer eller avanserte applikasjoner | Etter at det felles konseptet er definert; ikke for sekvensielle kapitler |
| Produktside | Vis frem flere primære funksjoner med produktbevis | Etter problemrammesetting og før spesifikasjoner, bevis eller prising |
| Brukscaseside | Koble stadier eller operasjonelle visninger til én målgruppes oppgave | Etter at brukscasen er navngitt; hold hvert element spesifikt for den målgruppen |
| Løsningsside | Par relaterte problemer eller resultater med løsningsarbeidsflyter | Etter løsningsoversikten; ikke bland resultater, attesteringer og CTA-er som jevnbyrdige |
| Funksjonsside | Forklar distinkte underfunksjoner av én funksjon | Etter kjernesvar for funksjonen; bruk skjermbilder som demonstrerer hver underfunksjon |
| Dokumentasjonsartikkel | Forklar parallelle grensesnittregioner eller konfigurasjonsmoduser | Bruk bare for ikke-sekvensielle konsepter; nødvendige handlinger hører hjemme i en stegliste |
QA-sjekkliste
- Sekvensen inneholder tre til seks genuint parallelle elementer.
- Én H2 og en kort introduksjon forklarer hvorfor elementene hører sammen.
- Hvert element har en konkret, grammatisk parallell overskrift.
- Hver brødtekst holder seg innenfor 40–120 ord og har sammenlignbar dybde.
- Hvert visuelle element eksisterer, bidrar med informasjon og samsvarer med sitt element.
- Alternativ tekst eller en tilgjengelig bildetekst formidler hvert visuelle elements nyttige informasjon.
- Standard DOM-rekkefølge er logisk uten noen CSS eller bilder.
- Bredskjermsveksling utledes automatisk; forfattere tildelte ikke vilkårlige sider.
- Mobil bruker én konsistent stablet rekkefølge uten horisontal rulling.
- Ingen formulering avhenger av venstre, høyre eller en annen visningsspesifikk posisjon.
- Intet element inneholder skjemaer, tabeller, nøstede visningskomponenter eller prosedyretrinn.
- Samlingen er ikke tilstøtende et annet stort gjentatt visuelt mønster.
- Lenker er beskrivende og begrenset til én valgfri lenke per element.
- Ingen skjematype utledes fra den vekslende layouten alene.
- Siden forblir nyttig når animasjon er deaktivert og bilder lastes sakte.
- Markdown-, Hugo- og WordPress-representasjoner bevarer de samme feltene og elementrekkefølgen.
Bruk zigzag-seksjoner når parallelle ideer fortjener parallelle bevis. Veksling bør hjelpe lesere med å legge merke til hvert sammenhengende element; den bør aldri være grunnen til at elementet eksisterer.
Flere veiledninger i denne delen
Klar til å sette det ut i livet?
Gratis sjekk · 7 dagers prøveperiode · ingen kredittkort