Sjablonenbouwer

Feature passport regarding a template builder with regard to linked decisions and regulations for governments

Conclusion

• De sjablonenbouwer heeft als doel om sjablonen te voorzien ihkv zittingen, besluiten en reglementen, en in de eerste plaats deze ter beschikking te stellen aan gebruikers van gelinkt notuleren applicaties (onafhankelijk welke leverancier).

• Een sjabloon bestaat uit een structuur van relevante blokken voorgedefinieerde en te definieren variabelen en tekstfragmenten. Het beheer van de variabelen en tekstfragmenten is ook een onderdeel van de sjablonenbouwer.

• Er dient een toegangspagina voorzien te worden ter beheer van sjablonen en parameters etc.

• Er dient een mogelijkheid te zijn om sjablonen / parameters te linken aan een thema (bijv. bevolking, cultuur,...). Een lijst van thema's waar we mee van start kunnen gaan, is gedefinieerd in loket (bbc)....

• Sjablonen hebben een eigenaar, en gebruikers die het sjabloon ter beschikking stellen via hun gelinkt notuleren applicatie. Analoog met template / instantie bij IPDC/LPDC.

• Lokale besturen hebben eigen en "gelokaliseerde" sjablonen die zij wensen te beheren en beschikbaar hebben afhankelijk van de gebruiker van de notuleringssoftware. Op termijn spreken we over een lokale en Vlaamse sjablonenbouwer. In de lokale kunnen gelokaliseerde sjablonen gebouwd worden "from scratch" of op basis van een bestaand (vlaams of buurgemeente) sjabloon.

• sjablonenbouwer wordt in fase 1 gebruikt door ABB, in een tweede fase zal deze uitgerold worden naar verschillende type content-bouwers. Te bekijken of lokale templates worden gemaakt en beheerd in de sjablonenbouwer, of eerder een visualisatie krijgen in de sjablonenbouwer.

• Rollen en Rechten worden gedefinieerd via ACM/IDM (rechtenbeheer)

Introduction

De sjablonenbouwer heeft tot doel een individu een template te laten samenstellen o.b.v. parameters, tekstblokken, keuzelijsten etc. zodat deze nadien kan gebruikt worden in notuleringssoftware door een (lokaal) bestuur voor een zitting, besluit of reglement ter agendering bij een orgaan.

De sjablonenbouwer laat ook toe de bouwblokken, zijnde de betreffende parameters, tekstblokken en keuzelijsten te beheren en aan te maken.

Verschillende gebruikers met verschillende rechten of toegang tot eigen en gedeelde content zullen gebruik maken van de sjablonenbouwer. Er bestaat ook een soort superuser (ABB-Digiteam).

Register	RDFA-editor & plugins	Gelinkt Notuleren	Pre-publish environment	publish environment
Impact	possible impact	possible impact	no impact	no impact

Status

link to JIRA-epic or story with the status https://binnenland.atlassian.net/browse/GN-3857

Context

Current state

Er zijn 2 à 3 soorten sjablonen:

• Besluitsjablonen (hardcoded GN)

• Reglementsjablonen (register van reglementen)

• in de toekomst zal ook een extra sjabloon van een zitting een vereiste zijn, vandaag bestaat er 1 structuur voor een zitting.

• Een sjabloon wordt gekenmerkt door:

  • tekst / html

  • applicatieprofiel van het betreffende sjabloon

  • “parameters” (rdf)

Naar technische functionaliteiten is er geen groots verschil tussen een besluitensjabloon en reglementensjabloon. Het markantste is dat bij een besluit een reglement kan toegevoegd worden, en niet omgekeerd. Voor de rest zijn dezelfde opmaak en structuur elementen toegankelijk bij de opmaak van beide type sjablonen. Het feit dat bepaalde elementen niet zullen gebruikt worden binnen bijv. een reglement (bijv. motivering), is in de eerste fase ondergeschikt aan de geboden flexibiliteit.

Een zittingsjabloon heeft een specifieke standaardstructuur. Het sjabloon voegt een orgaan, agendapunten en besluiten/kennisnames toe aan de basis. Een zitting opmaken o.b.v. een zittingssjabloon kan vandaag nog niet.

Documentation

User & data research

De definiëring van de sjablonenbouwer gebeurt op basis van verschillende gesprekken rond sjablonen en het gebruik en toepassing ervan die werden gevoerd in de periode nov/2022 - juni/2023. Insights

- Problems to solve for:

voorzien van meer templates die bruikbaar zijn bij besturen

integratie met bestaande paketten van leveranciers

betekenis geven aan tekst(onderdelen) ter verrijking van latere harvesting en rapporteringsdashboards.

- Requirements

Te halen uit uitgewerkte use cases, aandachtspunten:

Requirements m.b.t. het niveau template

• Er zijn 3 type templates: zitting, besluit en reglementen

• Templates worden geordend o.b.v. volgende "metadata" : thema, bestuur, gebruikte parameters, favorieten van een gebruiker of rol

  • thema's werden reeds gedefinieerd ihkv loket? op? en behelsen volgende:

    • Bouwen en Wonen

    • Burger en Overheid

    • Cultuur, Sport en Vrije Tijd

    • Economie en Werk

    • Milieu en Energie

    • Mobiliteit en Openbare Werken

    • Onderwijs en Wetenschap

    • Welzijn en Gezondheid

    extra tags: Naast het inhoudelijke-thema, wensen we ook belasting en retributie toe te voegen als extra onderscheidende elementen.

• templates hebben een titel of naam, en eigenaar

• variabelen kunnen opgemaakt worden en gealloceerd aan minstens een thema.

  • voorbeeld (gebaseerd op datamodel fiscale reglementen): belastingsvoet - thema Mobiliteit en Openbare werken - belasting - naam belasting - alternatieve naam belasting - (niet)forfaitair - euro/percentage

• Het zoeken of selecteren van een variabele zorgt ervoor dat bestaande variabelen optimaal herbruikt worden binnen de verschillende besturen, in de verschillende templates.

• vanuit een template kunnen variabelen gekozen worden of aangemaakt.

• Er kan gebruikt gemaakt worden van historisch aangemaakte / gebruikte variabelen. Bijv. variabele getal, retributiebedrag met min. 5 en max. 10 dient in de historiek te zitten.

• Het overzicht van variabelen (waaronder fragmenten en codelijsten) is toegankelijk o.b.v. logische elementen, bijv. naam, thema, bestuur, reeds gebruikt in templates (a, b)

• Future Feature: Van een bestaand document een template kunnen maken: nieuwe functie binnen GN “document acties” - bewaar als sjabloon linked to entity (e.g. VO/Lokaal Bestuur) and theme (thema)

• Een zittingssjabloon is in eerste instantie een zitting met ingevulde agenda / toegewezen besluitsjablonen die kan geselecteerd worden om een zitting op te maken. (initieel zal dit beperkt zijn tot volgende 2 : zitting aanmaken (gemeenteraad, college, ...) vs. zitting aanmaken ifv installatievergadering.

Requirements m.b.t. parameters / variabelen:

• We willen een parameter aanmaken centraal in het register ter gebruik in een template of ander document

• Parameters moeten – onafhankelijk waar men staat, of wat men eerder deed, ingevoerd kunnen worden. Bijv. Meerdere locaties in 1 artikel, in een tabel (per cel 1 parameter is ok).

• Parameters voegen kennis toe aan de tekst. Zij kunnen later gebruikt worden om business intelligence en/of bepaalde besluiten / detailinformatie te rapporteren/analyseren.

• parameters zijn ingedeeld o.b.v.

  o Generiek (VO) (fase 1)

  o Lokaal bestuur / toepassingsgebied

  o Interbestuurlijk

  o mogelijkheid toe te voegen tot favoriet van een persoon / bestuur / rol o.b.v dienst

• Parameters moeten vindbaar zijn. Een heuse zoek (ipv filter) is noodzakelijk.

  o automatische aanvullen (auto-suggestie)

  o synoniemen

  o informatie over kenmerken van de parameter (facets?)

  • type data (tekst, variabele, datum,...)

  • bestuur obv acm/idm inlog?

  • toepassing variabele / context

  • bedrag

  • keuze bedragen

  • thema’s

  • standaard naam (incl. overzicht bepaalde kenmerken) vs. eigen naam

    - Hoe zoeken ter rapportering?

    bijv. kinderopvangtarief voor ... (rdfa/triple/ai/hoe relevante URI's? capteren...) - obv datamodel? (toevoegen naam en alternatieve naam)

• Welke parameters hebben we alvast nodig?

  • Locatie – in te vullen via meerkeuzelijst op basis van koppeling met bijv. addressenregister. In een latere fase o.b.v. ontwikkeling GZG Slimme Raadpleegomgeving (obv polygoon of set van straten / wijk).

  • Datum

    o datum dd/mm/jjjj

    o formaat op basis van huisstijl aanpasbaar

    o type, bijv. startdatum, einddatum, … (datamodel van mogelijke data nodig?)

    o ? eventueel te koppelen aan bijv. besluit / reglement

  • Algemene parameter waar men een naam, type en waarde kan aangeven. Deze parameter kan gekoppeld worden aan specifieke data (bijv. leeftijd, inkomen, doelgroep, constraints,…) In praktijk kan o.b.v. deze parameter verschillende parameters worden opgemaakt door VO of lokaal bestuur.

    • Voorbeeld:

      o <naam> <variabele> <waarde> <linked1><Linked2> “<doelgroep> <constraints>”

      o Bijv. <aanslagvoet> <%> <besluittype><onderwerp=grafconcessie> <inwoners> leeftijd >18j> <inkomen>

      o De waarde kan komen uit een externe databron (bijv. lijst kinderopvangen) een een aan te maken databron (eenvoudige opsomming, cijfers van 0 tot 100, …)

  • Toelichtingsbepaling: type paragraaf, in basis altijd leeg, geen apart beheer nodig (enkel binnen template-opbouw in te vullen) - verschillende alinea’s tekst die niet meegaan naar het besluit. Een soort opmerkingenveld ter begeleiding bij het invullen van een template. Heden in word wordt er gekleurde italic tekst gebruikt die de gebruiker van het sjabloon zelf moet verwijderen.

    o <toelichtingsbepaling> <linked art. > <reglement / besluit>

    - Keuzevrijheid Voorbeeldbepaling / variaties: tekstalinea’s met eventueel andere parameters (bijv. datum, citaat,..), waaruit men kan kiezen

Value streams

🕵️‍♂️ Use Cases

Personas involved

a. Victor

b. Lieven (admin) - Hij / Lokale besturen (gemeenten) wensen…

c. Valerie (ABB-medewerker): initieel beheerder van de sjablonenbouwer (i.e. PO/PM) - superuser.

Usecases

Volgende flow :

Het gebruik van parameters binnen een document – men start met een “sjabloon” (i.e. een document type reglement of besluit) (dit kan binnen een sjabloon document of een niet sjabloon document binnen bijv. GN)

Dit heeft daarnaast minstens een titel, sjabloon-omschrijving en een URI (belang van visualisatie van linked data elementen - cfr. rechternavigatie als reeds uitgewerkt voor Embeddable.).

methode 1/ (niet-prioritair - fase 2)

vanuit word / bestaande tekst

copy/paste van tekst en structuur

aanpassen van structuur (opwaarderen)

toevoegen en aanduiden van parameters

• bestaande (steeds hiervan vertrekken)

• nieuwe

methode 2/ - prioritair

tekst ingeven en structuur aanbrengen

toevoegen van parameters

• zoek - suggestie

• Facets ter filtering resultaten o.b.v. kenmerken (bijv. bestuur, sleutelwoorden, ...)

• uri / triple

behoefte: testen van aangemaakt sjabloon / parameterveld

- via qa omgeving

- via "test sjablonen" mogelijkheid. invullen, / publiceren (in lijn met huisstijl)

Wat wil ik als gebruiker? - Use cases

Ik ben Victor, en ik wens:

• Ik wil het verschil zien tussen sjablonen (besluitsjablonen, reglementsjablonen, zittingssjabloon) en een onderdeel omtrent "parameters" (codelijsten, fragmentlijsten, variabelen (cijfer, datum, locatie, tekst,…)

• Ik kan minstens filteren op onderwerp/thema en gemeentes, voor sjablonen.

• Ik kan variabelen gebruiken binnen een ander thema / gemeente en worden gelinkt aan het sjabloon waaraan ze worden gelinkt.

• Ik krijg een korte opsomming van sjablonen (bijv. laatst geopende door de gebruiker of favorieten, of door mij gemaakt) om vlot naar de voor mij relevante sjablonen te gaan.

• Ik maak sjablonen en wijzig sjablonen. Ik heb een helder overzicht welke ter beschikking staan van "gelinkt notuleren" of actief gebruikt worden door welke specifieke gemeente.

• Ik kan vlot een variabele toewijzen aan een sjabloon, en omgekeerd binnen een sjabloon een specifieke variabele gebruiken. Zo kan ik o.m.

  • mogelijkheid om variabelen te hergebruiken die eerder werden aangemaakt

  • nieuwe variabelen en codelijsten aanmaken, die dan in het overzicht komen (en o.b.v. gebruik/aanmaak aan een gemeente worden gekoppeld. het thema is eventueel zelf te selecteren. (meerdere thema’s zijn mogelijk)

  • bedenken hoe bijv. fragmentlijsten goed kunnen voorgetoond worden (met hover?) en geselecteerd.

  • vandaag is het niet mogelijk om het sjabloon in werkbare vorm te zien binnen de sjablonenbouwer. Je kan dit wel een een testomgeving van gelinkt notuleren (notuleringssoftware). Voorlopig is dit ok, maar dit wil zeggen dat je een sjabloon eerst in test maakt, en dan naar productie brengt. Vraag is hoe dat in zijn werk kan gaan, zonder het werk opnieuw te moeten uitvoeren. Een oplossing is zeker een preview van het sjabloon, die ik binnen het register kan zien en uitproberen (vnl. naar lay-out en invullen van de variabelen.)

Ik ben Lieven, en ik wens:

• beschikbare sjablonen binnen de sjablonenbouwer te consulteren, en beschikbaar te maken voor mijn lokaal bestuur. Een sjabloon beschikbaar maken betekent dat het via het endpoint of mijn notuleringstoepassing beschikbaar is voor Saskia of Larissa. Iedere gemeente kan dit dus apart doen.

• nieuwe sjablonen aan te maken voor mijn lokaal bestuur en deze nadien ter beschikking te stellen.

• Een onderscheid te maken tussen mijn reeds bestaande sjablonen binnen mijn applicatie, en de nieuwe door Vlaanderen aangeleverd. (obv LDES notificatie?)

Ik ben Larissa, en ik wens:

• niet direct in de sjablonenbouwer te werken, ik werk met mijn notuleringssoftware en daar selecteer ik sjablonen waar ik verder op kan werken.

• Ik wens wel gebruik te maken van bestaande variabelen, en deze te gebruiken in mijn notuleringssoftware en besluiten/agendapunten/...

Ik ben Valerie, en ik wens:

• alles wat Victor kan, voor de eenvoud initieel toegespitst op mij als enige gebruiker (indien dit eenvoudiger zou zijn). Mijn rol is superadmin.

• alles wat Lieven kan, voor de eenvoud initieel toegespitst op mij als enige gebruiker (indien dit eenvoudiger zou zijn). Mijn rol is superadmin.

Scope + future iterations

In scope

- s)

Out of scope

- .

Future versions

🗜 Constraints

· Strategic/business constraints

· .

• Legal constraints

• .”­

· Technical constraints

·

🤔 Questions/Discussion points

This section is to capture any open questions when writing the FP. All answers should be documented in other sections of the FP.

.

Kick-off

Once the team has agreed on the scope (usecases + problems to solve) we can start designing / building.

After the writer is done with this, there needs to be a Kick-off meeting where the writer talks through the expectations with the technical and design team. The team can then decide which problems are feasible to solve for this feature.

This means that if, for example, the technical team thinks that one of the problems will take a lot longer than the analyst anticipated, the PO can still decide to work on that problem as part of another feature passport (* this then needs to be amended in the Problems section and a new feature passport can be created.)

Once the team has agreed on the scope (usecases + problems to solve) we can start designing / building.

· Toegang tot register en borden via register en borden. Toegang via gebruikersbeheer? Is er een rol die we daartoe kunnen gebruiken? initieel niet.

Product solution

Design

...

Mock-ups

· link to figma mockups

Eerste draft Mockups - te bespreken

landingspagina / homepage

Any explanation or extra documentation

Usercases / userflows

After the designer finish their task, a technical feasibility meeting follows where the solutions are presented. The team exchanges feedback and amends the feature passport where necessary.

Technical

This part of the feature passport is owned by the technical team

[Information about the technical solutions for expectations that need it - e.g. using mu-search for showing all types of positions in one table.]