Scope-systeem

Het scopesysteem bepaalt waar herbruikbare FaceFlow-secties zichtbaar zijn en worden gedeeld.

Voor technische gebruikers is scope een van de kernregels in de architectuur van FaceFlow. Het bepaalt of een herbruikbare sectie zich gedraagt als een site-breed asset, een pagina-familie-asset of een lokaal enkel-pagina-asset.

Drie scope-niveaus

• Site: gedeeld over de hele site
• Lay-out: gedeeld over Pagina's die dezelfde Lay-out gebruiken
• Pagina: lokaal voor één Pagina

Technisch mentaal model

Beschouw scope als een zichtbaarheid- en wijzigingsimpactcontract dat aan een instantie van een herbruikbare sectie is gekoppeld.

Conceptueel:

{
  "component": "announcement-strip",
  "scope": "site"
}

Het belangrijke veld is niet de exacte opslagvorm. De belangrijke regel is dat scope bepaalt hoe breed die instantie hergebruikt moet worden en hoe ver een latere wijziging zal doorwerken.

Waarom scope ertoe doet

Scope voorkomt dat hergebruik verandert in chaos.

Zonder scalpregels dupliceren teams ofwel:

• hetzelfde blok overal dupliceren
• één blok te veel delen dat lokaal had moeten blijven
• het overzicht verliezen welke wijzigingen welke Pagina's beïnvloeden

Scope maakt die grenzen expliciet.

Mentaal model

Site scope
  -> beïnvloedt alle relevante Pagina's op de site

Lay-out scope
  -> beïnvloedt Pagina's die één Lay-out delen

Pagina scope
  -> beïnvloedt slechts één Pagina

Dit is geen voorkeur voor inhoud. Het is een regel voor wijzigingsimpact.

Voorbeeld mapping van instanties

Een vereenvoudigde Pagina-assemblage zou er zo uit kunnen zien:

Layout: docs-shell

Site scope:
  announcement-strip

Layout scope:
  docs-sidebar
  docs-subnav

Page scope:
  release-notes-cta
  migration-faq

Dat ene diagram verklaart twee belangrijke technische feiten:

• niet elke herbruikbare sectie wordt gelijkelijk gedeeld
• de beoordeling van wijzigingen moet rekening houden met scope voordat de wijziging wordt goedgekeurd

Scope-voorbeelden

Site-scope

Gebruik wanneer een sectie zich moet gedragen als een site-breed asset.

Voorbeelden:

• globale aankondigingsbalk
• gedeelde navigatieondersteuningsstrip
• vertrouwensbanner die op de hele site wordt gebruikt

Lay-out-scope

Gebruik wanneer een sectie bij een pagina-familie hoort.

Voorbeelden:

• docs-sidebar die alleen op documentatiepagina's wordt gebruikt
• gedeelde subnavigatie voor één servicedeel
• sectie-brede ondersteuningsrail voor één lay-outfamilie

Pagina-scope

Gebruik wanneer de sectie uniek is voor één Pagina.

Voorbeelden:

• een eenmalige campagne-hero
• een lokale CTA-strip
• pagina-specifieke FAQ of bewijsblok

Voorbeeld wijzigingsbereik

Hetzelfde sectietype kan op verschillende scopes geldig zijn, afhankelijk van de intentie:

announcement-strip at Site scope
  -> change affects all relevant Pages

announcement-strip at Layout scope
  -> change affects one page family

announcement-strip at Page scope
  -> change affects only one Page

Daarom moet scope worden gekozen op basis van de beoogde blast radius, niet op basis van het gemak voor de redacteur.

Beslisregel

Stel één vraag:

If I change this section, which Pages should change with it?

Als het antwoord is:

• "alle relevante Pagina's" -> Site
• "Pagina's in deze ene familie" -> Lay-out
• "alleen deze ene Pagina" -> Pagina

Voorbeeldsamenstelling

Site scope:
  global-announcement

Layout scope:
  docs-sidebar

Page scope:
  pricing-faq

Dat model houdt hergebruik doelbewust en maakt wijzigingsimpact voorspelbaar.

Architectuurrichtlijnen

Gebruik scope om deze technische vragen te beantwoorden:

• waar moet deze instantie vindbaar zijn?
• hoeveel Pagina's zouden toekomstige bewerkingen erven?
• wie zou eigenaar moeten zijn van de wijziging?
• welk niveau van beoordeling is gerechtvaardigd voordat gepubliceerd wordt?

In de praktijk:

• Site-scope heeft meestal de strengste beoordeling nodig omdat de impact groot is
• Lay-out-scope heeft bewustzijn van de pagina-familie nodig
• Pagina-scope is de veiligste plek voor lokale experimenten

Technische impact

Scope beïnvloedt:

• waar een herbruikbare sectie beschikbaar is
• hoeveel Pagina's een wijziging kan beïnvloeden
• hoe teams eigenaarschap redeneren
• hoe gedeelde structuur in de loop van de tijd wordt onderhouden

Daarom moeten scopbeslissingen als architectuurbeslissingen worden behandeld, niet als gemakskeuzes voor redacteuren.

Beoordelingspatroon

Wanneer een team voorstelt om scope te verruimen, beoordeel het dan als een architectuurwijziging:

page -> layout
  question: is this section now shared by a durable page family?

layout -> site
  question: does this section now belong to the broader site, not one section?

Als het antwoord "niet echt" is, wordt de scope waarschijnlijk te vroeg verruimd.

Technische beoordelingschecklist

• komt de gekozen scope overeen met het beoogde wijzigingsbereik?
• is de sectie werkelijk herbruikbaar op dat niveau?
• zou een toekomstige redacteur begrijpen waarom de sectie gedeeld is?
• bevat de sectie inhoud die lokaal had moeten blijven?
• wordt een verondersteld lokale sectie op veel Pagina's gekopieerd?

Anti-patronen

Vermijd:

• site-scope voor inhoud die slechts één pagina-familie nodig heeft
• pagina-scope voor inhoud die in veel Pagina's wordt gekopieerd
• lay-out-scope voor inhoud die bij de globale siteshell hoort
• scope verruimen alleen om kortetermijninspanning te besparen

Voorbeeldregel in de praktijk

Main navigation utility bar -> Site scope
Developer docs sidebar -> Layout scope
Landing page final CTA -> Page scope

Gerelateerde ontwerpregel

Scope moet samen met objectverantwoordelijkheid worden beoordeeld:

• als de wijziging de shell aantast, bekijk de Lay-out
• als de wijziging één herbruikbaar sectiecontract aantast, bekijk de Component
• als de wijziging slechts één geassembleerde ervaring aantast, bekijk de Pagina

Gerelateerd

• Componenten
• Lay-outs
• Pagina's