Hieronder volgt de userstory voor 'nieuwsbrief' functionaliteit in de DvG. Twee vragen:
- Graag commentaar en ideeën. Er zitten nog een aantal vragen in de tekst.
- Wie wil mee opdrachtgever zijn voor deze functionaliteit en dus mee betalen?
Userstory: Als gemeente willen wij verschillende doelgroepen incidenteel of regulier kunnen informeren, zodat wij onze informatie op een goede, toegankelijke manier onder de aandacht kunnen brengen..
Publicatie
De nieuwsbrief is op de eerste plaats webcontent. De nieuwsbrief wordt gemaakt in het CMS en gepubliceerd op de website. De layout/opmaak volgt de stijl van de website en is responsive. De nieuwsbrief voldoet minimaal aan Webrichtlijnen versie 2 AA.
Meerdere onderwerpen
Voor een bepaalde doelgroep of bepaald onderwerp maak je een nieuwsbriefcategorie aan, bijvoorbeeld een “Raadsinformatiebrief” voor raadsleden of “Bouwplannen Wijk Noord” voor geïnteresseerden in de bouwplannen. Binnen de categorie maak je de individuele edities van de nieuwsbrief aan.
Voor iedere nieuwsbriefcategorie is een overzicht beschikbaar (omgekeerd chronologisch, nieuwste eerst) van de reeds eerder gepubliceerde nieuwsbrieven.
Vraag >>> Waar moet het overzicht te zien zijn? Alle nieuwsbrieven bij elkaar via 1 ingang? Nieuwsbrievenoverzicht juist bij het onderwerp/project verspreid over de website? Beide locaties tegelijk? <<<
Notificaties
Overweging push vs pull. Het uitgangspunt van DvG is pull. De meeste inwoners zitten niet op een zendende overheid te wachten en bezoeken de website van de gemeente zeer zelden. Dat wil niet zeggen dat inwoners of andere groepen over bepaalde onderwerpen niet actief op de hoogte gehouden willen worden, maar dan wel op de door hun gewenste manier. DvG beschouwt push-berichten als notificaties: een opt-in service bij het pull-bericht.
Je kunt je abonneren op verschillende soorten notificaties van de nieuwsbrieven:
- E-mail: notificatie met korte inhoud en link naar de website
- E-mail : volledige inhoud van de nieuwsbrief in de e-mail
- RSS feed
- Sociale media
Voor de e-mail notificaties kan de gebruiker zich afmelden via een linkje in de verstuurde e-mails en via een een formulier op de website.
Op het aanmeld/afmeld formulier kan de gebruiker ook wisselen van type notificatie (kort of volledig) of wordt doorverwezen naar een apart webformulier waar de gebruiker dit kan instellen.
De e-mail notificaties zijn netjes gestyled in de look-n-feel van de website, maar mogen wat layout/opmaak betreft eenvoudiger zijn. De notificaties zien er goed uit in de meest gebruikte mail clients.
De toegankelijkheid van de e-mail notificaties wordt gewaarborgd door ook een text/plain part te sturen als onderdeel van een multipart message.
Usertesten of Gov.uk “Make sure this is right?” model ook voor ons de beste check oplevert voor aanmelden e-mailadres.
Er is een RSS feed voor iedere nieuwsbriefcategorie.
De publicatie van een nieuwsbriefeditie kan op een sociale mediakanaal aangekondigd worden. Tenminste ondersteuning voor Twitter en Facebook.
Vraag >>> Optie: moet de redacteur vanuit het CMS een sociaal media bericht kunnen verzenden wanneer een nieuwe nieuwsbrief online komt? Moet dit automatisch verlopen? Of is dit een redactionele activiteit die de redacteur los in de desbetreffende sociale media applicatie moet uitvoeren? <<<
Per nieuwsbriefeditie wordt een unieke tracking tag toegevoegd aan de links in de notificaties.
Formaat
Iedere categorie nieuwsbrief heeft:
- een eigen titel, bijvoorbeeld “Raadsinformatiebrief”;
- optioneel een eigen logo;
- optioneel een eigen steunkleur;
- instellingsoptie formaat tracking tag op basis van vrije tekst + tokens
Iedere editie van de nieuwsbrief heeft:
- een datum (door redacteur aanpasbaar);
- optioneel een ‘thema’ (subtitel), bijvoorbeeld “Begroting 2016”;
- één of meerdere secties (onderwerpen);
- uitgestelde publicatiedatum (automatisch op datum/tijd in toekomst publiceren en notificaties verzenden);
- mogelijkheid tot tonen in Actueel blok
- social media buttons om de URL te delen (tenminste Twitter en Facebook; géén JS knoppen, maar lokaal gehost logo + linkje)
- automatisch gegenereerde unieke tracking tag (redacteur kan tag handmatig aanpassen)
Iedere sectie heeft:
- een kop;
- een body (wysiwyg);
-- mogelijkheid tot inline plaatjes; - optioneel een galerij (CSS only slider);
- optioneel een opvallende link als afsluiter (kan dmv LinkIt een interne of externe verwijzing bevatten).
Vormgeving
Standaard DvG styling is minimaal en eenvoudig aan te passen aan huisstijl van gemeente. Template is conform webrichtlijnen.
De secties hebben en de nieuwsbrief als geheel heeft een zeker promotioneel doel en mag ook tot lezen proberen te verleiden. Daarmee mag de nieuwsbrief tot op zekere hoogte ook afwijken van de layout/vormgeving van de website. Heldere en toegankelijke presentatie van de informatie staat voorop en de vormgeving past natuurlijk wel bij de huisstijl van de website.
Afwisseling zou bijvoorbeeld mogelijk zijn door 3 verschillende positioneringen van het beeldmateriaal toe te staan: centraal over volle breedte, halve kolom links of halve kolom rechts. Een ontwerper kan hier verdere voorstellen over doen.
Beheer
Een redacteur kan de nieuwsbrief previewen precies zoals deze op de website er uit komt te zien voordat de nieuwsbrief wordt gepubliceerd.
Een redacteur met voldoende rechten kan per categorie nieuwsbrief:
- een overzicht van e-mail subscribers en type subscription zien
- kan individuele subscribers handmatig toevoegen en verwijderen
- kan een lijst met e-mailadressen in bulk toevoegen
- (optioneel) kan zien hoe vaak een nieuwsbrief niet bij welk e-mailadres afgeleverd kon worden
Optioneel: Een redacteur kan een conform WR2AA toegankelijke PDF van de nieuwsbrief genereren.
- Het is nog niet duidelijk of dit een functionaliteit is die het CMS moet aanbieden, er staan vragen uit over de technische oplossing.
- Reden: het valt te verwachten dat bijvoorbeeld bij een raadsinformatiebrief er behoefte bestaat aan het (additioneel) archiveren of doorsturen van de nieuwsbrief in PDF formaat. Een van de uitgangspunten van de DvG nieuwsbrief is toegankelijkheid. We moeten dus op voorhand kijken hoe we van de toegankelijke HTML versie ook een toegankelijke PDF kunnen leveren, binnen óf buiten het CMS om.