Annoterede skærmbilleder: Regler og eksempler

Et annoteret skærmbillede viser en reel interfacetilstand og identificerer de præcise områder, en læser skal bemærke. Billedet bærer nummererede markører; siden bærer den matchende tekstforklaring. Denne adskillelse er elementet: hverken et umarkeret produktbillede eller etiketter bagt ind i pixels opfylder kontrakten.

Gennemgang af indholdsaktualitet, filtreret til én sporet URL.

1. Sporings-URL: Bekræfter, at gennemgangen gælder den påtænkte side frem for hele domænet.
2. Statusfilter: Indsnævrer tabellen til sider, der kræver en redaktionel beslutning.
3. Resultatdato: Viser, hvornår den underliggende gennemgangspost sidst blev opdateret.

Optagelsen venter stadig, så kommentaren er en produktionsspecifikation frem for en brudt billedreference. Når aktivet eksisterer, gengives billedet, billedteksten og den nummererede forklaring som én semantisk figur.

Hvorfor dette element er vigtigt

Læsere bruger et produktbillede til at besvare et rumligt spørgsmål: “Hvilken knap, værdi eller tilstand mener denne instruktion?” Tætte interfaces indeholder navigation, filtre, etiketter, data, badges og handlinger, der alle kan se lige vigtige ud. Et ikke-annoteret skærmbillede beder læseren om at reverse-engineere forfatterens opmærksomhed. Nummererede markører reducerer denne søgning til en direkte matchning mellem en synlig placering og en kort forklaring.

Elementet erstatter også skrøbeligt koordinatsprog. “Brug knappen til højre” bliver forkert, når en værktøjslinje brydes; “vælg statusfilter markeret 2” forbliver brugbart, så længe optagelsen er aktuel.

Maskinel udtrækning betyder, at software kan isolere og genbruge den nyttige betydning af en indholdsenhed. Computervision kan genkende interfacetekst, men kan ikke pålideligt udlede, hvorfor én af tyve knapper er vigtig for denne procedure. En synlig, ordnet forklaring skaber eksplicitte markør-til-forklaring-par, som søgesystemer, oversættelsesværktøjer, tilgængelighedssoftware og indholdsgennemgange kan behandle som tekst. Billedet leverer rumlige beviser; forklaringen leverer søgbar betydning. Dette følger de bredere elementets skriveregler : indhold forbliver typet og portabelt, selv når dets gengivelse ændres.

Indbag aldrig forklaringen i pixels. Pixeltekst kan ikke oversættes, søges, markeres eller rettes uden at redigere grafikken. Den er også usynlig for en skærmlæser, software der annoncerer digitalt indhold til personer, der ikke kan se skærmen. Kun markørnumre hører til i billedet.

Hvornår skal det bruges

Brug et annoteret skærmbillede, når læseren skal identificere et specifikt område i et reelt interface, og ord alene efterlader mere end ét plausibelt mål. Det er påkrævet, når to knapper har lignende navne, en vigtig tilstand er subtil, et resultat skal fortolkes i sin omgivende kontekst, eller en visuel konfiguration ikke kan gengives præcist i prosa. Det er også nyttigt, når en produktside kommer med et konkret interfacekrav, som billedet kan bevise.

Et skærmbillede er valgfrit, når instruktionen allerede navngiver en unik, synlig knap, og interaktionen er konventionel. “Vælg Gem ændringer” behøver normalt intet billede, når siden indeholder én sådan knap. Det bliver påkrævet, hvis samme skærm har Gem kladde, Gem visning og Gem ændringer, og det at vælge den forkerte ændrer resultatet.

Et skærmbillede er skadeligt, når det tilføjer vægt uden at løse usikkerhed. Tilføj ikke ét til dekoration eller for at gentage tekst, der er tydeligere i en tabel. Fjorten skærmbilleder i en fjorten-trins guide skaber fjorten afbrydelser, mobil-zoomproblemer og forældede aktiver. Optag de tvetydige trin; lad præcise verber bære de rutinemæssige.

Næsten-missere inkluderer:

• Et fuldt dashboard brugt til at forklare ét ikon: beskær til det mindste område, der bevarer orientering. En markør tabt i et bredt interface reducerer ikke søgeindsatsen.
• Et skærmbillede brugt som numerisk bevis: gentag den afgørende værdi i tekst eller en tabel. Pixels kan ikke være den eneste tilgængelige kopi af et krav.
• Et skærmbillede af en menu før den åbnes: optag den tilstand, læseren skal inspicere. Den lukkede tilstand beviser, at produktet eksisterer, men ikke hvilket valg der skal træffes.
• Et skærmbillede med kundedata: erstat dem med stabile demodata før optagelse. Sløring er let at overse.
• Et diagram forklædt som skærmbillede: brug et diagram til abstrakte relationer. Interfacerealisme hjælper kun, når interfacet er relevant.

Hvor skal det placeres

Placer figuren efter afsnittet eller trinnet, der først beder læseren om at inspicere interfacet. I en procedure sættes den efter handlingen og før succes-tilstanden eller fejlfindingen, så læseren finder knappen, før resultatet verificeres.

Hold billede, billedtekst og forklaring samlet. En overskrift må introducere gruppen, men et andet afsnit, fremhævelse, annonce eller sideskift må ikke adskille optagelsen fra dens nummererede forklaringer. En billedtekst identificerer hele skærmen og konteksten; den indeholder ikke en instruktion, der hører til i prosaen, eller erstatter forklaringen.

Placer ikke to fuldbredde-skærmbilleder ved siden af hinanden. Indsæt den forklaring, der adskiller dem, eller opret én mærket sammenligning, når begge tilstande skal vurderes sammen. Hold skærmbilleder væk fra ikke-relaterede handlingsopfordringer, tætte tabeller og gallerier.

Gentag kun elementet, når hver forekomst besvarer et forskelligt rumligt spørgsmål. Foretræk én fokuseret figur; giv ellers separate beskæringer forskellige filnavne og formål.

Anatomi

Anatomioptagelsen viser de synlige og tekstmæssige dele af ét komplet element. Forklarende etiketter forbliver i den gengivede forklaring frem for at blive en del af kildebilledet.

Gengivet forklaring

1. Kontekstgrænse: Inkluderer nok omgivende interface til at identificere siden og placeringen, men udelader ikke-relateret navigation og tomt rum.
2. Nummereret markør: Bruger en højkontrast-cirkel og et heltal, ikke kun farve, til at forbinde et område med dets forklarespost.
3. Målområde: Markerer den mindste komplette knap, værdi eller tilstand, der er nødvendig for forklaringen; den dækker aldrig målets etiket.
4. Orienteringselement: Bevarer én stabil overskrift, fane eller paneletiket, så læseren kan finde samme område i det levende produkt.
5. Billedtekst: Navngiver skærmen, tilstanden og scenariet i synlig tekst under billedet.
6. Forklaring: Bruger en ordnet liste, hvis numre nøjagtigt matcher markørerne, og hvis poster forklarer betydning, ikke blot udseende.

Markørnumre starter ved 1 og følger forklaringens rækkefølge. Brug to til seks per billede; én egner sig til et vanskeligt mål, mens mere end seks normalt signalerer en for bred optagelse.

Designeksempler

De understøttede varianter ændrer beskæring og visningsport, ikke annotationspolitikken. Hver variant bruger demodata, nummererede billedmarkører, en ekstern tekstforklaring og en synlig billedtekst.

Fokuseret knap: Foretrukket til en enkelt tvetydig handling. Bevar ét orienteringslabel, så beskæringen ikke bliver en anonym firkant.

Arbejdsgangstilstand: Brug, når forholdet mellem en indtastning, et filter, en status og et resultat er vigtigt. Hold ikke-relateret global navigation ude af billedet.

URL i kontekst: Den eneste standardvariant, der inkluderer browservinduesrammer, det vil sige browserens egne faner, adresselinje og knapper. Inkluder kun adresselinjen og nødvendig tilladelses- eller sikkerhedsindikator.

Mobil tilstand: Optag det faktiske smalle layout, når interaktionen ændres ved mobil bredde. Krymp ikke en bred computerskærm og kald det et mobileksempel.

Parametre

Parametrene udgør den portable indholdskontrakt. Visuelle værdier såsom markørfarve, kanttykkelse og billedteksttypografi tilhører gengiveren og er ikke forfatterfelter.

screenId identificerer produktfladen uafhængigt af dens filnavn, så en udgivelse kan finde forskellige beskæringer af content-freshness-audit. alt.yaml-filen forbliver enkel: ét filnavn efterfulgt af én foldet alternativ tekststreng.

Syntaks og kodeeksempler

Hver notation bevarer de samme metadata, billedtekst, markører og læserækkefølge billede-billedtekst-forklaring.

Portabel Markdown-direktiv

:::annotated-screenshot{src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport=1440 density="2x" screenId="content-freshness-audit" captureDate="2026-08-27"}
Gennemgang af indholdsaktualitet filtreret til én sporet URL.

1. **Sporings-URL:** Bekræfter hvilken side gennemgangen evaluerer.
2. **Statusfilter:** Begrænser resultaterne til sider, der afventer gennemgang.
3. **Resultatdato:** Viser, hvornår gennemgangsdataene blev opdateret.
:::

Adapteren henter alt fra mappens alt.yaml. En manglende filnavnøgle er en udgivelsesfejl, ikke tilladelse til at kopiere billedteksten.

Hugo shortcode-mapping

{{< annotated-screenshot src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport="1440" density="2x" screenId="content-freshness-audit" captureDate="2026-08-27" >}}
Gennemgang af indholdsaktualitet filtreret til én sporet URL.

1. **Sporings-URL:** Bekræfter hvilken side gennemgangen evaluerer.
2. **Statusfilter:** Begrænser resultaterne til sider, der afventer gennemgang.
3. **Resultatdato:** Viser, hvornår gennemgangsdataene blev opdateret.
{{< /annotated-screenshot >}}

Dette er en adapterkontrakt, ikke en registreret shortcode. Indtil en godkendt gengiver og aktiv findes, brug den etablerede semantisk-figur-pipeline eller lad den foreskrevne optagelseskommentar stå. Erstat ikke med en gengiver, der dropper forklaringen eller aktualitetsfelterne.

WordPress-blok eller shortcode

[annotated_screenshot src="workflow-state.webp" viewport="1440" density="2x" screen_id="content-freshness-audit" capture_date="2026-08-27"]
[caption]Gennemgang af indholdsaktualitet filtreret til én sporet URL.[/caption]
[marker number="1" label="Sporings-URL"]Bekræfter hvilken side gennemgangen evaluerer.[/marker]
[marker number="2" label="Statusfilter"]Begrænser resultaterne til sider, der afventer gennemgang.[/marker]
[marker number="3" label="Resultatdato"]Viser, hvornår gennemgangsdataene blev opdateret.[/marker]
[/annotated_screenshot]

En WordPress-blok kan eksponere felterne som knapper, men den skal gemme markørbeskrivelser som tekst.

Eksempler

God: én tvetydig tilstand, tre nyttige markører

Gennemgang af indholdsaktualitet for demo.example/pricing/.

1. Sporings-URL: Bekræfter, at resultatet tilhører prissiden valgt i instruktionen.
2. Skal gennemgås: Identificerer det præcise filter, der fjerner aktuelle sider fra arbejdskøen.
3. Sidst opdateret: Forhindrer redaktøren i at behandle et gammelt gennemgangsresultat som en aktuel diagnose.

Dette virker, fordi hver markør besvarer en beslutning, beskæringen bevarer orientering, og forklaringen forklarer konsekvenser, der ikke er synlige i pixels. Demodomænet er tydeligt ikke-kundedata.

Dårlig: en mærket produktplakat

Den dårlige version forklarer et helt dashboard på én gang. Otte pile krydser hinanden, etiketter skjuler knapper, og indbagt reklame giver ingen handling. Browserbogmærker skaber privatlivsrisiko, kundenavne gør godkendelse usikker, ingen skærmidentifikator understøtter opdateringer, og mobilskalering gør mål ulæselige.

Reparér det ved at vælge én opgave, bruge godkendte demodata, beskære til panelet og kun beholde nødvendige markører. Flyt forklaringer til en tekstforklaring, tilføj kontekstuel alternativ tekst , og notér skærmidentifikator og dato.

Skemamarkering og tilgængelighed

Et annoteret skærmbillede har ingen særlig Schema.org-type. Det kan udfylde en Articles image-egenskab eller et ImageObject med præcis contentUrl, billedtekst, bredde og højde. Opfind ikke markøregenskaber; hold forklaringen synlig.

Brug native figur-semantik: ét <figure>-element, der indeholder <img>, et <figcaption> og den ordnede forklaring. Billedteksten navngiver hele skærmen og tilstanden. Billedets alt-attribut beskriver, hvad skærmen viser i denne kontekst; den bør ikke starte med “skærmbillede af”, fordi billedelementet allerede annoncerer sig selv. Forklaringen leverer de detaljerede nummererede beskrivelser, så gentagelse af alle seks poster i alternativ tekst skaber en lang, duplikeret annoncering.

Sigt efter 80-180 tegn med maksimalt 250 som loft. Nævn produktområde, tilstand og markeret formål: “Gennemgang af indholdsaktualitet filtreret til én sporet URL, med markører på statusfilter og sidst opdateret dato.” Transkribér ikke interfacet, stop ikke søgeord ind, og brug ikke filnavnet. Dette informative billede har normalt brug for ikke-tom alternativ tekst.

Markørnumre skal være læsbare uden farve. Brug høj kontrast mod både lyse og mørke interfaceområder, hold deres visuelle størrelse ensartet, og dæk ikke etiketter eller værdier. Forklaringen bruger en ordnet liste i normal dokumentrækkefølge; undgå ARIA, eller Accessible Rich Internet Applications, roller, der gør statisk indhold til en alarm eller interaktiv widget. En aria-describedby-relation er kun valgfri, når test viser, at den forbedrer navigation uden at få den synlige forklaring til at blive annonceret to gange.

Ved smalle bredder skal responsivt design bevare betydningen. Skalér et bredt billede kun, mens markører og mål forbliver læselige; ellers brug en fokuseret beskæring eller ægte mobiloptagelse. Forårsag aldrig vandret rulning på sideniveau eller kræv zoom. Billedtekst og forklaring brydes nedenunder.

Indholds- og optagelsesregler

Konsistens gør skærmbilleder sammenlignelige og udskiftelige. Optag computerproduktskærme ved en fast 1440 CSS-pixel visningsport og 2x pixel-densitet, ofte kaldet Retina-densitet, hvilket registrerer to enhedspixels for hver CSS-pixel. Optag ægte mobile tilstande ved 390 CSS-pixels og 2x densitet. Brug det godkendte produkttema konsekvent inden for en guide; skift ikke mellem lys og mørk tilstand, medmindre temaforskellen er emnet.

Brug kun demodata: ingen rigtige navne, e-mailadresser, domæner, betalingsoplysninger, tokens, prompter eller resultater. Inspicer sidepaneler, seneste elementer, autoudfyldning, notifikationer og avatarer før optagelse.

Udelad browservinduesrammer, medmindre en URL, tilladelse eller browserknap er pointen. Skjul faner, bogmærker, udvidelser, downloads, profiler og notifikationer. Optag efter indlæsning; luk irrelevante værktøjstip og vis kun en markør, når det er nødvendigt.

Gem kildeoptagelser under cdn-assets/seo-playbook/elements/annotated-screenshot/. Brug små bogstaver og kebab-case navne baseret på skærm og tilstand, f.eks. freshness-audit-needs-review.webp; brug aldrig final, new, v2, en persons navn eller en dato som filnavn. Det stabile navn gør det muligt at erstatte aktivet uden at omskrive hver side. Brug WebP til normal levering, fortrinsvis en tabsfri indstilling, når lille interfacetekst skal forblive skarp. Brug kun PNG, når produktionspipelinen viser, at WebP skader tekst eller gennemsigtighed. Brug ikke JPEG til UI-optagelser med fin tekst og skarpe kanter.

Gengiv i maksimalt 1600 CSS-pixels bredde; en 1440-pixel 2x kilde kan være 2880 fysiske pixels. Bevar billedformat og iboende dimensioner. Optimering understøtter billede-SEO , men komprimering må ikke gøre tekst eller markører slørede.

Hver aktivmappe indeholder alt.yaml med én post pr. filnavn:

freshness-audit-needs-review.webp: >-
  AmICited-gennemgang af indholdsaktualitet filtreret til én sporet URL, med nummererede markører på gennemgangsstatus og sidst opdateret dato.

Nøglen matcher filnavnet præcist; værdien er alternativ tekst, ikke en billedtekst eller forklaring. Pladsholdere, standard-dashboards og ikke-eksisterende billedreferencer er forbudt. Afventende optagelser bruger kun en SCREENSHOT-kommentar og screenshotsPending = true.

Aktualitets- og genoptagelsespolitik

Skærmbilleder ældes stille, når en afbildet knap flytter sig eller skifter navn. Behandl hver optagelse som et syn af en registreret skærm: screenId forbinder produktændringer med aktiver, mens optagelsesdatoen identificerer den registrerede tilstand.

En UI-ændring udløser en genoptagelse, når den flytter eller omdøber et markeret mål, ændrer den tilstand, forklaringen beskriver, ændrer navigationsstien, der er nødvendig for at nå det, fjerner et bevaret orienteringselement, eller gør det gamle billede sandsynligt til at sende læseren til den forkerte knap. Genoptag hele figurens sæt for den pågældende skærm, inklusive fokuserede og mobile varianter. En farvetoken-ændring, afstandsjustering eller ikke-relateret sidepanel-tilføjelse kræver ikke automatisk udskiftning, medmindre skærmbilledet nu synligt er i konflikt med den levende oplevelse eller tilgængelighedsstandard.

Når en skærm ændres, søg efter dens screenId, derefter dens mappe og filnavn for at fange ældre anvendelser. Erstat stabile filer, gennemgå alt.yaml, og inspicér hver berørt forklaring. Omdøb ikke erstatningsfiler og efterlad ældre referencer.

Produktskærmsejeren signalerer ændringer; indholdsejeren accepterer erstatninger. Genoptag med samme demoopsætning, visningsport, densitet og tema. Gennemgå skærmbilleder ved hver væsentlig sideopdatering.

Indlægstyper der bruger det

postTypes front matter er den registrerede sammenkobling. Hver type bruger den samme elementkontrakt, men anvender en forskellig kravtærskel.

Casestudier kræver en ekstra grænse: enten indhent eksplicit tilladelse til at vise rigtige kundeoplysninger, eller genopbyg interfacet med tydeligt offentliggjorte demodata og behandl det som en arbejdsgangsillustration, ikke resultatbevis. Redigering er ikke en erstatning for samtykke eller et kontrolleret opsætning.

QA-tjekliste

En reviewer kontrollerer kommunikations- og vedligeholdelsesrisiko før visuel finish.

• Formål: Figuren løser én rumlig tvetydighed eller beviser én synlig interfacepåstand.
• Nødvendighed: Rutinetrin forbliver tekst; siden tildeler ikke som standard ét skærmbillede til hvert trin.
• Reel tilstand: Optagelsen viser den nøjagtige åbne menu, valgte filter, resultat eller fejl, der diskuteres i teksten.
• Demodata: Ingen kunde-, medarbejder-, konto-, browser-, token-, prompt- eller betalingsoplysninger er synlige.
• Optagelseskonsistens: Visningsport, 2x-densitet, tema, interfacetilstand og browservinduesramme-regel matcher standarden.
• Fokuseret beskæring: Nok kontekst bevares til orientering, men ikke-relaterede interfaceområder konkurrerer ikke med målet.
• Markører: Der er ét til seks fortløbende numre, hver med høj kontrast, læselig og fri af etiketter og værdier.
• Ekstern forklaring: Hver markør har én matchende ordnet-listepost i sideteksten; ingen forklaringsord er indbagt i pixels.
• Billedtekst: Figuren har en kortfattet synlig billedtekst, der navngiver dens skærm, tilstand og scenario.
• Alternativ tekst: Mappens alt.yaml indeholder en præcis filnavnnøgle og en kontekstuel beskrivelse inden for måltegnintervallet.
• Mobiladfærd: Målet og markørerne forbliver læselige uden vandret rulning på sideniveau eller påkrævet zoom; ellers findes en fokuseret beskæring.
• Filaftale: Sti, små bogstaver med kebab-case navn, format, dimensioner og iboende størrelse følger leveringsstandarden.
• Aktualitet: screenId og optagelsesdato er registreret, det levende UI matcher stadig, og alle referencer kan findes ved tekstsøgning.
• Portabel paritet: Markdown-, Hugo- og WordPress-repræsentationer bevarer samme aktiv, billedtekst, markørrækkefølge og forklaringsordlyd.
• Intet brudt aktiv: En ægte billedsti vises kun, efter at filen eksisterer; afventende optagelser forbliver kommentarer og beholder screenshotsPending = true.

FAQ

Akademiskabelonen gengiver de fem gennemgåede spørgsmål, der er gemt i denne sides [[faq]] front matter. De dækker skærmbilledfrekvens, eksterne forklaringer, længde af alternativ tekst, genoptagelsesudløsere og undtagelsen for browservinduesrammer.