Přepínač karet / person: Formát, pravidla a příklady

Přepínač karet/person poskytuje několika čtenářům odlišné cesty jedním ohraničeným tématem, aniž by je posílal na samostatné stránky. Popisky identifikují cestu; výběrem jedné se odhalí její panel na stejném místě. Prvek je užitečný pouze tehdy, jsou-li panely skutečnými partnery a každý panel zůstává přítomen v počátečním HTML stránky.

Vykreslený stav ukazuje jeden aktivní panel, ale další dva panely jsou také přítomny v objektovém modelu dokumentu (DOM) — strukturované reprezentaci stránky v prohlížeči. Jsou skryty pomocí nativního atributu hidden, nikoli načteny až po kliknutí. Produkční renderovací nástroj přidává klávesové a ukazatelové chování popsané níže; smluvní vztah autorského obsahu zůstává stejný napříč platformami.

Proč na tomto prvku záleží

Čtenáři filtrují stránku podle své role, cíle a úrovně odpovědnosti. Specialista na obsah může chtít pokyny pro psaní, SEO specialista validační pravidla a vedoucí týmu řízení. Dobře označený přepínač person snižuje úsilí potřebné k převedení obecných rad na „co to znamená pro mě?" Zároveň udržuje společný základ na jednom místě, čímž se vyhne třem téměř duplicitním stránkám soutěžícím o stejný záměr.

Psychologickou výhodou je rozpoznávání namísto interpretace. Čtenář rozpozná popisek jako „SEO týmy" rychleji, než by skenoval tři odstavce, aby odvodil, který z nich se ho týká. Karty také zachovávají prostorový kontext: panel se mění na místě, takže čtenář může porovnat partnerské cesty, aniž by musel opakovaně projíždět společný úvod.

Toto pohodlí však vytváří kompromis v oblasti strojové extrahovatelnosti. Strojová extrahovatelnost je schopnost crawleru, vyhledávacího indexu, asistenční technologie nebo vyhledávacího systému izolovat obsah při zachování jeho předmětu a vztahů. Viditelné nadpisy a odstavce se objevují ve zřejmé posloupnosti čtení. Karty zavádějí stav interakce: jeden je viditelný, několik nikoli, a software musí propojit každý popisek karty se správným panelem. Slabá implementace ponechá v HTML pouze aktivní panel, načítá další panely až po kliknutí nebo opakuje obecné nadpisy jako „Výhody" bez názvu persony. V každém případě stroj obdrží méně kontextu, než vidí čtenář.

Dokonce i správná implementace může snížit extrahovatelnost ve srovnání s běžnými sekcemi. Některé systémy upřednostňují počáteční viditelný text, zplošťují interaktivní vztahy nebo vynechávají skrytý obsah z úryvků. Karty jsou proto nástrojem pro směrování informací, nikoli způsobem, jak skrýt zásadní odpovědi. Umístěte sdílenou odpověď, definici, varování, podmínku způsobilosti a závěr mimo sadu karet. Panely používejte pro konkrétní aplikace, příklady, pracovní postupy nebo důkazy přizpůsobené publiku, které zůstávají užitečné poté, co je známa společná odpověď.

Použijte pravidla pro psaní prvků : nejprve napište celé vysvětlení, poté klasifikujte skutečnou sadu partnerských čtenářských cest jako tento typový prvek. Pravidla na této stránce mají přednost při mapování panelů, interakci a omezeních obsahu.

Kdy jej použít

Použijte přepínač karet/person, pokud platí všechny tyto podmínky:

1. Dvě až pět rozpoznatelných publik, kontextů nebo režimů potřebuje různé aplikace stejného tématu.
2. Každý panel odpovídá na stejnou otázku ve srovnatelné hloubce.
3. Většina čtenářů potřebuje vždy jeden panel, zatímco menšina může porovnávat dva nebo více.
4. Společnou odpověď lze uvést mimo prvek, aniž by čtenář musel otevřít každou kartu.
5. Udržení cest na jedné stránce je přehlednější než vytváření samostatných stránek s převážně duplicitními úvody.

Silné případy použití zahrnují implementační pokyny pro „Vývojáře / Editory / Recenzenty", cesty pro začlenění pro „Sólo / Tým / Agentura" a jednu schopnost vysvětlenou skrze „Plánuj / Produkuj / Měř". Popisky person by měly odrážet smysluplné rozdíly v pracovních postupech, důkazech, oprávněních nebo požadovaných výsledcích — nikoli demografické odhady.

Téměř správné případy často vznikají snahou zkrátit stránku. Neumisťujte sekvenční kroky do karet; skrytí kroku dva, dokud si jej čtenář nevybere, ničí pořadí postupu. Nekartujte krátký seznam definic, protože běžné nadpisy zpřístupní stejné informace s menší interakcí. Nepoužívejte karty pro podrobné srovnání funkcí: srovnávací tabulka udržuje kritéria současně viditelná. Nepoužívejte karty jako navigaci mezi nesouvisejícími tématy a nerozdělujte informace jen proto, že stránka působí dlouze.

Akordeon je vhodnější, pokud jsou sekce nezávislé otázky ve vertikálním toku čtení nebo pokud by mělo zůstat otevřených několik odpovědí. Samostatné stránky jsou lepší, pokud každé publikum potřebuje odlišný vyhledávací záměr, titulek, sadu důkazů, konverzní cestu nebo více než zhruba 300 slov unikátního obsahu. Pokud čtenář potřebuje všechny panely k bezpečnému nebo správnému jednání, jsou karty nevhodnou komponentou.

Kam jej umístit

Umístěte přepínač za sdílenou odpověď a odstavec, který vysvětluje, proč se cesty liší. Čtenář by měl rozumět společnému tématu před výběrem popisku. Na stránce produktu nebo řešení to obvykle znamená za hlavní hodnotovou nabídku a vysvětlení sdílené schopnosti, ale před podrobné důkazy a primární závěrečnou akci. V dokumentaci jej umístěte bezprostředně před instrukce specifické pro roli, které řídí.

Neumisťujte sadu karet před přímou odpověď stránky, definici nebo povinné varování. Neumisťujte ji mezi tvrzení a jeho zdroj, mezi předpoklad a postup, který jej řídí, ani mezi cenu a její kvalifikace. Tyto vztahy musí přežít i tehdy, když není vybrán žádný panel. Sada karet nesmí sousedit s jinou sadou karet, akordeonem, velkou srovnávací mřížkou nebo karuselem; sousedící modely interakce vytvářejí konkurenční ovládací prvky a nejasné pořadí čtení.

Vyhněte se vnořeným kartám. Vnější výběr skrývá vnitřní výběr, vytváří obtížné chování klávesnice a činí hloubkové propojení nejednoznačným. Také se vyhněte umístění přepínače person bezprostředně nad jiný volič publika ve formuláři nebo CTA. Pokud oba ovládací prvky používají podobné popisky, čtenáři nemusí vědět, zda mění viditelný obsah nebo odesílají preferenci.

Anatomie

Anatomie obsahuje jeden označený kontejner, jeden uspořádaný seznam karet a jeden panel pro každou kartu. Snímek obrazovky musí ukazovat neaktivní panely v inspektoru DOM i viditelný stav, protože přítomnost ve zdroji je součástí prvku, nikoli detail implementace.

1. Sdílený titulek: Uvádí společnou otázku nebo úkol, kterým se každý panel zabývá.
2. Seznam karet: Seskupuje dva až pět partnerských popisků ve stabilním autorském pořadí.
3. Popisek karty: Pojmenovává publikum, kontext nebo režim jazykem, který čtenáři rozpoznají.
4. Vybraný stav: Komunikuje aktivní kartu prostřednictvím textové sémantiky a viditelné úpravy, nikoli pouze barvou.
5. Panel: Obsahuje samostatný nadpis a obsah pro jeden popisek.
6. Programový vztah: aria-controls na kartě a aria-labelledby na panelu propojují každý pár.
7. Náhradní pořadí: Udržuje sdílený titulek, popisky a veškerý obsah panelů smysluplné, pokud se nespustí skripty nebo styly.

Mezery, okraje, tvar indikátoru, animace a zlomový bod náleží rendereru. Autoři řídí popisky, pořadí ve zdroji, obsah panelů a volitelný stabilní identifikátor fragmentu.

Příklady designu

Komponenta podporuje čtyři varianty. Každá varianta používá stejný model obsahu a požadavek na DOM.

Personové karty: Používejte popisky rolí, pokud se pracovní postupy, důkazy nebo další kroky skutečně liší podle čtenáře. Upřednostňujte zavedený jazyk zákazníků jako „Interní týmy" před vymyšlenými personami jako „Guruové růstu."

Kontextové karty: Používejte stavy mimo persony, jako je velikost týmu, provozní model nebo režim implementace. Sdílený titulek musí pojmenovat měnící se dimenzi, aby popisky nebyly zaměněny za navigaci stránky.

Vertikální karty: Používejte pouze tehdy, když popisky potřebují více horizontálního prostoru a není jich více než pět. Pořadí DOM a klávesnice zůstává karta jedna až karta pět, následované jejich přidruženými panely podle zvolené přístupné implementace.

Stav pro úzké obrazovky a náhradní stav: Popisky se mohou posouvat horizontálně, pokud je přetečení zřejmé z viditelného signálu, nebo může renderer zobrazit panely jako naskládané označené sekce. Nesmí zkracovat popisky na nejednoznačné fragmenty ani odstraňovat neaktivní obsah z HTML.

Parametry

Smlouva o obsahu udržuje vztah explicitní, zatímco vizuální a responzivní chování ponechává na rendereru.

Popisky jsou atributy, protože ovládají ovládací prvek; názvy panelů pocházejí z prvního nadpisu, protože náleží obsahu. Oba mohou být podobné, ale stručný popisek karty lze mapovat na plnější, extrahovatelný nadpis panelu. Těla panelů umožňují odstavce, krátký seznam, řádkový kód, jeden obrázek a jednu kontextovou akci. Neumožňují další sadu karet, akordeon, datovou tabulku, formulář, videopřehrávač ani vícestupňový postup.

Syntaxe a příklady kódu

Všechny tři zápisy zachovávají jeden titulek, seřazené popisky, nadpisy panelů, těla panelů, stabilní ID a počáteční výchozí hodnotu. Přenositelná direktiva Markdown je kanonická autorská forma.

Přenositelná direktiva Markdown

:::tabs-persona-switcher{default=content-teams variant=horizontal}
## Vyberte svůj tým

::item{label="Obsahové týmy" id=content-teams}
### Proměňte zadání v opakovatelný návrh

Začněte s požadovanou odpovědí, důkazy a sadou prvků. Napište celé zdůvodnění před použitím komponent.
::

::item{label="SEO týmy" id=seo-teams}
### Ověřte objevitelnost a extrahovatelnost

Prohlédněte si vykreslené HTML, interní odkazy, nadpisy a strukturovaná pole. Potvrďte, že každý panel dorazí v počáteční odpovědi.
::

::item{label="Vedoucí týmů" id=team-leaders}
### Posuďte systém, nejen stránku

Schvalte společný slib jednou, poté zhodnoťte, kde jednotlivá publika skutečně potřebují odlišný pracovní postup, důkazní bod nebo další krok.
:::
:::

Tělo nadřazeného prvku mapuje svůj první nadpis na title. Každá vnořená položka přebírá label a id z atributů, mapuje svůj první nadpis na item.title a zbytek na item.content.

Hugo shortcode

{{< tabs-persona-switcher title="Vyberte svůj tým" default="content-teams" variant="horizontal" >}}
  {{< tab-item label="Obsahové týmy" id="content-teams" title="Proměňte zadání v opakovatelný návrh" >}}
  Začněte s požadovanou odpovědí, důkazy a sadou prvků. Napište celé zdůvodnění před použitím komponent.
  {{< /tab-item >}}
  {{< tab-item label="SEO týmy" id="seo-teams" title="Ověřte objevitelnost a extrahovatelnost" >}}
  Prohlédněte si vykreslené HTML, interní odkazy, nadpisy a strukturovaná pole. Potvrďte, že každý panel dorazí v počáteční odpovědi.
  {{< /tab-item >}}
  {{< tab-item label="Vedoucí týmů" id="team-leaders" title="Posuďte systém, nejen stránku" >}}
  Schvalte společný slib jednou, poté zhodnoťte, kde jednotlivá publika skutečně potřebují odlišný pracovní postup, důkazní bod nebo další krok.
  {{< /tab-item >}}
{{< /tabs-persona-switcher >}}

Adaptér používá pouze pojmenované parametry. Musí vykreslit všechna těla položek během odpovědi serveru, odmítnout duplicitní ID a inicializovat interakci bez přepisování modelu obsahu.

WordPress blok

<!-- wp:amicited/tabs-persona-switcher {"title":"Vyberte svůj tým","default":"content-teams","variant":"horizontal"} -->
  <!-- wp:amicited/tab-item {"label":"Obsahové týmy","id":"content-teams","title":"Proměňte zadání v opakovatelný návrh"} -->
  <p>Začněte s požadovanou odpovědí, důkazy a sadou prvků. Napište celé zdůvodnění před použitím komponent.</p>
  <!-- /wp:amicited/tab-item -->
  <!-- wp:amicited/tab-item {"label":"SEO týmy","id":"seo-teams","title":"Ověřte objevitelnost a extrahovatelnost"} -->
  <p>Prohlédněte si vykreslené HTML, interní odkazy, nadpisy a strukturovaná pole. Potvrďte, že každý panel dorazí v počáteční odpovědi.</p>
  <!-- /wp:amicited/tab-item -->
  <!-- wp:amicited/tab-item {"label":"Vedoucí týmů","id":"team-leaders","title":"Posuďte systém, nejen stránku"} -->
  <p>Schvalte společný slib jednou, poté zhodnoťte, kde jednotlivá publika skutečně potřebují odlišný pracovní postup, důkazní bod nebo další krok.</p>
  <!-- /wp:amicited/tab-item -->
<!-- /wp:amicited/tabs-persona-switcher -->

WordPress by měl omezit vnitřní bloky na registrované položky karet. Náhled, uložené značení a výstup na front-endu musí zachovat každý panel; pohodlí editoru by nemělo měnit neaktivní položky na obsah načítaný klientem.

Příklady

Dobrý příklad

Zvolte cestu implementace

Hostovaná platforma — Spusťte bez údržby infrastruktury

Připojte schválený zdroj dat, nakonfigurujte role a ověřte výstup v pracovním prostoru stagingu. Dodavatel udržuje runtime aktualizace a monitoring; váš tým vlastní schvalování obsahu a kontrolu přístupu.

Vlastní hosting — Řízení nasazení a datových hranic

Nasaďte podporovaný balíček ve svém prostředí, připojte stejný schválený zdroj dat a určete vlastníka pro upgrady, monitoring, zálohy a kontrolu přístupu.

Toto funguje, protože oba panely odpovídají na stejnou implementační otázku, pojmenovávají provozní rozdíl a obsahují srovnatelné odpovědnosti. „Hostovaná platforma" a „Vlastní hosting" jsou rozpoznatelné popisky. Společné rozhodnutí zůstává jasné, pokud jsou oba panely zploštěny do zdrojového pořadí.

Špatný příklad

Prozkoumejte vše

Přehled: Naše platforma činí moderní týmy efektivnějšími.

Ceny: Kontaktujte prodej pro individuální nabídku a důležité smluvní podmínky.

Bezpečnost: Přečtěte si naši bezpečnostní dokumentaci.

Kariéra: Připojte se k našemu rostoucímu týmu.

Toto je navigace stránky maskovaná jako karty. Panely neodpovídají na jednu sdílenou otázku, popisky mísí informace pro kupující s firemním obsahem a důležité cenové podmínky jsou skryty za interakcí. Nahraďte sadu běžnými sekcemi stránky a skutečnou navigací. Pokud cenové možnosti vyžadují simultánní hodnocení, použijte cenovou nebo srovnávací strukturu namísto karet.

Strukturovaná data a přístupnost

Karty a přepínače person nevytvářejí vyhrazený typ Schema.org. Jejich obsah zůstává součástí obklopujícího Article, TechArticle, Product nebo WebPage, pokud tato stránka samostatně splňuje podmínky. Neoznačujte karty jako ItemList jen proto, že se opakují, a negenerujte více entit Person z popisků person. Popisek jako „Agentura" popisuje čtenářskou cestu, nikoli faktické tvrzení o osobě.

Používejte vzor WAI-ARIA karet pouze tehdy, když se rozhraní skutečně chová jako karty. Kontejner má role="tablist"; každý ovládací prvek má role="tab", unikátní ID, aria-controls a přesnou hodnotu aria-selected; každý panel má role="tabpanel" a aria-labelledby. Pro ovládací prvky používejte tlačítka, nikoli odkazy s falešnými cíli. Vybraná karta patří do pořadí tabulátoru stránky; neaktivní karty používají putovní tabindex="-1" a jsou dosažitelné šipkami. Home a End přesunou na první a poslední kartu. Aktivace může následovat fokus pouze při okamžitém přepínání panelů; jinak Enter nebo Space aktivuje zaměřenou kartu.

Fokus musí zůstat předvídatelný. Výběr karty automaticky nepřesune fokus do jejího panelu. Panel může použít tabindex="0", pokud jeho první obsah není jinak dosažitelný, což uživatelům klávesnice umožní do něj vstoupit. Viditelný indikátor fokusu a indikátor výběru se musí lišit a žádný nesmí spoléhat pouze na barvu.

Všechny panely musí být vykresleny v počáteční HTML odpovědi. Skrytí neaktivních panelů pomocí hidden, CSS nebo progresivně vylepšeného ekvivalentu je přijatelné; vytvoření panelů až po kliknutí nikoli. Bez JavaScriptu musí náhradní řešení zobrazit každý označený panel ve zdrojovém pořadí nebo poskytnout skutečné odkazy na serverově vykreslené cíle. Stabilní fragmenty mohou aktivovat panel, ale kanonická stránka zůstává jedna URL. Otestujte zoom, úzké obrazovky, dlouhé přeložené popisky, vztahy čtečky obrazovky, pořadí klávesnice a selhání skriptů.

Pravidla psaní

Začněte sdílenou otázkou. Pokud každý navrhovaný panel odpovídá na jinou otázku, karty nepoužívejte. Napište dvě až pět položek, nejlépe tři nebo čtyři. Udržujte popisky na jednom až čtyřech slovech a pokud možno do 28 znaků. Používejte paralelní gramatiku: všechny role („Editoři / Recenzenti"), všechny režimy („Hostováno / Vlastní hosting") nebo všechny fáze („Plánuj / Produkuj / Měř"). Nemíchejte roli, sloveso a marketingové fráze.

Každému panelu dejte nadpis o 3–10 slovech, který pojmenuje relevantní cestu i její výsledek, pokud samotný popisek karty nestačí. Pište 40–180 slov na panel, s absolutním maximem 300. Panely by měly mít srovnatelnou hloubku, ale nemusí mít stejný počet slov. Používejte přímý jazyk a konkrétní rozdíly v úkolech, důkazech, oprávněních, omezeních nebo akcích. Změna pouze zájmen z „ty" na „váš tým" neospravedlňuje další panel.

Společné informace udržujte mimo prvek. Opakování stejné úvodní věty v každém panelu vytváří nároky na údržbu a způsobuje, že extrahované pasáže vypadají jako duplicitní. Rozdíly umístěte dovnitř panelů a každý rozdíl formulujte dostatečně explicitně, aby přežil extrakci. Preferujte „Agenturní týmy mohou přiřazovat role na úrovni klienta" před „Získáte větší kontrolu", což ztrácí svůj předmět, když je odděleno od vybraného popisku.

Nikdy neumisťujte do sady karet:

• Jedinou definici stránky, přímou odpověď, závěr, bezpečnostní varování, právní kvalifikaci, pravidlo způsobilosti nebo přiřazení zdroje.
• Sekvenční kroky, které musí dokončit každý čtenář, nebo předpoklady, které řídí obsah mimo jeden panel.
• Další sadu karet, akordeon, karusel, komplexní datovou tabulku, formulář s více poli nebo automaticky přehrávaná média.
• Více než jednu primární výzvu k akci na panel nebo akce vedoucí do nesouvisejících fází konverzního trychtýře.
• Obsah načítaný až po interakci, i když je stav načítání pro lidského uživatele rychlý.
• Popisky jako „Jiné", „Více", „Obecné" nebo „Zdroje", které skrývají nedefinovaný vztah.

Pokud každý panel přesahuje 300 slov, potřebuje vlastní sadu důkazů nebo cílí na jiný vyhledávací záměr, publikujte samostatné sekce nebo stránky. Pokud čtenáři potřebují porovnat několik kritérií najednou, použijte tabulku. Pokud je obsah pouze volitelným detailem, použijte prózu nebo akordeon podle vztahu.

Typy příspěvků, které jej používají

Pole postTypes v front matter je zdrojem této tabulky. Uvedení znamená, že formát může podporovat karty; nečiní je povinnými.

Kontrolní seznam QA

• Jedna sdílená otázka: Každý panel odpovídá na stejnou ohraničenou otázku pro jiné publikum, kontext nebo režim.
• Odpovídající počet: Sada obsahuje dvě až pět karet, nejlépe tři až čtyři, se stručnými paralelními popisky.
• Viditelná společná odpověď: Definice, hlavní odpověď, povinná kvalifikace a závěr zůstávají mimo sadu karet.
• Přítomnost v počátečním DOM: Každý panel a jeho kompletní autorský obsah se objevuje v počátečním serverově vykresleném HTML.
• Explicitní kontext: Každý nadpis panelu a úvodní věta zůstávají srozumitelné při extrakci bez vizuálního stavu karty.
• Správné vztahy: ID karet a panelů jsou unikátní; aria-controls a aria-labelledby je správně párují.
• Chování klávesnice: Chování šipek, Home, End, Enter, Space, Tab a Shift+Tab odpovídá zvolenému modelu aktivace.
• Jasnost fokusu: Fokus a výběr jsou viditelně odlišné a výběr neočekávaně nepřesouvá fokus.
• Stabilní náhradní řešení: Selhání skriptů zobrazí označený obsah nebo použitelné serverově vykreslené cíle bez ztráty informací.
• Responzivní chování: Popisky zůstávají úplné a objevitelné při úzkých šířkách, 200% zoomu a s delším přeloženým textem.
• Bezpečné umístění: Komponenta neodděluje tvrzení od důkazu, varování od jeho rozsahu ani předpoklady od instrukcí.
• Žádné komplexní vnoření: Panely obsahují ohraničenou prózu a jednoduchý podpůrný obsah, nikoli další interakční systém.
• Zdrženlivost schémat: Renderer nevytváří seznamové, personové ani publikační schema z prezentačních popisků.
• Parita zápisu: Markdown, Hugo a WordPress zachovávají stejné pořadí, ID, výchozí hodnoty, popisky, nadpisy a těla panelů.

Recenzent by měl komponentu zamítnout, pokud neaktivní obsah vyžaduje síťový požadavek vyvolaný kliknutím, pokud existují zásadní informace pouze v jednom panelu nebo pokud popisky nepopisují partnerské cesty. Jedná se o obsahové a architektonické selhání; vizuální vylepšení je nemůže napravit.

FAQ

Strukturované FAQ položky v front matter se zabývají indexováním, fragmentovými URL, počtem karet, výzvami k akci a rozdílem mezi kartami a akordeonem. Jsou záměrně mimo interaktivní prvek, aby každý čtenář a renderer obdržel stejné implementační pokyny.