Screenshot annotati: Regole ed esempi

Uno screenshot annotato mostra uno stato reale dell’interfaccia e identifica le aree esatte che il lettore deve notare. L’immagine contiene marcatori numerati; la pagina contiene la legenda testuale corrispondente. Questa separazione è l’elemento: né un’immagine di prodotto senza marcature né etichette incorporate nei pixel soddisfano il contratto.

Audit di freschezza dei contenuti, filtrato per un URL tracciato.

1. URL tracciato: Conferma che la revisione si applica alla pagina prevista anziché all’intero dominio.
2. Filtro stato: Restringe la tabella alle pagine che richiedono una decisione editoriale.
3. Data risultato: Mostra quando il record di audit sottostante è stato aggiornato l’ultima volta.

L’acquisizione è in sospeso, quindi il commento è una specifica di acquisizione di produzione piuttosto che un riferimento a un’immagine non funzionante. Una volta che l’asset esiste, l’immagine, la didascalia e la legenda numerata vengono renderizzate come un’unica figura semantica.

Perché questo elemento è importante

I lettori usano un’immagine di prodotto per rispondere a una domanda spaziale: “Quale controllo, valore o stato intende questa istruzione?” Le interfacce dense contengono navigazione, filtri, etichette, dati, badge e azioni che possono sembrare tutti ugualmente importanti. Uno screenshot senza annotazioni chiede al lettore di decodificare l’attenzione dell’autore. I marcatori numerati riducono questa ricerca a una corrispondenza diretta tra una posizione visibile e una breve spiegazione.

L’elemento sostituisce anche il fragile linguaggio delle coordinate. “Usa il controllo a destra” diventa sbagliato quando una barra degli strumenti va a capo; “scegli il filtro stato contrassegnato con 2” rimane utilizzabile finché l’acquisizione è attuale.

L’estraibilità automatica significa che il software può isolare e riutilizzare il significato utile di un’unità di contenuto. La visione artificiale può riconoscere il testo dell’interfaccia, ma non può dedurre in modo affidabile perché uno di venti controlli è importante per questa procedura. Una legenda visibile e ordinata crea coppie esplicite marcatore-spiegazione che i sistemi di ricerca, gli strumenti di traduzione, il software di accessibilità e gli audit dei contenuti possono elaborare come testo. L’immagine fornisce prove spaziali; la legenda fornisce significato ricercabile. Questo segue le più ampie regole di scrittura degli elementi : il contenuto rimane tipizzato e portatile anche quando il suo renderizzatore cambia.

Non incorporare mai la legenda nei pixel. Il testo nei pixel non può essere tradotto, cercato, selezionato o corretto senza modificare l’immagine. È anche invisibile a uno screen reader, un software che annuncia i contenuti digitali alle persone che non possono vedere lo schermo. Solo i numeri dei marcatori appartengono all’immagine.

Quando usarlo

Usa uno screenshot annotato quando il lettore deve identificare una regione specifica in un’interfaccia reale e le parole da sole lasciano più di un bersaglio plausibile. È obbligatorio quando due controlli hanno nomi simili, uno stato importante è sottile, un risultato deve essere interpretato nel suo contesto circostante, o una configurazione visiva non può essere rappresentata fedelmente in prosa. È utile anche quando una pagina prodotto fa un’affermazione concreta sull’interfaccia che l’immagine può dimostrare.

Uno screenshot è facoltativo quando l’istruzione nomina già un controllo visibile univoco e l’interazione è convenzionale. “Seleziona Salva modifiche” normalmente non necessita di immagini quando la pagina contiene un solo pulsante di questo tipo. Diventa obbligatorio se la stessa schermata ha Salva bozza, Salva vista e Salva modifiche e scegliere quello sbagliato cambia il risultato.

Uno screenshot è dannoso quando aggiunge peso senza risolvere l’incertezza. Non aggiungerne uno per decorazione o per ripetere testo che è più chiaro in una tabella. Quattordici screenshot in una guida di quattordici passaggi creano quattordici interruzioni, problemi di zoom su mobile e risorse obsolete. Acquisisci i passaggi ambigui; lascia che i verbi precisi portino avanti quelli di routine.

Casi quasi corretti includono:

• Una dashboard completa usata per spiegare un’icona: taglia alla regione più piccola che preserva l’orientamento. Un marcatore perso in un’interfaccia ampia non riduce lo sforzo di ricerca.
• Uno screenshot usato come prova numerica: ripeti il valore decisivo nel testo o in una tabella. I pixel non possono essere l’unica copia accessibile di un’affermazione.
• Uno screenshot di un menu prima che si apra: acquisisci lo stato che il lettore deve ispezionare. Lo stato chiuso dimostra che il prodotto esiste ma non quale scelta fare.
• Uno screenshot contenente record di clienti: sostituiscili con dati demo stabili prima dell’acquisizione. Sfocare è facile da dimenticare.
• Un diagramma travestito da screenshot: usa un diagramma per relazioni astratte. Il realismo dell’interfaccia aiuta solo quando l’interfaccia è importante.

Dove posizionarlo

Posiziona la figura dopo il paragrafo o il passaggio che per primo chiede al lettore di ispezionare l’interfaccia. In una procedura, mettila dopo l’azione e prima dello stato di successo o della risoluzione dei problemi, così il lettore individua il controllo prima di verificare il risultato.

Mantieni insieme immagine, didascalia e legenda. Un’intestazione può introdurre il gruppo, ma un altro paragrafo, un callout, un annuncio pubblicitario o un’interruzione di pagina non devono separare l’acquisizione dalle sue spiegazioni numerate. Una didascalia identifica l’intero schermo e contesto; non contiene un’istruzione che appartiene alla prosa né sostituisce la legenda.

Non posizionare due screenshot a larghezza intera uno accanto all’altro. Inserisci la spiegazione che li distingue, oppure crea un confronto etichettato quando entrambi gli stati devono essere valutati insieme. Tieni gli screenshot lontani da inviti all’azione non correlati, tabelle dense e gallerie.

Ripeti l’elemento solo quando ogni occorrenza risponde a una domanda spaziale diversa. Preferisci una figura mirata; altrimenti dai a ritagli diversi nomi file e scopi distinti.

Anatomia

L’acquisizione dell’anatomia mostra le parti visive e testuali di un elemento completo. Le etichette esplicative rimangono nella legenda renderizzata anziché diventare parte dell’immagine sorgente.

Legenda renderizzata

1. Limite di contesto: Include interfaccia circostante sufficiente a identificare la pagina e la posizione, ma esclude navigazione non correlata e spazio vuoto.
2. Marcatore numerato: Usa un cerchio ad alto contrasto e un numero intero, non solo il colore, per collegare una regione alla sua voce di legenda.
3. Regione bersaglio: Segna il controllo, valore o stato completo più piccolo necessario per la spiegazione; non copre mai l’etichetta del bersaglio.
4. Punto di riferimento per l’orientamento: Preserva un’intestazione, scheda o etichetta di pannello stabile in modo che il lettore possa trovare la stessa area nel prodotto live.
5. Didascalia: Nomina lo schermo, lo stato e lo scenario in testo visibile sotto l’immagine.
6. Legenda: Usa un elenco ordinato i cui numeri corrispondono esattamente ai marcatori e le cui voci spiegano il significato, non solo l’aspetto.

I numeri dei marcatori iniziano da 1 e seguono l’ordine della legenda. Usane da due a sei per immagine; uno basta per un bersaglio difficile, mentre più di sei di solito indicano un’acquisizione troppo ampia.

Esempi di design

Le varianti supportate cambiano ritaglio e viewport, non la politica di annotazione. Ogni variante utilizza dati demo, marcatori numerati nell’immagine, una legenda testuale esterna e una didascalia visibile.

Controllo mirato: Preferito per una singola azione ambigua. Preserva un’etichetta di orientamento in modo che il ritaglio non diventi un rettangolo anonimo.

Stato del flusso di lavoro: Usalo quando conta la relazione tra un input, uno stato e un risultato. Tieni la navigazione globale non correlata fuori dall’inquadratura.

URL nel contesto: L’unica variante standard che include la chrome del browser, ovvero le schede, la barra degli indirizzi e i controlli del browser. Includi solo la barra degli indirizzi e l’indicatore di autorizzazione o sicurezza necessario.

Stato mobile: Acquisisci il layout stretto effettivo quando l’interazione cambia a larghezza mobile. Non ridurre uno schermo desktop ampio chiamandolo esempio mobile.

Parametri

I parametri costituiscono il contratto di contenuto portatile. I valori visivi come colore del marcatore, spessore del bordo e tipografia della didascalia appartengono al renderizzatore e non sono campi per l’autore.

Il screenId identifica la superficie del prodotto indipendentemente dal suo nome file, così una release può trovare diversi ritagli di content-freshness-audit. Il file alt.yaml rimane semplice: un nome file seguito da una stringa di testo alternativo piegata.

Sintassi ed esempi di codice

Ogni notazione preserva gli stessi metadati, didascalia, marcatori e ordine di lettura immagine–didascalia–legenda.

Direttiva Markdown portatile

:::annotated-screenshot{src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport=1440 density="2x" screenId="content-freshness-audit" captureDate="2026-08-27"}
Content freshness audit filtrato per un URL tracciato.

1. **URL tracciato:** Conferma quale pagina l'audit valuta.
2. **Filtro stato:** Limita i risultati alle pagine in attesa di revisione.
3. **Data risultato:** Mostra quando i dati dell'audit sono stati aggiornati.
:::

L’adattatore risolve alt dal alt.yaml della cartella. Una chiave nome file mancante è un errore di pubblicazione, non un’autorizzazione a copiare la didascalia.

Mappatura shortcode Hugo

{{< annotated-screenshot src="/images/seo-playbook/elements/annotated-screenshot/workflow-state.webp" viewport="1440" density="2x" screenId="content-freshness-audit" captureDate="2026-08-27" >}}
Content freshness audit filtrato per un URL tracciato.

1. **URL tracciato:** Conferma quale pagina l'audit valuta.
2. **Filtro stato:** Limita i risultati alle pagine in attesa di revisione.
3. **Data risultato:** Mostra quando i dati dell'audit sono stati aggiornati.
{{< /annotated-screenshot >}}

Questo è un contratto di adattatore, non uno shortcode registrato. Fino a quando non esistono un renderizzatore e un asset approvati, utilizza la pipeline semantic-figure consolidata o lascia il commento di acquisizione prescritto. Non sostituire con un renderizzatore che elimina la legenda o i campi di aggiornamento.

Blocco o shortcode WordPress

[annotated_screenshot src="workflow-state.webp" viewport="1440" density="2x" screen_id="content-freshness-audit" capture_date="2026-08-27"]
[caption]Content freshness audit filtrato per un URL tracciato.[/caption]
[marker number="1" label="URL tracciato"]Conferma quale pagina l'audit valuta.[/marker]
[marker number="2" label="Filtro stato"]Limita i risultati alle pagine in attesa di revisione.[/marker]
[marker number="3" label="Data risultato"]Mostra quando i dati dell'audit sono stati aggiornati.[/marker]
[/annotated_screenshot]

Un blocco WordPress può esporre i campi come controlli, ma deve memorizzare le descrizioni dei marcatori come testo.

Esempi

Buono: uno stato ambiguo, tre marcatori utili

Revisione freschezza contenuti per demo.example/pricing/.

1. URL tracciato: Verifica che il risultato appartenga alla pagina pricing selezionata nell’istruzione.
2. Da revisionare: Identifica il filtro esatto che rimuove le pagine correnti dalla coda di lavoro.
3. Ultimo aggiornamento: Impedisce all’editor di trattare un risultato di audit vecchio come diagnosi corrente.

Funziona perché ogni marcatore risponde a una decisione, il ritaglio preserva l’orientamento e la legenda spiega le conseguenze non visibili nei pixel. Il dominio demo è chiaramente un dato non cliente.

Cattivo: un poster di prodotto etichettato

La versione cattiva spiega un’intera dashboard in una volta sola. Otto frecce si incrociano, le etichette oscurano i controlli e la promozione incorporata non dà alcuna azione. I segnalibri del browser creano un rischio per la privacy, i nomi dei clienti rendono incerta l’approvazione, nessun identificatore di schermata supporta gli aggiornamenti e la scalatura mobile rende i bersagli illeggibili.

Riparalo selezionando un’attività, usando dati demo approvati, ritagliando il suo pannello e mantenendo solo i marcatori necessari. Sposta le spiegazioni in una legenda testuale, aggiungi testo alternativo contestuale e registra l’identificatore della schermata e la data.

Markup schema e accessibilità

Uno screenshot annotato non ha un tipo Schema.org speciale. Può popolare la proprietà image di un Article o un ImageObject con contentUrl, didascalia, larghezza e altezza accurati. Non inventare proprietà per i marcatori; mantieni la legenda visibile.

Usa la semantica nativa delle figure: un <figure> che contiene <img>, un <figcaption> e la legenda ordinata. La didascalia nomina l’intero schermo e stato. L’attributo alt dell’immagine descrive cosa mostra lo schermo in questo contesto; non deve iniziare con “screenshot di” perché l’elemento immagine si annuncia già da solo. La legenda fornisce le spiegazioni numerate dettagliate, quindi ripetere tutti e sei gli elementi nel testo alternativo crea un annuncio lungo e duplicato.

Punta a 80–180 caratteri, con 250 come limite massimo. Nomina l’area di prodotto, lo stato e lo scopo marcato: “Audit di freschezza dei contenuti filtrato per un URL tracciato, con marcatori sul filtro stato e sulla data dell’ultimo aggiornamento.” Non trascrivere l’interfaccia, infilare parole chiave o usare il nome file. Questa immagine informativa normalmente necessita di testo alternativo non vuoto.

I numeri dei marcatori devono essere leggibili senza colore. Usa alto contrasto sia su regioni dell’interfaccia chiare che scure, mantieni coerente la loro dimensione visiva e non coprire etichette o valori. La legenda usa un elenco ordinato nel normale ordine del documento; evita ruoli ARIA, o Applicazioni Internet Ricche Accessibili, che trasformano il contenuto statico in un avviso o widget interattivo. Una relazione aria-describedby è facoltativa solo quando i test mostrano che migliora la navigazione senza causare la doppia pronuncia della legenda visibile.

A larghezze ridotte, il design responsivo deve preservare il significato. Scala un’immagine ampia solo mentre marcatori e bersagli rimangono leggibili; altrimenti fornisci un ritaglio mirato o un’acquisizione mobile genuina. Non causare mai scorrimento orizzontale a livello di pagina o richiedere zoom. Didascalia e legenda vanno a capo sotto.

Regole di contenuto e acquisizione

La coerenza rende gli screenshot confrontabili e sostituibili. Acquisisci schermate di prodotto desktop a un viewport fisso di 1440 pixel CSS e densità di pixel 2x, spesso chiamata densità Retina, che registra due pixel fisici per ogni pixel CSS. Acquisisci stati mobile reali a 390 pixel CSS e densità 2x. Usa il tema di prodotto approvato in modo coerente all’interno di una guida; non alternare modalità chiara e scura a meno che la differenza di tema non sia l’oggetto.

Usa solo dati demo: niente nomi reali, indirizzi email, domini, dettagli di fatturazione, token, prompt o risultati. Ispeziona barre laterali, elementi recenti, completamento automatico, notifiche e avatar prima dell’acquisizione.

Escludi la chrome del browser a meno che un URL, un’autorizzazione o un controllo del browser non sia il punto. Nascondi schede, segnalibri, estensioni, download, profili e notifiche. Acquisisci dopo il caricamento; chiudi i tooltip non pertinenti e mostra un cursore solo quando essenziale.

Conserva le acquisizioni originali sotto cdn-assets/seo-playbook/elements/annotated-screenshot/. Usa nomi in kebab-case minuscolo basati su schermo e stato, come freshness-audit-needs-review.webp; non usare mai final, new, v2, il nome di una persona o una data come nome file. Il nome stabile permette di sostituire l’asset senza riscrivere ogni pagina. Usa WebP per la distribuzione normale, preferibilmente una configurazione senza perdita quando il testo piccolo dell’interfaccia deve rimanere nitido. Usa PNG solo quando la pipeline di produzione dimostra che WebP danneggia il testo o la trasparenza. Non usare JPEG per acquisizioni UI con testo fine e bordi netti.

Renderizza a non più di 1600 pixel CSS di larghezza; una sorgente 2x a 1440 pixel può essere 2880 pixel fisici. Preserva le proporzioni e le dimensioni intrinseche. L’ottimizzazione supporta la SEO delle immagini , ma la compressione non deve sfocare testo o marcatori.

Ogni cartella di asset contiene alt.yaml con una voce per nome file:

freshness-audit-needs-review.webp: >-
  AmICited content freshness audit filtrato per un URL tracciato, con marcatori numerati sullo stato di revisione e sulla data dell'ultimo aggiornamento.

La chiave corrisponde esattamente al nome file; il valore è testo alternativo, non una didascalia o legenda. Segnaposto, dashboard fittizie e riferimenti a immagini inesistenti sono proibiti. Le acquisizioni in sospeso usano solo un commento SCREENSHOT e screenshotsPending = true.

Politica di aggiornamento e riacquisizione

Gli screenshot invecchiano silenziosamente quando un controllo raffigurato si sposta o cambia nome. Considera ogni acquisizione come una vista di una schermata registrata: screenId collega le modifiche del prodotto agli asset, mentre la data di acquisizione identifica lo stato registrato.

Una modifica dell’interfaccia attiva una riacquisizione quando sposta o rinomina un bersaglio marcato, cambia lo stato che la legenda spiega, altera il percorso di navigazione necessario per raggiungerlo, rimuove un punto di riferimento di orientamento preservato, o rende probabile che la vecchia immagine porti il lettore al controllo sbagliato. Riacquisisci il set completo di figure per quella schermata, incluse le varianti mirate e mobile. Un cambio di colore del tema, un aggiustamento della spaziatura o l’aggiunta di una barra laterale non correlata non richiedono sostituzione automatica a meno che lo screenshot ora non sia in conflitto visibile con l’esperienza live o lo standard di accessibilità.

Quando una schermata cambia, cerca il suo screenId, poi la sua cartella e nome file per individuare usi precedenti. Sostituisci i file stabili, controlla alt.yaml e ispeziona ogni legenda interessata. Non rinominare i file di sostituzione lasciando in sospeso i riferimenti più vecchi.

Il proprietario della schermata di prodotto segnala le modifiche; il proprietario dei contenuti accetta le sostituzioni. Riacquisisci con la stessa fixture demo, viewport, densità e tema. Controlla gli screenshot durante ogni aggiornamento sostanziale della pagina.

Tipi di post che lo utilizzano

Il postTypes nel frontmatter è l’iscrizione registrata. Ogni tipo usa lo stesso contratto dell’elemento ma applica una soglia di requisiti diversa.

I casi di studio richiedono un vincolo aggiuntivo: o ottieni l’autorizzazione esplicita a mostrare informazioni reali del cliente o ricostruisci l’interfaccia con dati demo chiaramente dichiarati e trattala come un’illustrazione del flusso di lavoro, non come prova di risultati. La redazione non sostituisce il consenso o una fixture controllata.

Checklist QA

Un revisore verifica il rischio di comunicazione e manutenzione prima della rifinitura visiva.

• Scopo: La figura risolve un’ambiguità spaziale o dimostra un’affermazione visibile dell’interfaccia.
• Necessità: I passaggi di routine rimangono testo; la pagina non assegna uno screenshot a ogni passaggio per impostazione predefinita.
• Stato reale: L’acquisizione mostra il menu aperto esatto, il filtro selezionato, il risultato o l’errore discusso nel testo.
• Dati demo: Non sono visibili informazioni di clienti, dipendenti, account, browser, token, prompt o fatturazione.
• Coerenza acquisizione: Viewport, densità 2x, tema, stato dell’interfaccia e regola della chrome del browser corrispondono allo standard.
• Ritaglio mirato: Rimane contesto sufficiente per l’orientamento, ma le aree dell’interfaccia non correlate non competono con il bersaglio.
• Marcatori: Sono presenti da uno a sei numeri continui, ciascuno ad alto contrasto, leggibile e libero da etichette e valori.
• Legenda esterna: Ogni marcatore ha una voce corrispondente in elenco ordinato nel testo della pagina; nessun testo di legenda è incorporato nei pixel.
• Didascalia: La figura ha una didascalia visibile concisa che nomina schermo, stato e scenario.
• Testo alternativo: Il alt.yaml della cartella contiene una chiave nome file esatta e una descrizione contestuale entro la fascia di lunghezza target.
• Comportamento mobile: Bersaglio e marcatori rimangono leggibili senza scorrimento orizzontale a livello di pagina o zoom richiesto; altrimenti esiste un ritaglio mirato.
• Contratto file: Percorso, nome in kebab-case minuscolo, formato, dimensioni e dimensione intrinseca seguono lo standard di distribuzione.
• Aggiornamento: screenId e data di acquisizione sono registrati, la UI live corrisponde ancora e tutti i riferimenti sono trovabili tramite ricerca testuale.
• Parità portatile: Le rappresentazioni Markdown, Hugo e WordPress preservano lo stesso asset, didascalia, ordine dei marcatori e formulazione della legenda.
• Nessun asset rotto: Un percorso immagine reale appare solo dopo che il file esiste; le acquisizioni in sospeso rimangono commenti e mantengono screenshotsPending = true.

FAQ

Il template academy renderizza le cinque domande revisionate memorizzate nel frontmatter [[faq]] di questa pagina. Coprono frequenza degli screenshot, legende esterne, lunghezza del testo alternativo, trigger di riacquisizione e l’eccezione della chrome del browser.