Dilemma's redesign 2024

Uit NORA Online
Naar navigatie springen Naar zoeken springen

Een deel van de Verzamelde gebruikersbehoeften zijn 'no regret' verbeteringen: iedereen heeft er baat bij en niemand heeft er last van. Voor een aantal andere behoeften geldt dat ze weliswaar breed gedeeld worden, maar de invoering er van voorzichtig moet gebeuren, bijvoorbeeld omdat:

  • Een korte termijn behoefte van het individu botst met de lange termijn behoefte van de community als geheel
  • De behoefte van de ene gebruikersgroep kan schuren met die van een ander
  • De voorkeuren hoe een behoefte ingevuld kan worden verschillen tussen gebruikers binnen dezelfde gebruikersgroep

We moeten deze dilemma's goed in gedachten houden om te voorkomen dat een verbetering voor de een onverwachts een verslechtering voor de ander betekent. Waar mogelijk zoeken we manieren om alle partijen recht te doen, daar organiseren we bijvoorbeeld brainstorms over per dilemma om creatieve oplossingen te verzinnen. En waar dat niet kan moet het besluit bewust genomen worden wat er op dat moment de voorrang krijgt en waarom.

  1. Eigen korte termijn doel vs breder belang lange termijn
  2. Zelfde onderwerp, verschillend doel
  3. Verschil volwassenheid organisaties en architecten
  4. Eén bron voor iedereen of werken met doelgroepen?
  5. Volledigheid versus eenvoud
  6. Navigeren via menu’s, via links in de tekst of via zoeken
  7. Je wilt de ‘juiste term’ gebruiken maar ook gevonden worden
  8. De eisen van stabiel co-beheer versus dynamische co-creatie

NB: Deze lijst is waarschijnlijk niet uitputtend en je kunt discussiëren over de scheiding en overlap van dilemma's. Het voldoet echter wel als aanzet om een paar eerste brainstorms in te schieten. Houdt verder in gedachten dat dit onze meest actuele gedachten zijn, die we altijd naar wens aan kunnen passen. Hieronder staat een beschrijving van elk dilemma, inclusief welke partijen het betreft en op welke niveaus het schuurt (content, structuur, navigatie, layout, beheer).

Eigen korte termijn doel vs breder belang lange termijn[bewerken]

De gebruiker komt meestal met een gericht doel naar noraonline, om kennis te halen of om specifieke informatie te publiceren. Je bent tevreden als je dat hebt kunnen doen, zonder zaken die je aandacht afleiden of waar je tussendoor moet navigeren. Enkele zaken die genoemd zijn in het gebruikersonderzoek die kunnen afleiden zijn:

  • Nieuwsberichten (met name op inhoudelijke pagina’s, dus gericht nieuws over een onderwerp)
  • Agenda (weer met name op inhoudelijke pagina’s, dus gericht op het onderwerp)
  • Extra navigatiemenu’s

Op de lange termijn heeft de gebruiker wel baat bij een levende community, waarbij mensen met elkaar meedenken, nieuws en vraagstukken delen, feedback geven, deelnemen aan bijeenkomsten. En die community kan alleen levend blijven als telkens een deel van de nieuwe en terugkerende bezoekers geactiveerd worden om in actie te komen en te participeren. De inzichten uit gamification leren dat mensen gemakkelijker acteren op korte termijn motivatie en doelen, dan op lange termijn motivaties. Ook al nemen bezoekers zich voor om regelmatig te zoeken naar nieuws, agenda, feedbackmogelijkheden, reviews et cetera, in de praktijk zul je dit vergeten en pas als je op enige manier getriggerd wordt doorklikken. Dat geldt helemaal voor bezoekers die nog niet weten dat de NORA een community is waar meer te vinden is dan de kennis alleen: je gaat niet op zoek naar dingen waarvan je niet weet dat ze er zijn.

Partijen die dit betreft[bewerken]

Het raakt in feite alle gebruikers, zowel bezoekers als bewerkers. Het belang van de community op lange termijn wordt behartigd door de community managers, die tot nu toe ook de plaatsing van nieuwsblokken, agendablokken, feedbackmogelijkheden, banners met mededelingen et cetera hebben bepaald. Zij kunnen uitleggen wat ze er mee proberen te bereiken, waarna we samen kunnen zoeken naar manieren hoe je dat ‘niet-storend’ aanpakt. Oorspronkelijke doelen vanuit community-managers:

  • Nieuws niet alleen op de voorpagina plaatsen (want daar komt maar 14% van de bezoekers op binnen), maar in de context van pagina’s die er mee te maken hebben
  • Bijeenkomsten over onderwerpen ook aankondigen op de landingspagina van zo’n onderwerp, want daar komt de doelgroep
  • Concreet nieuws plaatsen ipv link naar ‘nieuws,’ omdat architecten het liefst inhoudelijk getriggerd worden (nieuwsgierigheid) en zo snel kunnen beoordelen of het voor hen relevant is
  • Feedback- en contactmogelijkheden op elke inhoudelijke pagina, om de drempel laag te leggen om echt te reageren, maar ook om uit te stralen dat het echte mensen betreft die hier mee bezig zijn en geen bureaucratisch clubje waar je eerst een jurist en een communicatiemedewerker langs moet voor er iets aangepast wordt.

Niveaus waarop het kan schuren of botsen[bewerken]

Het gaat hier niet zozeer om de inhoud van nieuws, bijeenkomsten et cetera, maar vooral om plekken waar deze getoond worden. Het zal dus opgelost moeten worden op de niveaus van structuur (herkennen wat het is en afspreken waar het wel en niet thuis hoort), navigatie en lay-out.

Zelfde onderwerp, verschillend doel[bewerken]

Wie op noraonline een bepaald onderwerp raadpleegt kan dat vanuit verschillende doelen doen, zoals bijvoorbeeld:

  • Oriëntatie (wat is het globaal en moet ik er wat mee?)
  • Verdieping (wat is er al bekend en beschikbaar?)
  • Implementatie (welke afspraken, handreikingen et cetera zijn voor mij relevant?)
  • Hergebruik in eigen documenten of systemen (hoe exporteer ik dit en mag ik het hergebruiken?)

Dat maakt dat het niet gemakkelijk is om een landingspagina te maken voor een bepaald onderwerp: de belangrijkste vraag voor de lezer verschilt en wat de een dolgraag wil weten maakt de pagina voor de ander onoverzichtelijk en druk.

Partijen die het betreft[bewerken]

Alle gebruikers hebben hier mee te maken en in meerdere of mindere mate betreft het alle onderdelen van de wiki. Voor goede oplossingsrichtingen zullen zowel de groep passanten (relatief veel oriëntatie & verdieping) als de ‘usual suspects’ binnen de NORA Familie (toepassing & hergebruik) mee moeten denken. En de uiteindelijke oplossingen moet gedragen kunnen worden door de expertgroepen en andere aanbieders van kennis en door NORA Beheer.

Niveaus waarop het kan schuren of botsen[bewerken]

Een deel van het issue ligt in de content: welke content is relevant voor welke groep of voor welk doel? Maar het gaat ook om structuur (weten pagina’s voor wie ze bedoeld zijn?), om navigatie (kunnen mensen de pagina’s die voor hen bedoeld zijn vinden?) en om lay-out van (landings-)pagina’s (welke vragen beantwoord je eerst, waar en op welke manier?).

Verschil volwassenheid organisaties en architecten[bewerken]

Al jaren leeft er de wens bij een deel van de NORA Familie om meer in Archimate te werken en op noraonline Archimate platen beschikbaar te stellen. Architecten die veel werken met Archimate kunnen hierdoor gemakkelijker hun werk doen en de content hergebruiken in hun eigen systemen. Daar staat tegenover dat we ook al jaren signalen binnenkrijgen van architecten die Archimate nog niet kennen, het niet kunnen gebruiken of het zelfs bewust niet gebruiken. Voor ‘leken’ en architecten die de taal niet machtig zijn kunnen Archimate platen moeilijk leesbaar zijn, of verkeerd geïnterpreteerd worden. Hoewel er een meerderheid in de NORA Familie lijkt te zijn die gebruik van Archimate als best practice ondersteunt, kunnen we niet verwachten dat alle architecten en alle organisaties al zo ver zijn of hier binnen een jaar naar toe werken. In de community van beginnend overheidsarchitecten horen we mensen die er serieus aan beginnen, maar in de eigen organisatie niet de tijd, tooling en oefening kunnen vinden om ‘vloeiend’ te worden in Archimate.

Partijen die het betreft[bewerken]

Om dit goed op te lossen moeten we de wensen van de partijen die vragen om Archimate zien in te willigen op een manier die mensen die (nog) geen archimate kunnen lezen niet in de weg zit. We kunnen hiervoor wellicht mensen uit de groep beginnend overheidsarchitecten benaderen, of binnen ICTU Serina en Mavi.

Niveaus waarop het kan schuren of botsen[bewerken]

Dit dilemma ontstaat als nieuwe content in Archimate vorm wordt aangeboden, hetzij ter vervanging van oude content hetzij als aanvulling hierop. We moeten op het niveau van structuur ruimte inbouwen voor Archimate-content en dit markeren, zodat we er in de navigatie voor kunnen kiezen of we de Archimate-content als eerste landingspagina tonen, of juist een niet-Archimate variant. Dit heeft ook betrekking op de layout van de landingspagina’s van blokjes content: waar krijgt Archimate-content een plekje en hoe herkent de gebruiker het? In content en lay-out vraagt het ook iets van de pagina’s met Archimate-content zelf: hoe geleiden we de bezoeker zonder Archimate kennis door de informatie?

Eén bron voor iedereen of werken met doelgroepen?[bewerken]

De gebruikers van noraonline zijn divers, zowel qua achtergrond in organisatie, domein en expertiseniveau als qua functie, rol en het doel waarvoor ze NORA willen inzetten. Dat maakt het vaak moeilijk om in één tekst of in één landingspagina alles weer te geven wat relevant is voor elke bezoeker en deze niet te verwarren met zaken die (nog) niet relevant lijken. Veel van de wiki’s in de NORA Familie kiezen daarom voor een indeling naar doelgroep, waarbij je via het menu alle teksten voor bijvoorbeeld solution architecten kunt vinden. Teksten worden geschreven naar deze doelgroep toe en anderen die de kennis tot zich willen nemen zullen zich in moeten leven in de context van de groep. Of teksten worden neutraal gehouden en voor verschillende doelgroepen in het menu gehangen. Je ziet hier al snel wrijving tussen enerzijds de wensen om kennis breed beschikbaar te stellen en goed te beheren (alles publiek en transparant, één bron, wijzigingen niet op verschillende plekken aan hoeven brengen) en anderzijds de behoefte aan op maat gesneden teksten, layout en navigatie.

Welke partijen betreft het?[bewerken]

Goed op maat snijden vraagt veel kennis en contact met de doelgroep, wat betekent dat NORA Beheer dit niet alleen kan doen of kan monitoren. Aanbieders van kennis moeten zelf aan kunnen geven voor wie hun kennis relevant is, en/of zoekers van kennis moeten selecteren welk aanbod past bij hun vraag. De Gebruikersraad zou een deel van de knopen door kunnen hakken (welke groepen of welke taken willen we dan onderscheiden en ondersteunen en wat doen we met de overige content?), maar heeft niet per se de kennis en capaciteit om dat ook zo in te richten en te onderhouden.

Niveaus waarop het kan schuren of botsen[bewerken]

Als je (een vorm van) optimalisatie voor doelgroepen wilt heeft dat invloed op alle niveaus: op contentniveau moet je wijzigingen aanbrengen (welke teksten hebben we nodig, welke termen hanteren we, welke voorkennis verwachten we?), op het niveau van navigatie moet je kunnen onderscheiden welke content relevant is voor welke doelgroep en daartussen kunnen navigeren en qua layout kun je onderscheid maken tussen secties voor verschillende doelgroepen met kleur of opmaak). Realistisch gezien zul je dat niet voor alle groepen goed kunnen doen en inrichten en is bepaalde content voor meerdere of de meeste groepen relevant – ook dat stelt eisen aan content, navigatie en layout.

Het belangrijkste niveau voor de oplossing ligt echter in structuur en beheer: we hebben een structuur nodig die differentiatie naar doelgroepen mogelijk maakt en ondersteunt, maar ook niet-ingedeelde content en content voor meerdere groepen een plekje biedt. Dat zal bovendien in de tijd moeten kunnen veranderen, op basis van keuzes in de Gebruikersraad en de bredere omgeving en community. We hebben een eerste aanzet voor zo’n structuur gegeven in ‘Veilig varen op de zee van kennis.’

Volledigheid versus eenvoud[bewerken]

Iedereen wil op noraonline de kennis kunnen vinden die hij/zij op dat moment nodig heeft. En iedereen wil dat er niet te veel wildgroei in content op de website is, maar dat duidelijk is wat er wel en niet thuis hoort. Maar als je gaat praten over wat dat dan inhoudt stuit je al snel op verschillende voorkeuren, waarbij voor alle posities wel wat te zeggen valt:

  • Inhoudelijke keuzes wat er wel en niet op de website thuis hoort: Moeten we het houden bij het DNA van de NORA Familie, of is andere content ook relevant? Wie bepaalt dat en voor hoe lang ligt dat dan vast?
  • Is de behoefte aan meer voorbeelden en inzicht in de relaties tussen de NORA Familieleden te verenigen met de behoefte aan minder, overzichtelijke content?
  • Historie is vaak belangrijk, maar moet die in de context van de wiki zelf te zien zijn zoals nu of is een apart archief een beter idee?
  • Willen we lange pagina’s waar je alles kunt vinden zonder extra navigatie nodig te hebben, of juist korte rustige pagina’s waar je tussen navigeert?

Partijen die het betreft[bewerken]

Iedereen, maar het zal het NORA projectteam zijn dat op sommige punten knopen zal moeten doorhakken of voorleggen aan de NORA Gebruikersraad. Inhoudelijk gezien is te verwachten dat die inhoudelijke keuzes pas na de redesign gemaakt kunnen worden en bovendien door de tijd heen zullen veranderen. Daarom kiest het projectteam voor een flexibele en duurzame structuur op te zetten die wijzigingen in scope en types pagina’s (voorbeelden, relaties, verwijzingen) op een later moment mogelijk maakt. Voor de overige niveaus moeten we beide kanten onderzoeken, waar mogelijk kiezen om ze beide aan te bieden en waar dat niet mogelijk is de keuze mede pragmatisch bepalen: wat is de beste keuze op dit moment binnen techniek, budget en deadline? Sorteren we daarmee afdoende voor op een latere keuze als we die verwachten? Hebben we een idee op wie dit de meeste impact heeft en hebben zij mee kunnen denken?

Niveaus waarop het kan schuren of botsen[bewerken]

Op elk niveau kan een behoefte aan volledigheid de zaken nodeloos complex maken. Concreet liggen een aantal oplossingen op het niveau van structuur:

  • Door content in verschillende zones te laten vallen kun je bestaande keuzes over inhoud implementeren en verduidelijken, terwijl je ook voor toekomstige keuzes ruimte laat: Elke zone heeft een eigen beheerregime waarin staat wat er thuis hoort, wie dat wanneer mag bepalen en aan welke beheereisen het moet voldoen. Dat geeft duidelijkheid die je kunt gebruiken in navigatie en layout. Het is bovendien flexibel: wanneer je het beheerregime besluit te veranderen kun je content uit een zone verwijderen of verplaatsen naar een andere zone waar het wel thuis hoort.
  • Zolang er (nog) geen besluit is gevallen om een los archief op te zetten kunnen pagina’s die niet meer actueel zijn automatisch of handmatig binnen een eigen archiefzone vallen. Deze voldoen immers niet meer aan de beheereisen van de oorspronkelijke zone, zoals dat de content geactualiseerd wordt en er een actieve contactpersoon is.
  • Door content in blokjes (containers) bij elkaar te plaatsen, en pagina’s binnen blokjes te typeren naar hun rol kun je voorsorteren op navigatie, layout of zoekfuncties die het aan de gebruiker laten of ze voorbeelden, verwijzingen, archimate-platen et cetera wel of niet willen tonen en op welke plek. Zo kun je eenvoud en overzicht behouden terwijl je de compleetheid mogelijk houdt.

Mede op basis van die structuurkeuzes kun je op het niveau van navigatie en layout proberen de eenvoud vast te houden en wat niet voor iedereen relevant is benaderbaar te maken zonder dat het in de weg zit. Ook keuzes die uiteindelijk in de content doorgevoerd zullen moeten worden, zoals of je lange of korte pagina’s maakt, moeten eerst in navigatie en layout onderbouwd en ondersteund worden - kun je inderdaad makkelijk navigeren tussen korte pagina’s of wordt dat juist omslachtig?

Navigeren via menu’s, via links in de tekst of via zoeken[bewerken]

We zijn op de meeste websites gewend dat er een menu staat (links of boven in beeld of achter een hamburgerknop) en eventueel een sitemap als niet alles in één menu past. In wiki’s als wikipedia is daar een extra optie bijgekomen: doorklikken van pagina naar pagina via hyperlinks in de tekst. In de praktijk is op veel websites een extra navigatie-optie, via teksten of knoppen. En vinden veel mensen het tijd besparen door gelijk de zoekfunctie van de website te gebruiken in plaats van te zoeken in menu of naar knoppen. De meeste mensen hebben één of twee van die opties als voorkeur, of ze switchen afhankelijk van de taak die ze uitvoeren. Allemaal vinden we het fijn als we na een paar klikken ook weer terug kunnen naar waar we binnen kwamen: waar zijn we terecht gekomen en waar kunnen we heen? De eerste vereiste is dat de ‘terug’ knop in je browser het doet. Maar daarnaast zijn er ook andere oplossingen, zoals kruimelpaden, doorklikbare sitemaps et cetera, die niet voor iedereen even prettig zijn. Voor wie het menu volgt is het bijvoorbeeld vervelend als een diepere pagina daar niet in blijkt te staan. Voor iemand die in de tekst door-klikt is een kruimelpad vaak verwarrend: zo ben ik hier helemaal niet gekomen. En wie via een (interne of externe) zoekmachine op een pagina belandt heeft een andere informatiebehoefte dan wie het ‘voorgaande’ stuk al heeft gelezen. In de praktijk zullen we alle drie de navigatiemogelijkheden moeten faciliteren en zoeken naar manieren waarop ze elkaar niet in de weg zitten. Wellicht komt daar in de toekomst nog een AI-assistent bij ook.

Partijen die het betreft[bewerken]

Iedereen, je zal met name een contrast zien tussen mensen die vooral in hun ‘eigen’ bekende stukje van de wiki rondhangen en mensen die regelmatig breder kijken of denken. Idealiter vragen we gebruikers in brainstorm of demo hun eigen voorkeursnavigatiestijl te kiezen en van daaruit mee te kijken naar probleem en oplossingen.

Niveaus waarop het kan schuren of botsen[bewerken]

Dit uit zich natuurlijk met name op het niveau van navigatie. Maar een deel van de oplossing zal gevonden moeten worden in beheer en afspraken over content: Wat je wel en niet als context meegeeft in je teksten en of je verwijzingen op maar één manier of op meerdere manieren mag of moet verwerken is een afspraak die je moet maken en moet ghandhaven. Veel schrijvers willen bijvoorbeeld ‘geen dubbelingen,’ maar regelmatig zal de gebruiker een andere volgorde hebben dan verwacht en slechts een deel van de pagina’s over een bepaald onderwerp lezen. Een ander deel van de oplossing kan gevonden worden in de structuur en layout: welke metadata geef je aan een pagina mee en hoe geef je die vervolgens weer zodat een gebruiker weet waar hij is en waar hij heen kan?

Je wilt de ‘juiste term’ gebruiken maar ook gevonden worden[bewerken]

Expertgroepen en andere aanbieders van kennis denken vaak lang na over de termen die ze gebruiken en de termen die ze vermijden. Ze willen de lezer direct meenemen in de ‘juiste’ begrippen of het correct gebruik van termen, zodat ze niet in valkuilen stappen die de beginner nog niet herkent. Tegelijk komt de zoeker van kennis vaak binnen op de ‘verkeerde’ term en kan die alleen leren als de juiste content ook via die ingang vindbaar is. Dat is zeker het geval wanneer zender en ontvanger in verschillende sectoren of types organisatie werkzaam zijn: een architect-consultant zal de commerciële term hanteren, ook voor de overheidsopdracht waar hij voor is ingehuurd. Het bepalen van de ‘juiste’ termen staat buiten scope van de redesign. Maar het is wel zaak om te zorgen dat wie in een zoekmachine of op noraonline zelf zoekt naar kennis die we in huis hebben die ook weet te vinden. Dit is een aandachtspunt om mee te nemen in o.a. zoekmachineoptimalisatie en bepalen van optionele metadata, maar ook bij de keuze voor termen in navigatiemenu’s en het al dan niet mogelijk maken om via kronkelpaadjes alsnog op je bestemming te komen. Voorbeelden van ‘juiste’ en ‘minder juiste’ termen:

  • Europese begrippen en definities versus Nederlandse vertalingen van begrippen en definities (Capabilities vs Generieke functies)
  • Afkortingen (bekend bij expert) versus uitgeschreven titels (begrijpelijker voor niet-expert)
  • Overheidstermen versus generieke of zelfs commerciële termen

Partijen die het betreft[bewerken]

Dit dilemma ligt op het snijvlak tussen bewerkers die kennis brengen en bezoekers die kennis halen. Beide groepen moeten meegenomen worden in oplossingen.

Niveaus waarop het kan schuren of botsen[bewerken]

Vooral op het niveau van de content (“dit wordt in de markt ook wel X genoemd, maar dat dekt de lading niet helemaal”), maar ook in de metadata en techniek zijn hier oplossingen denkbaar om termen die bewust niet in de hoofdtekst voorkomen wel te gebruiken om de pagina te vinden (SEO, eigenschap met aliassen, doorverwijzing). We moeten onderzoeken waar de beste kansen liggen.

De eisen van stabiel co-beheer versus dynamische co-creatie[bewerken]

Een sterke wens van de bezoekers is om actuele, goed doordachte en geverifieerde kennis te lezen en waar dat niet altijd mogelijk is in ieder geval duidelijkheid te krijgen van de status van het gelezene: hoe actueel is het, wie heeft er wat over besloten, is het voorschrijvend en zo ja voor wie? Dat vergt goed ingericht beheer van pagina’s, meer beheer dan realistisch vanuit NORA Beheer geboden kan worden. Niets alleen is er geen budget om alle pagina’s periodiek te herzien, maar de kennis die daarvoor nodig is ligt ook niet bij het beheerteam, maar in de brede community: Wat uit co-creatie ontstaat kan je niet centraal beheren zonder medewerking van de creatoren. Eigenlijk is co-beheer noodzakelijk, waarbij van elk stukje op de wiki te achterhalen is wie er over gaat en die inhoudelijk eigenaren zich ook committeren aan beheerafspraken. De dynamiek van co-creatie maakt de overstap naar co-beheer vaak moeilijk: je wilt laagdrempelig kunnen beginnen zonder al te veel verplichtingen of administratie vooraf, de eerste initiatiefnemers blijven niet altijd betrokken, de inhoud is nog niet uitgekristalliseerd dus het is ook nog niet precies te zeggen wie er over zou moeten gaan en welke relaties er liggen naar andere kennis en gremia.===

Partijen die het betreft[bewerken]

De behoefte wordt het meest gevoeld bij de bezoekers en de oplossing ligt grotendeels op het bordje van de kennisbrengers: zij zullen beheerafspraken moeten maken en zich er aan houden. NORA Beheer vervult hier uiteraard een belangrijke rol en zal, gezien de beperkte capaciteit, ook moeten kijken hoe we dit slim kunnen inregelen.

Niveaus waarop het kan schuren of botsen[bewerken]

Dit lijkt vooral naar voren te komen in de content: die is al dan niet beheerd en al dan niet duidelijk of het beheerd is. Maar het gaat verder: we moeten in de structuur een koppeling maken tussen bepaalde beheerafspraken (beheerregimes) en types content of zones binnen de wiki en die ook in de metadata terug laten komen. De navigatie kan op grond van die metadata zaken die niet goed beheerd worden niet tonen of dieper weg stoppen. En de layout geeft de metadata weer op een manier die de bezoeker duidelijkheid geeft en de mogelijkheid om contact op te nemen of meer te lezen over hoe het beheer is ingericht. Hiervoor is een eerste aanzet gedaan in ‘Veilig varen op de zee van kennis.’ (blog Marieke Vos op LinkedIn met presentatie gedachten rond structuur: veilig varen op de zee van kennis)