Projectplan verbetering website gemeente Deventer

Projectplan verbetering website gemeente Deventer

Door Jeroen Hoogeweij

1. Producten & Processen; de stand van zaken De meerderheid van de nederlandse huishoudens is nu aangesloten op internet. Uit recent onderzoek blijkt, dat het web zeventien jaar na het ontstaan het belangrijkste deel van de mediamix geworden is. Onderzoek laat zien dat internet gebruikers de uitkomsten van zoekmachines even belangrijk vinden als de meningen van vertrouwde vrienden en familieleden, actualiteiten bereiken mensen steeds meer als eerste via het web, met behulp van bijvoorbeeld RSS feeds, www.nu.nl , of een site als www.digg.com. Daarnaast is informatie gedemocratiseerd en is het gezag van traditionele informatieverstrekkers tanende. Burgerjourmalistiek is in opkomst, traditionele journalistiek in verval. (nieuws van vandaag inwereken) De toegenomen snelheid van het internet en de beschikbaarheid van nieuwe online geeedschappen hebben een nieuw internet gemaakt, waarin het onderscheid tussen de maker en de consument van content voor een groot deel weggevallen is. Overheden moeten hun rol daarin opnieuw tegen het licht houden.

1.1

Producten

Vanzelfsprekend is het hoofdproduct hier www.deventer.nl , waaronder twee subcategorieën vallen: het Content Management Systeem SharePoint in de eerste plaats en content in de tweede plaats. Deze zijn op hun beurt weer verweven met het te ontwikkelen bestuurlijk en raadsinformatiesysteem en de diensten van het digitaal loket, waaraan in de paragraaf ‘processen’ meer aandacht wordt gegeven..

www.deventer.nl Door toename in het gebruik van internet als informatiebron, wordt transparantie en toegankelijkheid van overheidsinformatie op het internet steeds belangrijker. Websites die deze informatie bevatten zouden toegankelijk moeten zijn voor alle internetgebruikers: burgers (inclusief mensen met een functionele beperking), bedrijven, andere overheden en zoekmachines. Dat betekent dat technieken die groepen gebruikers of vormen van gebruik bij voorbaat uitsluiten, niet mogen worden toegepast. Volgens de meest recente metingen op advies.overheid.nl neemt de gemeente Deventer een zesenzeventigste positie in op de officiële overheidsranglijst.

Er moet echter niet te vroeg gejuicht worden, want deze ranking zegt feitelijk niet zoveel. De vorige score van de website op alle toetsingscriteria was 52% en leverde een 204e plaats op, nu is die gestegen naar 58.72%, een stijging van dik zes punten. Veel gemeenten schommelen in deze ‘ middenmoot’.

De gemeente Deventer ambieert niet in deze middenmoot te zitten, maar wil in plaats daarvan het predikaat ‘excellente dienstverlener’ verdienen. Hierover meer in de toekomstvisie. Uitgaande van de overheidsscan scoort de site niet goed op: (bestuurlijke) transparantie, vergunningen en catalogi. Daarnaast moet de site beter voldoen aan eisen van accesibility. In de hieronder weergegeven tabel volgt een korte evaluatie van www.deventer.nl

Kenmerk website Look & feel

Digitaal loket

Content

Bereikbaarheid in zoekmachines Alt tags

Gebruik elementen

Interactiviteit met de burger

Raadstukken Bestemmingsplannen Vergunningen

Stand van zaken Op dit moment is de communicatie afdeling bezig met het ontwikkelen van een huisstijl. In het kielzog daarvan zal een nieuw template ontworpen worden. Er worden nu nog maar een paar kleine digitale diensten aangeboden, maar dit Er wordt nu gewerkt aan een inhaalslag Er moet een begin gemaakt worden met de plaatsing van statische content, zoals introducties op delen van de site. nu zijn er nog veel ‘ lege plekken’. Meta tags zijn geheel afwezig, er heeft geen zoekmachine optimalisatie plaatsgevonden. 
 Worden geregeld gebruikt voor lange stukken tekst, die eigenlijk in de content horen. Oneigenlijk gebruik van alt tags heeft tot gevolg, dat de site minder goed toegankelijk is voor blinden en slechtzienden. Ook op andere vlakken is de toegankelijkheid onvoldoende
 Elementen als ‘zie ook’ en ‘links’ zijn vaak helemaal niet ingevuld, daarnaast kunnen er veel meer ‘blokjes’ opgenomen worden aan de linker en de rechterkant. Op dit moment is een voorzichtig begin gemaakt met een blog van de burgemeester.
 In samenwerking met de griffie wordt er gewerkt aan een bestuurlijk informatiesysteem, waarvan los van bestuurlijke informatie ook raadsverslagen etc. ontsloten worden.





SharePoint 2003/ 2007; omgevingsfactoren Er bestaat onzekerheid over de uiteindelijke IT structuur waarmee dit CMS uit moet kunnen wisselen. Op dit moment is het Content management Systeem van de website CMS 2002, dat nauw verweven is met de nu draaiende SharePoint 2003 structuur. Er wordt gepland om medio november over te stappen op SharePoint 2007. Vanuit de gemeenteraad, dientengevolge de griffie en ook andere organisatiedelen wordt er grote druk uitgeoefend om het bestuurlijk en gemeentelijk informatiesysteem en andere functionaliteiten zo spoedig mogelijk op de website beschikbaar te maken. De deadline van de griffie lag op november, dat deze deadline niet gehaald werd, moet onder meer onderbouwd worden in de richting van de gemeenteraad. Voor de afdeling IDM is zelfs december niet haalbaar, omdat hun focus primair gericht is op ontwikkeling van producten van het digitaal loket, wat een onderdeel van de site is. Om deze reden is vanuit deze afdeling te weinig menskracht beschikbaar om te helpen met de rest van de site. Daarnaast worden de toegankelijke weergave op de site van het Bestuurlijk en Raads informatie systeem en ook andere functionaliteiten op dit moment niet opportuun geacht door de afdeling IDM. Deze gaat ervan uit dat dit binnen Sharepoint 2007 plaats zal vinden, waarvan de opleveringstermijn onduidelijk is. Ook is het in het verleden diverse malen voorgekomen, dat functionele behoeftes waarin niet voorzien kon worden, leidden tot een nieuwe website met een afzonderlijke URL. Een goed voorbeeld hiervan is de wijkaanpak, wat wel degelijk een beleidsspeerpunt van de gemeente is. Deze sites moeten weer ‘teruggewonnen’ worden, om het succes en de levendigheid van de gehele site te kunnen garanderen. De afhankelijkheid van het toekomstige Sharepoint 2007 mag niet leiden tot het niet realiseren van deze functionaliteiten, want door een parallel ontwikkeltraject in te gaan, kan er goed op die behoeftes ingespeeld worden. Het is technisch bekeken haalbaar om dat rond de jaarwisseling rond te hebben, via de in het ontwerpdeel verder uitgewerkte oplossingsrichting. Aan de andere kant moet naadloze aansluiting van de webapplicatie op de omringende infrastructuur onder alle omstandigheden gegarandeerd worden. Ook leert een korte analyse in het licht van de ambitie de top tien van gemeentelijke websites te maken ons, dat de meeste geuite wensen op procesmatig (klantgerichtheid van de website beheersstructuur, flexibiliteit) en functioneel niveau niet te realiseren zullen zijn binnen een Sharepoint 2007 omgeving. De door Sharepoint gegenereerde pagina’s zijn daarnaast onvoldoende ‘accessible’ om een toppositie voor de site te kunnen garanderen, deze zullen niet de W3C normering halen, waardoor de site binnen Sharepoint nooit in de top tien van Nederlandse gemeentes zal kunnen komen. Op dit moment wordt er door Microsoft gewerkt aan een ‘accessibility’ toolkit voor Sharepoint 2007 om dit euvel te verhelpen, maar deze is nog niet voltooid of aangetoond. http://blogs.msdn.com/sharepoint/archive/2007/09/05/pre-announcing-the-accessibility-kit-forsharepoint-aks.aspx. Daarnaast is de ontwikkeling van Sharepoint webparts (het alternatief) een langdurig en kostbaar proces. Het eindresultaat is vervolgens een brok functionaliteit met een in ‘steen gehouwen’ opmaak, die moeilijk op een wezenlijk niveau aan te passen is door de webmaster. Standaard beschikbare webparts in MOSS 2007 bieden onvoldoende flexibiliteit en Sharepoint is wederom nog bezig met de ontwikkeling van aanvullende standaard webparts, die een dynamische en interactieve website kunnen faciliteren. De

bouw van deze webparts is te vinden op: http://www.codeplex.com/CKS . Opgemerkt moet worden dat de beschikbare functionaliteiten zelfs hier aan de magere kant zijn. Microsoft is nog bezig met het maken van een inhaalslag op het vlak van web 2.0 en bovenstaande twee links zijn daar een goede illustratie van. Inzet van Sharepoint als webapplicatie is kort samengevat duur, arbeidsintensief, inflexibel en moeilijk aan te passen. Ondanks het overweldigend nut van Sharepoint als Enterprise Content Mangement omgeving (intranet), betekent dit niet dat het ook een voor de hand liggende keuze is voor Web Content Management.

IDM Om bovenstaande redenen moet er gekozen worden voor een systeem dat zich allereerst onafhankelijk van de organisatiebrede implementatie van Sharepoint 2007 kan ontwikkelen, en los daarvan agnostisch moet zijn over de vraag of dit versie 2003 of 2007 betreft, zodat de decentrale redacteuren binnen de hun bekende intranet structuur bediend kunnen worden. Daarnaast kan er (paradoxaal genoeg) wel degelijk al uitgegaan worden van een Sharepoint 2007 omgeving, die functionaliteit is nu al via de ingang van het digitaal loket en het daarvoor aangelegde midoffice voor de web applicatie beschikbaar, vanzelfsprekend ook voor andere functionaliteiten. Op een technisch niveau is via die route al een ‘service oriented architecture’ beschikbaar, die met behulp van XML altijd uit zal kunnen wisselen met het te bouwen CMS. Als van dit midoffice gebruik gemaakt wordt, is bovendien een goede integratie met de rest van de diigitale omgeving van de gemeente Deventer gegarandeerd. Ook de modus operandi van de afdeling IDM moet meegewogen worden in de keuze van een oplossingsrichting. Zoals elders aangegeven, faciliteert de afdeling IDM op het moment niet met het functioneel en technisch beheer van de site, dit is uitbesteed aan derden. Ook wordt er geen alternatief geboden voor aangegeven oplossingsrichtingen, of praktisch handen en voeten gegeven aan rollen die IDM hoort te vervullen in de totstandkoming van de nieuwe web applicatie. De oorzaak hiervan ligt bij een capaciteitsprobleem. Daarnaast werd er eerst gepland om ook Windows Vista te implementeren binnen de gemeente Deventer en werd dit onverwachts afgeblazen kort voor het implementatietraject ingegaan zou worden. Vanuit het website project bekeken betekent zo’n signaal, dat er rekening gehouden moet worden met het onverwachts niet doorgaan van de implementatie van Sharepoint 2007. Zoals uit bovenstaan,de links blijkt, is ook deze applicatie nog volop in ontwikkeling. Het eventueel mislopen van de implementatie zou geen impact moeten hebben op het digitaal loket, omdat dit deel nu al gefaciliteerd wordt vanuit een Sharepoint 2007 omgeving. Maar het heeft wel een impact op inrichting van de beheersorganisatie, omdat er voor de decentrale redactie moet gelden dat deze het CMS kan bedienen vanuit het systeem waarmee ze ook het intranet bedienen, los van de vraag of dit Sharepoint 2003 of 2007 zal zijn. Ook moet er gezorgd worden, dat de output van het midoffice van Sharepoint geen negatief effect zal hebben op de zuiverheid van de code op de site.

XML en Service Oriented Architecture Microsoft Office SharePoint Server 2007 biedt een open, schaalbaar platform zodat uitbreiding op basis van open standaarden als XML en SOAP (Simple Object Access

Protocol) tot de mogelijkheden behoort. Een hedendaagse IT organisatie functioneert vanuit een z.g. ‘Service Oriented’ systeemvisie. (wikipedia definitie). Uiteenlopende technologieën opereren op een met elkaar geïntegreerde wijze en zijn voor elkaar ontsloten omdat ze met elkaar kunnen communiceren. Deze visie op systeemintegratie wordt voluit gefaciliteerd door SharePoint 2007. Het voorziet in een integratieweefsel dat op betrouwbare wijze verschillende applicaties met elkaar verbindt en inschaalbaar coördineert, terwijl de integriteit van transacties (via XML) in stand blijft. In makkelijker Nederlands: het maakt tegenwoordig niet zoveel meer uit welk programma een stukje functionaliteit afkomstig is, zolang ze maar met elkaar uit kunnen wisselen. Sharepoint 2007 is vanuit deze gedachte zelfs ontwikkeld. Het is daarom mogelijk dat de communicatie afdeling onder eigen beheer een CMS bouwt, dat door middel van XML volledig kan uitwisselen met SharePoint 2007. Zo kunnen alle afzonderlijke afdelingen hun doelstellingen behalen en is de communicatie afdeling tegelijk in staat om een maatwerk systeem op te zetten, dat flexibel kan inspelen op de behoeftes van een zich snel transformerend internet. De diensten van het digitale loket worden op dit moment al gehost met een SharePoint 2007 server. Deze kunnen onverminderd gehost blijven worden binnen een nieuw CMS, onder een afzonderlijk tabblad. Hierover in het volgende deel meer.

1.2

Processen

1.2.1 Beheersorganisatie Rollen en verantwoordelijkheden zijn op dit moment nog diffuus. In juni 2006 is de hiernaast weergegeven hiërarchische structuur binnen de organisatie voorgesteld, maar deze is nooit formeel vastgelegd. Daarnaast is de invloed van MACAW, een externe partij te groot. Tijdens internet overleggen is gebleken, dat alle betrokken partijen het erover eens zijn dat MACAW een vertragend effect heeft op processen. De webmaster moet geregeld maanden wachten voor een betrekkelijk kleine aanpassing, die onder eigen beheer een kwestie van minuten was geweest.

1.2.2 Redactionele kant De rolverdeling tussen auteurs, de redacteur en de content beheerder is ook niet transparant. Op het moment richt Marja Beumer zich met name op het SharePoint intranet deel en Ike Nagelkerke op het internet. Voor de reorganisatie begin dit jaar was de bestaande decentrale redactiestructuur een gegeven, maar erna hield deze op te bestaan. Op dit moment is de situatie, dat

decentrale redacteuren niet de formele taak hebben om content te verzorgen, deze taak heeft geen weerslag gevonden in een FTE definitie. Daarnaast zijn er veel mensen op andere plekken terechtgekomen, waardoor er veel ‘geheugen’ en vaardigheden uit de organisatie verdwenen zijn. Er is een inventarisatie gemaakt van de auteurs per afdeling en de daarmee verbonden inspanning. Als er op managementniveau een beslissing is genomen voor een decentrale redactiestructuur (wat onvermijdelijk lijkt gegeven de aard van elke site die een bestuurlijke organisatie vertegenwoordigt), kan deze ‘uitgevouwen’ worden in de richting van de rest van organisatie. Ook de relatie van de webredactie met de decentrale redacteuren is onvoldoende. Binnen afdelingen bestaat ontevredenheid over de klantgerichtheid van de webredactie en vanuit de webredactie bestaat ontevredenheid over de invulling van de rol van webredacteuren. Om deze reden is het van belang om het proces tussen webredactie en decentrale redacteuren goed te definieren en ervoor te zorgen dat er heldere afspraken gemaakt worden.

1.2.3 IT kant Op dit moment is er weinig grip op het onderhoud en zelfs maar kleine wijzigingen van de website. Het volledige beheer van de site is los van de plaatsing van artikelen uitbesteed aan MACAW, het functioneel en technisch beheer wordt op dit moment uitgevoerd door deze organisatie. Hiervoor heeft de afdeling IDM met laatstgenoemde een Service Level Agreement afgesloten, kleine klussen die Chris (de webmaster) heeft, worden afzonderlijk gefactureerd door MACAW en buiten de SLA gehouden. Er bestaat onduidelijkheid over de vraag wie eigenlijk MACAW op het onderhoud van de site stuurt. Overigens is deze SLA minimaal gebleven en is gesteld op een inspanning van negen uur per maand. De webmaster moet in de nieuwe beheersorganisatie meer grip hebben op de website. Om een paar recente voorbeelden te geven: al een maand geleden was het verzoek ingediend, om de achtergrondkleur van een template in de site te wijzigen. Conform het afgesproken proces wordt de opdracht dan door de webmaster op de teamsite geplaatst en moet dan door een werknemer van MACAW daaruit opgepikt worden. Dit gebeurde pas een half jaar na het verzoek. Daarnaast heeft MACAW aangegeven het zo druk te hebben, dat ze zelfs overwegen werk aan het digitaal loket te outsourcen naar Oost Europa. Hetzelfde geldt voor maanden geleden aangevraagde kalender functionaliteit voor op de site, die eveneens nog steeds niet opgeleverd is. Door ervoor te kiezen een webmaster zelf de site bij te laten houden, worden afhankelijkheden van externe partijen geminimaliseerd en kan de webmaster proactiever reageren op bestaande behoeftes vanuit de organisatie. Om dat te bereiken zal de site semantisch ontwikkeld moeten worden, wat betekent dat CSS en XHTML 100% in handen van de webmaster moeten zijn. Binnen een Sharepoint omgeving wordt de CSS (styling) vanuit een moeilijk te bereiken masterpage gedefinieerd, wat de styling bemoeilijkt voor de webmaster. Ook om deze reden is Sharepoint geen voor de hand liggende web applicatie. Om bovenstaande situatie te kunnen veranderen, moeten er wijzigingen aangebracht worden in de manier van werken en moeten goede afspraken gemaakt worden met de technische beheersorganisatie. Daarnaast moet de achterliggende technische structuur zo ingericht worden, dat deze onder geen enkele omstandigheid het faciliteren van de

organisatie kan hinderen. Er moeten om deze redenen nieuwe keuzes gemaakt worden voor methodiek (agile, semantisch). Deze manier van werken moet ook ingebed zijn in de te ontwikkelen technische structuur. Processen moeten flexibel ingericht worden, op een manier dat de gemeente constant grip houdt op het ontwikkeltraject en snel kan voorzien in nieuwe functionele behoeftes. In principe hoeft het niet langer dan een week te duren om een nieuwe complexe functionaliteit ontwikkeld te hebben. Doelen in de richting van technische ontwikkelaars/ beheerders moeten meetbaar gemaakt worden, zodat zaken die mis dreigen te gaan al in een vroeg stadium bijgestuurd kan worden.

2. Deventer 2.0 ; toekomstige producten en processen 2.1

Doelstellingen

Met de inrichting van de Deventer website moeten los van hierboven genoemde vebeterpunten de volgende algemene doelstellingen behaald worden: • • • • • •

Verstrekken van informatie, eenzijdig communiceren Uitwisselen van informatie, tweezijdig communiceren Doen van zaken, transacties en verlenen van daarmee verbonden diensten aanwezig zijn op het web, web presence (aansluiten op deventer blogosphere) Verhogen van gebruik van de website. Verdienen van het predikaat ‘excellente dienstverlener’, wat zich vertaalt in een top tien positie van de overheidsmonitor.

vanuit deze doelstellingen wordt in 2008 het volgende concreet gerealiseerd:

• • • •

Aantal unieke bezoekers van de site met 10% vermeerderen tov 2007 80% van de informatie op de site is in maart 2008 actueel en accuraat(eenzijdige informatieverstrekking) Er staan in februari 2008 minimaal 5 interactieve functionaliteiten online Website verschijnt in de top 10 van de monitor overheid.nl in juni 2008

Bovenstaande doelstellingen zijn gebaseerd op de internetvisie die eind 2006 door de gemeente is vastgesteld; uiteraard is deze aangepast aan het huidige tijdsbeeld. Zoals bekend: een zeer snel veranderend tijdsbeeld als het gaat om internettoepassingen. Daarnaast zijn ook de doelstellingen zoals geformuleerd door de raad meegenomen en is het werkproces dusdanig ingericht, dat zowel burgers als gemeentewerkers maximaal gefaciliteerd worden. Ook moet de site bij voorbaat al toegerust zijn op veranderingen van technologie, omgeving en nieuwe functionele behoeftes van de organisatie.

2.2 Producten www.deventer.nl Verstrekken van informatie Een gemeentelijke website is altijd ten dele een expertsite. Dit moet vooral naar voren komen in de tabbladen ‘Gemeenteraad’ en ‘Bestuursinformatie’. Thans wordt onder beide delen alleen nog algemene informatie verstrekt over de raad. Deze moet natuurlijk samengevoegd worden onder het raadsdeel, onder het bestuurlijke tabblad moeten alle openbare bekendmakingen zoals kap-en bouwvergunningen geplaatst worden. Verder moet er invulling gegeven worden aan het raads- en bestuurlijk deel volgens het door de griffie aangegeven pad.

Uitwisselen van informatie Meer dan alleen een ‘zender’ is overheid 2.0 er voor en door burgers. Kennis stroomt niet langer meer een richting uit, van de bestuurders naar de bevolking, maar wordt samen met burgers tot stand gebracht. Bestuurders houden blogs bij waarin commentaar gegeven wordt op issues van de dag; overheidssites hebben wiki’s waarin mensen tips kunnen uitwisselen over hun belastingteruggave of subsidies; databases met restaurant recensies, festivals en andere activiteiten zijn vrijelijk beschikbaar en kunnen door iedereen weer opnieuw gebruikt worden in interactieve kaarten. Voor een nieuwe publieke dienst in de lucht gezet wordt, kijkt de overheid eerst of er een community bestaat die dezelfde dienst al beter doet. Kort samengevat laat overheid 2.0 haar grip op het web wat vieren en faciliteert interactiviteit. Door van deze tools gebruik te maken, is de rol van burgers in toenemende mate veranderd van passieve ontvangers van door experts geleverde informatie, in actieve producenten van informatie en consumenten van informatie die door andere burgers plaats van experts geleverd is. De duizenden door overheden gefaciliteerde websites brengen een enorme hoeveelheid informatie voort. De hierboven beschreven tools maken het mogelijk dat door de publieke sector verschafte informatie opnieuw gebruikt kan worden om nieuwe diensten te maken, die nooit verzonnen waren op het moment dat de informatie verzameld werd. Een goed en actueel voorbeeld hiervan is een website die in de verkiezingstijd door het CDA werd ontwikkeld www.wietvrij.nl die via google maps laat zien welke scholen coffeeshops in de buurt hebben. Met Google maps als basis is

informatie afkomstig van de kamer van koophandel (coffeeshops) gecombineerd met informatie afkomstig van het ministerie van Onderwijs (scholen).

User generated website: een voorbeeld Hieronder een voorbeeld hoe een een actief participerende gebruiker zijn eigen nieuwspakket over de gemeente Deventer kan samenstellen. Klik op het plaatje om het voorbeeld ‘live’ te zien.

Verlenen van diensten en doen van zaken Deze zullen vooral plaatsvinden binnen de ‘mijn loket’ functionaliteit. Henk Plomp is in samenwerking met IDM verantwoordelijke voor de totstandkoming van de functionaliteit van dit deel in zoverre dat mid- en back office functionaliteit betreft, de afdeling communicatie is verantwoordelijk voor de afhandelingsprocedure van transacties aan de voorkant. De volgende processen en producten zijn gepland in de geprojecteerde projectdoorloop van Henk Plomp:

Fasering / activiteiten (Tussen)resultaten:

Start

Eind

Feitelijke planning m.b.t. 7 produkten FO

Juli 07

Aug.07

Planning minima- en parkeerprodukten, 3 APV’s en 3 Vergunningen

Aug.07

Bouwen volgens bovenstaande planning

Juli 07

01-04-2008

Planning resterende producten Voorstel beheer Mijn Loket

Onder ‘voorkant worden hier de te nemen stapjes in de transactie afhandeling verstaan, de registratieprocedure en de uitleg van ‘Mijn loket’. Kortom, alles wat zichtbaar voor de gebruiker plaatsvindt. Aan deze kant van ‘Mijn loket’ moet minimaal evenveel aandacht besteed worden als aan het mid- en back office, waar op dit moment de meeste energie in wordt gestoken. Uit een een onderzoek van de consumentenautoriteit is gebleken dat 90% van de onderzochte webwinkels niet voldoet aan wettelijk verplichte criteria.

Dit jaar zijn webwinkels (natuurlijk is ‘mijn loket’ ook een webwinkel) een speerpunt van de consumentenautoriteit. Dat betekent dat ze er extra op gaan toezien, dat webwinkels hun zaak wel volgens de regels voeren, zodat consumenten erop kunnen vertrouwen dat ze geen kat in de zak kopen. Daarnaast kan inzet van (degradable) javascript in de formulieren een goede gebruikerservaring zorgen. Door het front office deel uit te laten maken van het CMS, kan er gezorgd worden voor een mooi vormgegeven en makkelijk te gebruiken digitaal loket. Een goed ontwerp van een webshop houdt rekening met deze wettelijke voorwaarden. Veel digitale winkeliers en webdesigners zijn niet goed op de hoogte van deze regels en maken daarom bijvoorbeeld de stapjes die leiden tot een aankoop te onduidelijk. Vaak wordt het accent teveel gelegd op technische realisatie en te weinig op de afhandelingsprocedures. In relatie met ‘Mijn Loket’ moet communicatie zorg dragen voor de volgende zaken: • • • •

Registratieprocedures Vormgeven van de formulieren op basis van ergonomische uitgangspunten Uitleg procedures Ontwerp procesgang van transacties op gebruikersniveau

In afstemming met Henk Plomp moeten deze zaken in de door hem neergelegde tijdsplanning gepast worden.

Samenvattend Los van ‘Mijn Loket’ en BIS functionaliteiten moeten de volgende functionaliteiten op de website geïmplementeerd worden: daarnaast moet de site voldoende flexibel opgebouwd zijn, om makkelijk te kunnen voorzien in de behoeftes, zoals die vanuit de organisatie gesteld zijn. Op procesniveau en ook op technisch niveau zal de website in zijn fundament veranderd moeten worden.

2.2 Beheersorganisatie Zoals aangegeven in het eerste deel, is er veel mis met de huidige beheersorganisatie. Het technisch en functioneel beheer word nu uitgevoerd door MACAW en er bestaat ontevredenheid over de invulling van die rollen. Kleine wijzigingen zijn moeilijk en absurd traag (een half jaar) te realiseren, structurele, culturele en procesmatige wijzigingen zijn niet haalbaar binnen de begrenzingen van de nu bestaande webapplicatie. Om te borgen dat deze situatie zich niet zal herhalen, zijn in het technisch ontwerp randvoorwaarden voor de technisch beheerder opgenomen. De webmanager en de teamleider communicatie moeten daarnaast direct een Service level agreement afsluiten met de technisch beheerder, die tweewekelijks geevalueerd wordt met de webmaster en de webmanager. Deze SLA is loopt nu nog via de afdeling IDM, maar moet in de toekomst direct met de afdeling communicatie afgesloten worden. De rol van webmaster is door een samenloop van omstandigheden binnen de organisatie ook uitgehold geraakt, waardoor deze op het moment moeilijk effectief invloed kan uitoefenen op de functionaliteit van de site. In die zin gaat de functionele sturing van twee kanten mis. Los van het argument van accessibility is dit een beslissende motivatie om te kiezen voor een inrichting die 100% semantisch is (strikt gescheiden en makkelijk aanpasbare XHTML en CSS die aan de ‘oppervlakte’ van de applicatie ligt). Zonder een heel stijle leercurve kan de webmaster de website dan op een wezenlijk niveau aanpassen en hoeft zich alleen tot de technisch beheerder te wenden, als er aanpassingen op het niveau van de applicatie gemaakt moeten worden. De XHTML en CSS + javascript van het beheerssysteem zijn de verantwoordelijkheid van de webmaster. Op het niveau van webredacteur is er op het moment sprake van rolonduidelijkheid. Dit heeft geleid tot de onwenselijke situatie, dat er geen goede content geschreven wordt, decentrale redacteuren niet op de jusite manier begeleid worden en buitenproportioneel veel aandacht van de webredacteur verschoven is naar het takenpakket van de webmanager. Om deze rolonduidelijkheid te beeindigen zijn de rollen van redacteur en manager in de beheersstructuur beter gescheiden en wordt er meer accent gelegd op een redacteur waarbij de nadruk vooral ligt op schrijfvaardigheden.

Ook is er sinds de reorganisatie begin dit jaar geen goede invulling meer gegeven aan de decentrale redactiestructuur, waardoor op veel afdelingen niet duidelijk is wie er op dit niveau verantwoordelijk is voor de aanlevering van content op de site. Om hierin verandering te brengen is op MT niveau enige besluitvorming zeer noodzakelijk. Dit alles heeft geleid tot het hierboven weergegeven organogram. De verbindingen hierin staan voor wederzijdse relaties die verder benoemd zijn in de rollen. Als laatste moet opgemerkt worden, dat er vanuit wijkaanpak ook bewoners artikelen op de site gaan plaatsen en er daarnaast (ingelogde) bloggers en forum reageerders bijkomen. Ook die moeten als redactionele rol geidentificeerd worden. De rollen van anonieme gebruiker, forumreageerder, aanschaffer van artikelen op de site (DIGID) en decentraal redacteur van buiten de organisatie worden nadere gespecificeerd in respectievelijk het deel van het functioneel ontwerp dat zal gaan over de inlogprocedures(s) en het digitaal loket. Het front office van het digitaal loket zal verderop uitgebreid gespecificeerd worden.

2.2.1. Meten is weten

Webstatistieken worden steeds vaker gebruikt. Een paar jaar geleden kon je volstaan met eens per week een rapport over het aantal hits op de website bekijken, maar een gemiddelde website heeft nu veel meer gegevens beschikbaar: bezoekers, unieke bezoekers, bezoeken, funnels, klikpaden, binnenkomstpagina’s, etcetera. Met de komst van Google Analytics liggen voor elke website webstatistieken binnen handbereik.

Op dit moment is het voor niet-IT’ers moeilijk om in te schatten of de Deventer site wel of niet succesvol is. Door Google analytics op de site te implementeren en van tevoren doelen op de site vast te stellen, is het mogelijk om het succes van pagina’s, delen van pagina’s, portalen en digitale diensten meetbaar te maken. Niet alleen zijn web analytics zinvol voor het algemeen inzichtelijk maken van het succes van de site en delen daarvan, deze informatie kan er ook voor zorgen dat de communicatieprocessen tussen de internet redactie, aanstuurders van de internet redactie, technische beheerders/ ontwikkelaars, management, teams en afdelingen gefaciliteerd worden. Met behulp van analytics is er gekozen voor een gemeenschappelijke taal en referentiekader en is de mogelijkheid tot onderlinge verslaglegging en toetsing ontstaan. Door de ontstane mogelijkheid van gedetailleerde rapportage, kunnen per decentrale redacteur afspraken gemaak worden over te behalen doelen. Dit moeten meetbare doelen zijn, die periodiek teruggekoppeld worden door de webmaster met de decentrale webredacteur.

2.2.2 Afspraak, Analyse, Aanbeveling, Actie Afspraak 1. Uit de organisatie ontstaat een content/ functionele behoefte voor op de site. Deze content behoefte wordt via de decentrale internet redacteur becomuniceerd met de web manager, gemeenschappelijk worden meetbare doelstellingen geformuleerd voor enerzijds de te realiseren functionaliteit en anderzijds specifieke analytics statistieken en conversiedoelen die het succes van die content/ functionele behoefte meetbaar maken. Ook wordt in dit document de inspanning van de decentrale redacteur neergelegd. Deze afspraken worden vastgelegd in een wederzijds overeengekomen document. 2. De webmanager communiceert deze functionele/ content behoefte in het periodiek overleg met webmaster, webredacteur, en technisch beheerder/ ontwikkelaar. 3. De statische en dynamische content wordt aan de hand hiervan bijgewerkt door de webredacteur, aanpassingen op CSS/XHTML/Javascript/Ajax vlak door de webmaster, aanpassingen of toevoegingen op Webapplicatie niveau door de technisch beheerder. 4. Als de functionaliteit/ content opgeleverd is, moet deze goedgekeurd worden door de decentrale webredacteur in kwestie. Er wordt dan een afspraak gemaakt om de statistieken uit analytics periodiek met elkaar terug te koppelen.

Analyse Het toepassen van de statistieken wordt begonnen met het analyseren van de informatie. Wat kan uit het rapport afgeleid worden? Zijn er opvallende trends? Zijn er zaken die verbeterd zouden kunnen worden? Met deze analyse wordt analyse over verbeterpunten van de website of een specifieke actie of pagina mogelijk.

Aanbeveling Hierdoor kunnen aanbevelingen geformuleerd worden om de website te verbeteren. Zo kan bijvoorbeeld in de statistieken gezien worden, dat de zoekfunctie op de site vaak geen resultaten teruggeeft. Uit de analyse kan blijken,

dat bezoekers vaak combinaties van producten met producteigenschappen zochten, bijvoorbeeld “huisdier + belasting”. De aanbeveling kan dan zijn om de zoekmachine aan te passen om op producteigenschappen te kunnen zoeken, bijvoorbeeld “huisdieren”. Andere voorbeelden kunnen zijn dat een bepaald evenement dat in Deventer plaats zal vinden een ondergrens aan unieke hits moet krijgen, of dat er een ondergrens aan transacties van een dienst in het digitaal loket gesteld wordt.

Actie Het uitvoeren van de aanpassingen, de actie, is de laatste stap van de cirkel. Het wijzigen van de functionaliteit van de zoekmachine, het wijzigen van tekst op een pagina, het aanpassen van een menu: het zijn allemaal voorbeelden van dergelijke acties. Als zo’n actie uitgevoerd is, kunnen hiervan de resultaten weer geevalueerd worden. De cirkel van analyse, aanbeveling en actie begint op dat moment weer opnieuw. Het verbeteren van de website is dan ook een continu proces.

2.2.2 Webmanager Rollen 1. Rapporteren aan de teamleider communicatie over processen binnen de webredactie 2. Onderhouden van contact met de technische beheerders en ontwikkelaars 3. Coordinatie van de webredactie, stellen van key performance indicators met webmaster en webredacteur 4. Evalueren van deze key performance indicators 5. Coordineren van periodieke evaluaties met afdelingen 6. Stellen van conversie doelen voor afzonderlijke pagina’s, diensten of portalen op de site 7. Periodiek rapporteren van Google analytics informatie en (laten) aanpassen van de site op basis van deze informatie 8. Maken van afspraken met de decentrale redacteur over te leveren functionaliteit en bewaken van die gemaakte afspraken 9. Bijhouden van nieuwe ontwikkelingen op marketing en internet vlak en opzetten van initiatieven voor doorontwikkeling van de site 10. Vorming van nieuw beleid met betrekking tot de site

2.1.2 Content beheer (Webredacteur) Rollen 1. Het schrijven van artikelen 2. Het voeren van eindredactie op door decentrale redacteuren aangeleverde teksten. Hier moet vooral gekeken worden naar stijl en spelling, inhoudelijk zijn de redacteuren zelf eigenaar van hun content. Artikelen krijgen een status mee verbonden met hun urgentie. Status 1 moet binnen drie uur geplaatst zij, status 2 binnen een dag en status 3 binnen een week. 3. Het zijn van een ‘ambassadeur’ voor de website binnen de organisatie (EHBI) 4. Doen van nieuwsgaring (voor human interest artikelen)

5. Begeleiden van decentrale redacteuren in de dagelijkse content flow, de eindredacteur is vast aanspreekpunt voor iedereen die verbonden is met de internetredactie. 6. Voeren van overleg met initiatiefnemers voor nieuwe content binnen de organisatie 7. Bijhouden van Deventer ‘blogosphere’ (maken van rss mash ups en weergeven op de site) 8. Modereren van fora en reacties op blogs op de site De op dit moment geformuleerde taakomschrijving gekoppeld aan de rol van webredacteur sluit niet goed aan op de vereisten van een geprofessionaliseerde webredactie. De voornaamste oorzaak hiervoor is te vinden in het feit, dat de aangestelde redacteur niet schrijft, maar de taakinvulling voornamelijk vindt in het reguleren van informatiestromen binnen de organisatie en opereren op beleidsmatig en projectmatig niveau. Ook betekent het, dat de statische delen van de website niet of onvoldoende met content gevuld zijn omdat de tijdsbelasting vooral vloeit naar deze beleidsvormende taken. Om deze redenen zijn deze activiteiten dan ook verschoven naar de rol van webmanager. Om de hier gestelde rollen goed te kunnen vervullen, zijn de volgende leertrajecten noodzakelijk voor de huidige webredacteur: 1. 2. 3. 4.

Een cursus webschrijven Een cursus beeldbewerking (Fireworks CS3) Een cursus Dreamweaver Cursus vraaggestuurd werken

2.2.1.2 Decentrale redactiestructuur Hierin zijn vier rollen te onderscheiden: 1. Decentraal redacteur verbonden met een afdeling of eenheid binnen de organisatie, die aan die eenheid gerelateerde content verzamelt, schrijft en plaatst. 2. Decentraal redacteur die vanaf huis content aan de redactieflow toevoegt 3. Ingelogde en ongemodereerde blogger die direct kan plaatsen, zowel van binnenuit als vanaf huis 4. Ingelogde forum reageerder, die na zijn aanvankelijke inschrijving mt behulp van een cookie atomatisch ingelogd is op de site. Er is nog geen besluitvorming tot stand gekomen over de decentrale redactiestructuur. In de praktijk is er wel een inventarisatie hiervan te maken en is inmiddels ook een inschatting van de decentraal-redactionele inspanningen op individueel niveau gemaakt (Excel bestand beschikbaar). Het is van wezenlijk belang, om deze decentrale redactiestructuur niet alleen op MT niveau te laten bekrachtigen, maar deze ook te vertalen in de FTE definitie/ taakomschrijving van de redacteur in kwestie. Deze zullen vervolgens in de Eerst Hulp Bij Internet/Intranet samenwerking tussen IDM en de afdeling communicatie (Marja en Christiaan) geassisteerd worden.

2.1.1 Functioneel beheer (Webmaster) Rollen: 1. Functioneel beheer van de website. Onder functioneel beheer versta ik het onderhouden van de website en doorvoeren van aanpassingen op de website die op XHTML, CSS en Javascript niveau liggen. 2. Ook zoekmachine optimalisatie en cijfermatige rapportage aan de webmanager hoort bij de vaardigheden van een webmaster. Binnen Google analytics worden in de navigatiestructuur en het digitaal loket conversiedoelen ingesteld, voor elke pagina minimaal één. Op basis van de managementinformatie die uit die opzet voortkomt, moet de webmaster de navigatie van de site actief aanpassen. Als het bijvoorbeeld het doel is dat een bepaalde boodschap indringend onder de aandacht van de Deventer bevolking wordt gebracht, kan een bepaald aantal (unieke) hits als conversiedoel ingesteld worden. Als dit doel niet gehaald wordt, kan geconcludeerd worden dat de pagina op de verkeerde tekst in de navigatie staat. 3. Vanuit de gemeente in samenwerking met de webmanager coordineren van het technisch beheer en functionele doorontwikkeling van de website (in een ‘agile development’ omgeving als ruby gaan doorontwikkeling van de webapplicatie en technisch beheer hand in hand). 4. Beheren van het Front Office van het digitaal Loket Om de hier gestelde rollen goed te kunnen vervullen, zijn de volgende leertrajecten noodzakelijk voor de huidige webmaster: 1. Cursus HTML, CSS & javascript (met name de Ajax techniek, Jquery, Interface en Mootools) 2. Cursus web analytics en omgaan met cijfermatige doelstellingen (KPI’s). 3. Cursus vraaggestuurd werken

Technisch Beheer Het technisch beheer zal net als nu uitbesteed worden aan een externe partij, met een aantal belangrijke verschillen: de communicatie afdeling zal direct een SLA aangaan met de technische beheerspartij, die op een andere manier dan nu zal werken; ontwikkeling en beheer gaan hand in hand. De reden dat dit zo gebeurt, is dat er vanuit overwegingen van flexibiliteit gekozen is voor een ‘agile’ ontwikkelmethodiek. Hierop wordt uitgebreid ingegaan in het technisch ontwerp. Dit komt er kort samengevat op neer, dat nieuwe functionaliteiten door de technische beheerorganisatie constant bij ontwikkeld kunnen worden, zodat er bijvoorbaat al goed ingespeeld kan worden op onvoorziene functionele wensen van gebruikers. Omdat het niet te voorzien is welke functionaliteiten afdelingen over een paar jaar zullen wensen, is het aan te raden een beheersorganisatie op zo’n manier op te zetten, dat dit op eenvoudige wijze te realiseren is als die wens zich voordoet. Op dit moment zijn verschillende delen van de site uitgeweken naar hun eigen web adressen (bijvoorbeeld wijkaanpak), omdat er niet flexibel ingespeeld kon worden op functionele wensen.

3. Navigatie, technisch en visueel ontwerp Navigatie ontwerp Hieronder volgt het navigatie ontwerp van www.deventer.nl. De in het ontwerp gebruikte kleuren zijn niet de voorgestelde kleuren, omdat die nog bepaald moeten worden door het huisstijl bureau. Eerst zullen alle afzonderlijke elementen en doorgevoerde wijzigingen in kaart gebracht worden, vervolgens

Statisch navigatiedeel Onder ‘statische navigatie’ versta ik de niet-interactieve navigatiedelen die op iedere pagina van de site te zien zijn, bestaande uit de thans aanwezige tabbladen in de navigatie en de menustructuur die verschijnt nadat een tabblad geselecteerd is. Op dit moment worden de onderliggende links van de navigatie linksboven getoond en in het middendeel van de portaalpagina. Binnen de huidige navigatie opzet is er gekozen voor een menu structuur onder de tabbladen, zodat de samenhang beter zichtbaar wordt. Ook zijn de ‘alt’ teksten bij de links aangepast en ingekort, zodat de site toegankelijk is voor slechtzienden en blinden en daarnaast hoger scoort bij advies.overheid.nl .

Tabbladen Door te kiezen voor een zuivere CSS tabblad structuur, is de webmaster in staat om de tabblad navigatie op eenvoudig wijze aan te passen. Omdat plaatjes elementen op deze manier vermeden zijn, is de navigatie volledig toegankelijk gemaakt voor alle zoekmachines.

Wijzigingen:

Bijzonderheden

‘Bezoekers’

voor het bezoekersdeel wordt een afzonderlijk linkblok aangemaakt aan de linkerkant van de driekoloms navigatie

‘Bestuursinformatie’

het deel bestuursinformatie is ten dele opgegaan in het deel ‘Stadhuis’ en ten dele in het deel Gemeenteraad

(ctrl)

Klik Hier

Voor een live demonstratie van de tabbladen

Bewoners

Wijzigingen:

Bijzonderheden:

‘Werk & Inkomen’

uit loketten>> stadhuis naar bewoners verplaatst

‘Zorg & Welzijn’

uit onderste navigatie naar boven gehaald

‘Woningen & Wijken’

een noemer om ‘Wijkaanpak’ en ‘Woningen en Wijkvernieuwing’ onder te vangen

‘Leefomgeving’

Hoger in de navigatie geplaatst

‘Accomodaties & Voorzieningen’

uit onderste navigatie naar boven gehaald

‘Leven in de Stad’

verwijderd

‘Onderwijs’, ‘Cultuur’ en ‘Nieuwbouw’

Uit onderste navigatie naar boven gehaald.

Woningen & Wijken

Wijzigingen

Bijzonderheden

‘Woningen & Wijken’

een noemer om ‘Wijkaanpak’ en ‘Woningen en Wijkvernieuwing’ onder te vangen

Wijkaanpak

Wijzigingen

Bijzonderheden

‘Wijkaanpak algemeen’

Van onderen naar boven gehaald. Introductie hoort altijd bovenaan

Leefomgeving

Wijzigingen Volgorde op relevantie aangepast

Dorpen (was eerder: “Leven in de dorpen”)

Wijzigingen Volgorde aangepast: Diepeveen en Lettele zijn dorpen, platteland is een algemener thema

Bedrijven

Wijzigingen Geen wijzigingen

Vestigingslocaties

Wijzigingen Geen wijzigingen

Gemeenteraad

Wijzigingen

Bijzonderheden

Voor en door de Raad

Uit deel ‘Bestuursinformatie’ gehaald, dat deel is verwijderd uit tabblad navigatie.

Verordeningen

Uit deel ‘Bestuursinformatie’ gehaald, dat deel is verwijderd uit tabblad navigatie. Terug naar stadhuis

Stadhuis

Wijzigingen

Bijzonderheden

Burgerzaken

Naar boven gehaald uit ‘loketten’

Bestuursinformatie

Nieuwe categorie

Routebeschrijving

Naar stadhuis verplaatst, mensen zoeken immers de weg naar het stadhuis

Trouwen in Deventer, Onderscheidingen en Guldenboek

Verplaatst van ‘bewoners’naar ‘Stadhuis

Bestuursinformatie

Wijzigingen

Bijzonderheden

Organisatie

Naar boven gehaald uit ‘loketten’

Stadsinformatie

Nieuwe categorie

Inspraak & Klachten

Naar stadhuis verplaatst, mensen zoeken immers de weg naar het stadhuis

Bekendmakingen

Verplaatst van ‘bewoners’ naar ‘Stadhuis

Bezuinigingen

Een niveau naar onderen verplaatst

Loket

Wijzigingen

Bijzonderheden

Digitaal Loket

In samenspraak met henk Plomp en IDM is overeengekomen, dat

Tag Cloud

n.b. subnavigatiedelen die in bovenstaand overzicht niet voorkomen, zijn hetzelfde gebleven.

Onder de tabblad navigatie zal een alternatieve navigatie aangeboden worden, die gebaseerd is op gebruik in plaats van lineaire hierarchie. Redacteuren voeren bij elk te plaatsen artikel tags in. Tags die de meeste unieke hits krijgen worden groot weergegeven, hoe minder hits hoe kleiner de tekstlink die verschijnt. Als een van de links aangeklikt wordt, verschijnt een pagina met alle pageviews die dat tag hebben meegekregen.

Driekoloms structuur Gekozen wordt voor een gecentreerde driekoloms structuur, die uit CSS opgebouwd is (en niet uit tabellen of frames). Daarnaast moet het middendeel van de pagina een absolute breedte hebben, nu is het middendeel relatief aan de grootte van het beeldscherm, wat een lelijk effect kan geven.

Statische tekstblokken met dynamische content Hiermee worden linkblokken bedoeld, die een vaste plek hebben op alle pagina’s van de website, maar waarvan de inhoud periodiek wisselt of interactief is. Vanuit vastgestelde KPI’s worden links uit de navigatieboom naar boven getild, om extra prominent weer te kunnen geven. Nu komen zulke blokken alleen op de voorpagina voor, maar deze vaste linkblokken zullen in de nieuwe navigatiestructuur op alle plekken te zien zijn. Voor de volgende content worden linkblokken aan de linker- en rechterkant van de navigatie vrijgemaakt: 1. Subnavigatie pageviews die meer aandacht moeten krijgen (denk aan WMO, speciale projecten, of ‘Heidema’s zomer’) 2. Een nieuwsblok waarin RSS feeds van diverse media geaggregeerd worden 3. De navigatie uit het deel ‘bezoekers’ van de huidige site 4. Een blok met plaatjeslinks die voeren naar pagina’s die onder de aandacht gebracht kunnen worden (denk bijvoorbeeld aan digid) 5. Een op javascript gebaseerd inlogblokje voor toegang tot de fora en andere functionaliteiten op de site 6. Een blokje dat de laatste reacties uit de fora toont 7. (eventueel) een blokje dat leidt naar chat funtionaliteit. Ook deze tekstblokken zullen 100% CSS zijn, gebruikmakend van de techniek zoals weergegeven op http://www.roundedcornr.com/. Door gebruik te maken van deze techniek, kan er gevarieerd worden met de weergave van de linkblokken, die zeer eenvousig aangepast kunne worden. Dit zorgt voor een levendig ogende pagina.

Middendeel Het middendeel krijgt een absolute breedte en zal niet meetrekken met de breedte van het beeldscherm. In dt deel wordt de inhoud van de individuele pageview weergegeven

Javascripts en Ajax: Jquery, Interface en Mootools Een van de grote voordelen van inzet van Ruby on Rails is, dat gebruik van Ajax en javascripts ingebakken zitten in het systeem. Standaard wordt de script.a.culo.us bibliotheek ingezet, maar Jquery begint in toenemende mate de standaard te worden binnen een Ruby omgeving. Vroeger was inzet van javascripts ongewenst, omdat dat de site ontoegankelijk zou maken voor veel gebruikers. Door Javascript effecten ‘degradable’ te maken, is deze kritiek gelukkig niet meer van toepassing. Mootools is zo goed in elkaar gezet, dat het zelfs door de officiele W3C site (bewaker van standaarden op het web). Ook de andere Voor verschillende visuele effecten en ook functionaliteit in de site (zoals een inlog en uitwisseling van XML via JSON) kan javascript worden ingezet en ook voor interactiviteiten, die het gebruik vereenvoudigen. De lijst van mogelijke interactiviteiten is zeer groot: http://jquery.com/plugins/project/Plugins/name http://ui.jquery.com/

Een goed voorbeeld hiervan is de ‘shopping cart’ zoals die in interface gevonden kan worden: http://interface.eyecon.ro/demos/cart.html

De gebruiker hoeft een product slechts aan te klikken en de rekensom wordt automatisch aan de rechterkant germaakt, vervolgens kan er met een druk op de knop tot aanschaf overgegaan worden. deze bestelling word vervolgens doorgegeven aan het mid office van het digitaal loket. Een ander bruikbaar voorbeeld is de weergave van afbeeldingen. Hieronder het caroussel voorbeeld, waarmee afbeeldingen mooi gepresenteerd kunnen worden: http://interface.eyecon.ro/demos/carousel.html Als een afbeelding aangeklikt wordt, vergroot deze vervolgens bovenop de pagina, terwijl de achtergrond verduisterd wordt:

Functionele brokken Beredeneerd vanuit de route 2010, wensen van de raad en afzonderlijke afdelingen, moeten de volgende functionaliteiten gerealiseerd worden: • • • • • • • • •

•

•

• • • • • • • •

• • •

Fora , reactie- en chat opties, die informatie produceren net zo makkelijk maken als consumeren. De mogelijkheid om fora en blogs automatisch naar bepaalde gebruikers door te sluizen Een formulier dat decentrale redacteuren van zowel binnen als buiten de organisatie in staat stelt content toe te voegen aan de content flow van de webredacteur Blog tools met reactiemogelijkheid Een captcha tool om reageerders te verifieren Reageer optie die het mogelijk maakt dat ‘stalkende’ reageerders hun eigen reactie wel geplaatst zien, maar de rest van het internet niet en van alle reageerders het ip adres vastleggen Sociale netwerk tools die gebruikers in de gelegenheid stellen elkaar te informeren. Nieuwspagina’s die burgers in staat stellen zelf journalistiek te bedrijven. Op Wikipedia gebaseerde websites (zg ‘wikis’) die gebruikers in staat stellen kennis met betrekking tot een bepaald onderwerp te verzamelen. Deze zullen de plaats innemen van de ‘faq’ pagina’s en ontstaan vanuit een samenwerking tussen burger en ambtenaar Ontwikkeling van een goede zoekfunctie. Hiervoor zijn drie oplossingsrichtingen te geven: gebruik maken van Google search (gratis), de uitgebreide functionaiteit van de SharePoint search inzetten die binnenshuis al aanwezig is met de site integreren, of een search applicatie aankopen. (Bijvoorbeeld Convera). Monitoren van bezoekers: Na enige tijd overwogen te hebben om gebruik te maken van Nedstat, is er toch besloten om Google Analytics met de site te integreren. Deze is inmiddels in werking. RSS Feeds: Alle blogs, nieuwsoverzichten, portalen en andere overzichtspagina’s moeten hun eigen RSS feed meekrijgen RSS reader: Ook moet het mogelijk zijn om rss feeds uit verschillende bronnen Video en audio opties Een nieuwsbrief systeem Een kalender met agenda Search tool Een goed ogend Geografisch Informatie Systeem Een front office/webwinkel die gebruikt maakt van visuele effecten zoals die beschikbaar gemaakt zijn in Jquery, om een angename gebruikerservaring te realiseren Een binnen het CMS beschikbaar gemaakt rapportagetool, dat op Google analytics gebaseerde informatie beschikbaar maakt Een bij voorkeur met elkaar geintegreerde inlogprocedure voor het DIGID (loket) en de rest van de site (fora, blogs, burgejournalisten etc) De mogeljkheid van persoonlijke profielpagina’s voor burgers, bestuurders, politici en ambtenaren.

4.2

Technisch ontwerp

De technische ontwikkelaar moet ervoor zorgen dat zijn ingezette technologie zo volledig mogelijk gedocumenteerd wordt, zodat er geen sprake is van een afhankelijkheidsrelatie met de systeem ontwikkelaar. Daarnaast moet deze zoveel mogelijk gebruik maken van bestaande technologieen, zodat zijn werk reproduceerbaar is. In samenspraak met de ontwikkelaar zullen tijdlijnen goed afgestemd worden, maar doelstelling is om de website voor de jaarwisseling in de lucht te hebben. De ontwikkelaars zullen ook zorg dragen voor het technisch beheer van de site.

4.2.1. Methoden en Technieken; randvoorwaarden Om aan de strenge eisen te voldoen waaraan overheden tegemoet moeten komen om hoog te scoren op advies.overheid.nl een van de basisvoorwaarden om, te voldoen aan het het geambieerde predikaat ‘excellente dienstverlener en dit ook goed samen te laten vallen met de diverse behoeftes van de organisatie, moet in het ontwikkeltraject aan een aantal randvoorwaarden voldaan worden:

1. Drempelvrije webontwikkeling De website van de Gemeente Deventer dient open te staan voor een heterogene groep van gebruikers, inclusief slechtzienden of mensen met een andere handicap. Om dit mogelijk te maken moeten webpagina’s semantisch en 100% conform de volgende richtlijnen ontwikkeld worden: • •

Kwaliteitsregeling Webrichtlijnen WCAG (Web Content Accessibility Guidelines) Conformance Level “Double-A”: Priority 1, 2

De gemeente Deventer moet het voorrecht kunnen genieten, om de W3C keurmerken voor XHTML, CSS en print te kunnen dragen. N.B. De inhoud in het Microsoft SharePoint mid-office moet evenzo drempelvrij weer te geven zijn, wil de website daadwerkelijk het predikaat ‘drempelvrij’ kunnen verdienen. Op dit vlak is MOSS 2007 niet onproblematisch. De verantwoordelijkheid hiervoor ligt deels bij de technisch beheerder/ ontwikkelaar voor het juist weergeven van documenten en deels bij de afdeling IDM voor het correct vanuit het midoffice

doorgeven van deze content (decentrale redactiestructuur en digitaal loket). Geinventariseerd moet worden

2. Synchronisatie met Microsoft SharePoint De inhoud van de website van Gemeente Deventer zal worden opgeroepen uit het Microsoft SharePoint midoffice en met regelmatige tussenpozen automatisch worden gesynchroniseerd. Tijdens deze synchronisatie wordt de nieuwste inhoud opgehaald in XML formaat door middel van enterprise service integratie en lokaal opgeslagen voor gebruik op de website. Deze techniek is sneller, robuuster en efficiënter dan het real-time ophalen van de inhoud, doordat niet continu verbindingen gelegd hoeven te worden. Dit voorkomt wachttijden en onnodig gebruik van bandbreedte. 3.

Semantische web ontwikkeling Hieronder wordt verstaan, dat naast gebruik van open standaarden an sich, ook de best practices voor inzet van die open standaarden toegepast worden, waardoor deze zo optimaal mogelijk gebruikt worden. Door hier goed invulling aan te geven, kan de website hoog scoren in de ranglijst van gemeentelijke websites. Hieronder valt bijvoorbeeld een ‘best practice’ als de strikte scheiding van layout en opmaak, door geen opmaak op de nemen in de XHTML. Hiermee wordt het volgende bereikt: • • • • • •

1.

Verbetering van de toegankelijkheid van de site voor slechtzienden en anderen met een functionele handicap Eenvoudiger onderhoud en wijzigingen aan pagina´s op alle navigatie niveau´s Verbeterde performance omdat alle opmaak cacheable gemaakt is De optie om pagina´s te personaliseren door middel van thema´s wordt zo mogelijk Makkelijke uitvoer van testst om te controleren dat de site er identiek uitziet in alle browsers, in ieder geval Explorer, Firefox, Opera en Safari. Alle javascript effecten moeten ‘degradable’ geimplementeerd worden. Bij de implementatie van interactieve elementen en visuele effecten is vaak specifieke functionaliteit vereist in de browser van de gebruiker. Als de gebruiker deze functionaliteit niet ter beschikking heeft bijvoorbeeld vanwege een handicap, uit veiligheidsoverwegingen, of vanwege een verouderde browser, dan moet de functionaliteit op de pagina onverminderd blijven werken.

Flexibele softwareontwikkeling (agile development): Om maximaal in te kunnen spelen op de behoeftes van de organisatie, is het raadzaam om volgens een zo flexibel mogelijke methodiek te ontwikkelen en beheren. Vanuit het beheersperspectief is dat al kort aangestipt, maar hier is het van belang om dit verder uit te werken. Omdat er sprake moet zijn van een structuur die ook in kan spelen op nu nog onvoorziene functionele behoeftes en ook om vanuit de gemeentelijke organisatie voldoende grip te hebben op het ontwikkeltraject, is het van belang om voor de ontwikkelaar zg. ‘iteraties’ te benoemen ofwel mijlpalen, zowel voor de technische ontwikkeling, als voor het technisch beheertraject daarna.

Iedere mijlpaal bevat een nieuw component. Bovendien is iedere dag de nieuwste versie van de software te gebruiken; de zogenaamde ‘interim release’. Deze regelmatige cyclus heeft als voordeel dat het ontwikkelingsproces bijgestuurd kan worden terwijl het evolueert. De mogelijkheid om direct feedback te kunnen leveren biedt een belangrijk voordeel, namelijk de garantie dat de website exact naar wens wordt ook als tussentijds functionele eisen veranderen of nieuwe ideeën ontstaan. Terwijl de website wordt ontwikkeld, kan Gemeente Deventer dagelijks feedback leveren, prioriteiten verschuiven, functionele eisen wijzigen en de projectvoortgang bewaken. 2.

Testgestuurde ontwikkeling (test driven development): Door de leverancier moet bij voorbaat de garantie gegeven worden, dat per iteratie geleverde componenten stabiel zijn en werken. Binnen een agile development omgeving wordt dit bereikt en goed geborgd, door op basis van tests te ontwikkelen. Dit betekent dat er eerst een test geschreven wordt die een te bouwen component moet halen en er vervolgens code geschreven wordt die die test moet kunnen halen. Dit is een zeer puristische ontwikkelmethodiek, die robuuste functionaliteit garandeert. De offrerende partij moet daarnaast ook inzichtelijk kunnen maken, hoe ze hun testgedreven model ingericht hebben. Zo wordt ook de transparantie van het ontwikkeltraject voor de gemeente Deventer gegarandeerd. Bovenstaande methodieken zijn het optimaalst toe te passen binnen een Ruby on Rails omgeving, maar in zekere zin ook mogelijk binnen bijvoorbeeld asp.net.

3.

Enterprise Service Integratie. Hieronder wordt het aan elkaar koppelen van verschillende gegevensbronnen bedoeld. Dit wordt bereikt, door te ontwerpen volgens de regels van Service Oriented Architecture. Deze benadering heeft twee belangrijke voordelen voor de gemeente Deventer: •

•

4.

De inhoud van de Gemeente Deventer website kan naadloos worden uitgelezen en gesynchroniseerd met de inhoud van het Microsoft SharePoint mid-office. Microsoft SharePoint Server 2007 in het bijzonder bevat uitstekende mogelijkheden voor datauitwisseling volgens de open en de facto XML standaard. Het gebruik van open standaarden en Service Oriented Architecture garandeert dat de website ook in de toekomst gereed is om met minimale inspanning data uit te wisselen met externe systemen.

Open standaarden Het te ontwikkelen systeem moet volledig beantwoorden aan open standaarden voor opmaak, layout en data uitwisseling. Het is de bedoeling dat er op dit vlak tegemoet gekomen wordt aan ontwikkelingsrichtlijnen voor software die per april 2008 verplicht gesteld zijn voor overheden. Daarnaast maakt gebruik van open standaarden enterprise service integration mogelijk en verzekert dat de website van de Gemeente Deventer nu en in de toekomst naadloos kan aansluiten op externe databronnen, onafhankelijk van de vraag welke technologie in de toekomst ingezet gaat worden.

Specifiek gaat het hier om de volgende open standaarden:

Standaard CSS (Cascading Stylesheets)

voor opmaak van webpagina’s

REST (Representational State Transfer)

voor datauitwisseling via het web

SOAP

voor datauitwisseling via web services

XHTML (Extensible HyperText Markup Language)

voor de layout van webpagina’s

XML (Extensible Markup Language)

voor datauitwisseling, inclusief:

XPath (XML Path Language) en XQuery

voor het uitlezen van XML data

XSLT (Extensible Stylesheet Language Transformations)

voor het manipuleren van XML data

Bovenstaande punten bieden Gemeente Deventer de mogelijkheid om een heterogene groep van gebruikers te bedienen.

2.2

Ruby on Rails

Het is op deze plek van belang, om wat langer stil te staan bij de gekozen ontwikkelomgeving, en die verder te onderbouwen. Ruby on Rails is een ontwikkelomgeving die veel sneller dan normaal complexe web 2.0 functionaliteiten ‘op de rails’ kan zetten. Om die reden is hij zeer geschikt om in te zetten op de Deventer website. Het betekent minder inspanning en een kortere doorlooptijd om een CMS te realiseren dat flexibeler kan functioneren dan standaard functionaliteiten. Bovendien is het een omgeving waarbinnen aan alle hierboven genoemde methoden en technieken mogelijk zijn. Ruby on Rails is een open source framework voor het ontwikkelen van webapplicaties. Het bestaat uit twee delen: de in 1993 ontwikkelde taal Ruby en het raamwerk waarin ermee gewerkt wordt, de zg. ‘rails’. Ruby on Rails is een implementatie van de Model-ViewController architectuur (object georiënteerd programmeren), wat zorgt voor een scheiding van business logica, presentatie en interactie met de gebruiker. Bijkomende eigenschap is dat zoveel mogelijk (tijdrovende) configuratie-opties weggelaten worden. Zo volgt in tegenstelling tot Sharepoint (.net applicaties) de mapping tussen database, objecten en interface een serie intuïtieve regels, en wordt slechts expliciet als er van die conventies wordt afgeweken. Samen met een aantal ingebouwde generatoren voor het snel bouwen van prototypes (z.g. ‘gems’), maakt dat de omgeving uitstekend voor Rapid Application Development en "agile" technologieën.

Los daarvan is Ruby on Rails uitstekend in staat via XML uit te wisselen met Sharepoint 2007 en is het zeer flexibel. Het is daarom dan ook de voorkeurstaal die toegepast word in typische web 2.0 applicaties, wat als bijkomend voordeel heeft dat de standaard bibliotheken van Rails functionaliteiten, de Rubygems , zeer uitgebreid zijn en veel sneller groeien dan .net functionaliteiten.

Made in Ruby on Rails

Sharepoint Met behulp van XML moeten twee belangrijke links naar de site toe worden gelegd: decentrale redacteuren maken nog steeds gebruik van Sharepoint zoals ze al gewend waren, maar als ze een artikel plaatsen wordt de gegenereerde XML aangeboden aan het centrale beheerssysteem. Daarnaast zal in de webapplicatie ruimte vrijgemaakt worden voor het digitaal loket. Het achterliggende midoffice zal eveneens aangestuurd worden door Sharepoint.

Waarom Ruby on Rails en niet Sharepoint? Allereerst is het van belang om aan te geven, dat de werkelijke keuze hier ligt tussen asp.net en Ruby on Rails. En zelfs dat is geen werkelijke keuze, want een dynamische taal als Ruby is volledig te integreren met asp.net met behulp van de dynamic language runtime. Ook is het gewoon mogelijk om een Ruby on Rails applicatie op een IIS server te installeren (de sharepoint ‘eigen’ server). Asp.net zelf draait op de zogenaamde common language runtime en kan dynamische talen gelijktijdig, in dezelfde machine

draaien. Begin 2008 kunnen overigens in Ruby on Rails ontwikkelde functionaliteiten geconverteerd worden in webparts, met behulp van Ironruby. Dit maakt dan deel uit van de Microsoft ‘Silverlight’ omgeving, het platform dat Microsoft biedt voor de ontwikkeling van ‘Rich Internet Applications’, waarvan de te bouwen website van de gemeente Deventer een goed voorbeeld is. Vooral dat laatste gegeven maakt een discussie over de keus tussen Sharepoint of Ruby on rails niet relevant. Op mijn blog ga ik daar dieper op in. Toch zijn er verschillende redenen te noemen, waarom er niet in de eerste instantie ontwikkeld moet worden in Sharepoint, maar in Ruby on Rails. Deze redenen zijn budgettair van aard, en hangen daarnaast samen met het te bewandelen tijdpad, de benodigde flexibiliteit die de webredactie moet betrachten in de richting van andere afdelingen, beschikbare functionaliteiten en beheersbaarheid van de applicatie.

Budget: Als je in Sharepoint een site zou bouwen zou je veel meer geld dan de op dit moment geoffreerde 40.000 euro kwijt zijn. Een indicatie is de thans voorliggende offerte van MACAW, die voor een handjevol diensten een offerte van 170.000 euro heeft liggen.

Tijdpad: Ook is, (de ontwikkelmethode van Ruby on Rails wordt 'agile web development' genoemd, hierover staat meer onder het deel ‘technisch beheer’ hierboven), het tijdpad om die functionaliteiten te bouwen, gemiddeld drie keer korter dan een ontwikkeltraject in Sharepoint. Er ligt bij Deventer extra druk op dit tijdspad, omdat de griffie van de gemeenteraad te horen heeft gekregen dat ze eind oktober hun website af moeten hebben. De afdeling IDM blokkeerde de griffie in dat streven, omdat het verstandiger zou zijn te wachten tot sharepoint 2007 zou zijn geimplementeerd en migratie van 2003 naar 2007 te ingewikkeld zou zijn.

Functionele eisen: Een belangrijke functionele eis is dat de site interactiever (web 2.0 geschikt) moet worden. Ruby on Rails is de taal bij uitstek, om in te zetten op meer interactiviteit. Wat eigenlijk nodig is om het predikaat 'excellente dienstverlener' te verdienen, is een zg. 'rich internet application'. Microsoft heeft wel een pakket om zo'n Rich Internet Application te bouwen, dat heet 'Silverlight' (en niet Sharepoint). Het is niet vebazingwekkend dat de meerwaarde van Silverlight met name bestaat uit de mogelijkheid tot integratie van dynamische talen met het asp.net raamwerk. Daarnaast moet er sprake zijn van een webapplicatie, die op makkelijke wijze ook kan voorzien in thans nog onvoorziene functionaliteiten. De webredactie staat, omdat het zeer uiteenlopende afdelingen poogt te bedienen, in een complex krachtenveld van functionele wensen van uiteenlopende afdelingen, waarop het flexibel in moet kunnen spelen. Sharepoint zal niet tegemoet kunnen komen aan die eis, omdat de hoeveelheid potentieel beschikbare functionaliteiten daarvoor te beperkt is. Het is dan ook van huis uit helemaal geen web content management systeem, maar een Enterprise content management systeem. Dat betekent dat de wat interactievere webparts in sharepoint met name gericht zijn op interne werkprocessen.

Technische eisen: Ook is Sharepoint opgebouwd uit voor een redacteur of webmaster maar moeilijk aan te passen templates en webparts. Dat betekent, dat een eens

gebouwde site onvoldoende flexibel aan nieuwe eisen aangepast kan worden, in de praktijk zullen er daarom maar weinig wijzigingen mogelijk zijn . Een goed op de toekomst toegeruste site bergt de mogelijkheid in zich om constant aangepast te kunnen worden op alle niveau’s, dat is in een Sharepoint omgeving een veel bewerkelijker traject. Als er voor sharepoint gekozen wordt is de site 'in steen gehouwen' en dat sluit niet aan op de eis van flexibiliteit. Dan blijft de site in wezen hetzelfde, tot er weer een nieuwe gebouwd wordt. Een paar jaar geleden kon dat nog, maar tegenwoordig is dat geen optie meer.

Aansluiting: Op het hoogste niveau genereert Sharepoint 'XML' en die kan zonder enig probleem vervolgens opgepikt worden door Ruby on Rails. Er is dus helemaal geen sprake van een slechte aansluiting. Bovendien kunnen begin volgend jaar in Ruby on Rails ontwikkelde functionaliteiten met behulp van 'Ironruby' geconverteerd worden naar sharepoint, vanaf dat moment zijn ruby functionaliteiten integraal onderdeel van Sharepoint.

4.3

Visueel ontwerp

Op het moment is het nog niet mogelijk om het visueel ontwerp verder uit te werken, omdat er gewerkt wordt aan de totstandkoming van de huisstijl. het huisstijl bureau krijgt wel een briefing mee. Visuele wensen en eisen voor de website zijn: ~ ~ ~ ~ ~ ~ ~

stramien voor opmaak webpagina’s, waarbij gebruik gemaakt wordt van stylesheets (CSS) menu’s: een hoofdniveau en daaronder twee subniveaus, waarbij de niveaus door kleur(tinten) onderling goed te onderscheiden zijn dat bij navigatie de keuzeoptie bij voorkeur donkerder van ondergrondkleur wordt de tekst goed contrast heeft met de ondergrond en een onderscheid wordt gemaakt tussen actieve en passieve tekst. De actieve tekst geeft door kleurverandering de keuze aan. mogelijkheid om tekst groter weer te geven (voor slechtzienden) vormgeving digitale formulieren met aankruismogelijkheden, invulvelden en navigatie-elementen verwijzen naar functionaliteiten zoals bijvoorbeeld het printen van de pagina

Aangeleverd dient te worden enkele voorbeeldpagina’s (waaronder de homepagina en een pagina van de gemeenteraad), in normale tekstgrootte en met grote letter, waarna stylesheets ontwikkeld kunnen worden. Hieronder een voorbeeld van een compleet op CSS code gebaseerd menu.

4.4; Tijdspad

Duur

Aanvang

Wie

Rollen en processen op internetredactie evalueren

Taak

31 dagen

20-7-2007

Jeroen Hoogeweij

Voltooid



Decentrale redactiestructuur evalueren

31 dagen

20-7-2007

Jeroen Hoogeweij



Beheersorganisatie evalueren

31 dagen

20-07-2007

Jeroen Hoogeweij



Niet ingevulde site onderdelen invullen

20 dagen

6-8-2007

Ike Nagelkerke

 0%

Statische content bijwerken en andere op de site ontbrekende inhoud

30 dagen

6-8-2007

Ike Nagelkerke, decentrale redacteuren

Technisch ontwerp

46 dagen

6-8-2007

Jeroen Hoogeweij



Functionele wensen afdelingen en teams inventariseren

50 dagen

20-8-2007

Jeroen Hoogeweij, Ike Nagelkerke

 50%

Evaluaties en inventarisaties communiceren

70 dagen

31-8-2007

IDM, Griffie, Susan vd Zwaag, Gosse Hiemstra, webredactie, Henk Plomp, Jeroen Hoogeweij



 30% 70%

Visueel ontwerp

31 dagen

3-9-2007

Jeroen Hoogeweij, Susan vd Zwaag



Functioneel ontwerp

26 dagen

3-9-2007

Jeroen Hoogeweij

70%

Aanbesteding ontwikkelaar

26 dagen

3-9-2007

Jeroen Hoogeweij, Susan vd Zwaag, IDM, Martijn Heijtbrink

Alt tags in pagina's bijwerken

25 dagen

1-10-2007

Ike Nagelkerke

Communiceren plan met MT, besluitvorming

6 dagen

9-10-2007

MT, Susan vd Zwaag, IDM, Wim de Jong, Jeroen Hoogeweij

Aanpassen plan aan de hand van uitkomst besluitvorming

12 dagen

16-10-2007

Jeroen Hoogeweij

25%

 25%  0%

 

Terugkoppelen van individuele invulling sites met de teams

11 dagen

Bouwen www.deventer.nl door ontwikkelaar

50 dagen

23-10-2007

Web ontwikkelaar



Aanvang training CSS + XHTML voor webmaster

41 dagen

5-11-2007

Chris Breman, trainer

 10%

Aanvang training webschrijven en beeldbewerking voor redacteur

41 dagen

5-11-2007

Ike Nagelkerke, trainer

 10%

Aansluiten van webapplicatie op Mid Office van Sharepoint (XML)

10 dagen

8-11-2007

Web ontwikkelaar, IDM, jeroen Hoogeweij



Contentmigratie

6 dagen

Web ontwikkelaar, Ike Nagelkerke, MACAW, Jeroen Hoogeweij



Christiaan Wuijts;Marja Beumer

 10%

Web ontwikkelaar, Jeroen Hoogeweij, externe tester

 

Instructie van decentrale redacteuren door EHBI

Parallel draaien en testen van site

35 dagen

11 dagen

22-10-2007

16-11-2007

23-11-2007

4-1-2008

Jeroen Hoogeweij;Ike Nagelkerke

Plaatsen van conversiedoelen op pagina’s, deelpagina’s en diensten

7 dagen

10-1-2008

Chris Breman, Jeroen Hoogeweij

Site live

5 dagen

21-1-2008

Web ontwikkelaar

 25%



5. Implementatie en Acceptatie