De Interactieve Kerk

Informatica — Universiteit van Amsterdam Informatica — Universiteit van Amsterdam

Bachelor Informatica

De Interactieve Kerk Micha Kroes

17 juni 2011

Begeleiders: Dick van Albada (UvA), Jurjen van Houwelingen (Gopublic)

2

Samenvatting Kerken laten op dit moment veel liggen op het gebied van internet en interactiviteit. Dit terwijl hier wel behoefte aan is. In deze scriptie zal er een web based maatoplossing voor kerken worden ontwikkeld en gepresenteerd die probeert in deze behoefte te voorzien. Dit project wordt voor Gopublic, een internet- en webdesignbureau, ontwikkeld. Deze web based maatoplossing zal uit een publiek deel en een intern deel bestaan. Het interne deel is een aparte module met een beveiligde omgeving voor leden waar zij eenvoudig bestanden, activiteiten en berichten kunnen uitwisselen. Deze scriptie zal zich vooral richten op de technische uitwerking van dit interne deel. Hiervoor zal eerst een functioneel ontwerp worden gemaakt. Dat wordt uitgewerkt tot een technisch ontwerp en dan volgt de implementatie.

2

Inhoudsopgave 1 Inleiding 1.1 De Interactieve Kerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Over Gopublic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Probleemomschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Opdrachtomschrijving 2.1 Doelgroep . . . . . . 2.2 Functionaliteiten . . 2.2.1 Groepen . . . 2.2.2 Leden . . . . 2.2.3 Profiel . . . . 2.2.4 Rechten . . . 2.2.5 Instellingen . 2.2.6 Meertaligheid 2.3 Conceptueel Model .

4 5 6 6

. . . . . . . . .

7 9 9 9 9 10 10 11 11 11

3 Functioneel ontwerp 3.1 Wireframes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Toelichting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 13 13

4 Technisch ontwerp 4.1 Patterns . . . . . . . . . . . . 4.1.1 Model View Controller 4.1.2 Active record . . . . . 4.2 Database design . . . . . . . 4.2.1 ERD . . . . . . . . . . 4.3 Golive CMS . . . . . . . . . . 4.4 Module . . . . . . . . . . . .

. . . . . Pattern . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

15 17 17 18 18 18 19 20

5 Implementatie 5.1 Database . . . . . . . . . . . 5.1.1 Uitbreidingen . . . . . 5.1.2 Basis . . . . . . . . . . 5.2 Beveiliging . . . . . . . . . . 5.3 Performance . . . . . . . . . . 5.3.1 Server-side . . . . . . 5.3.2 Frontend Performance 5.4 Ontwerp . . . . . . . . . . . . 5.4.1 Kleuren . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

21 23 23 23 23 24 24 25 27 27

6 Future work 6.1 Sociale Media . 6.2 Faciliteiten . . 6.3 Schaalbaarheid 6.4 Onderhoud . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

29 31 31 31 31

. . . .

. . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

7 Conclusie

32

8 Bibliografie

33

3

4

HOOFDSTUK 1

Inleiding Op dit moment laten kerken nog veel liggen op het gebied van internet en interactiviteit. Veel kerken hebben niet de technische mogelijkheid om hun leden meer te betrekken op dit gebied. Interactie is juist voor kerken belangrijk en hier is dan ook behoefte aan een oplossing wat meer biedt dan alleen maar een website of een forum. Juist kerken hebben behoefte aan een totaaloplossing waarbij de website niet slechts een visitekaartje is met hun naam maar een online communicatieplatform waarbij de website wordt gebruikt als kern voor alle media en interactie. Hier wordt er een webbased oplossing genaamd ’De Interactieve Kerk’ gepresenteerd. Deze maatoplossing is in opdracht van Gopublic ontwikkeld. Daarom volgt eerst een korte inleiding over wat Gopublic is en waarom de oplossing wordt ontwikkeld.

1.1 De Interactieve Kerk Dit jaar is Gopublic begonnen met een nieuw maatproduct: De Interactieve Kerk[7]. Deze oplossing is bedoeld om kerken te helpen het internet interactief in te zetten en de website te zien als een interactief communicatieplatform[16]. Juist kerken hebben echter specifieke behoeftes als het gaat om een website. Het is bijvoorbeeld belangrijk om een blog bij te kunnen houden of nieuwsberichten waarbij leden ook kunnen reageren. Een andere veelgenoemde behoefte is om nieuwsbrieven te kunnen versturen waar leden zich op kunnen inschrijven. Over het algemeen houden kerken wekelijks een bijeenkomst waar ook lezingen worden gehouden. Vaak willen leden die hier niet bij kunnen zijn dit terug kunnen luisteren of eventuele extra bestanden bekijken. Ook wordt hier vaak gebruikt gemaakt van thema’s waar op dat moment aandacht aan wordt besteed. Voor deze specifieke vraag zijn al reeds een aantal modules ontwikkeld. Deze zijn op het moment: • Prekenmodule Beheert en toont preken en hun series.

• Slideshow module Beheert een of meerdere slideshows met afbeeldingen en beschrijvingen

• Blog/nieuws module Om nieuws en blogberichten te beheren en te plaatsen

• Thema module Voor het beheren van thema’s(afbeeldingen) die ook kunnen worden gekoppeld aan een pagina.

• HTML Nieuwsbrief module (dubbel opt-in) Verstuur nieuwsbrieven en vul deze met de inhoud van de website

• Content en structuurmanager Hiermee kunnen de teksten en menu’s worden beheerd

• Uitgebreide kalender module Hiermee kunnen activiteiten worden gepland en deze kunnen worden gekoppeld aan content van de website

• Inschrijfmodule Inschrijven voor de nieuwsbrief van de website • Statistieken Uitgebreide gebruikersstatistieken door middel van Google Analytics.

• Fotoalbums Hiermee kunnen fotoalbums en foto’s aangemaakt en beheerd worden.

Deze modules voldoen nog niet geheel aan de behoeftes voor kerken. Veel kerken willen graag meer hun leden betrekken bij de verschillende activiteiten.[15] Vaak is het zo dat een kerk opgedeeld is in verschillende groepen. Vanuit deze groepen ontstaat steeds meer de vraag naar een intern gedeelte waar interactie kan plaatsvinden, zoals berichten of bestanden delen. Zodat deze interactie steeds meer plaats kan vinden vanuit een centrale plek. Waardoor de website een 5

plek wordt waar leden en groepen informatie met elkaar kunnen uitwisselen en delen, en niet alleen informatie kunnen opvragen.

1.2 Over Gopublic In 2005 is Gopublic opgericht door Jeroen Houwen en Jurjen van Houwelingen. In de eerste instantie begon Gopublic als internetbureau voor midden en klein bedrijf en leverden daarnaast ook veel grafisch en visueel werk zoals fotografie, brochures, logo ontwerp en overige grafische vormgeving. Gopublic specialiseert zich op het moment steeds meer op internet en interactiviteit. Vooral door de doorontwikkeling van Golive, het content management systeem van Gopublic, ontstonden steeds meer nieuwe idee¨en om het internet juist op een interactieve manier in te zetten en niet langer slechts als ’de zender’ van communicatie. Voor basisscholen heeft Gopublic een specifieke maatoplossing ontwikkeld: De Interactieve School.[11] Momenteel is Gopublic ook bezig met de ontwikkeling van een nieuwe maatoplossing: De Interactieve Kerk. Voor non-profit organisaties met een beperkt budget werkt Gopublic soms ook met open-source oplossingen zoals Wordpress. De afgelopen tijd wordt er vooral gewerkt aan maatoplossingen voor hele specifieke branches en sectoren. Op dit moment worden er 3 diensten aangeboden: • Golive CMS De dienstverlening van Gopublic bestaat nog vooral uit websites ontwikkelen voor klanten en aansluiten op het eigen Golive CMS. Per klant wordt er een modulair maatpakket samengesteld met modules uit het Golive CMS. Dit CMS is uitgebreid met de volgende maatoplossingen: – De Interactieve School De Interactieve School bestaat uit een website met een aantal specifieke modules. Zo krijgt iedere groep binnen een school een eigen pagina met nieuws en blogberichten, kunnen docenten gemakkelijk foto albums uploaden, is er een uitgebreide groepgevoelige kalender met verjaardagen en activiteiten en nog veel meer. Mogelijkheden zijn onder meer: inloggen voor ouders, absentiemeldingen en lespakketten voor bovenbouw groepen. – De Interactieve Kerk Dit concept wordt behandeld in deze scriptie.

1.3 Probleemomschrijving Het maatproduct is een totaalconcept waarbij een intern deel en het publieke deel van de website elkaar aanvullen en versterken. Momenteel is het publieke deel al ontwikkeld maar wat nog ontwikkeld moet worden is een intern ledendeel waar leden op kunnen inloggen en met elkaar kunnen communiceren, activiteiten aanmaken, data plannen, bestanden delen, etcetera.

6

7

8

HOOFDSTUK 2

Opdrachtomschrijving Zoals al eerder is aangegeven in de probleemomschrijving moet er een intern deel ontwikkeld worden. Dit gedeelte van de website heeft bepaalde functionaliteiten en moet aan bepaalde voorwaarden voldoen voordat het gebruikt kan worden. In deze scriptie ga ik in op de eisen waaraan het systeem moet voldoen.

2.1 Doelgroep De oplossing is bedoeld als maatoplossing voor veel kerken binnen Nederland. Deze kerken vari¨eren in soorten en maten. Hiermee wordt in de maatoplossing dus rekening gehouden. Hierbij wordt het publieke deel op maat gemaakt en is het interne deel altijd algemeen. Op het moment van schrijven zijn er vijf pilots die deze oplossing gaan gebruiken. Deze pilots gaan dus de eerste versie van het ontwikkelde systeem gebruiken. Aan de hand van ondermeer het feedback op de pilots zal het systeem doorontwikkeld worden. Wat echter in deze scriptie vooral behandeld zal worden, is de basisversie van het systeem waarin de minimale eisen naar voren zullen komen. Hierin is meegenomen dat het systeem in de toekomst nog uitgebreid gaat worden.

2.2 Functionaliteiten Er is behoefte aan een systeem waarbij groepen centraal staan, en waarbij leden activiteiten, bestanden of berichten kunnen uitwisselen. Bij De Interactieve Kerk kan er bij een groep gedacht worden aan: ’Jeugd’, ’Band’ of ’Leiders’.

2.2.1 Groepen Voor de groepen zijn de volgende drie zaken belangrijk: Berichten Als eerste moeten er berichten kunnen worden gestuurd naar de groep. Deze berichten moeten worden gekoppeld aan de groep. Per groep zijn er verschillende leden die rechten hebben om een nieuw bericht te plaatsen. Tevens kan men reageren op een bericht. Activiteiten Groepen hebben ook activiteiten. Als er een activiteit wordt aangemaakt, wordt de groep hiervan op de hoogte gesteld. Eventueel kan een groepslid ook aangeven of hij/zij hierbij aanwezig is. Een activiteit kan een hele dag duren of men kan een tijdsduur instellen. Ook op een activiteit kunnen leden reageren. Bestanden Bestanden kunnen ook worden geupload in een groep. Deze zijn alleen toegankelijk voor degenen die bij de groep horen. Gebruikers kunnen zelf instellen of ze op de hoogte willen worden gesteld als er nieuwe bestanden zijn geplaatst. Leden kunnen alleen bestanden verwijderen die zij zelf hebben geplaatst.

2.2.2 Leden Registratie en groepsleden Om lid te worden van het systeem moet iemand zich eerst registreren. Dit kan door minimaal de basisgegevens, namelijk NAW gegevens, e-mailadres en wachtwoord op te geven. Als iemand 9

zich registreert, is hij/zij lid van de groep Algemeen. Alle leden zitten dus in deze groep. Om lid te worden van andere groepen moet een groepsleider een lid uitnodigen voor de betreffende groep. Deze groep Algemeen kan heel groot worden en hierbij moet dus goed rekening worden dat leden hier geen misbruik van kunnen maken. Standaard heeft een lid die zich aanmeld dan ook geen rechten om activiteiten, berichten dan wel bestanden te plaatsen.

2.2.3 Profiel Elk lid heeft een profielpagina. Op deze profielpagina zijn de gegevens van het lid te zien. Deze pagina is ook beschikbaar voor betrokken andere leden. Een betrokken lid beschikt standaard over een aantal velden, namelijk NAW-gegevens, e-mailadres, telefoonnummer en een profielafbeelding. Extra velden Elke kerk heeft de mogelijkheid om een aantal extra velden toe te voegen die een lid kan invullen. Zo kan elke kerk eigen aanvullende gegevens toevoegen per lid die voor hen interessant zijn.

2.2.4 Rechten Globale rechten Binnen De Interactieve Kerk zijn per gebruiker verschillende rechten beschikbaar. Ook maakt het Golive CMS gebruik van een aparte ledenmodule met beheerders. Deze leden hebben meer rechten dan de gebruikers van ’De Interactieve Kerk’ module. Rollensysteem Voor het rechtensysteem wordt er gebruik gemaakt van een rollensysteem. Hierbij zijn de rollen dynamisch en kunnen de rollen worden beheerd door de gebruikers van het CMS. Een rol heeft een variabel aantal rechten die aan of uit kunnen worden gezet. Er is een standaard rol die voor elke gebruiker geldt. Verder kunnen ´e´en of meerdere rollen aan een gebruiker worden toegewezen. Daarbij gelden de volgende opties als wel of geen recht: • Groep - aanmaken - verwijderen - leden toevoegen - leden verwijderen

• Berichten - plaatsen - verwijderen • Bestanden - uploaden - verwijderen

• Activiteit - aanmaken - verwijderen - publieke activiteit aanmaken

Hierdoor kan men rollen samenstellen die er op de volgende manier uit kunnen zien: • Standaard lid: - Mag geen berichten plaatsen - Mag geen activiteiten aanmaken - Mag geen bestanden uploaden

• Groepsleider: - Mag berichten plaatsen - Mag activiteiten aanmaken - Mag publieke activiteiten aanmaken - Mag bestanden uploaden - Mag mensen toevoegen aan groep - Mag mensen verwijderen uit de groep

• Betrokken lid - Mag berichten plaatsen - Mag activiteiten aanmaken - Mag geen pub. activiteiten aanmaken - Mag bestanden uploaden 10

2.2.5 Instellingen Mailnotificaties Van elke wijziging of update die plaats vindt binnen een groep dient er een mail te worden gestuurd naar de leden die in deze groep zitten. De instellingen van de mailnotificaties staan nog niet helemaal vast. Dit omdat het systeem in de toekomst nog uitgebreid zal worden, waardoor er meer notificaties verstuurd kunnen gaan worden. Bij nieuwe berichten, bestanden, activiteiten of reacties wordt er dus een update gestuurd naar de betreffende leden. Deze mailnotificaties zijn per lid instelbaar. Dit is belangrijk omdat bijvoorbeeld gezamenlijk activiteiten in de groep ’Algemeen’ naar iedereen wordt gestuurd. Hierdoor kan dus iedereen makkelijk bereikt worden maar dit kan ook ongewenst zijn. Profiel Het profiel van een lid is, zoals eerder al genoemd, door het lid zelf in te stellen. Dit moet dus binnen in de module kunnen gebeuren zonder ingelogd te zijn in het Golive CMS. Dit houdt in dat niet alleen beheerders, die toegang hebben tot het Golive CMS, leden kunnen beheren.

2.2.6 Meertaligheid Het systeem moet volledig beschikbaar zijn in twee talen, namelijk Nederlands en Engels. Deze taal moet per gebruiker persoonlijk zijn in te stellen.

2.3 Conceptueel Model Naar aanleiding van de eisen heb ik een conceptueel model gemaakt. Hierin geef ik in een diagram weer hoe de relaties zijn tussen de verschillende componenten. Dit diagram geeft de basis weer

Figuur 2.1: Het conceptuele model in diagram vorm

van het concept ’De Interactieve Kerk’. Er zijn een aantal groepen. Deze bestaan uit een aantal leden. Een lid kan activiteiten, berichten of bestanden plaatsen en deze zijn gekoppeld aan een groep. Doordat leden kunnen reageren op activiteiten of berichten vind er interactie plaats.

11

12

HOOFDSTUK 3

Functioneel ontwerp Aan de hand van de functionele eisen die zijn opgesteld en het conceptuele model heb ik een functioneel ontwerp gemaakt. Een functioneel ontwerp geeft weer hoe componenten terugkomen en waar deze terugkomen. Er is nog geen visueel ontwerp gemaakt. De elementen die weer worden gegeven staan nog niet vast qua grootte en ook de indeling kan nog worden veranderd in het uiteindelijke ontwerp.

3.1 Wireframes In het functioneel ontwerp worden de elementen en de relaties hiertussen vastgelegd. Uiteindelijk worden er wireframes gemaakt, wat eigenlijk alleen maar schetsen zijn. Views Een website bestaat uit verschillende views. Deze views kunnen bijvoorbeeld bestaan uit een overzichtspagina of een profielpagina. Deze zijn voor De Interactieve Kerk allemaal vastgesteld en in een wireframe gezet. Onderstaand figuur toont vier verschillende views. De elementen hierin wil ik kort toelichten. Er zijn nog veel meer views maar deze vier dekken de kern van het ontwerp.[14]

3.1.1 Toelichting In dit wireframe komen een aantal elementen terug. Hieronder zal ik deze elementen kort toelichten: Hoofdmenu Het hoofdmenu bestaat uit de tabs Mijn Overzicht, Groepen en Leden. Bij Mijn Overzicht staat de gebruiker centraal en wordt alleen de informatie weergeven van de groepen waar de gebruiker in zit. Bij Groepen is er eerst een groepenoverzicht van waaruit men een groep selecteert. Het groepoverzicht is hetzelfde als Mijn Overzicht, alleen is dan alle informatie gefilterd per groep. Submenu De eerste view biedt een overzicht waarin de meest recente bestanden, activiteiten en berichten worden genoemd. Maar voor deze genoemde zaken is er ook een vergroot overzicht waarin alleen de bestanden, activiteiten of berichten worden getoond. Als men in een groep zit wordt dit weer gefilterd op de groep. Sidebar De overzichtspagina heeft aan de rechterkant een kolom waarin verschillende blokken worden getoond (sidebar). Deze blokken worden op een generieke manier opgezet zodat in de toekomst bij een nieuwe functionaliteit meerdere blokken onder elkaar kunnen worden getoond. Gebruiker of groepsinformatie Het bovenste blok van deze sidebar is de profielafbeelding. Hier wordt bij Mijn Overzicht de afbeelding van de gebruiker getoond en bij een groepsoverzicht de afbeelding van de groep. Kalender De kalender kan op twee verschillende groottes worden weergegeven. In de vergrote weergave kunnen de activiteiten zelf met eventuele reacties worden bekeken. De kleine weergave staat alleen op de overzichtspagina en geeft alleen de titel van de activiteit weer. 13

(a) Mijn Overzicht

(b) Kalender

(c) Bestanden

(d) Profiel

Figuur 3.1: Wireframes Bestanden, activiteiten of berichten plaatsen Mits de gebruiker hier de rechten voor heeft, is er bij het overzicht een formulier om een bestand, activiteit of bericht te plaatsen. Bij een gespecificeerde view, bijvoorbeeld berichten, verschijnt alleen het formulier om een bericht te plaatsen. Moeilijkheden Tijdens het maken van het funcioneel ontwerp worden er nog geen visuele ontwerpkeuzes gemaakt. Dit is concreet lastig toe te passen omdat een wireframe min of meer wel op schaal wordt gemaakt. In dit geval is er gebruik gemaakt van de software Keynote Wireframe Toolkit [14]. Bij deze software zijn er al veel verschillende elementen visueel uitgewerkt waardoor het lijkt alsof er al ontwerpkeuzes zijn gemaakt. Daarom is het in sommige gevallen zelfs beter om slechts globale lijnen uit te tekenen en niet een wireframe ook visueel goed eruit te laten zien.

14

15

16

HOOFDSTUK 4

Technisch ontwerp Nu het functioneel ontwerp is gemaakt, kan er nu worden gekeken op welke manier de applicatie gebouwd moet worden. Hieronder zal ik een aantal technische zaken uitwerken, waarin meer wordt uitgelegd hoe deze applicatie is gebouwd. Een aantal kaders waarin wordt gewerkt, zoals de patterns, zijn reeds vastgesteld aangezien de applicatie moet samenwerken met het Golive CMS. Daarom zal ook een toelichting worden gegeven hoe het Golive CMS[3] technisch is uitgewerkt en hoe deze nog verder uitgebreid kan worden.

4.1 Patterns 4.1.1 Model View Controller Pattern Het MVC pattern is een pattern waarbij de software architectuur is drie delen wordt opgesplitst: [2] • Model Definieert de representatie van de informatie waarmee de applicatie werkt. • View De view geeft de informatie weer. • Controller De controller verwerkt en reageert op events, die meestal het gevolg zijn van handelingen van de gebruiker.

Figuur 4.1: Het MVC model geillustreerd

Het volgende voorbeeld illustreert het concept in de praktijk: 1. Persoon A klikt op een link http:/www.voorbeeld.nl/producten/website/bestellen, de browser stuurt een request naar webserver 2. De controller handelt de applicatie-specifieke logica af. Bijvoorbeeld controleren of de gebruiker is ingelogd. 3. Verder gebruikt de controller Models op toegang te krijgen tot de applicatiedata. Dit is over het algemeen de database. 4. De controller stuurt de gegevens door naar een view. Deze view maakt deze data klaar om aan de Client te laten zien. 5. Als dit klaar is wordt de data gevormd tot een complete view en wordt dit getoond aan de gebruiker. 17

4.1.2 Active record Voor alle communicatie met de database gebruik ik het Active record pattern[2]. Dit pattern is een makkelijke manier om standaard operaties op de database uit te voeren. Dit pattern was al volledig ge¨ımplementeerd in het Golive CMS. Bij deze manier wordt een tabel of een view verpakt in een klasse. Hierdoor kan ik met de klasse en de daarbijbehorende functies communiceren. Dit pattern heeft de standaard CRUD (Create Read Update Delete) operaties al geimplementeerd en deze operaties kunnen via eenvoudige functies worden aangeroepen. Het voordeel hierbij is dat de data direct als object wordt teruggegeven en dat er dus ook op die manier mee gewerkt kan worden. De klasse die gebruikt wordt bij een tabel of view staat in de model map van het MVC-model. Read Als ik bijvoorbeeld de gegevens van een lid wil opvragen dan zou dat kunnen met onderstaande code: // find member $member = ActiveRecord::find("dik_mem_member",array("member_id"=>3));

Dit wordt dan vertaald in de volgende SQL Code SELECT * FROM ‘dik_mem_member‘ WHERE ‘member_id‘ = 3 LIMIT 1;

Update Hetzelfde geldt voor het opslaan van een lid $member = new Dik_mem_member(); $member->id = 3; $member->first_name = "Joe"; $member->save();

Dit wordt dan vertaald in de volgende SQL Code UPDATE ‘dik_mem_member‘ SET ‘first_name‘=’Joe’ WHERE ‘member_id‘ = 3;

Mocht er geen id worden opgegeven wordt dit vertaald in INSERT INTO ‘dik_mem_member‘(‘first_name‘) VALUES (’Joe’);

4.2 Database design Alle data die gebruikt wordt, moet worden opgeslagen in een database. Dit doe ik met behulp van MySQL. Om de database structuur inzichtelijk te maken en de entiteiten en de relaties hiertussen, heb ik een ERD (entity-relationship diagram) ontworpen.

4.2.1 ERD De database is gemakkelijk onder te verdelen in een aantal entiteiten, namelijk een groep, een lid (met velden), activiteiten, berichten en bestanden. Deze zijn met behulp van koppeltabellen met elkaar verbonden. Voor het gemak zijn lid-gerelateerde tabellen in het groen weergegeven, groep-gerelateerde velden in het donkerblauw, recht-gerelateerde in het rood en de overige in het lichtblauw. 18

Figuur 4.2: ERD van de database

4.3 Golive CMS De toepassing wordt ontwikkeld binnen Gopublic en is een uitbreiding op het Golive CMS (Content Management System)[3]. Hierdoor moet de toepassing aan een aantal eisen voldoen en op een bepaalde manier opgebouwd worden. Omgeving Bij het Golive CMS en toepassingen die hierop draaien wordt gebruik gemaakt van de programmeertaal PHP met behulp van MySQL voor de database. MVC-model Het CMS hanteert het MVC-model en staat op een centrale plek op de server. Elke website die hierop wordt aangesloten, kan gebruik maken van de klassen die hier staan. Centrale klassen en functies die door meerdere websites worden gebruikt, kunnen hier worden gezet. Mappenstructuur Elke website, en tevens het CMS zelf, hanteert een mappenstructuur die voor elke website hetzelfde is. De belangrijkste worden even toegelicht. • classes - controller Deze map bevat alle controller php bestanden. - model Alle model php bestanden, elke tabel heeft in de database zijn eigen klasse - util (optioneel) Deze map is optioneel. Het CMS heeft deze map, en het bevat algemene klasses die niet in een MVC structuur zijn te plaatsen. - view Alle view php bestanden. • css Alle stylesheet bestanden • js Alle javascript bestanden • templates Deze map bevat alle html templates. Deze templates zijn gelijknamig aan de view bestanden. Bijvoorbeeld als er een view blog.class.php is, dan staat hier een blog.tpl Een aantal centrale klasses die essentieel zijn, staan alleen in de CMS mappen. Hierdoor is het mogelijk algemene wijzigingen door te voeren. 19

Opbouw Het CMS en elke website zijn modulair opgebouwd. Daardoor is uitbreiding mogelijk, namelijk door meerdere klasses toe te voegen. Het volgende voorbeeld illustreert de werking hiervan. Als voorbeeld gebruik ik een website die ook blogberichten moet kunnen tonen waarop men tevens reacties kan plaatsen. In dat geval zijn er 3 klasses vanuit het MVC model nodig en een template bestand: • Blog_controller.class.php Deze klasse handelt het formulier om reacties te plaatsen af. • Blog_model.class.php Deze klasse slaat de reacties op in de database en wordt aangestuurd door de controller. • Blog_view.class.php Deze klasse toont de blog. • blog.tpl Dit is het template bestand die de html bevat van de blog. De Blog_view.class.php maakt gebruik van de klasse View.class.php die ervoor zorgt dat blog.tpl wordt verwerkt en getoond.

4.4 Module De blog geeft een goed voorbeeld hoe een module gebouwd kan worden. Deze vier bestanden zijn namelijk de kern van elke module. Uiteraard is dit slechts de kern, zodra een module groter wordt kan het handiger worden om klasses op te delen in meerdere bestanden. Om dus een extra module te maken, moeten deze vier bestanden aangemaakt worden. Op deze manier ga ik ook te werk. Lokaal en centraal Een module kan centraal of lokaal worden aangemaakt. Het verschil is dat de bestanden in de website structuur staan of centraal in het CMS. Deze module wordt ontwikkeld door eerst de module lokaal aan te maken en goed te testen en daarna pas centraal beschikbaar te stellen voor elke website.

20

21

22

HOOFDSTUK 5

Implementatie Nu in het technisch ontwerp vastgesteld is op welke manier het gebouwd wordt, kan aan de daardwerkelijke implementatie worden begonnen. In dit hoofdstuk zal ik een aantal zaken toelichten waartegen ik ben aangelopen.

5.1 Database 5.1.1 Uitbreidingen In de implementatiefase werd al snel duidelijk dat er veel uitbreidingen nodig waren. Hoewel de basisopzet hetzelfde is gebleven, is in het uiteindelijke model nog veel meer toegevoegd. Zo kunnen er nu bijvoorbeeld reacties worden geplaatst op berichten en op activiteiten. Tevens is het rechtenmodel opnieuw ontworpen en zijn er meer eigenschappen aan een bestand toegevoegd.

5.1.2 Basis Tijdens het ontwikkelen zijn er ook nieuwe idee¨en ontstaan. Deze idee¨en zijn niet technisch altijd even moeilijk maar doordat dit er veel kunnen zijn, kan de complexiteit wel groter worden. Hieruit blijkt dat er van tevoren wel goed moet worden nagedacht over een ontwerp, zodat er een goede basis gelegd kan worden. Naarmate de implementatie vordert, worden er constant wijzigingen gemaakt. Ook in de database is dit het geval. Hier kan men zich niet altijd van tevoren goed op voorbereiden, maar dit is wel iets om rekening mee te houden. Waar vooral ook rekening mee moet worden gehouden, is dat er geen ontwerpfouten moeten worden gemaakt over functionaliteiten die van te voren al vaststaan.

5.2 Beveiliging De aanmeldingsprocedure van het systeem is als volgt aangepakt. Bij het aanmelden moet de gebruiker zijn gebruikersnaam (e-mailadres) invoeren en zijn wachtwoord. Eventueel kan worden gekozen om de gebruiker te onthouden. Als de gegevens correct zijn, wordt de gebruiker opgeslagen in een sessie. Sessies kunnen door de hele site worden opgevraagd en worden weggegooid bij het sluiten van de browser.

Cookies Cookies zijn kleine bestanden die op de computer van de gebruiker worden opgeslagen. Deze kunnen eenvoudig worden aangemaakt en worden beheerd. Aan cookies kunnen, in tegenstelling tot sessies, een leefbaarheidsdatum worden meegegeven waardoor deze nog steeds toegankelijk zijn als de browser opnieuw wordt opgestart. Als de gebruiker ervoor heeft gekozen om zijn gegevens te onthouden, wordt zijn gebruikersnaam en een random gegenereerde code opgeslagen in een cookie. Deze code wordt ook in de database opgeslagen. Hierdoor kan gecheckt worden of de gebruiker nog is ingelogd zonder zijn wachtwoord op te slaan in een cookie. Dit is zo gedaan omdat cookies gemakkelijk op kunnen worden gevraagd bij het bestandssysteem. Zeker op openbare plekken zou dit een veiligheidsrisico kunnen zijn. 23

5.3 Performance Een belangrijk aspect bij het succesvol ontwikkelen van een webbased oplossing is performance. Dit is onder te verdelen in twee gebieden, namelijk performance aan server-side en aan client-side. Als er een request wordt gemaakt voor een bepaalde view, wordt deze eerst verwerkt op de server. Als dit verwerkt is, wordt er uiteindelijk slechts HTML samengesteld en dit wordt naar de client gestuurd die de pagina bekijkt. Om inzicht te krijgen in wat er allemaal wordt geladen, heb ik de website www.google.nl gemeten. Onderstaande afbeeldingen tonen de meetresultaten. De eerste

(a) Niet gecached (1,28 sec)

(b) Gecached (758 ms)

Figuur 5.1: Snelheidsresultaten van de website http://www.google.nl, een paars blok geeft de wachttijd weer en een grijs blok duidt aan dat het bestand wordt ontvangen

afbeelding geeft de tijd weer wanneer de website voor het eerst wordt bezocht. Daarna worden verschillende bestanden gecached en bij het opnieuw bekijken van de pagina hoeven meerdere bestanden niet opnieuw te worden geladen. Hierdoor is de laadtijd een stuk korter geworden. De paarse blokken in de afbeelding geven aan dat de server bezig is een verzoek te verwerken. Ik zal de performance op twee manieren behandelen: • server-side Hier ga ik in op de snelheid waarmee de server een verzoek afhandelt. • client-side Hier zal ik voornamelijk ingaan op hoe snel de website wordt getoond op de computer van de client.

5.3.1 Server-side Snelheid en optimalisatie kan je op verschillende manieren bereiken. Ik maak gebruik van de taal PHP in combinatie met MySQL voor de database. Dit kan op verschillende manieren efficient worden gebruikt. Een gedeelte hiervan heb ik al uitgelegd bij het MVC-model. Veel snelheidswinst kan worden behaald door effici¨ent om te gaan met database query’s. Een veel voorkomend probleem is het N+1 query probleem[9]. N + 1 query problem Dit type query heb ik vaak nodig gehad. Ik zal dit eerst illustreren aan de hand van een voorbeeld waarbij alle groepnamen weer moeten worden geven van een bepaald lid. Het aantal groepen waar dit lid in zit noemen we N. Dan is 1 query nodig voor het opvragen van de groepen van dit lid, en vervolgens N query’s om de groepsnaam op te vragen. Dit kan ook beter door eager loading te gebruiken. Onderstaand voorbeeld gebruikt slechts 2 query’s om hetzelfde te bereiken. SELECT * FROM ‘dik_group‘ WHERE ‘group_id‘ IN ( SELECT ‘group_id‘ FROM ‘dik_mem_group‘ WHERE ‘member_id‘ = 3 ) "

24

5.3.2 Frontend Performance Veel van de snelheidswinst bij websites valt te behalen aan de frontend[1]. Steve Souders heeft een aantal regels opgestelt die samen een richtlijn vormen waardoor de laadtijd van een website versnelt [12]. Een aantal regels die voor mij relevant waren zijn: 1. Make Fewer HTTP Requests Dit is de belangrijkste regel. Een aantal manieren om zo weinig mogelijk HTTP requests te maken zijn: CSS Sprites, image maps, gecombineerde bestanden, inline afbeeldingen. 2. Add an Expires Header Zorg ervoor dat bestanden langer gecached kunnen worden. 3. Gzip Components Comprimeert eerst de bestanden voordat ze verzonden worden. 4. Put Stylesheets at the Top Als stylesheet bestanden bovenaan staan worden deze direct verwerkt waardoor de browser al zoveel mogelijk kan tonen zonder dat de pagina nog helemaal is geladen. 5. Put Scripts at the Bottom Scripts blokkeren parallele downloads terwijl ze pas meestal aan het eind nodig zijn. 6. Make JavaScript and CSS External Als deze bestanden extern geladen worden kunnen ze gecached worden. Echter veroorzaakt dit wel meer HTTP requests. Hierdoor is het vaak trade-off tussen het aantal HTTP requests en de grootte van het HTML bestand. 7. Minify JavaScript and CSS Door deze bestanden te minimaliseren (spaties weghalen, variabelen minimaliseren etc.) wordt de bestandsgrootte kleiner. Een aantal van deze regels heb ik toegepast. Hieronder zal ik wat meer zeggen over hoe ik dit heb gedaan. Minimaliseer javascript en css Het beste is om deze bestanden zo klein mogelijk te houden. Dit houdt in dat er zo weinig mogelijk spaties in staan en dat de variabelen zo klein mogelijk gehouden worden. Dit zorgt er echter voor dat deze bestanden niet meer handmatig zijn aan te passen. Daarom heb ik ervoor gekozen dit slechts aan het eind toe te passen. Hiervoor gebruik ik een library minify[5] van Google die dit automatisch doet. Deze comprimeert niet alleen deze bestanden, maar voegt ze ook bij elkaar waardoor er weer minder http-requests nodig zijn. Gzip-compressie Door compressie toe te passen, zorgt de server ervoor dat de bestanden eerst worden gecomprimeerd en daarna pas worden verzonden. Zeker bij tekstbestanden kan hiermee grote snelheidswinst worden behaald. Een populaire manier om te comprimeren is gzip-compressie. In mijn geval word de compressie toegepast door de server die zo is geconfigureerd. Caching In principe zorgt de browser al voor een groot gedeelte van de caching. Dit kan echter nog meer worden be¨ınvloed door de expires header aan te passen. Dit kan door het .htaccess bestand aan te passen. Dit is een bestand wat in de root van de website staat en waardoor serverconfiguraties veranderd kunnen worden. Afbeeldingen, javascript en css-bestanden dienen een expires header te hebben die ver in de toekomst ligt, dit is op de volgende manier in te stellen: # 480 weeks Header set Cache-Control "max-age=290304000, public" 25

Page Speed Google heeft Page Speed ge¨ıntroduceerd om de performance van websites te meten aan de hand van een aantal regels. Een aantal zijn hiervoor genoemd. Page Speed geeft een score op een schaal van 100, waarbij 100 het hoogst haalbare is. Deze score is ook belangrijk bij het indexeren van de zoekresultaten van Google[10]. Om deze score te meten is er een extensie voor Firefox beschikbaar die de Page Speed analyseert. Bij ’De Interactieve Kerk’ heb ik een aantal verbeteringen doorgevoerd en gekeken wat voor invloed dit had op de Page Speed-score. Bijgaande afbeeldingen tonen de verbeteringen die tot stand komen door de volgende regels toe te passen: • Minify JavaScript and CSS • Add an Expires Header Testomgeving De volgende meetresultaten zijn gedaan op http://www.deinteractievekerk.nl. Alleen de homepage is bekeken en dit dient slechts ter illustratie om het effect van een aantal regels te laten zien die zijn toegepast. Deze website is op het moment van schrijven aan wijzigingen onderhevig en zodoende zullen deze resultaten niet gereproduceerd kunnen worden.

(a) Geen caching en geen geminimaliseerde javascript en css

(b) Geen caching en wel geminimaliseerde javascript en css

(c) Caching en geminimaliseerde javascript en css

Figuur 5.2: Page Speed verbeteringen Het is te zien dat de snelheid aanzienlijk is verbeterd door deze twee regels toe te passen. Voor ’De Interactieve Kerk’ zijn vooral deze twee regels ook erg belangrijk, aangezien een groot deel van de bezoekers hier regelmatig op zal komen. Hier moet dus extra veel aandacht worden besteed aan caching.

26

5.4 Ontwerp Aan de hand van een functioneel ontwerp kan een ontwerp worden gemaakt. Dit wordt door een vormgever gedaan. Bijgevoegd zijn een aantal views die zijn ontworpen. Deze ontwerpen hebben niet veel toelichting nodig aangezien dit reeds gedaan is in het functioneel ontwerp. De personen en hun persoonsgegevens zijn fictief.

5.4.1 Kleuren Er is een keuze die wel erg opvalt en waar ook bewust voor is gekozen en dat is de keuze om in verschillende hoofdkleuren te werken. Hierdoor is het duidelijk welke filtering er plaatsvindt bij de verschillende elementen, zoals uitgelegd in het functioneel ontwerp.

(a) Mijn Overzicht - met een kalender, aankomende (b) Kalender - met een vergroot overzicht van de activiteiten, dashboard en profiel activiteiten en een activiteit kan bekeken worden

(c) Berichten - met links de berichten en rechts het bericht zelf en de bijbehorende reacties

Figuur 5.3: Ontwerp Mijn Kerk

27

(d) Bestanden

(a) Groepen Overzicht - met alle groepen waar gebruiker (b) Groepsberichten - berichten gefilterd per groep en bij zit opgesomd in groepskleur

(c) Ledenoverzicht - leden uit jouw groepen en een kaart (d) Profielpagina - met kleine kaart met dichtsbijzijnde waar alle leden op weer worden gegeven leden, profielgegevens en familie

Figuur 5.4: Ontwerp Groepsoverzicht en Leden

28

29

30

HOOFDSTUK 6

Future work Tijdens de ontwikkeling van de module zijn er verschillende nieuwe idee¨en onstaan die in de toekomst ge¨ımplementeerd zouden kunnen worden. Ook kan het systeem nog fouten vertonen die nog moeten worden opgelost. De basis van ’De Interactieve Kerk’ is gelegd maar er zijn nog een aantal functionaliteiten waar in de toekomst nog naar gekeken kan worden.

6.1 Sociale Media Allereerst is een feature om meer sociale media te integreren, met name Facebook is een belangrijke factor hierin. Een mogelijkheid zou kunnen zijn om volledige profielinformatie te importeren uit Facebook. Hierdoor zouden gebruikers eenvoudig zich kunnen registreren en toch een volledig profiel hebben. Ook is het een mogelijkheid dat een activiteit, die publiek wordt gemaakt, wordt gepost op Facebook.

6.2 Faciliteiten Veel kerken werken met locaties en faciliteiten. Zo kan het wenselijk zijn om een locatie te reserveren bij een vergadering. Bij een locatie kan men bijvoorbeeld denken aan een lokaal. Over het algemeen zijn er slechts een aantal standaard locaties beschikbaar. Deze behoefte zou ook in het systeem moeten kunnen worden ge¨ımplementeerd. Bijvoorbeeld door een extra tab naast de leden tab te maken met ’Faciliteiten’.

6.3 Schaalbaarheid Het doel bij deze module is om de module voor veel kerken in Nederland in te zetten. Hierdoor zullen er in de toekomst veel gebruikers onstaan die tegelijkertijd op het systeem werken. Op dit moment is het nog onduidelijk hoe dit het systeem be¨ınvloedt en wat de maximale capaciteit is en hoe dit verbeterd zou kunnen worden.

6.4 Onderhoud De module is nog niet uitgebreid getest door een aantal echte gebruikers. In de toekomst zal er nog veel onderhoud moeten worden gepleegd om de wellicht bestaande fouten op te lossen.

31

32

HOOFDSTUK 7

Conclusie In de inleiding is er aangetoond dat er een bepaalde behoefte is vanuit de kerken. Deze behoefte heb ik verwerkt in een web based oplossing die verschillende functionaliteiten bied. De opdrachtomschrijving beschrijft welke functionaliteiten het systeem moet hebben om de probleemomschrijving op te lossen. Deze opdrachtomschrijving is nu in het geheel beschreven maar was in de eerste instantie kleiner. Gaandeweg is deze uitgebreid met meer functionaliteiten die nodig bleken te zijn. Dit terwijl bijvoorbeeld het functioneel ontwerp al gemaakt bleek te zijn. De behoefte en vraag die in de inleiding is vastgesteld wordt nu echter wel goed beschreven in de opdrachtomschrijving. De stap van het vertalen van een behoefte naar een opdrachtomschrijving, waarbij wordt vastgesteld aan welke eisen het systeem moet voldoen, had ik nog niet eerder gedaan. Dit heb ik tijdens dit project wel geleerd. Hierna is een functioneel ontwerp vastgesteld. Het functioneel ontwerp is daarna vertaald naar een technisch ontwerp waarin wordt beschreven op welke manier het systeem gemaakt gaat worden. Het functioneel ontwerp heb ik voor de eerste keer gemaakt. Hierdoor heeft dit wel iets meer tijd gekost dan verwacht. Verder was het ook lastig om visueel geen ontwerpkeuzes te maken terwijl de wireframes dit wel suggereren. Ik heb hierbij geleerd om functionele eisen om te zetten in een wireframe en ook me verdiept in wat een functioneel ontwerp is en wat erin moet staan. Het technisch ontwerp gaat in op de technische omgeving waarin ik heb gewerkt. Hierbij ben ik begonnen met een database ontwerp te maken. Deze is in het begin eenvoudig gehouden. De database is tijdens de implementatiefase uitgebreid, ook omdat er tijdens de ontwikkeling meerdere functionaliteiten bij zijn gekomen. Hierbij heb ik wel geleerd om bijvoorbeeld een database in deze fase van ontwikkeling simpel te houden en slechts goed na te denken over de basis. Dat er tijdens de ontwikkeling nog meer uitbreiding komt is bijna niet te voorkomen. Bij de implementatie is er goed gekeken naar de performance van het systeem. Hierbij is rekening gehouden met caching en compressie. Een aantal regels zijn gehanteerd waardoor vooral de Page Speed Score zoveel mogelijk is geoptimaliseerd. Deze regels zijn concreet op meerdere manieren toe te passen. Hierdoor was de implentatie leerzaam en ook interessant om dit voor dit specifieke systeem toe te passen. Verder heb ik geleerd dat performance vooral afhankelijk is van de front-end implementatie. Het grootste deel van het verwerken van een website is de front-end. Hierbij kan gedacht worden aan javascript en stylesheet bestanden minimaliseren en het langer cachen van bestanden (met name afbeeldingen). De web based oplossing ’De Interactieve Kerk’ is grotendeels succesvol ge¨ımplementeerd. Een gedeelte van de functionaliteiten, zoals omschreven in de opdrachtomschrijving, dient nog gebouwd te worden, maar de basis is wel gemaakt. Tijdens de ontwikkeling zijn er een hoop nieuwe idee¨en ontstaan die grotendeels bij future work zijn terug te vinden. Over het algemeen is de module echter succesvol gebouwd en ook al enthousiast ontvangen door betrokken gebruikers van de pilots.

33

34

Bibliografie [1] Jason Glasgow Arvind Jain. Let’s make the web faster. Website, 2011. http://code.google. com/intl/nl/speed/articles/use-compression.html. [2] Steve Burbeck. Applications programming in smalltalk-80tm: How to use model-viewcontroller (mvc), 1992. [3] Golive CMS. http://www.golivecms.nl/. [4] M. Fowler. Patterns of enterprise application architecture. The Addison-Wesley signature series. Addison-Wesley, 2003. [5] Google. Minify. http://code.google.com/p/minify/. [6] Gopublic. http://www.gopublic.nl/. [7] De Interactieve Kerk. http://www.deinteractievekerk.nl/. [8] Hyun Joo Lee. Optimizing web pages. Technical report, The University of Texas at Austin, 2003. [9] Ruby On Rails. Active record query interface. http://guides.rubyonrails.org/active_ record_querying.html#eager-loading-associations. [10] Alain P.J. Sadon. SEO voor Webprofessionals. 2011. Naar duurzame topposities in Google via de SEOGuru methode. [11] De Interactieve School. http://www.deinteractieveschool.nl/. [12] Steve Souders. High Performance Web Sites: Essential Knowledge for Front-End Engineer. O’Reilly, September 2007. [13] Steve Souders. High- performance web sites. Communications of the ACM, 51(12):36–41, 2008. [14] Keynote Wireframe Toolkit. http://keynotekungfu.com/. [15] Boele P. Ytsma. Kerkelijk werk en internet - een vreemd tijdverdrijf of een noodzakelijke zoektocht? 2007. http://www.zoekendgeloven.nl/. [16] Boele P. Ytsma. Internetcommunities - de kunst van leven op het internet. 2009. http: //www.zoekendgeloven.nl/.

35