Overleg sjabloon:Onderwerp-kader

Wensen doorontwikkeling, voortgekomen uit implementatiefase

• Op een paar pagina's stond een imagemap ipv een reguliere afbeelding op de plek waar nu het navigatiemenu staat. Het zou fijn zijn als die geïntegreerd kan worden in het navigatiemenu (voor zover niet te groot en complex, want dan kun je het beter in de hoofdtekst laten en flink groot tonen). M.M.Vos (overleg) 31 jan 2023 17:18 (CET)
• Het zou slim zijn om de toepassingen van dit sjabloon eens naast elkaar te leggen en te kijken welke oplossingen zoal gehanteerd zijn voor veelvoorkomende issues zoals contactgegevens ipv contact, afbeelding invoegen vanuit de eigenschappen et cetera, en de beste hiervan uit te kiezen en als best practice te documenteren (en evt overal door te voeren). Dit omdat blijkt dat sommige sjablonen wel netjes een contactpersoon et cetera aanpassen en andere niet. En dat sommige sjablonen vooringevulde eigenschappen al niet meer tonen als de variabele leeg is toegevoegd (Afbeelding=, zonder vulling). M.M.Vos (overleg) 31 jan 2023 17:18 (CET)
• Gebruik van hoofdletters en kleine letters bij variabelen is niet helemaal consistent, dit leidt af bij de analyse van bugs (doet-ie het nu niet omdat ik een hoofdletter gebruikte).M.M.Vos (overleg) 31 jan 2023 17:18 (CET)

M.M.Vos (overleg) 15 dec 2022 14:42 (CET) Ik merk dat, doordat gekozen is om geen grootte te bepalen, pagina's met hetzelfde kader maar een verschillende afbeelding (zoals de Kernwaarden van Dienstverlening en de Kwaliteitsdoelen, die elk een .svg pictogram hebben) wat ongelijk ogen als je van pagina naar pagina doorklikt. Op zich geen halszaak, want geen gebruikelijke use case, maar wel opvallend als je de opmaaksjablonen netjes probeert te krijgen.

M.M.Vos (overleg) 29 nov 2022 16:48 (CET) Mooi stukje werk. Ik ben vooral blij met:

1. Het naar rechts verschuiven, waardoor in een snelle test een pagina als Grafisch overzicht relaties Kernwaarden en Kwaliteitsdoelen met Beleidskaders een kader kan hebben zonder dat die het relatieoverzicht omlaag duwt.
2. De mogelijkheid te scrollen binnen een (te) lange inhoudsopgave voor het thema.
3. De keuze om een eigen thema-sjabloon te behouden en die als input te gebruiken voor het algemene onderwerp-kader.

Natuurlijk heb ik nog een paar opmerkingen / wensen n.a.v. de voorbeeld-versie vanuit Gegevensmanagement.

Vragen / opmerkingen

• Heb je de nieuwe positie (ruk naar rechts) en max lengte voor het menu al uitgebreid getest, of moet ik nog even kijken of er pagina's zijn waar dit wellicht iets raars doet voordat we overal een werkversie van maken?
  • fijn als je het test. Vooral op https://noraonline.test.wikixl.nl, omdat daar de nieuwste Vector skin staat.--Joris Dirks (overleg) 6 dec 2022 09:15 (CET)
• Wil je dit kader alleen gebruiken voor onderwerpen, of ook voor de Bindende Architectuurafspraken, Standaarden, Bouwstenen et cetera? In dat geval zou ik graag zien welke onderdelen vast staan en waar je variatie in mogelijk maakt, ook aangezien ik de uiteindelijke layout van de nieuwe bindende architectuurafspraken aan het bepalen ben (er zit nu bijv. nog 'RFC' als afbeelding bij de implicaties en de Architectuurafspraken, dat moet een icoon worden).
  • ik wil hetzelfde absoluut gebruiken voor die dingen. In mijn visie is 'Standaarden' of 'Bouwstenen' een onderwerp net als 'Architectuurafspraken'. Daarbij zou ik echt een veel korter menu gebruiken, zoals: Architectuurafspraken/inhoudsopgave en als je alle principes/beleidskaders/kwaliteitsdoelen etc. per sé op de pagina wil laten zien, die via de sjabloon onder de details van de huidige tonen. Dat maakt het:
    • makkelijker navigeerbaar voor visueel/motorisch beperkten (want niet in het standaard-menu maar in een apart overzicht)
    • makkelijker onderhoudbaar (want automatisch gegenereerd)
    • overzichtelijker, zeker straks in een responsieve site--Joris Dirks (overleg) 6 dec 2022 09:15 (CET)
• Sowieso zou het voorbeeld van gegevensmanagement wat meer documentatie kunnen gebruiken (niet in de code maar in uitleg er boven). Dan weet iedereen of het bijvoorbeeld mogelijk is een extra regel of eigenschap toe te voegen en zo ja waar dan wel en waar niet. Ik deed er nu ook vrij lang over om uit te vinden hoe de inhoudsopgave werkte en weet nu nog niet in hoeverre die nog op te maken is (alleen verder inspringen oogt niet erg overzichtelijk) of wellicht per deelonderwerp aan te passen is (zodat je de extra laag alleen toont van de pagina waar je nu bent en voor de rest niet).
  • Je kunt extra eigenschappen/tekst na de standaard-eigenschappen maken. Ik heb dat nu verduidelijkt. --Joris Dirks (overleg) 6 dec 2022 09:15 (CET)
• Het is voor mij door de combi van sjablonen niet helemaal duidelijk of de weergegeven Status op dit moment die is van de pagina (opgehaalde eigenschap Status actualiteit), van het thema (eenmalig gezet en veranderbaar in sjabloon van het thema) of een tussenvorm hierin, waarin je het bij het aanroepen van het sjabloon in de pagina zet, maar er geen status actualiteit aan gekoppeld is. Ik zie voor en nadelen in alle drie de varianten, ik verwacht dat we nu op variant 3 zitten, maar ik wil het even checken en doorspreken: wat is op termijn de meest wenselijke situatie en sorteren we daar nu op voor of bewust nog niet?
  • de semantische eigenschap ophalen 'kan' niet; een semantische eigenschap die op dezelfde pagina wordt gezet en wordt opgevraagd zorgt voor timing-conflicten (als je hem opslaat, staat die eigenschap nog niet, dus zie je nog de oude eigenschap, tot de pagina vernieuwd wordt). Wat je nu ziet bepaalt de redacteur van het onderwerp. Sjabloon:Onderwerp-kader zet zelf niets, tenzij je iets definieert in die sjabloon. Maar je kan als eindredacteur van een onderwerp bepalen in je sjabloon 'Onderwerp Gegevensmanagement' dat |Status actualiteit=, waardoor alle pagina's in dat onderwerp 'Concept' worden tenzij er iets anders is gedefinieerd. In Sjabloon:Onderwerp Gegevensmanagement blijft 'Status actualiteit' ook leeg, tenzij je iets doorgeeft. --Joris Dirks (overleg) 6 dec 2022 09:15 (CET)
• Is het een bewuste keuze om de afbeelding weer te geven zonder 'thumb' (en als bestand: ipv afbeelding:, hetgeen volgens mij afwijkt van het advies in de help-sectie)? Het ziet er mooier uit, maar aangezien er een link naar een onderwerp aan hangt wordt het zo voor de gebruiker (en de inhoudelijke eigenaar) wel erg moeilijk om naar de afbeelding te gaan voor een vergroting of meer informatie.
  • Ja, ik vind dat kader niet mooi, te veel drukte geven op een pagina (: Dat je de afbeelding niet kan vergroten is wel een beperking hierbij. Ik word niet verdrietig als we daar weer thumb doen, maar zou het bij redesign van de vormgeving graag bij gebruikers toetsen. --Joris Dirks (overleg) 6 dec 2022 09:15 (CET)
• Je kiest er voor om een standaard naamgeving te vermelden voor de afbeelding die gebruikt wordt. Maar de afbeelding wordt handmatig geset in het sjabloon van het onderwerp - dat betekent dat die standaardnaamgeving niet gebruikt gaat worden. In mijn ogen is dat ook praktischer, aangezien een afbeelding wellicht van gebruik kan veranderen: eerst als afbeelding voor het thema, daarna alleen op een sub-pagina gebruikt, of andersom, of zelfs in een ander thema. Een standaardnaamgeving en een sjabloon dat die standaard effectief afdwingt omdat de afbeelding anders niet vertoond wordt, zou in zo'n geval ofwel een duplicaat van de afbeelding betekenen, of de kans dat met het veranderen van de afbeelding voor het thema andere pagina's stuk gaan.
  • Als je niet handmatig in 'Sjabloon:Onderwerp onderwerpnaam' een afbeeldingsnaam gebruikt, zoekt'ie naar een afbeelding 'Afbeelding:Onderwerpnaam-kaderillustratie.png'. Stukje automatie als je het eenvoudig houdt, maar compatibiliteit met andere gevallen. --Joris Dirks (overleg) 6 dec 2022 09:15 (CET)

Wensen

• Ik zou het onderwerp graag gecentreerd zien staan en als onderschrift bij de afbeelding i.p.v. er boven: De afbeelding zou de blikvanger moeten zijn en bij ontwerp van o.a. de pictogrammen van de nieuwe NORA Bindende Architectuurafspraken is dat ook het uitgangspunt geweest. Alle informatie hoort wat mij betreft onder die afbeelding, liefst in de vorm van een 'deze pagina is onderdeel van'. Nu lijkt het woord per ongeluk verdwaald te zijn. Mijn voorkeur zou zijn om alle kopjes te centreren (contact, status, inhoudsopgave), maar wellicht zijn er zwaarwegende redenen om dat niet te doen, zoals dat een tabel die je onder water gebruikt dan niet meer lekker werkt.
  • Links centreren zie ik meer op Rijksoverheid.nl, maar kopjes in Wikipedia's infobox is weer in het midden. Dan heb ik het echt over kopjes-kopjes, want 'contact' etc. zijn nu de labels van een 'description list'. Die zijn standaard links gecentreerd. In Wikipedia's infobox zijn label en waarde niet in description lists, maar in tabellen opgenomen. Ik koos voor description list omdat dat veel eenvoudiger is in code, en je net iets makkelijker dingen kan toevoegen.
  • De naam van het onderwerp bovenaan en daarna de afbeelding heb ik gedaan omdat Wikipedia, Fandom en andere sites met infoboxes of vergelijkbare, ook de kop bovenaan hebben en daarna een illustratie. Maar zonder Nielsen best-practice onder de arm kan ik ook dat alleen maar als voorkeur en gewoonte beargumenteren --Joris Dirks (overleg)
• Je hebt gekozen om de auteurs van gegevensmanagement onder de kop 'contact' te zetten, waarbij ook de contactpersoon niet meer los genoemd wordt maar alleen te herkennen is aan een doorklikbaar mailadres. Het nadeel daarvan wordt direct duidelijk aangezien Jaap van den Berg met pensioen is gegaan: een auteur blijft relevant, maar is wellicht niet meer beschikbaar voor contact. Wat mij betreft krijgt elke pagina een maillink na een kopje 'contact' of 'feedback' (idealiter een keuze die je zet in het sjabloon van het thema), en kun je daaronder nog meer informatie kwijt over de pagina, zoals auteurs, beheerders, inhoudelijke eigenaren et cetera die los van de contactpersoon kunnen veranderen. Die gegevens moet je dan als extra regels in het thema-sjabloon kunnen toevoegen en weer laten geven inclusief 'auteurs' , 'beheerders' of andere kwalificatie die je mee wilt geven. Dat geeft de flexibiliteit die de situatie nu nodig heeft om het snel te doen en dan kunnen we in de aanloop naar de redesign 2023 op basis van de indelingen en termen die we de gebruikers voorleggen kijken wat we moeten standaardiseren en hoe.
  • Wat je beschrijft is een slecht voorbeeld in Gegevensbeheer, omdat ik daar niet eenduidig zag of er één contactpersoon moest zijn. En ik deed iets fout met het mailadres. Wat ik bedoeld had was zoiets als hier: https://noraonline.test4.wikixl.nl/wiki/Voorbeeld-onderwerp. Maar dat geeft nog niet de mogelijkheid om meerdere contactpersonen, of vrije tekst te geven. --Joris Dirks (overleg) 6 dec 2022 09:15 (CET)
• Ik zou de inhoudsopgave het liefste niet voor het hele onderwerp kunnen en moeten maken, maar ook voor deelonderwerpen. Zo kun je voor de wat verder uitgewerkte thema's de navigatie tussen pagina's die bij hetzelfde deelonderwerp horen faciliteren, zonder dat die diepste laag in de weg zit voor andere pagina's en je daar dus ver moet scrollen. Dit gaat binnen verschillende thema's spelen. Het maakt mij niet uit of dat gaat met een hiërarchie van onderwerpen/deelonderwerpen die we ergens vast leggen voor een onderwerp, of met de bestaande categorieën, of nog op een andere manier - ik kan me voorstellen dat de meest logische plek hiervoor het sjabloon voor het thema is en niet de generieke van het onderwerp-kader zelf. Als ik het zelf zou moeten gaan uitzoeken zou ik denk ik een switch inbouwen welke inhoudsopgave getoond wordt, op basis van een woord of categorie die ingevoerd is in het sjabloon van het thema.
  • Ik raad aan om heel spaarzaam te zijn met sub-onderwerpen, om de complexiteit voor de lezer en redacteur te beperken. Zoals hierboven ergens gezegd, zou ik voor 'alles van elementtype x' een lijst onderaan de pagina middels sjabloon van het elementtype gebruiken. Maar als je bij Gegevensmanagement een sub-onderwerp Raamwerk gegevenskwaliteit wil hebben; gewoon Sjabloon:Raamwerk gegevenskwaliteit maken en daar in de inhoudsopgave beginnen met als eerste niveau 'gegevensmanagement' en als tweede niveau 'Raamwerk gegevenskwaliteit'? --Joris Dirks (overleg) 6 dec 2022 09:15 (CET)

Nabranders

• M.M.Vos (overleg) 2 dec 2022 11:10 (CET) Nog een nabrander: ik zie dat je voor een aantal onderwerpen een nieuw sjabloon Onderwerp naaam onderwerp hebt aangemaakt, ik neem aan dat dat alleen voor de test was? Ik ben van plan gewoon het sjabloon van het thema te gebruiken, namelijk sjabloon:Themanaam (en in het geval van Duurzame Toegankelijkheid en AI & Algoritmen zelfs thema-afkorting), zodat het voor iedereen minder in-type-werk is en andere eigenschappen die het thema nodig heeft in hetzelfde sjabloon gezet kunnen worden zonder dat je daar nog extra dingen voor nodig hebt. --Joris Dirks (overleg) 6 dec 2022 09:22 (CET)
  • Goed idee. Nu was het vooral gemakzucht aan mijn kant om zeker te weten dat die naam nog niet gebruikt werd.
• Nog een nabrander: je had het in je mail over inklapbaar/uitschuifbare balk met inhoudsopgave, dat heb ik eigenlijk niet getest: mij viel alleen de doorscroll-optie op.
  • rechtsonder zit (in firefox) een hoekje dat je kan verslepen om de inhoudsopgave kleiner te maken. Groter kan helaas niet in deze opzet, dan zou ik iets fancy's moeten laten maken.--Joris Dirks (overleg) 6 dec 2022 09:22 (CET)

Iedere persoon, organisatie of functionele eenheid die gebruik maakt van een informatiesysteem

Nederlandse Overheid Referentie Architectuur.