Bachelorproject Eindverslag

Bachelorproject Eindverslag IN3405 BSc-project TU Delft, faculteit EWI 30 juni 2008 Chris van Egmond, 1232444 Sung-Shik Jongmans, 1340263 Thijs Zandvliet, 1245198 Commissie Opdrachtgever: Carlo Schneider Begeleider TU: Peter van Nieuwenhuizen Coördinator Bsc project: Matthijs Sepers

Voorwoord

Samenvatting

Ter afsluiting van de bachelor-fase van de opleiding Media en Kennis Technologie aan de TU Delft, wordt een project uitgevoerd in de vorm van een stage. Het doel van dit project is het opdoen van ervaring in het zelfstandig uitvoeren van een project, en het doorlopen van een volledig softwareontwikkeltraject. Voor dit project staan 15 ECTS (420 uur), waarvan 3 ECTS reeds in het derde kwartaal dient te worden ingevuld met een vooronderzoek (zie ook bijlage B). De overige 12 ECTS zijn in het vierde kwartaal ingeroosterd. Dit document is het eindrapport voor dit project, dat wordt uitgevoerd ten behoeve van Nescio’s Hermitage bv. Onze opdrachtgever is Carlo Schneider, en onze begeleider aan de universiteit is Peter van Nieuwenhuizen. Beiden willen we hartelijk danken voor de assistentie tijdens de volledige projectduur.

Er bestaan tegenwoordig veel verschillende dating-websites, waarop mensen een partner kunnen zoeken. Deze websites begeleiden de singles tot aan de date, en laten het vervolgens voor wat het is. De opdrachtgever wil inspelen op het gat, dat de dating-sites achterlaten, door partners middels Internet begeleiding te bieden bij het hebben van een relatie. Hij heeft voor ogen, dat partners op periodieke basis een test afnemen om de toestand van de relatie op dat moment te evalueren, en de partners indien nodig van advies te voorzien. Bij aanvang van het project hebben we de requirements met de opdrachtgever doorgesproken, en middels MoSCoW prioretisering vastgesteld, dat de Must Haves uit dat diagram de te behalen doelen zijn voor het bachelorproject. Omdat het systeem conceptueel gezien nog niet uitgewerkt was, is er door voortschrijdend inzicht vaak gesleuteld aan deze requirements, waardoor de originele Must Haves niet allemaal ge¨ımplementeerd zijn. Het ene deel van het product, dat we afleveren ter beoordeling, is te vinden op http://www.wizzlove.com/. Gebruikers kunnen zich hier registreren, waarna ze in kunnen loggen om een test af te nemen. De ingevulde vragenlijsten worden vervolgens door de server verwerkt, en het testresultaat kan door de gebruikers bekeken worden. Het ontwerp van de layout is door een externe designer gedaan. Naast deze basis functionaliteit is het voor gebruikers ook mogelijk om hun gegevens aan te passen, lidmaatschappen cadeau te geven, en hun eigen horoscoop te bekijken. Het andere deel is te vinden op http://www.wizzlove.com/cms. Dit is het content management systeem, waar de administrator alle content teksten, vragenlijsten, afbeeldingen - van de website aan kan passen. De administrator kan verder andere CMS-gebruikers - al dan niet met beperkte i

Lijst met gebruikte afkortingen

rechten - toevoegen en verwijderen. Daarnaast beschikt het CMS over een statistieken-overzicht. Deze statistieken hebben zowel betrekking op het aantal bezoekers, als de antwoorden op bepaalde vragen. Uiteraard zijn deze statistieken anoniem, wat ze echter niet minder waardevol maakt.

AJAJ - Asynchronous Javascript And JSON AJAX - Asynchronous Javascript And XML CMS - Content Management Systeem CSS - Cascading Style Sheet HTML - HyperText Markup Language HTTP - HyperText Transfer Protocol JSON - JavaScript Object Notation NRT - Nationale RelatieTest PDO - PHP Data Objects PHP - PHP: Hypertext Preprocessor URL - Uniform Resource Locator

ii

Inhoudsopgave Voorwoord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Samenvatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lijst met gebruikte afkortingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i i ii

1 Inleiding 1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Opbouw van document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1

2 Analyse 2.1 Doelstelling . . . . . . . . 2.2 Definities . . . . . . . . . 2.3 Requirements . . . . . . . 2.4 Planning en taakverdeling

. . . .

2 2 2 3 5

. . . . . . .

6 6 6 7 8 10 10 11

3 Ontwerp 3.1 Website . . . . . 3.1.1 Database 3.1.2 AJAX . . 3.1.3 Structuur 3.1.4 Accounts 3.1.5 Design . . 3.2 Wizard . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

iii

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . . . . . . . .

11 12 14 14 16 16 17 18 18 19

. . . . . . . . . . . .

20 20 20 23 23 24 24 27 30 30 31 32 32

5 Beveiliging 5.1 Website beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 CMS beveiliging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Beveiliging van persoonsgegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 34 35 35

3.3

3.4

3.2.1 Het eerste ontwerp . . . 3.2.2 De revisie . . . . . . . . 3.2.3 Quattro Stagioni . . . . 3.2.4 Detailontwerp . . . . . . Content Management Systeem 3.3.1 Verschillende functies . 3.3.2 WYSIWYG editor . . . 3.3.3 WinQs . . . . . . . . . . 3.3.4 Bestandsstructuur . . . Integratie van onderdelen . . .

4 Implementatie 4.1 Website . . . . . . . . . . . . . 4.1.1 PHP . . . . . . . . . . . 4.1.2 JavaScript . . . . . . . . 4.1.3 CSS . . . . . . . . . . . 4.2 Wizard . . . . . . . . . . . . . . 4.2.1 PHP . . . . . . . . . . . 4.2.2 Javascript . . . . . . . . 4.3 Content Management Systeem 4.3.1 PHP . . . . . . . . . . . 4.3.2 JavaScript . . . . . . . . 4.3.3 CSS . . . . . . . . . . . 4.3.4 FCKeditor . . . . . . .

INHOUDSOPGAVE

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

iv

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

INHOUDSOPGAVE

6 Tests 6.1 Client . . . . . . 6.1.1 Javascript 6.1.2 CSS . . . 6.2 Server . . . . . . 6.3 AJAX . . . . . . 6.4 Alpha tests . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

36 36 36 36 37 37 38

7 Evaluatie

39

8 Conclusie

41

9 Aanbevelingen

43

A Opdrachtbeschrijving

45

B Vooronderzoek

47

C Opzet requirements

52

D Use Cases

56

E Database Diagram

60

F Klassediagram

63

G Flowchart Wizard

66

H Planning

68

I

CMS Sitemap

70

J CMS Handleiding

72

INHOUDSOPGAVE

v

INHOUDSOPGAVE

Hoofdstuk 1

Inleiding 1.1

Probleemstelling

Hoofdstuk 4 is wat technischer opgesteld. Hier gaat het om de imIn Nederland worden jaarlijks 80.000 huwelijken gesloten en 37.000 ont- plementatie van de code. Dit deel is eigenlijk alleen interessant voor bonden. Een op de drie ` a vier huwelijken eindigt in echtscheiding. Er is een personen die aan de site zullen werken, voornamelijk programmeurs. Het vacu¨ um ontstaan in relaties door de sterk afgebrokkelde rol van familie en geeft een iets diepere beschrijving van de verschillende delen van de website. kerken. Er is behoefte aan een ’relatie-coach’. Hoofdstuk 5 behandelt de beveiliging van de website. Aan de hand hiervan kunnen de opdrachtgever en programmeurs zien waar wel en waar 1.2 Opbouw van document geen rekening mee is gehouden tijdens het project. Zodoende kan er ook Het document is opgebouwd met verschillende delen. Niet alle delen zijn gekeken worden naar beveiliging van de website in de toekomst. voor iedereen even interessant. Hoofdstuk 6 is gewijd aan het testproces. Hierin is te lezen hoe we Hoofdstuk 2 van het document geeft een analyse van het project waarbij de website getest hebben op fouten. Het gaat hier om het testen tijdens de implementatie van de website; voor een uitgebreide usertest was er geen tijd. onder andere de definities en requirements behandeld worden. Hoofdstuk 3 gaat vervolgens in op de ontwerpfase. Het project is De laatste drie hoofdstukken geven ten slotte respectievelijk een evaldoor ons onderling verdeeld in drie grote taken. Deze worden dan ook apart uatie, conclusie en een aantal aanbevelingen. behandeld. De ontwerpfase kan interessant zijn voor eventuele toekomstige programmeurs, maar ook voor de opdrachtgever om te zien wat er werkelijk mogelijk is met de website. 1

Hoofdstuk 2

Analyse 2.1

Doelstelling

Account Een account is een lidmaatschap van één van de partners. Dit houdt in, dat bij de registratie van een relatie twee accounts worden aangeHet doel van het project is het ontwerpen en implementeren van (een pro- maakt. totype van) een relatie-test, vormgegeven in een website. Voor 50 euro kunnen stellen een abonnement nemen en zich registreren op de website, waarbij Alert / WinQ Alerts (of WinQs) zijn berichten, die naar gebruikers van ze beide aparte inloggegevens krijgen. Na registratie kan een stel gedurende het systeem worden verstuurd, wanneer de situatie daarom vraagt. Dit kan 5 jaar gebruik maken van de website, en in die periode een onbeperkt aantal bijvoorbeeld zijn om gebruikers te attenderen op de verjaardag van hun tests doen voor een serieuze blik op de relatie, en relatie-quizzes, die een partner of om een nieuwe test aan te kondigen. luchtigere ondertoon hebben. Content Management Systeem / CMS Het CMS is het onderdeel van De Nationale Relatietest is een eigentijds concept voor levenspartners om het systeem, dat voor gebruikers niet zichtbaar is, en de CMS-gebruikers in elkaar periodiek te confronteren met verwachtingen, wensen en tekortkominstaat stelt om de inhoud van de website en wizard aan te passen, alsmede gen in de relatie en aldus een bijdrage te leveren aan de verbetering en zelfs statistieken te raadplegen en alerts te verzenden. mogelijk de duurzaamheid van relaties. CMS-Account Een CMS-account is de bevoegdheid om van het CMS gebruik te maken. Aan elk CMS-account zijn specifieke rechten verbonden, 2.2 Definities die per CMS-account kunnen verschillen. Deze rechten hebben betrekking We hanteren tijdens het Bachelorproject en dit verslag de termen zoals op de mate waarin CMS-gebruikers toegang hebben tot bepaalde data en deze kunnen modificeren. gedefinieerd in deze sectie. 2

CMS-Gebruiker / CMS-User Een CMS-gebruiker is een natuurlijk Website De website is de grafische schil, die voor gebruikers zichtbaar is, persoon, die toegang tot het CMS heeft, en derhalve een CMS-Account wanneer zij het systeem willen gebruiken. bezit. Wizard De wizard is de software-entiteit binnen het systeem, die voorziet Gebruiker / User Een gebruiker is een natuurlijk persoon, die gebruik in het genereren, weergeven, ontvangen en verwerken van vragenlijsten ten maakt van het systeem, en derhalve een account bezit. Elke gebruiker is behoeve van de SoloTest en DuoTest. uniek, wat wil zeggen, dat elke natuurlijk persoon slechts één account mag hebben.

2.3

Requirements

Op basis van de opdrachtbeschrijving (te vinden in bijlage A), vergaderinQuatroStagioniTest / QST De QST is de lichte meerkeuze test, waarbij gen met de opdrachtgever, en de opzet requirements (te vinden in bijlage C), enkele grappige en ludieke vragen over de partners gesteld worden. hebben we het volgende MoSCoW diagram samengesteld, waarbij de Must Haves als minimale requirements zijn vastgesteld, en derhalve bij oplevering Relatie Een relatie is in het systeem een koppeling tussen minimaal twee ge¨ımplementeerd moeten zijn. accounts. Twee van deze accounts representeren de beide partners van een 1. Must Have tastbare relatie. Andere accounts, die aan een relatie gekoppeld zouden kunnen zijn, zijn accounts die de getuigen in het geval van een huwelijk • Account beheer representeren. – Registreren – Aanmelden Rol Elke gebruiker van het systeem bekleedt één of meerdere rollen, te – Gegevens wijzigen weten: – Rol aanduiding – Verzonden alerts raadplegen • Partner. Elke gebruiker mag deze rol maximaal één keer bekleden. • Wizard

• Getuige. Elke gebruiker mag deze rol een ongelimiteerd aantal keer bekleden.

– – – – – –

SoloTest en DuoTest / ST en DT De Solo- en DuoTest zijn lange, uitgebreide tests, waarbij alle aspecten van de relatie aan bod komen. Het verschil tussen beide is, dat bij de SoloTest slechts één partner wordt ondervraagd, terwijl bij de DuoTest beide partners aan bod komen. 2.3. REQUIREMENTS

3

Vragenlijst genereren Antwoorden verwerken Advies genereren Beantwoorde vragenlijsten raadplegen Adviezen raadplegen Vragen wijzigen (enkel voor CMS-gebruikers) HOOFDSTUK 2. ANALYSE

• Geschiedenis en statistieken

– Doorgeven echtscheidingen en beeindiging GPs. – Raadplegen van statistieken over inwoners van bepaalde gemeenten.

– Dagelijkse aanmeldingen en afmeldingen – Bezoeker statistieken – Gegevens een aantal jaar bewaren

3. Could Have

• Mediafunctionaliteit

• Vastleggen vermogensboedel bij huwelijkse voorwaarden

– Geluid – Flash

• Onderlinge communicatie – PM – Chat

• Content Management Systeem – – – – – –

Statistieken weergeven Alerts wijzigen Teksten op de website wijzigen Afbeeldingen op de website wijzigen Geluidsfragmenten op de website wijzigen Verwijderen / toevoegen / deactiveren / activeren accounts

• RSS – Nieuws – Mededelingen 4. Would Have • Webshop

• Overige voorwaarden

– Bestellen relatie gerelateerde artikelen – Cadeaus (voor bijvoorbeeld Valentijnsdag)

– Periodieke database backup – Vindbaarheid Google – Betaalmodule

Gedurende het project hebben er door voortschrijdend inzicht enige aanpassingen plaatsgevonden. We hebben hierbij enkel de Must Haves beschouwd, omdat de overigen niet relevant zijn voor het Bachelorproject. Een aantal van de requirements zijn hierdoor komen te vervallen of van inhoud gewijzigd.

2. Should Have • Getuigen – Bekijken gegevens partners – Vragenlijsten invullen – Adviezen verkrijgen

De vervallen requirements zijn de onderdelen, die betrekking hebben op de mediafunctionaliteit. Reden hiervoor is het aantrekken van een gespe• Gemeenten cialiseerde designer door de opdrachtgever. Deze designer is verantwo– Toevoegen nieuwe huwelijksinschrijvingen en geregistreerde ordelijk voor het grafische ontwerp van de website, en draagt hierbij ook partnerschappen zorg voor de eventuele integratie van Flash en geluidsfragmenten. 2.3. REQUIREMENTS

4

HOOFDSTUK 2. ANALYSE

de ontwikkeling van de wizard. Daarnaast was het efficienter, omdat hij de afhankelijkheden en restricties op dat moment beter kende dan Chris, en Chris zijn handen bovendien vol had aan de andere functionaliteiten van het CMS.

De inhoud en invulling van de requirements is gedurende het project vaak veranderd. Wat betreft het accountbeheer waren het voornamelijk wijzigingen in de door de opdrachtgever gewenste gegevens van gebruikers. Deze wijzigingen hadden uiteraard ook betrekking op de werking van het Content Management Systeem, terwijl de wizard buiten schot bleef. Desalniettemin is de invulling van de wizard aan veranderingen onderhevig geweest. Waar het idee eerst was om een korte en een lange test aan te bieden, heeft men op een gegeven moment het besluit genomen om één enkele - lange en relatief zware - test aan te bieden, en daarnaast nog een andersoortige test op te zetten, die meer lichtvoetig van aard is. Deze lichte test is niet aan de requirements toegevoegd, omdat we al redelijk ver in het project zaten toen deze beslissing genomen werd, en wij van mening waren, dat we dit niet in de beschikbare tijd zouden kunnen implementeren.

Kijkend naar de Must Haves van de requirements constateren we de volgende taakverdeling: • Chris – Content Management System • Sung-shik – Wizard

2.4

• Thijs

Planning en taakverdeling

– Account beheer Aan het begin van het Bachelorproject hebben we een globale planning – Geschiedenis en statistieken gemaakt met daarin een groffe verdeling van de te verrichten arbeid - requirements analyse, ontwerp, implementatie, testen - opgesplitst per onderdeel, – Overige voorwaarden welke te vinden is in bijlage H. In de laatste week van mei hebben we deze vervolgens aangevuld met een zeer gedetailleerde dagplanning om een beter We merkten al eerder op, dat de mediafunctionaliteit door de externe debeeld te krijgen van waar we op dat moment stonden, wat er nog gedaan signer is verzorgd. In bijlage H is een Gantt chart te vinden die de planning over tijd grafisch weergeeft. moest worden, en wat haalbaar was. In de eerste planning stond, dat Thijs zich voornamelijk bezig zou houden met de AJAX implementatie en de database. Gedurende het project bleek dit echter makkelijker dan voorzien, en is hij zich ook al snel bezig gaan houden met de website, wat een stuk bewerkelijker was dan verwacht. Hoewel het aanpassen, toevoegen, en wijzigen van vragen een onderdeel van het CMS is, heeft Sung-shik in plaats van Chris dit voor zijn rekening genomen, omdat hij bepaalde onderdelen al goed kon gebruiken voor 2.4. PLANNING EN TAAKVERDELING

5

HOOFDSTUK 2. ANALYSE

Hoofdstuk 3

Ontwerp 3.1

Website

informatie. Om al deze informatie uiteen te zetten zullen we een overzicht geven van de inhoud per tabel in de database in alfabetische volgorde. In De website is de schil van het geheel. Het is de representatie van alle bijlage E is een volledig database diagram te vinden. content naar de gebruikers toe en bepaalt in grote mate de sfeer van de site. Een zeer belangrijk aspect van de website is dat hij gebruiksvriendelijk alert - bevat de alerts welke verzonden kunnen worden aan gebruikis. Niet elke gebruiker is een computerexpert dus hier zal rekening mee ers gehouden moeten worden. Ook moet er een goede structuur ontwikkeld answer - bevat de antwoorden die gegeven zijn bij een test van de wizard worden zodat er makkelijk delen toegevoegd kunnen worden aan de site. child - bevat de kinderen van een relatie Met name ook voor eventuele anderen die zullen werken aan de site in de class - bevat verschillende klassen welke nodig zijn voor de wizard toekomst is de structuur een belangrijk item. In dit deel van het verslag cms user - bevat de gebruikers van het CMS zullen we een korte toelichting geven over het ontwerp per onderdeel. Te consult - bevat de tests die door een partner aangevraagd zijn beginnen met de database welke een zeer relevant onderdeel van de site is, content - bevat de inhoud van verscheidene pagina’s van de website aangezien hier een hoop content van de site in komt. Vervolgens een stukje education - bevat opties voor het onderwijs dat een gebruiker genoten heeft over AJAX, de structuur, accountbeheer en te besluiten met het design van ethnic - bevat opties voor de etnische achtergrond van een gebruiker de site en ook gelijk de bovenste laag van het geheel. event - bevat events welke onder andere nodig zijn voor de winQs image - bevat de afbeeldingen van de gebruikers menu - bevat de verschillende menugroepen 3.1.1 Database menuitem - bevat de menuitems, vaak gerelateerd aan menu en/of content Zoals al reeds gemeld in de inleiding bevat de database onder andere occupation - bevat opties voor het beroep van de gebruiker een groot deel van de content van de website, maar ook een hoop andere partner - bevat de gerelateerde partners 6

preference - bevat de belangrijkheid van een sectie bij een door iemand ingevulde vragenlijst question - bevat alle vragen van de wizard questionnaire - bevat de vragenlijsten, die bij een test horen relation - bevat een relatie relationstatus - bevat opties voor de status van een relatie religion - bevat opties voor het geloof van de gebruiker section - bevat de verschillende secties waarin een vragenlijst ingedeeld is sentalert - bevat de verzonden alerts session - bevat de sessies van gebruikers, van inloggen tot uitloggen subclass - bevat de verschillende subklassen welke nodig zijn voor de wizard subsection - bevat de onderverdeling van sections in subsections text nl - bevat alle nederlandstalige regels en stukjes statische tekst van de website user - bevat alle informatie van een gebruiker visitor - bevat verschillende informatie van een willekeurige bezoeker voucher - bevat informatie voor een voucher welke cadeau gedaan kan worden winq - bevat de winqs welke verstuurd worden aan gebruikers winq type - bevat de verschillende typen winqs witness - bevat alle informatie van een getuige

en een relation id bevat. Deze verwijzen direct naar het user id in de tabel user en het relation id in de tabel relation. Op deze manier wordt een gebruiker gekoppeld aan een relatie.

Allerlei verschillende soorten informatie zijn opgeslagen in de database zoals duidelijk zichtbaar. Allergrootste voordeel van een database is dat gegevens makkelijker gewijzigd kunnen worden. Vooral met behulp van een CMS welke gekoppeld wordt aan de database kan ook een reguliere gebruiker content van de website wijzigen en/of bekijken.

Om met de tijd mee te gaan hebben we gelijk in het begin van het project al besloten om de AJAX techniek toe te passen in de website om zo een soort Web 2.0 website te krijgen. Dit geeft gelijk ook een moderne uitstraling en brengt een hoop gebruiksvriendelijkheid met zich mee. Een voorbeeld van een AJAX feature die we gebruikt hebben is het weergeven van het sterrenbeeld zodra een geboortedatum ingevuld is.

Een goede databasestructuur is belangrijk, voornamelijk voor de toekomst. Als de site eenmaal actief is, is het niet meer zo makkelijk om tabellen aan te passen en het kan gebeuren dat een aantal statistieken incompleet zijn omdat hier van te voren te weinig rekening mee gehouden is. Kolommen toevoegen aan een tabel is later nog wel mogelijk, de data hierin zal echter vaak alleen gelden voor nieuwe records. Het is dus zeer belangrijk om van te voren goed te overdenken welke gegevens in de database komen en om eventueel tijdens het proces nog tabellen aan te passen en/of toe te voegen.

3.1.2

AJAX

Mede dankzij de grote toepassing in de webservices van Google en Amazon is AJAX een veelgebruikte techniek op het Internet geworden. AJAX staat voor Asynchronous Javascript And XML en is een term voor het ontwerp van interactieve websites waarin asynchroon gevraagde gegevens worden opgehaald van de webserver. Het is hierdoor niet meer nodig om pagina’s volledig op te halen elke keer als er informatie opgevraagd wordt.

Om alles zo dynamisch mogelijk te houden is ervoor gekozen om veel geDe techniek die wij gebruiken is echter niet volledig AJAX. De afkorting bruik te maken van relationele databases wat uiteindelijk inhoud dat tabellen met elkaar in verbinding staan. Zo is er een tabel partner welke een user id zou eigenlijk AJAJ moeten worden aangezien wij geen gebruik maken van 3.1. WEBSITE

7

HOOFDSTUK 3. ONTWERP

Om de structuur iets duidelijk te kunnen omschrijven zullen we een heel XML maar van JSON. In de praktijk is hier echter niets van te merken. Het is slechts een andere manier voor het transporteren van data tussen, in ons globaal overzicht geven van een aantal files die betrokken zijn in het geheel. geval, php en javascript. engine.php In eerste instantie wilden we vrijwel alles met AJAX transporteren. Hier Verwijst naar de verschillende delen, welke gekoppeld zijn aan de website. hebben we echter vanaf gezien, omdat dit niet in alle gevallen efficient en gebruiksvriendelijk is. Bij een refresh of bij een druk op de ¨terug¨ knop van engine nrt.php de browser zou toepassing van AJAX namelijk betekenen, dat niet hetgeen Bevat alle functies, die te maken hebben met de website. Deze linkt ook gebeurt wat men verwacht dat er gebeurt. Bij refresh zal men uitkomen op naar objecten en andere subfiles, die hierbij gebruikt worden. de beginpagina en bij het kiezen voor ¨terug¨ zal de gebruiker op de pagina komen voordat de NRT pagina bezocht werd. AJAX wordt nu slechts engine wizard.php toegepast op kleine elementen die een duidelijk dynamische tint aan de pag- Bevat alle functies welke te maken hebben met de wizard. Deze linkt ook ina meegeven. Neem onder andere het voorbeeld van het sterrenbeeld, maar naar objecten en andere subfiles welke hierbij gebruikt worden. zo zit er ook een krachtmeter in voor een ingevoerd wachtwoord. engine cms.php Ook in de wizard wordt de AJAX techniek toegepast. Dit heeft echter Bevat alle functies, die te maken hebben met het CMS. Deze linkt ook naar voornamelijk als reden, dat het stukken efficienter is om kleine brokjes code objecten en andere subfiles, die hierbij gebruikt worden. bij de server op te vragen, dan in één keer de volledige pagina. Door de engine ajax.php AJAX techniek wordt nu alleen het deel geladen dat nodig is. Zoals de naam al vertelt is dit het AJAX gedeelte. Via javascript wordt er verwezen naar deze file en deze stuurt requests naar een andere file welke 3.1.3 Structuur vervolgens weer data teruggeeft. We hebben nu een aantal belangrijke items gehad, met name de database en de AJAX techniek. Dit alles moet zo goed mogelijk samen met elkaar engine ajax functions.php werken. Alleen een database is niet genoeg. De gegevens moeten ook daad- De AJAX engine verwijst naar deze file en deze file vangt vervolgens alle werkelijk gebruikt worden. De AJAX techniek is leuk maar het moet wel verzoeken op. Aan de hand van een variabele verwijst deze file door naar makkelijk gebruikt kunnen worden zonder een hoop extra code er aan te functies welke de daadwerkelijke data zullen verwerken. Vervolgens zal deze spenderen. Al met al is het belangrijk om een goede structuur aan te bren- file een antwoord geven in JSON formaat. gen in de website. Hiervoor hebben we een door onszelf zo genoemde ’engine’ gebouwd. Zoals de term al doet vermoeden is dit het hart van de site en engine db con.php zorgt deze ervoor dat het geheel blijft draaien. Daarnaast verbindt het alle Dit is de connectie module om data te verkrijgen uit de MySQL database losse elementen met elkaar. 3.1. WEBSITE

8


of om data weg te schrijven naar de database, welke door alle delen van de de hand van variabelen - meegegeven in de URL - uitzoekt welke pagina site gebruikt kan worden. geladen moet worden. In veel van de gevallen is hier een functie geschreven welke een opzet genereert met daarin de benodigde variabelen. Zoals hierboven al te zien is, verbindt de engine.php de losse delen van de site met elkaar. Website, wizard en CMS worden op deze manier Voor zowel de Google zoekbots als voor de gebruikers hebben we de samengevoegd. Als een bepaalde file gebruik wil maken van alle functies, URL’s geformatteerd tot een beter leesbaar geheel. Hiervoor is een module die omgaan in de site, dan hoeft deze slechts gebruik te maken van deze beschikbaar welke gebruikt wordt door Apache (de Webserver). Wat engine.php file. normaal gesproken zou bestaan uit: http://www.wizzlove.com/index.php?cat=main$\&$page=1

Dat alle functies bereikbaar zijn brengt echter ook nadelen met zich mee. Grootste nadeel is, dat er heel goed rekening gehouden moet worden met functienamen. Een functienaam die in zowel de website als de wizard hetzelfde is, zal een foutief functionerende website generend, resulterend in een wit scherm. Dit is iets wat we uiteraard willen voorkomen. Om deze reden hebben we prefixes in het leven geroepen. Functies die te maken hebben met de wizard zullen beginnen met engine wizard waarna de functienaam zal volgen. Functies die te maken hebben met de CMS beginnen met engine cms en tenslotte de functies die te maken hebben met de website beginnen met engine nrt . Voordeel buiten de compatibiliteit is dat er ook een beter overzicht ontstaat. Het is direct duidelijk in welk deel van de site een bepaalde functie zich bevindt. Nu we nog met alles vers in het hoofd aan het werk zijn zal dit niet altijd een probleem zijn. In de toekomst zal het echter niet meer zo vers in het hoofd zitten. Buiten dat zullen er ook andere mensen aan de site gaan werken.

wordt nu omgezet tot http://www.wizzlove.com/main/1 De tweede opzet is vele malen duidelijker en ook gelijk korter. Google leest hierbij ook gelijk de pagina als een aparte pagina terwijl normaal gesproken alle pagina’s beginnend met index.php gegroepeerd worden. Om Google ook nog een stukje te helpen met kernwoorden hebben we ook een fictieve html file meegegeven in de URL wat resulteert in het volgende: http://www.wizzlove.com/main/1/Beginpagina.html

Uiteraard bevat deze fictieve html pagina per pagina een andere naam. De naam is samengesteld uit de titel van de pagina met daarachter een .html geplakt. Titels bestaande uit meerdere woorden zullen samengevoegd Een aantal pagina’s wordt op eenzelfde wijze weergegeven door direct data worden met behulp van streepjes (-). uit de database te verkrijgen. Dit is echter niet in alle gevallen mogelijk. Reden hiervoor is dat een groot aantal pagina’s dynamische teksten bevatten Een van de voorwaarden die we kregen was dat de website meertalig welke uit andere tabellen van de database komen. Deze pagina’s moeten dus op een andere manier opgevangen worden. Voor deze en andere bijzondere opgezet moet kunnen worden. Gevolg hiervan is dat alle Nederlandstalgevallen is er een init() functie geschreven in de engine nrt.php, welke aan ige tekst in de files ook in de database verwerkt moet worden. Met behulp 3.1. WEBSITE

9


van categorienamen en tags worden deze opgeslagen. Voordeel hiervan is dat precies dezelfde database gemaakt kan worden met bijvoorbeeld Engelstalige tekst erin verwerkt. Toch zal ook met de huidige structuur nog een hoop werk verzet moeten worden om de site volledig te vertalen. Dit werk is echter aan de sitebeheerder aangezien de code hier volledig op toegespitst is.

kinderen die een stel samen heeft. Wijzigingen zijn eventueel nog mogelijk door te voeren vanuit de laatste stap door terug te gaan naar de vorige stappen.

Als alle informatie van de drie stappen correct is ingevuld dan zal de registratie daadwerkelijk uitgevoerd worden. Alle informatie zal weggeschreven worden in de daarvoor bestemde tabellen. Bij het wegschrijven wordt het 3.1.4 Accounts account nog op non-actief gezet. Deze zal pas op actief gaan zodra de betalEen van de belangrijkste punten van de website zijn natuurlijk de ge- ing voldaan is. De betaling kan voltooid worden aan de hand van de e-mail bruikers. Hierbij kan je onderscheid maken tussen bezoekers en leden. De die verzonden wordt zodra de registratie voltooid is. bezoekers zullen andere delen van de website zien dan de leden. De leden Zodra de registratie en de betaling voltooid is kan de gebruiker de hebben volledig toegang tot de mogelijkheden, die de website te bieden heeft. De bezoekers zouden door de site gestimuleerd moeten worden om ook lid bevoegdheid krijgen om de ledensectie van de website te betreden. Vanaf te worden. Vandaar zullen deze voornamelijk tekst voorgeschoteld krijgen hier wordt het ook mogelijk de wizard te gebruiken en winQs toegestuurd te krijgen. Uiteraard is het dan ook mogelijk om eerder ingevoerde gegevens welke de kracht van de website weergeeft. aan te passen. Ook is het leuk om een pasfoto toe te voegen zodat het stel Om lid te worden is het noodzakelijk om jezelf te registreren. Dit proces op de loginpagina samen in beeld komen. is nog redelijk complex aangezien alle data onder andere gecontroleerd moet worden op validiteit. Zo moet een mobiele telefoonnummer bestaan uit tien 3.1.5 Design cijfers en zal een e-mail adres moeten bestaan uit een bepaalde structuur Mede door gebrek aan tijd en voornamelijk ook gebrek aan ervaring op voor deze als valide wordt bestempeld. Als niet alle gegevens goed zijn het gebied van webdesign is er voor het uiterlijk van de website een derde ingevuld dan krijgt de gebruiker hier een melding van. aangetrokken. Deze heeft een ontwerp gemaakt van de verschillende delen Voor het registratieproces is gekozen voor een stappenplan. In dit geval van de website welke vervolgens door ons daadwerkelijk ge¨ımplementeerd betreft het drie stappen. De eerste stap is de registratie voor de eerste wordt. partner. De volgorde hierin maakt niet uit, en wordt bepaald door degene die als eerste het toetsenbord ter hand neemt. De tweede stap is de registratie van de tweede partner. Bij het registratieproces wordt niet gekeken naar geslachten. Zo is het dus mogelijk om een relatie bestaande uit twee mannen of vrouwen te hebben. De derde en laatste stap bestaat uit de gezamenlijke gegevens. Hieronder valt informatie als de status van de relatie maar ook de 3.1. WEBSITE

Alle informatie met betrekking tot opmaak en layout van de pagina’s staat opgeslagen in CSS files. Hierdoor is het mogelijk om in de toekomst de website een compleet andere look-and-feel te geven door slechts deze files en de benodigde plaatjes aan te passen. Bepaalde speciaal vormgegeven elementen zijn echter wel ook codetechnisch aangepast op het design. Hier is

10


echter nog steeds heel veel ruimte voor aanpassing, ook zonder het aanpassen die daarbinnen vallen behandelen een specifiek onderwerp, dat binnen dat domein van relevantie is. Een voorbeeld is de parent section De Relatie met van de code. de child section Stabiliteit. In het ontwerp van de database hebben we er overigens rekening mee gehouden, dat deze boomstructuur in de toekomst 3.2 Wizard dieper - en eventueel zelfs cyclisch - gemaakt kan worden. Eerder in dit document hebben we de wizard gedefinieerd als de softwareentiteit binnen het syteem, die voorziet in het genereren, weergeven, ontvangen en verwerken van vragenlijsten ten behoeve van de SoloTest en DuoTest. In deze sectie zullen we het ontwerp van de wizard nader toelichten, waarbij zowel het proces als de technische details aan de orde zullen komen. Bij aanvang van het project was bij de opdrachtgever niet duidelijk hoe de wizard er precies uit moest komen te zien. Er bestond een globaal doch vaag idee, en op het conceptuele vlak zijn wij nauw betrokken geweest bij de uitwerking hiervan. De uiteindelijke flowchart is te vinden in bijlage G.

Na overleg met de opdrachtgever werd besloten, dat alle vragen van het type Hoe waardeer je ... op een schaal van nul tot honderd zouden worden. Het liefst zou men uiteraard kiezen voor open vragen, maar het redeneren met de antwoorden zou in een dergelijke vorm in die mate complex worden, dat al vlug duidelijk werd, dat dat op dit moment geen optie is. Hoewel alle vragen hetzelfde van opzet zijn, hebben enkele van hen een speciale waarde. Deze vragen zijn de sleutelvragen - key questions - van een parent- of childsection, wat inhoudt, dat het antwoord op deze vragen iets concluderends zegt over de desbetreffende sectie. Besloten werd, dat deze key questions immer aan het einde van een parent- of child section gesteld zouden worden, 3.2.1 Het eerste ontwerp waarbij de initiële waarde van het antwoord - standaard is deze gelijk aan Nadat de requirements in overleg met de opdrachtgever vastgesteld waren, nul - bepaald zou worden door antwoorden op aan de sectie gelieerde vragen, konden we beginnen met het ontwerp van de in zijn ogen belangrijkste die eerder in de test gesteld zouden worden. component van het systeem. We zijn begonnen met het opzetten van een database diagram, waarin we de belangrijkste entiteiten van het systeem Omdat mensen niet alle onderdelen van een relatie even belangrijk vinden, gemodelleerd hebben. Op dat moment was het heersende beeld van de wiz- is het van belang, dat alle vragen op een wijze gewogen worden, die het meest ard anders dan hoe de wizard uiteindelijk ge¨ımplementeerd is. relevant is voor de individuele gebruiker. De oplossing, die we hier voor Aanvankelijk had men voor ogen, dat de wizard twee verschillende - een korte en een uitgebreide - vragenlijsten zou genereren op basis van eenzelfde set vragen, waaruit gekozen kon worden. Voor deze opzet is vervolgens een ontwerp gemaakt, waarbij een vragenlijst ingedeeld is in secties - parent sections - en subsecties - child sections - waarbij een parent section één of meerdere child sections en vragen kon bevatten, en een child section slechts vragen. Elke parent section betreft een bepaald domein, en de child sections 3.2. WIZARD

vonden in dit eerste ontwerp, was het aan de gebruiker vragen van de mate van belangrijkheid die hij of zij aan het onderwerp van een bepaalde sectie zou toekennen. De vorm, waarin deze vraag gesteld werd, was wederom op een schaal van nul tot honderd. Deze waarden zouden we vervolgens kunnen afbeelden op een wegingsfactor - in een gesprek is eens een bereik tussen een half en vier benoemd - waarmee het gegeven antwoord vermenigvuldigd zou kunnen worden. Tevens moest het mogelijk zijn om aan te geven, dat bepaalde secties niet van toepassing zijn.

11


Zoals reeds verteld waren de gebruikers in deze opzet van de wizard vrij om voor een lange of een korte test te kiezen. Bij de korte test werden enkel de key questions gevraagd per sectie, terwijl de lange test naast deze key questions ook meer gedetailleerde vragen stelde. Daarnaast was het de bedoeling, dat bepaalde secties in de korte test in het geheel niet gesteld zouden worden op basis van de door de gebruiker aangegeven importantie. Het idee hierachter was, dat je iemand niet wil vermoeien met vragen, die iets behandelen wat hij of zij toch niet belangrijk vindt.

De partners zijn het niet met elkaar eens. Het verschil in antwoord is groter dan dertig. Het advies zou opgebouwd worden middels een top-down approach, waarbij eerst een overzicht werd gegeven van de resultaten wat betreft de parent sections, en waarna vervolgens middels drop-down elementen een gedetailleerder overzicht zou kunnen worden opgevraagd door de gebruiker.

3.2.2 Bij aanvang was niet duidelijk, wat en hoe de resultaten van een ingevulde test naar de gebruiker geprojecteerd moest worden. Gaandeweg de eerste vier weken van het project is daar langzaam een beeld bij ontstaan. Wanneer een test is gedaan, hebben we in principe twee lijstjes - één van elke partner - van waarderingen. Het leek ons het meest logisch om deze antwoorden met elkaar te vergelijken, waardoor discrepanties zichtbaar worden. Deze verschillen - maar ook de overeenstemming - zouden vervolgens gecategoriseerd worden in een viertal klassen, te weten:

De revisie

Op een gegeven moment werd voor de opdrachtgever duidelijk, dat de opzet met een lange en een korte test niet de juiste was. De korte test begon namelijk steeds meer op de lange test te lijken, door het wegvallen van vragen. Tevens ontstond de opvatting, dat er ook een test moest komen, die niet door beide partners gedaan zou hoeven te worden, omdat beide partners mogelijkerwijs niet even gemotiveerd zijn om aan de test mee te doen. Deze twee factoren leidden er toe, dat het ontwerp van de wizard herzien moest worden.

• Positieve overeenstemming Omdat de korte test geen toevoegende waarde meer had, kwam deze te Beide partners zijn het met elkaar eens aan de positieve kant van het spectrum. Het verschil in antwoord is minder dan vijftien en het laagste vervallen. Zijn plaats werd opgevuld door de SoloTest. In het kader van consistentie werd de uitgebreide test tot DuoTest omgedoopt, maar in essentie antwoord is hoger dan vijftig. veranderde daar niets aan. De SoloTest bevat precies dezelfde vragen als • Negatieve overeenstemming de DuoTest, maar de interpretatie van de antwoorden geschiedt op andere Beide partners zijn het met elkaar eens aan de negatieve kant van het wijze, door het wegvallen van de antwoorden van de partner, waardoor er spectrum. Het verschil in antwoord is minder dan vijftien en het laagste niet meer vergeleken kan worden. antwoord is lager dan vijftig. De vraagstelling is niet veranderd, maar uiteindelijk bleek wel, dat er niet • Parti¨ ele overeenstemming veel non-key questions benodigd waren. Dit was ook een van de redenen, dat Beide partners zijn het ten dele met elkaar eens. Het verschil in antwode korte test erg veel op de uitgebreide test begon te lijken. De vragen met ord ligt tussen vijftien en dertig. betrekking tot importantie zijn komen te vervallen, en vervangen door een soort taart. Deze taart is opgedeeld in een aantal punten gelijk aan het aantal • Geen overeenstemming 3.2. WIZARD

12


child sections binnen een parent section. Gebruikers kunnen deze punten vergroten en verkleinen, wat respectievelijk het verzwaren en verlichten van de weging van een child section binnen een parent section representeert. Deze aanpasbare taart wordt aan het einde van een parent section aan de gebruiker aangeboden, waarbij tegelijkertijd het antwoord op de key question van de parent section wordt aangepast. Hierdoor kunnen gebruikers zien of de door de software berekende waardering overeenkomt met de gevoelsmatige, en dit aanpassen door sommige child sections zwaarder mee te laten tellen ten op zichte van andere. In deze opzet is het niet meer mogelijk om de waarde handmatig aan te passen - zonder de taart te gebruiken - wat bij de eerste opzet nog tot de mogelijkheden behoorde. Een andere wijziging ten opzichte van de eerste opzet is het moment waarop de importantie wordt bepaald. In de allereerste opzet was dat bij aanvang van de test, tijdens het ontwerp en implementatie van de eerste opzet is dat verschoven naar de aanvang van de desbetreffende child section, en in het uiteindelijke ontwerp wordt de taart aangeboden aan het einde van de parent section.

met interpretaties van de wizard zelf. Hiervoor wordt gebruik gemaakt van de antwoorden van partnerX en partnerY bij de parent section die handelt over de relatie.

• Je partner over zichzelf Een overzicht van wat partnerY van zichzelf vindt. Hiervoor wordt gebruik gemaakt van de antwoorden van partnerY bij de parent section, die vragen stelt over hoe je jezelf ziet.

• Je partner over jou Een overzicht van wat partnerY van partnerX vindt. Hiervoor wordt gebruik gemaakt van de antwoorden van partnerY bij de parent section, die vragen stelt over hoe je je partner ziet.

• Jij over jezelf In de eerste versie van de vragenlijst stonden er vijf verschillende parent Een overzicht van wat partnerX van zichzelf vindt. Hiervoor wordt sections, waarbij één - deze handelt over de relatie - met zichzelf vergeleken gebruik gemaakt van de antwoorden van partnerX bij de parent section, werd tijdens de interpretatie en de andere vier paarsgewijs. Uiteindelijk is die vragen stelt over hoe je je jezelf ziet. deze vragenlijst gereduceerd tot drie parent sections, waarbij naast de relatie twee niet-paarsgewijs-vergelijkbare parent sections overbleven, namelijk een sectie over hoe partnerX zichzelf ziet, en een andere over hoe partnerX partnerY ziet. Besloten werd om bij het weergeven van het advies de top-down De ene partner krijgt hierdoor dus inzicht in alle antwoorden, die de andere benadering - in de vorm van virtuele tabbladen - te behouden, en deze onder partner heeft gegeven. te verdelen in een vijftal onderdelen: • Algemeen Een zeer algemeen overzicht van de hoe de wizard de relatie interpreteert.

Inmiddels ontstond er ook meer duidelijk over de interpretatie en categorisering van de antwoorden. De vier klassen zijn uitgebreid naar drie hoofdklassen en drie subklassen. De combinaties van deze klassen leveren • De relatie Een overzicht van wat beide partners van de relatie vinden, aangevuld voorts negen klassen op. 3.2. WIZARD

13


Rampzalige overeenstemming Risicovolle overeensteming Veilige overeenstemming Rampzalig compromis Risicovol compromis Veilig compromis Rampzalig meningsverschil Risicovol meningsverschil Veilig meningsverschil

0 ≤ score ≤ 15 0 ≤ score ≤ 15 0 ≤ score ≤ 15 16 ≤ score ≤ 30 16 ≤ score ≤ 30 16 ≤ score ≤ 30 31 ≤ score ≤ 100 31 ≤ score ≤ 100 31 ≤ score ≤ 100

0 ≤ answer ≤ 45 46 ≤ answer ≤ 60 61 ≤ answer ≤ 100 0 ≤ answer ≤ 45 46 ≤ answer ≤ 60 61 ≤ answer ≤ 100 0 ≤ answer ≤ 45 46 ≤ answer ≤ 60 61 ≤ answer ≤ 100

Rampzalig antwoord Risicovol antwoord Veilig antwoord

0 ≤ answerX ≤ 45 46 ≤ answerX ≤ 60 61 ≤ answerX ≤ 100

Het antwoord op elke key question wordt aan de hand van bovenstaande tabellen gecategoriseerd. Omdat de key questions samenvattend en concluderend voor een child section zijn, meenden we dat het niet nodig is om ook nog de individuele vragen te beschouwen bij het interpreteren van de antwoorden. In de database staat voor elke combinatie van klasse en sectie een stukje tekst, dat als interpretatie dient voor die situatie. Concreet betekent dit, dat er ongeveer driehonderd verschillende teksten opgeslagen zijn.

Hierbij geldt:

3.2.3

Quattro Stagioni

3.2.4

Detailontwerp

• answerX : Het antwoord tussen nul en honderd, dat gegeven is door Tijdens de uitwerking van het herziene ontwerp van de wizard, stelde de oppartnerX. drachtgever een nieuwe test voor, die wat lichtvoetiger van aard zou worden, • answerY : Het antwoord tussen nul en honderd, dat gegeven is door dan de Solo- en DuoTest. Deze test zou elk seizoen ververst moeten worden met nieuwe vragen, wat de naam Quattro Stagioni verklaart. Omdat partnerY. het implementeren van een dergelijk nieuwe test te veel tijd in beslag zou nemen, is besloten, dat deze niet ge¨ımplementeerd zou worden tijdens het • score : Het absolute verschil tussen answerX en answerY. Bachelorproject. score = abs(answerX - answerY) • answer : Het minimum van de twee gegeven antwoorden. answer = min(answerX, answerY)

De hierboven gegeven klassering is enkel relevant in het geval dat er daadwerkelijk scores berekend kunnen worden. Dit geldt alleen voor de secties, waarin vragen worden gesteld, waarvan de antwoorden tussen de partners vergeleken worden. Voor de parent sections waarvoor dit niet het geval is, blijven er slechts drie klassen over: 3.2. WIZARD

In deze sectie zullen we dieper ingaan op het ontwerp van de Wizard. We onderscheiden hierin de volgende componenten, welke we beurtelings zullen bespreken:

14

• PHP • Javascript • CSS HOOFDSTUK 3. ONTWERP

Merk op, dat we HTML niet specifiek benoemen in deze enumeratie. Dit komt, doordat alle HTML code door PHP gegenereerd wordt, wat meer uivoerig besproken zal worden bij de behandeling van PHP. PHP Hoewel de wizard het belangrijkste onderdeel van het systeem is, is het technisch gezien een module, die in principe aan elke website toegevoegd zou kunnen worden, mits ondersteund door een correcte database architectuur. Om de onderhoudbaarheid van de wizard te garanderen is deze opgebouwd uit een zestal PHP bestanden, waarvan er slechts één aan de integrerende pagina toegevoegd hoeft te worden. Deze zes bestanden zijn: • engine wizard.php Dit is de interface van de wizard naar de buitenwereld. Dit bestand voorziet in de communicatie tussen de wizard en de integrerende pagina, en voegt zelf de overige PHP bestanden toe, waardoor de integrerende pagina slechts engine wizard.php hoeft toe te voegen.

zijn er geen monolitische functies, die grote stukken code produceren, maar wordt er telkens een klein stukje HTML gereturneerd. • engine wizard ajax.php De AJAX requests van de client worden allereerst door de ajax-engine opgevangen, waarna - in het geval van de wizard - een functie wordt aangeroepen uit dit bestand, die voorziet in de verdere verwerking van de request. Al deze functies wijzen een stukje HTML toe aan een bepaalde div in de pagina. • engine wizard tech.php In dit bestand staan een aantal handige en wederkerende functies, die door alle bij de wizard horende bestanden worden gebruikt. • engine wizard db.php Alle database queries ten behoeve van de wizard staan in dit bestand. Het is mogelijk, dat bepaalde queries in dit bestand ook in bijvoorbeeld het query-bestand van het CMS staan. Hoewel dit voor enige redundatie zorgt, hebben we toch voor deze opzet gekozen om de modulariteit te vergroten en afhankelijkheden tussen deelsystemen zo beperkt mogelijk te laten.

• engine wizard core.php Dit bestand bevat de code, die op de server uitgevoerd moet worden ten behoeve van de toestand van de server en de database zelf. Omdat het In tegenstelling tot de meeste systemen, die we tijdens onze opleiding berekenen van resultaten iets is, wat direct gebeurt na het ontvangen gezien en geprogrammeerd hebben, is de wizard geen object georienteerd van een ingevulde vragenlijst, en de weergave zuiver HTML betreft en systeem. Hoewel PHP de mogelijkheden biedt, zagen we de noodzaak van geen calculaties meer vereist, staat in dit bestand enkel code voor het object orientatie niet in voor een systeem als dit. Wat zwaar gewogen heeft verwerken van een ingevulde vragenlijst. bij het maken van deze beslissing, is het feit, dat HTTP in beginsel een stateless protocol is. Dit betekent, dat bij elke HTTP-request - in het geval van • engine wizard html.php Alle HTML code ten behoeve van de wizard wordt door in dit be- een volledig object-georienteerd systeem - het gehele programma opnieuw stand staande PHP code gegenereerd op de server. De functies kunnen ge¨ınitialiseerd en opgebouwd moet worden. Naast de vertragende factor is in twee categorieën worden ingedeeld. Enerzijds zijn er functies voor het ook een extra - onnodige - belasting van de server. Overigens maakt de het weergeven van een vragenlijst en anderzijds de functies voor het wizard wel gebruik van de object-georienteerde database connectie module, weergeven van een test resultaat. Omdat we gebruik maken van AJAX die we geschreven hebben als wrapper om PDO. 3.2. WIZARD

15


• wizard result.css In dit bestand wordt alle CSS gedeclareerd ten behoeve van het weergeven van test resultaten binnen de overlay.

Javascript De wizard maakt hevig gebruik van Javascript op zowel grafisch gebied als het gebruik van AJAX. Omdat de wizard in een half-transparante overlay wordt afgebeeld op de gewone pagina, is er Javascript code benodigd voor het tonen en verwijderen van deze overlay. Omdat Javascript niet zo eenvoudig toegevoegd kan worden als PHP, moest er een afweging gemaakt worden tussen twee kwaden. Enerzijds is het het meest overzichtelijk om de Javascript code over meerdere bestanden te verspreiden. Het nadeel hiervan is echter, dat er zeer veel verschillende bestanden aan de integrerende pagina - in dit geval index.php - moeten worden toegevoegd. Aan de andere kant was er de mogelijkheid van een groot monolitisch Javascript bestand, wat onoverzichtelijkheid als nadeel heeft. Geheel naar Nederlands gebruik hebben we uiteindelijk voor een compromis gekozen, en de code verspreid over twee bestanden:

3.3

Content Management Systeem

Het Content Management Systeem (CMS) is een belangrijk onderdeel van dit project. Het dient voornamelijk om het voor de administrators eenvoudiger te maken om wijzigingen toe te passen op verschillende onderdelen van de website en om de gebruikers-accounts te beheren. Er zijn veel verschillende open-source en ook commerciële CMS te vinden op het internet. Echter, in ons geval moet er veel specifieke functionaliteit aanwezig zijn, welke we zullen bespreken in de eerstvolgende sectie. Hierdoor is besloten om zelf een eigen CMS te ontwikkelen. In deze paragraaf bespreken we verder de opzet van de bestandsstructuur, vervolgens een sectie over een tekst editor, daarna een duidelijke specificatie van het fenomeen ’WinQs’, om te eindigen • wizard overlay.js met een stukje over het uiterlijk van het CMS. Voor een uitgebreide handleiDit bestand bevat alle code voor het tonen en verwijderen van de overding van het Content Management Systeem, zie bijlage J. Voor een sitemap, lay. zie bijlage I. • wizard content.js Dit bestand bevat alle code voor de inhoud, die de overlay krijgt. Hi- 3.3.1 Verschillende functies eronder valt zowel de test zelf, als het resultaat van een gemaakte test. Het CMS kent 6 basis-functies:

CSS

• Edit website

Wat betreft de CSS code hadden we hetzelfde probleem als met de Javascript bestanden. Ook in dit geval hebben we voor een tussenoplossing gekozen, waarbij we gebruik maken van een drietal CSS bestanden:

• Edit Wizard • Edit WinQs

• wizard overlay.css In dit bestand wordt alle CSS gedeclareerd ten behoeve van de overlay.

• Manage CMS gebruikers

• wizard questionnaire.css In dit bestand wordt alle CSS gedeclareerd ten behoeve van het weergeven van een vragenlijst binnen de overlay.

• Bekijk statistieken

3.3. CONTENT MANAGEMENT SYSTEEM

16

• Manage NRT gebruikers


Edit website

Manage NRT gebruikers

Dit is in feite waar de meeste Content Management Systemen voor gebouwd Hier kunnen de accounts van alle leden van de Nationale Relatietest bekeken zijn: het eenvoudig kunnen aanpassen van tekstuele en grafische inhoud van worden. Accounts kunnen worden geactiveerd, gewijzigd, of verwijderd. Ook kunnen hiervandaan e-mails verzonden worden naar gebruikers. websites, met behulp van een WYSIWYG editor (zie 3.3.2). Bekijk statistieken Edit Wizard Hier moet de centrale vragenlijst aangepast kunnen worden; vragen kunnen worden toegevoegd of verwijderd. Ook kan hier de vragenlijst ’getest’ worden aan de hand van ingevulde waarden: de administrator kan een soort dummytest invullen (dwz. voor elke vraag een score van de ene en een score van de andere partner invullen in een tabel), waaruit vervolgens de resultaten weergegeven worden. Dit om snel en eenvoudig te kunnen controleren of bepaalde redenaties goed worden gegeven.

Van alle ingevulde vragenlijsten kunnen hier specifieke anonieme statistieken opgevraagd worden. Er kan gefilterd worden op gebruikers, zodat statistieken opgevraagd kunnen worden, toegepast op een bepaalde groep. Op deze manier kan er waardevolle informatie uit de vragenlijsten gehaald worden; onderzoekers of psychologen kunnen een hypothese of vraagstelling testen (een simpel voorbeeld: ’Hoe verhoudt het zelfbeeld van mannen zich tot het beeld dat vrouwen van hen hebben?’) aan de hand van de beschikbare gegevens.

3.3.2

Edit WinQs In deze sectie kunnen alle verschillende soorten WinQs (persoonlijke berichten) aangemaakt en/of verzonden worden. Er wordt onderscheid gemaakt tussen drie categorieën: collectieve standaard WinQs, individuele standaard WinQs, en handmatig aangemaakte WinQs. Voor meer informatie over WinQs, zie paragraaf 3.3.3.

WYSIWYG editor

Om content van websites aan te passen, zijn er op het internet verschillende kant en klare tekst editors te vinden, die ge¨ıntegreerd kunnen worden in de eigen code. Deze worden ’What You See Is What You Get’ (WYSIWYG) editors genoemd. De gebruiker kan op een visuele manier tekst, opmaak, afbeeldingen e.d. bepalen, welke door de editor omgezet worden naar HTML code.

Er bestaan verschillende commerciële en open source editors. We hebben uiteindelijk gekozen voor de open source editor ’FCKEditor’ (http://www. In dit scherm kunnen administrators CMS gebruikers aanmaken, verwijderen fckeditor.net/). Deze is redelijk zwaar (in vergelijking tot de andere beken aanpassen. Een CMS gebruiker kan inloggen met zijn of haar e-mail ende open source opties), maar heeft een heel uitgebreid scala aan mogeliadres en een wachtwoord. Verder worden van elke gebruiker de naam en jkheden. Enkele van de belangrijkste features zijn: rol opgeslagen. Meer over de rolverdeling is te vinden in het hoofdstuk • Ondersteunt alle browsers ’Beveiliging’. Manage CMS gebruikers


17


• Output in XHTML 1.0

• Als een e-mail bericht

• Font en text formatting (bold, italic, size, color, bullet lists, etc)

• Als een verzonden SMS bericht

• Kopiëren/knippen/plakken, undo en redo • Links, anchors, afbeeldingen, met server browsing support • Tabellen maken en aanpassen • Form velden • Rechtermuisknop geeft context-menu • Toolbar kan compleet naar wens samengesteld worden

Er zijn twee verschillende soorten WinQs te onderscheiden: de individuele WinQ en de collectieve WinQ. Beide soorten dienen te kunnen worden aangepast binnen het CMS. Individuele WinQs worden per gebruiker aangemaakt, gebaseerd op persoonlijke data (voorbeeld: bij het registreren worden er al WinQs aangemaakt gebaseerd op de verjaardag, het begin van de relatie, en op een eventuele trouwdag). Collectieve WinQs worden en masse aangemaakt, en kunnen ook naar meerdere (of alle) gebruikers verzonden worden. Denk aan een berichtje op Valentijnsdag, aankondiging van een nieuw sterrenbeeld, of zomaar een willekeurige tip.

• Skin support • Bevat een spellingschecker • Integratie met ASP, ASP.NET, Java, ColdFusion, Perl, PHP, JavaScript 3.3.4 en meer

Bestandsstructuur

Het complete CMS komt terecht in een subfolder cms, ’bovenop’ de code voor de website. Om als administrator via je browser bij het CMS te komen, zet je /cms achter het adres van de NRT website. In deze map staan alle • Eenvoudig te gebruiken voor web users PHP bestanden die de uiterlijke verzorging en de werking van het CMS voor Voor de eindgebruiker werkt deze editor zeer intuitief; het doet denken aan hun rekening nemen. Daarnaast staan er een aantal mappen: een web-versie van bijvoorbeeld OpenOffice Writer of Microsoft Word. • Eenvoudig te installeren voor web developers

3.3.3

WinQs

css

In deze map staan alle .css bestanden. layout.css en style.css zorgen voor WinQs zijn de ’persoonlijke berichtjes’ die de gebruiker op de volgende de vormgeving en stijl van het CMS. wizardManagement.css en overlay.css drie manieren te zien kan krijgen: worden gebruikt door de Wizard sectie van het CMS, en cms overlay.css • Als een berichtje op de persoonlijke profielpagina op de website regelt de overlay voor de overige delen van het CMS. 3.3. CONTENT MANAGEMENT SYSTEEM

18


fckeditor Hier staan alle bestanden benodigd voor de ’WYSIWYG’ editor (zie 3.3.2). De bestandsstructuur van deze module laten we hier buiten beschouwing; voor meer informatie zie http://www.fckeditor.net/.

images Zoals de naam al doet vermoeden, worden hier alle afbeeldingen, buttons, achtergronden et cetera opgeslagen die benodigd zijn voor het CMS.

Alle componenten worden beheerd op een server. De componenten CMS en Website communiceren beiden met de database. Verder kan via het CMS de website worden aangepast. De Wizard ten slotte, is een integraal onIn deze map worden alle .js bestanden opgeslagen. Deze bevatten alle derdeel van de Website. CMS gebruikers communiceren logischerwijs met JavaScript functies die nodig zijn in het CMS. het Content Management System, en leden en ook dagelijkse bezoekers communiceren met de Website.

js

wizard Bevat een aantal PHP bestanden met hulp-functies voor het wizard-deel van het CMS.

3.4

Integratie van onderdelen

Onderstaand ’component diagram’ geeft duidelijk aan hoe het systeem in elkaar dient te steken: 3.4. INTEGRATIE VAN ONDERDELEN

19


Hoofdstuk 4

Implementatie 4.1

Website

engine.php

Met de beschrijving van de website zullen we ons beperken tot de algemene structuur en de visuele elementen. Hieronder valt ook de structuur van de database. We zullen beginnen met een stukje wat ingaat op de inhoud van de verschillende PHP files. Vervolgens bespreken we de JavaScript files en de opzet van de CSS files. Voor een overzicht van de volledige structuur verwijzen we naar bijlage F. Use-case specificaties zijn te vinden in bijlage D.

4.1.1

PHP

Met het programmeren is rekening gehouden met een structuur die de dynamica van de site zou moeten bevorderen. Er is begonnen met een algemene engine file waarin de verschillende delen samen komen. Ook in de toekomst is het mogelijk hier nieuwe delen toe te voegen. Met de beschrijving zullen we beginnen bij deze algemene file en langzaam alle daaraan gelinkte delen beschrijven.

Deze file bevat eigenlijk nauwelijks code, het doel van deze file is om de verschillende delen van de site toe te voegen. In dit geval zijn dat de website zelf, de wizard en ten slotte het CMS. engine_nrt.php Dit is eigenlijk de belangrijkste file van het geheel. Hierin zitten vrijwel alle functies die de website gebruikt om de code te genereren. De file begint met een init() functie welke bekijkt welke pagina geladen moet worden. Standaard zal hier de titel en inhoud vanuit de database geladen worden. Er zijn echter een groot aantal uitzonderingen. Deze uitzonderingen worden opgevangen door functies welke de inhoud vervolgens genereren. Aangezien er ook gebruik wordt gemaakt van formulieren welke verstuurd worden zullen deze ook hier opgevangen worden waardoor er buiten het genereerproces ook data weggeschreven zal worden. De menu’s worden gegenereerd vanuit de database. Deze zijn gecategoriseerd in 2 typen. Type 1 is voor de horizontale weergave aan de bovenkant van de website en type 2 voor de verticale weergave aan de zijkant

20

van de website. Een menu bestaat uit verschillende menuitems welke apart Als een gebruiker probeert om op een pagina te komen waar deze geen in de database staan. Er zijn verschillende functies in het leven geroepen rechten toe heeft dan zal hier een melding voor komen. om het menu te creëren. De eerste functie haalt de verschillende menu’s op. Per menu worden dan vervolgens de menuitems opgehaald met een anAangezien de database alleen maar US formaat accepteert van data zijn dere functie. De titel van de menu’s en menuitems kunnen vervolgens apart er twee functies geschreven om de data te converteren indien nodig. Van opgehaald worden. US naar EU en terug. Met data in deze context worden dag, maand en jaar bedoelt. De pagina’s hebben vrijwel allemaal een eigen URL welke eindigt op de titel van de pagina met als extensie .html. Het kan gebeuren dat de titel uit engine_nrt_db.php meerdere woorden bestaat, in dat geval zal door een daarvoor geschreven Alle database queries met betrekking tot de website staan hierin en kunfunctie de titel tot 1 woord gemaakt worden met streepjes (-). nen aangeroepen worden vanuit alle bestanden binnen de engine. Er staan queries in voor het lezen, toevoegen, aanpassen en verwijderen van records. Voor het in- en uitloggen zijn er 2 verschillende functies voor zowel de weergave als voor het proces. Bij het inloggen worden een aantal waarden engine_nrt_account.php waaronder user id en username opgeslagen in een session zodat later geconIn deze file staan alle functies met betrekking tot de accounts. Zo worden troleerd kan worden of een gebruiker wel of niet ingelogd is. Bij het uitloggen hierin de formulieren gegenereerd voor het registreren. Net als de formulieren worden deze waarden vervolgens verwijderd. voor het wijzigen van informatie achteraf. Tijdens het registreren kan een gebruiker de geboortedatum invullen. Als deze compleet in beeld staat zal het bijbehorende sterrenbeeld direct verschijnen in het veld horoscoop. Hiervoor is een object geschreven die aan de hand van de datum het sterrenbeeld ophaalt. Later zal het sterrenbeeld gebruikt worden om de horoscoop van de geregistreerde persoon weer te geven.

Als de gebruiker aan het registreren is dan zal alle data opgeslagen worden zodra diegene van stap verandert (van registratie partner één, naar registratie partner twee, naar registratie gezamenlijke gegevens, of vice versa). Deze data wordt allemaal opgeslagen in een sessie, wat betekent dat de data tijdelijk op de server opgeslagen wordt zolang de sessie bestaat. De sessie wordt verwijderd als de gebruiker zich geregistreerd heeft of zodra men inof uitlogt. Voordeel van dit alles is dat er geen data verloren gaat als men Het verzenden van e-mail is mogelijk door het e-mail adres van de gead- iets vergeten is in te vullen of als niet alle data correct is ingevuld. resseerde, het onderwerp, het bericht en de naam van de geadresseerde mee Alle selectboxen op de pagina worden gevuld vanuit de database. Daarte geven aan de daarvoor bestemde functie. Het bericht zal vervolgens verdoor is het heel makkelijk om opties toe te voegen, aan te passen of te stuurd worden in een vooraf bepaalde opmaak. 4.1. WEBSITE

21

HOOFDSTUK 4. IMPLEMENTATIE

Bij het aanvragen van een cadeaubon zijn er net als bij het registratieproverwijderen. Deze opties zullen later opgeslagen worden als een id zodat de ces een aantal gegevens nodig. Ook deze gegevens worden gevalideerd en aanpassingen ook bij de gebruiker worden doorgevoerd. vervolgens met een random gegenereerde code opgeslagen. Deze code zal later op de cadeaubon afgedrukt worden zodat deze gebruikt kan worden Als alle informatie van een formulier ingevuld is dan wordt deze gecondoor de ontvanger bij de registratie. Na eenmalig gebruik van de code zal troleerd zodra men op volgende klikt. Het controleren houdt in dat alle data deze op inactief worden gesteld. moet voldoen aan de eisen die per veld gesteld zijn. Zo mag een BSN uit maximaal 9 getallen bestaan en verder geen letters bevatten. Zodra een gebruiker geregistreerd is kan men een foto op het profiel zetten. Hiervoor is een upload functie ingebouwd. De foto moet qua grootte binnen Ook bij het wijzigen van data in een later proces zal alle data gecontroleerd de eisen vallen. De foto wordt vervolgens opgeslagen in de database als worden op validiteit, het is niet mogelijk data weg te schrijven die niet valide binaire data. Het is ook mogelijk de foto later aan te passen of te verwijderen. is. engine_ajax.php De laatste stap bestaat uit het betalingsproces. Betaling is voornamelijk mogelijk met iDeal en anders via handmatige overboeking. Het kan ook gebeuren dat iemand een cadeaubon gekregen heeft waardoor er niet betaald hoeft te worden. In dat geval dient de code te worden ingevuld welke op de cadeaubon staat.

Deze file verwerkt de AJAX verzoeken. De functie makeRequest() in deze file krijgt parameters mee welke vervolgens meegestuurd worden naar de file engine ajax functions.php. Vervolgens wordt er gecontroleerd of er inmiddels een antwoord gekomen is. Als dit het geval is dan wordt het teruggekregen JSON object verwerkt. Dit is een soort array waar alle verkregen data in zit. Het is mogelijk om op die manier meerdere delen van de website aan te passen zonder dat de website gerefreshed hoeft te worden.

Als alle stappen succesvol uitgevoerd zijn zal de data weggeschreven worden naar de database. Zolang de betaling nog niet officiëel voltooid is zal engine_ajax_functions.php het account op inactief worden gezet. Pas zodra de betaling zeker binnen is Zoals net al gemeld vangt deze file de AJAX verzoeken op. Aan de komt deze op actief te staan. hand van een van de meegekregen parameters wordt gekeken welke functie aangeroepen moet worden. De functie wordt vervolgens aangeroepen en Het kan gebeuren dat iemand zijn of haar wachtwoord vergeten is. In dat nadat er een JSON object is gecreëerd wordt deze in de file geprint waardoor geval is er een mogelijkheid om een nieuw wachtwoord aan te vragen. De de engine ajax.php deze kan uitlezen. procedure is dat de gebruiker de gebruikersnaam en het e-mail adres invult. Vervolgens krijgt diegene een e-mail met daarin een link. Als er op die link De AJAX techniek wordt gebruikt voor: geklikt wordt zal er een nieuw wachtwoord toegestuurd worden, ook per e-mail. • het controleren van de sterkte van een wachtwoord 4.1. WEBSITE

22


• het controleren of een gebruikersnaam reeds bezet is.

ajax_functions.js

• het resetten van een wachtwoord

Alle data die ingevuld is bij het registratieproces moet verstuurd worden naar de server zodat deze gevalideerd en weggeschreven kan worden. Hiervoor wordt een hele rij parameters gecreëerd welke naar de ajax engine gestuurd worden. De waarden worden uit de velden gehaald met behulp van de id’s die aan elk invoerveld toegekend zijn. Een array bevat vervolgens alle namen van die id’s zodat deze in een loop opgehaald kunnen worden. Deze techniek wordt ook in andere functies binnen de javascript file gebruikt zodat er geen onnodig werk verricht hoeft te worden.

• het verkrijgen van het sterrenbeeld • het registreren • het toevoegen en verwijderen van kinderen tijdens de registratie • het aanpassen van gegevens na de registratie • het contact formulier • het verkijgen van de horoscoop

Bij het verwijderen van een foto zal om bevestiging gevraagd worden, dit is gedaan met behulp van javascript.

• het aanmaken van een cadeaubon Vrijwel alle functies in de javascript file zijn er op gericht om een serie Ten slotte zijn er nog een aantal objecten welke gebruikt worden door parameters naar de AJAX engine te sturen en hebben verder dus geen nadere meerdere files: toelichting nodig. clientinfo.class.php - Vraagt allerlei informatie op van een bezoeker, zoals browser en taal. messages_switch.js constellation.class.php - Zoekt het juiste sterrenbeeld bij een geboorteOp de beginpagina staat een foto met daarbij een tekstje van een persoon. datum. Deze wordt afgewisseld door nog twee andere foto’s met tekstjes. Het effect voor deze verandering staat in deze file geprogrammeerd. Hierbij is rekening registration validate.class.php - Bevat functies voor het valideren van gehouden met meerdere browsers. In het geval van de nieuwste browsers gegevens. zal het veranderen van twee berichten geleidelijk aan gebeuren. Het ene rss reader.class.php - Leest RSS feeds uit vanaf het internet. bericht verdwijnt langzaam en het andere verschijnt langzaam. In het geval van Internet Explorer 6.0 en ouder is dit niet mogelijk, hierbij zullen de berichten dan ook direct veranderen. 4.1.2 JavaScript Er zijn twee javascript files welke dienst doen voor de website zelf. De 4.1.3 CSS javascript wordt voornamelijk gebruikt voor de AJAX techniek maar in somDe hele website is opgebouwd uit blokken tekst. Deze blokken worden mige gevallen ook om HTML elementen aan te passen zonder dat daar AJAX gecreëerd met behulp van div- en span-elementen. Het voordeel hiervan is bij gebruikt wordt. 4.1. WEBSITE

23


dat de layout en het design van de website compleet veranderd kan worden door de eigenschappen van de div- en/of span-elementen aan te passen. Alle eigenschappen van de elementen staan in twee verschillende css files.

4.2

Wizard

In deze sectie zullen we de implementatie van het gedetailleerde ontwerp bespreken. We zullen eerst kijken naar de invulling van de verschillende PHP bestanden, vervolgens naar de Javascript code kijken en besluiten met een beschouwing van de CSS code.

layout.css In deze file staan alle eigenschappen met betrekking tot de positionering van de pagina. Zo staan de hoogte en breedte van een blok erin vermeld wanneer dit wenselijk is. De uitlijning wil ook nog weleens anders zijn, zo kan je links, rechts en in het midden uitlijnen. Nog twee veelgebruikte eigenschappen zijn padding en margin. Padding betekent de ruimte die tussen de inhoud en de rand van het blok zit, margin de ruimte die tussen de rand van het blok en de omgeving zit.

4.2.1

PHP

Zoals reeds besproken is alle PHP code ten behoeve van de wizard opgedeeld in een zestal bestanden. Tijdens de implementatie bleek, dat deze indeling in sommige gevallen misschien te extreem was, en in andere gevallen te conservatief, omdat de verdeling van de functies over de bestanden uiteindelijk verre van evenwichtig is gebleken. engine_wizard.php

style.css Zoals alle layout in de layout.css staat, staat alle style in de style.css. Alle opmaak van de pagina wordt hierin beschreven. Dit kan zijn voor de blokken maar ook voor bepaalde html-elementen. Qua kleuren zitten hierin de verschillende achtergrondkleuren, tekstkleuren en kleuren van lijnen. De kleuren van lijnen worden niet in elke browser ondersteund maar wordt voor die browsers die het wel ondersteunen toch gedefiniëerd. Op de pagina staan ook veel afbeeldingen welke bijdragen aan het design, deze worden ook in deze file gedefinieerd. Buiten kleuren en plaatjes wordt er ook opmaak voor de tekst beschreven. Opmaak in de zin van tekstgrootte, vetgedrukt of niet, onderstreept of niet en het font type. Bij sommige elementen is het mogelijk om randen om het element te zetten met een kleur. Ook deze worden beschreven. 4.2. WIZARD

Dit bestand bestaat uit twee functies, namelijk engine_wizard_init en engine_wizard_action. De eerste functie retourneert HTML code voor de overlay van de wizard door zelf de functie engine_wizard_html_overlay aan te roepen, en diens resultaat terug te geven. De tweede functie is in principe een switch, waarin - aan de hand van de POST[’action’] variabele, die met elk verzonden form gestuurd wordt - de te ondernemen acties worden bepaald. De initialisatie functie dient direct na de opentag van de body in het integrerende HTML document te worden ingevoegd, omdat de overlay over de hele body moet worden weergegeven, en niet in een ander div element. De action functie kan direct na de initialisatie functie worden aangeroepen, zodat te allen tijde gecontroleerd kan worden of de wizard een bepaalde actie uit moet voeren, nadat een form terug naar de server gestuurd is.

24


Allereerst worden de antwoorden van de dummy uit de database gehaald, en opgeslagen in op de server aangemaakte POST variabelen. Hierdoor wordt het verzonden form gesimuleerd. Nadat al de POST variabelen ge¨ ınitialiseerd zijn, wordt engine_wizard_core_submit_questionnaire De twee functies in dit bestand zijn engine_wizard_core_submit_ aangeroepen. questionnaire en engine_wizard_core_submit_dummy.

engine_wizard_core.php

De eerste functie wordt aangeroepen door engine_wizard_action op het moment dat een ingevulde vragenlijst de server bereikt. Er wordt in deze functie eerst gekeken of het een solo of een duo test betreft. In het eerste geval wordt er direct een nieuwe record in de consult tabel ingevoerd, en aan de hand van de teruggekregen consult id verder berekend. In het tweede geval wordt er eerst gekeken of er nog een niet afgeronde duo test bestaat. Als dat het geval is, wordt de consult id van deze test opgezocht. Als er geen onafgeronde duo test bestaat, wordt er een nieuwe consult aan de database toegevoegd, analoog aan het geval waarin het een solo test betrof. Vervolgens worden alle gegeven antwoorden aan de database toegevoegd. Hierbij wordt gebruik gemaakt van het eerder bepaalde consult id en de user id van de gebruiker. Zodra alle antwoorden zijn toegevoegd, worden de scores berekend - in sommige gevallen mede gebaseerd op de antwoorden van de partner - en deze scores worden gecategoriseerd. Al deze data wordt aan de database toegevoegd aan records in de tabel preference.

engine_wizard_html.php De functies in dit bestand worden gebruikt om HTML te genereren en te retourneren naar de aanroepende functie. Dit is de enige plaats binnen de wizard, waar HTML geproduceerd wordt. Hoewel de vorige twee behandelde bestanden elk slechts twee functies bevatten, bestaat engine_wizard_html. php uit meer dan dertig functies. De reden hiervoor is het gebruik van AJAX. In principe was het mogelijk om alle code voor het genereren van de HTML voor een vragenlijst in één functie te stoppen, maar een splitsing in deelfuncties was geboden, omdat we telkens slechts fragmenten van de vragenlijst middels AJAX aanvragen. Hierdoor bestaat het genereren van de HTML voor een vragenlijst uit elf verschillende functies. De HTML genererende functies in dit bestand zijn als volgt opgebouwd: 1. Initialiseer parameters De parameters, die benodigd zijn voor het genereren van de HTML worden bepaald en toegekend. Wanneer de bron van een dergelijke waarde verandert, hoeft dit maar op één plaats aangepast te worden, in plaats van door alle HTML code heen.

De tweede functie wordt gebruikt voor een CMS-achtig doeleind. Tijdens de implementatie en het testen van de code groeide het verlangen om op een automatische manier tests in te voegen, zodat de vragenlijst niet telkens handmatig ingevuld hoeft te worden. Hiertoe hebben we de 2. Genereer HTML zogenaamde dummy-tests in het leven geroepen. In het CMS kunnen deze 3. Retourneer HTML tests aangemaakt worden, en de users met een negatieve user id - deze zijn voorbehouden aan CMS gebruikers - kunnen deze vervolgens uitvoeren. Een functie, die wél HTML genereert, maar niet volgens bovenstaand De functie engine_wizard_core_submit_dummy voorziet in de afhandeling van deze dummies en wordt aangeroepen door engine_wizard_action. stramien is opgebouwd, is engine_wizard_html_overlay. Deze functie 4.2. WIZARD

25


wordt aangeroepen door engine_wizard_init en genereert de HTML die nodig is voor het tonen van de overlay. Deze overlay bestaat uit twee divs, waarvan de ene dient voor de semi-transparante achtergrond, en de ander voor de content, die bovenop deze achtergrond ligt. Standaard worden de divs niet getoond, omdat deze pas mogen verschijnen op het moment, dat de gebruiker een vragenlijst wil invullen of een testresultaat wil bekijken. Het is van essentieel belang, dat deze divs al wel in de pagina aanwezig zijn, omdat ze anders later niet meer opgeroepen kunnen worden zonder een refresh van de pagina. Naast de HTML genererende functies zijn er ook een tweetal ondersteunende functies. De ene wordt gebruikt om een numerieke datum om te zetten naar een string met Nederlandse namen van maanden, en de andere definieert een array met hexadecimale kleurcodes, die gebruikt kunnen worden door de wizard. engine_wizard_ajax.php

content. De eerste wordt enkel aangeroepen wanneer een gebruiker begint met het maken van een vragenlijst, en de tweede wordt gedurende de rest van dit proces gebruikt. We hebben deze opsplitsing gemaakt, omdat er bij de start van de test niet één, maar twee divs ingevuld moeten worden. Naast de content div moet er ook een zogenaamde form div gevuld worden met form elementen, waarin de antwoorden op de vragen opgeslagen worden. Zodra deze form div eenmaal ge¨ınitialiseerd is, hoeft er aan de innerHTML gedurende de rest van de test niets meer veranderd te worden, terwijl de inhoud van de content div wel blijft veranderen. Dit is dus een fundamenteel verschil tussen deze twee functies. In de functie take_questionnaire_content staat een switch statement, die aan de hand van de meegekregen parameter target een bepaalde functie uit engine_wizard_html aanroept. Deze switch is noodzakelijk, omdat de inhoud van de content div afhankelijk is van de vraag waarbij de gebruiker op dat moment is. Het weergeven van het resultaat is opgebouwd uit verschillende tabbladen. Voor het weergeven van elk van deze tabbladen bestaat er een aparte functie in engine_wizard_ajax.php, die wordt uitgevoerd wanneer de overeenkomstige AJAX-request de server bereikt. Omdat elk tabblad uit meerdere sub-pagina’s bestaat, bevindt zich in elke functie een switch, die aan de hand van de aangevraagde pagina een gerelateerde functie uit engine_wizard_form aanroept. Bij het openen van het test resultaat wordt naast de content van het tabblad ook de tabs zelf ingeladen in een aparte div. De HTML voor deze tabs worden gegenereerd door aanroeping van engine_wizard_html_overlay_show_result_tabbar.

De functies in dit bestand worden aangeroepen door engine_ajax_ functions.php en vormen dientengevolge een reactie op de AJAX-requests, die de client naar de server stuurt. Wat structuur betreft zijn alle functies in dit bestand op eenzelfde manier opgebouwd: eerst worden de parameters ge¨ınitialiseerd, vervolgens wordt een functie aangeroepen uit engine_wizard_html en de geretourneerde HTML wordt tot slot terug naar de client gestuurd. Daarnaast zijn de functies onder te verdelen in een tweetal groepen, namelijk die ten behoeve van het invullen van een vragenlijst, engine_wizard_tech.php en die ten behoeve van het opvragen van test resultaten.

In dit bestand staan zes functies, die op meerdere plaatsen binnen de Voor de eerste groep bestaan er twee functies, namelijk take_ wizard worden aangeroepen. questionnaire_begin - we verwerpen voor dit moment de prefix engine_ • engine_wizard_tech_unfinished_questionnaire wizard_ajax in het kader van leesbaarheid - en take_questionnaire_ 4.2. WIZARD

26


Functie die een 1 retourneert als een bepaalde gebruiker een onafgeronde worden opgevraagd, en gesorteerd op datum. Vervolgens wordt het vragenlijst heeft, en in alle andere gevallen een 0. Om dit te controleerste element uit deze array geretourneerd. eren worden alle onafgeronde vragenlijsten van een bepaalde gebruiker engine_wizard_db.php opgevraagd, en gekeken of dit aantal groter is dan 0. In dit bestand staan alle queries, die de andere bestanden van de wiz• engine_wizard_tech_unfinished_consult Functie die een 1 retourneert als een bepaalde relatie een onafgeronde ard gebruiken. Elke functie komt overeen met één query, en is als volgt consult heeft, en in alle andere gevallen een 0. Dit wordt op eenzelfde opgebouwd: manier gecontroleerd als bij de functie hierboven. 1. Maak een verbinding met de database connectie module: $con = new engine db con(); • engine_wizard_tech_finished_consult Retourneert een array met alle afgeronde consults, waaraan een ge2. Voer de querie uit: bruiker deelgenomen heeft. Om deze array te verkrijgen worden eerst $result = $con→query(query); alle door de gebruiker afgeronde vragenlijsten opgevraagd. Aan de hand Hierin is query de uit te voeren query. van deze vragenlijsten worden de daaraan gelieerde consults gecon3. Als het een SELECT of INSERT query betreft wordt er iets geretroleerd op voltooiing. De afgeronde consults worden vervolgens aan tourneerd. de resultaat array toegevoegd, die tot slot wordt teruggegeven aan de aanroepende fnctie. • Wanneer het een SELECT query betreft: return $result;

• engine_wizard_tech_relation_id Retourneert de relation id van de actieve relatie van een bepaalde gebruiker. • engine_wizard_tech_classify Retourneert de subclass id op basis van een score en de twee antwoorden van de partners. Allereerst worden de grenzen van de klassen uit de database gehaald, en vervolgens worden de opgegeven waarden naast deze grenzen gelegd om te bepalen tot welke klasse de score en antwoorden horen.

• Wanneer het een INSERT query betreft: return $con→lastInsertId(); De queries zijn gegroepeerd per tabel. Een andere mogelijkheid was geweest om ze te groeperen per type query, maar uiteindelijk leek het ons overzichtelijker om dit per tabel te doen, omdat het in dit geval makkelijker te bepalen is, welke queries voor een bepaalde tabel al bestaan, en dit mogelijke wildgroei van queries voorkomt.

4.2.2

Javascript

• engine_wizard_tech_last_finished_consult_id Retourneert de consult id van de meest recent afgeronde consult van De Javascript code is een belangrijk onderdeel van de wizard, omdat een bepaalde gebruiker. Alle afgeronde consults van deze gebruiker het invullen van de vragenlijsten afhankelijk is van de functionaliteit, 4.2. WIZARD

27


die Javascript biedt. Zoals eerder gemeld is de code verdeeld over twee bestanden, waarvan we de implementatie voorts nader zullen toelichten. wizard_overlay.js De code in dit bestand is in drie delen op te splitsen: code ten behoeve van het weergeven van vragenlijsten, code ten behoeve van het weergeven van test resultaten, en code ten behoeve van het tonen en verwijderen van de overlay. De functies in de eerste twee groepen worden aangeroepen vanuit onclick events in de HTML, terwijl de functies uit de laatste groep enkel worden aangeroepen vanuit functies in de eerste twee groepen. Vragenlijst weergave Voor de weergave van vragenlijsten worden de volgende vier functies gebruikt:

wordt de functie waitForPreferencePie aangeroepen. Als de volgende pagina het begin van een nieuwe subsectie is, wordt de functie waitForPreferencePointer aangeroepen. Tot slot wordt het scherm weer geheel naar boven gescrolld. • waitForPreferencePie Zolang het element preferencepie_resolved gelijk is aan null, roept deze functie zichzelf aan. Zodra het element niet meer null is, wordt de importantie-taart getekend, waarbij alle punten even groot zijn. De reden voor het gebruik van deze constructie is de AJAX-request. De Javascript code wacht namelijk niet tot er een antwoord van de server is ontvangen, maar gaat direct door. Door aan dit antwoord het hidden input element preferencepie_resolved toe te voegen, wordt de echte content van deze functie pas uitgevoerd, zodra de innerHTML volledig geladen is.

• startTest Dit is de functie, die aangeroepen wordt, wanneer de gebruiker een vragenlijst wil gaan invullen. Allereerst wordt er een AJAX-request naar de server gestuurd om de content van de overlay op te vragen. Vervolgens worden functies aangeroepen om de overlay te tonen, en tot slot wordt het scherm geheel naar boven gescrolld in het kader van gebruikersgemak. • go Deze functie verzorgt de navigatie door de vragenlijst. Wanneer go wordt aangeroepen, laat de gebruiker weten, dat hij naar een andere pagina binnen de vragenlijst wil. Als de huidige pagina een vraag bevat, wordt er eerst gekeken of deze vraag beantwoord is. Wanneer dat niet het geval is, wordt er een prompt getoond, waarin de gebruiker daar nog eens extra op wordt geattendeerd. Vervolgens wordt er een AJAX-request gedaan voor de content van de volgende pagina. Indien de volgende pagina het einde van een sectie is, 4.2. WIZARD

28

• waitForPreferencePointer Deze functie is hetzelfde opgebouwd als waitForPreferencePie. Zodra de AJAX-request is afgehandeld, worden de pointers en waarden HOOFDSTUK 4. IMPLEMENTATIE

op de balk hersteld, zodat de antwoorden op eerder ingevulde vragen behouden blijven. Het is van belang om eerst op de afhandelign van de request te wachten, omdat er voor dat moment nog geen balken of pointers zijn om te muteren, omdat de innerHTML op dat moment nog niet aanwezig is. Test resultaat weergave Voor de weergave van de test resultaten worden de volgende functies gebruikt:

• showOverlay Toont de volledige zwarte semi-transparante overlay, welke een schermgrote div is, door het display element op ’block’ in te stellen. • showOverlayContent Toont de witte div, die bovenop de semi-transparante overlay ligt, en waarin de content wordt weergegeven, door het display element op ’block’ in te stellen. • hideOverlay Verstopt de overlay en content op de overlay door de CSS van deze divs aan te passen; het display element wordt op ’none’ ingesteld.

• showResult Deze functie begint met een AJAX-request om de standaard pagina voor test resultaten op te vragen. Vervolgens wordt de overlay getoond wizard_content.js en de gerelateerde divs. Wanneer het resultaat van een specifieke test wordt opgevraagd, wordt er met de AJAX-request ook een consult id De code in dit bestand is in twee delen op te splitsen. Allereerst is er meegestuurd. Wanneer het laatste test resultaat gewenst is, wordt deze consult id niet meegestuurd, waarna de server zelf uitzoekt wat het de code ten behoeve van de importantie-taart. Het andere deel betreft code ten behoeve van de preferentie-balken. Merk op, dat deze verschillaatste resultaat is. lende soorten functies niet geheel stroken met de naamgeving van dit bestand en diens oospronkelijke doel in het ontwerp. De functies in het be• showResultDefault/showResultDiagnose/showResultHistory Functies die voorzien in het wisselen van de tabbladen. Eerst wordt de stand wizard content.js worden nu gebruikt voor de grafische dynamische grafische kant afgehandeld door middel van het wisselen van images en elementen. achtergrondkleuren van divs, en vervolgens wordt er een AJAX-request gedaan, waarin de content van het tabblad wordt opgevraagd bij de Importantie-taart Voor de importantie-taart worden de volgende functies gebruikt: server. • showResultTab Deze functie verandert de content van een tabblad zonder de gekozen tab zelf te veranderen, en bestaat daardoor enkel uit een AJAX-request naar de server.

• editPreference Deze functie tekent een taartpunt op het canvas. Allereerst wordt het canvas opgezocht. Vervolgens wordt de kleur van de taartpunt ingesteld, en tot slot wordt deze getekend aan de hand van opgegeven start en eind hoeken.

Overlay Voor de weergave van de overlay worden de volgende functies gebruikt:

• editPreferencepieRemove/editPreferencepieAdd Wanneer een bepaald taartstuk verkleind moet worden - en de andere

4.2. WIZARD

29


Deze functies worden aangeroepen wanneer een gebruiker bij respectievelijk een vraag of subsectie kiest voor de NVT - niet van toepassing - optie. Allereerst wordt de pointer verplaatst naar buiten de balk, en vervolgens worden de hidden fields aangepast, zodat ook de server weet, dat deze vraag of subsectie niet van toepassing is voor de gebruiker, wanneer het form teruggestuurd wordt naar de server. De reden voor het opsplitsen van deze twee functies is analoog aan die bij de hierbovenstaande functies.

daarmee vergroot - wordt deze functie aangeroepen. Eerst wordt het canvas opgezocht en volledig gewist. Vervolgens worden alle relevante subsecties - subsecties waarbij de gebruiker geen NVT heeft ingevuld bepaald, zodat men weet hoeveel graden er van het te verkleinen taartstuk afgehaald moeten worden. Als alle relevante subsecties verkregen zijn, wordt er over deze subsecties ge¨ıtereerd. Omdat van alle subsecties de grootte van de hoek wordt opgeslagen, kan bij de te verkleinen taartpunt eenvoudig een aantal graden afgetrokken worden gelijk aan het aantal relevante subsecties - 1. Bij de overige relevante subsecties wordt juist 1 graad opgeteld, zodat alle taartpunten bij elkaar opgeteld 360 graden zijn. Tidjens het itereren worden de punten ook al getekend door een aanroep van editPreference, waarbij de starthoek telkens aangepast wordt, zodat de taart een mooie ronde vorm krijgt. Het vergroten van een taartpunt werkt analoog door aanroeping van editPreferencepieAdd. Preferentie-balk gebruikt:

• updateAnswerParentSection Deze functie wordt aangeroepen net voordat de laatste pagina van een sectie wordt getoond. Het gemiddelde over de hele sectie wordt berekend, wat vervolgens op een niet-muteerbare preferentie-balk wordt weergegeven. Ook wanneer de importantie-taart wordt aangepast wordt deze functie aangeroepen, omdat het gemiddelde van een sectie anders is, wanneer de gewichten veranderen.

Voor de preferentie-balk worden de volgende functies

4.3

• pointQuestion/pointChildSection Deze functies worden aangeroepen wanneer een gebruiker op respectievelijk een preferentie-balk klikt voor een vraag of subsectie. Eerst wordt bepaald wat de x-co¨ ordinaat van deze klik was ten opzichte van het begin van de balk. Vervolgens wordt hieruit bepaald wat het antwoord zou zijn op een schaal van 1 tot 10, en de pointer wordt op de goede plaats onder de balk geschoven. Ten slotte worden de hidden fields, die tot het form behoren, wat uiteindelijk terug naar de server gestuurd wordt, aangepast. De reden dat we deze twee functies hebben opgesplitst tussen vragen en subsecties is het feit, dat de naamgeving van de HTML elementen in beide gevallen verschillen, waardoor een generieke functie onoverzichtelijker zou zijn dan twee aparte. • resignQuestion/resignChildSection 4.3. CONTENT MANAGEMENT SYSTEEM

Content Management Systeem

In deze sectie wordt de implementatie van het Content Management Systeem besproken. Naast de PHP, JavaScript en CSS code, bespreken we hier ook de integratie van de FCKeditor module met het systeem.

4.3.1

PHP

Alle webpagina’s die bezocht kunnen worden in het CMS, hebben hun eigen PHP bestand. Deze zorgen ervoor dat de pagina’s opgebouwd worden en bevinden zich in de map /cms. Daarnaast zijn er ook een aantal algemene bestanden, die zich in de map /engine bevinden. Deze bestanden zorgen voor de functionaliteit (database aanroepen, authorizatie van gebruikers, error handling, e.d.) van het CMS. Allereerst zullen we deze ’algemene’ bestanden bespreken.

30


engine_cms.php Dit bestand wordt direct ge¨ınitialiseerd vanuit engine.php. bevindt zich de functionaliteit van het CMS.

Hierin

geeft de 6 sub-secties weer waarin het CMS is onderverdeeld, en hier kan de gebruiker kiezen wat hij wil gaan doen in het CMS. Vanaf hier worden de PHP bestanden in een duidelijke structuur opgedeeld. Elk bestand begint met de prefix cms_. Vervolgens komt daar de naam van de subsectie achter. Als er nog een niveau dieper wordt gekeken, volgt er nog een underscore ( ) en vervolgens de naam van deze pagina. De structuur is dus vergelijkbaar met een soort mappenstructuur, en kan er als volgt uit zien: cms_<subsectie>_*.php

De volgende zaken worden er afgehandeld: - Het valideren van een gebruiker bij login - Sessies aanmaken en verwijderen - Controleren of gebruiker op een bepaalde pagina mag komen - Fouten afhandelen - Generiek aanmaken van HTML: Weergave van het ’[gebruikersnaam] is ingelogd’ blokje Weergave van de ’separators’ die op elke pagina staan Schrijven van code voor de overlay Instantiëren en weergeven van de FCKeditor Weergave van foutmeldingen Weergave van zoekfilters - Alle AJAX methoden die het CMS gebruikt

De ’homepages’ van elk van de onderdelen zijn dus als volgt: cms_website.php cms_wizard.php cms_winqs.php cms_cmsusers.php cms_nrtusers.php cms_statistics.php

engine_cms_db.php

Vervolgens ziet bijvoorbeeld de pagina voor het aanmaken van een nieuwe Het grootste deel van de hiervoor genoemde functies doet wel één of CMS gebruiker er als volgt uit: cms_cmsusers_adduser.php. meerdere database aanroepen. Net als de Wizard en de website, heeft ook het CMS een eigen bestand dat deze aanroepen verzorgt. Alle queries die 4.3.2 JavaScript ooit gedaan worden binnen het CMS, staan hier gespecificeerd. Voor het CMS is er een centraal JavaScript bestand geschreven: engine_

Naast deze algemene functionaliteit zijn er bestanden voor het renderen van de pagina’s zelf. Navigeren naar http://www.wizzlove.com/cms levert allereerst het bestand index.php op. Deze geeft het login-scherm weer, en na een succesvolle login komt de gebruiker op home.php. Deze pagina 4.3. CONTENT MANAGEMENT SYSTEEM

cms.js. Deze verzorgt dynamiek van het systeem: het zorgt er voor dat sommige simpele operaties gewoon binnen de browser worden uitgevoerd zonder dat er een HTTP request gedaan dient te worden. Dit bestand staat in de map /cms/js en bevat alle JavaScript functionaliteit voor het CMS. Een aantal belangrijke functies zullen hier besproken worden.

31


clearFilters maakt alle filters leeg. Verder is er nog een hulp-methode limitinput(evt,strList,bAllow) die de input van karakters in het postDeze functies worden aangeroepen om een stukje ’overlay’ weer te geven code veld beperkt tot getallen. of te verbergen. Een overlay is een stuk HTML (meestal een invulformulier) dat weergegeven wordt wanneer de gebruiker een bepaalde actie wil doen AJAX functies (bijvoorbeeld het wijzigen van een stuk tekst op de website). Dit wordt dan weergegeven ’bovenop’ de originele pagina, met een donkere transparante Tot slot bevat dit JavaScript bestand twee AJAX functies. ajax_change_ achtergrond. winq(id,target) opent een overlay formulier voor de gebruiker om een winQ aan te passen, en ajax_apply_filter(target) zorgt ervoor dat de De functies show_overlay() en hideOverlay() worden aangeroepen om gegeven input van een gebruiker na het zoeken op filters, direct kan worden de overlay op een bepaalde pagina zichtbaar danwel onzichtbaar te maken. omgezet naar output en weergegeven wordt in het formulier, zonder dat er Verder is er nog een hulpfunctie getPageSize() die de dimensies van de een nieuwe HTTP request gedaan dient te worden. pagina op de monitor van de gebruiker retourneert, zodat de overlay volledig passend en goed gepositioneerd in het scherm wordt weergegeven. 4.3.3 CSS Overlay functies

Ook het CMS bevat zijn eigen CSS bestanden. Deze zijn te vinden in de map /cms/css. Net als de website, heeft ook het CMS de bestanden layout.css om de positionering te regelen, en style.css om de opmaak te De enige functie in deze sectie is de functie confirmation(cms_user_id), bepalen. Daarnaast is er nog een apart bestand genaamd overlay.css die die een bevestiging vraagt aan de gebruiker om een gebruiker met ID gelijk verschillende uiterlijke kenmerken van de overlay bepaalt. aan de parameter te verwijderen.

User Management functies

Website Management functies

4.3.4

FCKeditor

De integratie van de open source WYSIWYG editor FCKeditor, is heel Net als bij de User Management functies, zijn hier twee functies eenvoudig. Allereerst kan er een zip-bestand gedownload worden, die de (deleteMenuitem(menu_item_id) en delete_menu(menu_id)) die de gebruiker vragen te bevestigen dat er respectievelijk een menu-item of een complete source code bevat. Deze is in de map /cms/fckeditor te vinden. Vervolgens kan de editor aangeroepen worden door bovenin het PHP volledig menu moet worden verwijderd. bestand de volgende regel te plaatsen: Filter funcies

include_once("fckeditor/fckeditor.php");

Hiermee worden de verschillende filters (voor het zoeken naar gebruikers) bestuurd. De functie showBox(boxID) maakt een ’listbox’ zichtbaar Daarna kan er op de pagina zelf een editor geinitialiseerd worden of onzichtbaar, wanneer de gebruiker op het pijltje naast deze box klikt. door een nieuw FCKeditor object aan te maken, deze de juiste attributen 4.3. CONTENT MANAGEMENT SYSTEEM

32


mee te geven, en de functie Create() aan te roepen, en de FCKeditor geeft de benodigde HTML code terug.


33


Hoofdstuk 5

Beveiliging 5.1

Website beveiliging

Beveiliging op de website is een belangrijk aspect, voornamelijk omdat daarop ook interactie met gebruikers mogelijk is. Over het algemeen zal men de mogelijkheden tot interactie op een positieve manier gebruiken. Het is echter ook mogelijk dat kwaadwillenden hier misbruik van proberen te maken. Het is dus belangrijk dat er rekening wordt gehouden met die kwaadwillenden. Met het bespreken van de verschillende onderdelen die extra aandacht nodig hebben met betrekking tot beveiliging zullen we van boven naar beneden gaan in de hiërarchie. Beginnende bij de website zelf en langzaam aan richting database naar beneden. Op de website staan verschillende invoervelden waar je tekst in kan zetten. De meeste van deze invoervelden hebben als doel om informatie van de gebruiker te verkrijgen. De meeste invoervelden zijn aanwezig bij het registratieproces. De bedoeling van de invoervelden is om normale tekst in te voeren welke nodig is voor het opgeven van bijvoorbeeld de naam van de gebruiker. Buiten normale tekst is het mogelijk om hier niet gangbare tekst

in te zetten in de zin van karakters welke de code kunnen be¨ınvloeden als deze de volgende keer weergegeven worden. Tijdens het registratieproces wordt alle invoer opgeslagen als er van stap veranderd wordt (van registratie partner één, naar registratie partner twee, naar registratie gezamenlijke gegevens, of vice versa). Dit betekent echter ook dat deze data opnieuw opgehaald wordt als men terug gaat naar de stap waar de data ingevoerd is. Tijdens het ophalen kan het gebeuren dat de code anders ge¨ınterpreteerd wordt omdat er bijvoorbeeld ’">’ ingevuld was waardoor de code onderbroken wordt. Alle code die de gebruiker erachter zet kan dan uitgevoerd worden. Om dit te voorkomen worden die en andere karakters die kwaad zouden kunnen doen gefilterd uit de tekst. Tijdens de validatie van alle ingevoerde informatie bij het registratieproces wordt ook gecontroleerd of er vreemde karakters worden gebruikt. Is dit het geval dan zal de gebruiker hierop attent gemaakt worden zodat deze de informatie aan kan passen. Mochten de karakters op bijzondere wijze toch richting de database gestuurd worden dan zullen deze geëscaped worden waardoor het niet kan gebeuren dat de karakters later als code ge¨ınterpreteerd worden. Dit zou bijvoorbeeld kunnen gebeuren als men gegevens later gaat wijzigen. Dezelfde controle vindt plaats bij het contact formulier en voor het aanmaken van

34

geval is, wordt er terug genavigeerd naar home.php. Als beide checks wel goed gaan, krijgt de gebruiker uiteraard de gewenste pagina te zien.

een cadeaubon waarbij gegevens ingevuld dienen te worden. Het kan gebeuren dat kwaadwillende gebruikers bij de invoervelden voor gebruikersnaam en wachtwoord tijdens het inloggen een stukje code invoeren waardoor het controleren van de gebruikersnaam en wachtwoord omzeild kan worden, ook wel SQL injection genoemd. Ook hier is rekening mee gehouden met behulp van escape. Doordat de te controleren gegevens geëscaped worden is het niet mogelijk dat de MySQL query hierdoor be¨ınvloed wordt. Als men het wachtwoord vergeten is dan is het mogelijk een nieuwe aan te vragen. Om te zorgen dat geen ongewenste personen op die manier een wachtwoord kunnen verkrijgen wordt er een bevestiging tot het wijzigen van het wachtwoord per e-mail gevraagd. Per e-mail krijgt de gebruiker een URL welke gebruikt kan worden om daadwerkelijk het wachtwoord aan te vragen. Als die link uitgevoerd is dan zal er een nieuwe e-mail verstuurd worden richting de betreffende gebruiker waarin het wachtwoord vermeld staat.

Een gebruiker kan inloggen met zijn e-mail adres in combinatie met een wachtwoord. Dit wachtwoord wordt opgeslagen in de database door middel van een MD5 hash. Administrators mogen nieuwe gebruikers aanmaken (gebruikers kunnen zich niet registreren of iets dergelijks), en administrators kunnen gegevens van gebruikers aanpassen (inclusief de rol die zij vervullen) en verwijderen. Het is echter niet mogelijk om de rol van een andere administrator (of jezelf) te ’down-graden’, of een andere administrator te verwijderen; mocht dit toch nodig zijn, dan moet dit via de database gebeuren. Een gebruiker kan zelf wel zijn eigen wachtwoord, naam of e-mail adres wijzigen.

5.3

Beveiliging van persoonsgegevens

De persoonsgegevens in de database zijn enkel toegankelijk voor de mensen, die ook het wachtwoord van de database hebben. Dit is de enige 5.2 CMS beveiliging beveiliging van de gegevens. Op dit moment wordt de data niet extra verBinnen het CMS zijn er drie rollen die een gebruiker kan hebben. Deze sleuteld. Vanuit het CMS kunnen de persoonlijke gegevens - door CMSgebruikers met de juiste rechten - wel opgevraagd worden. Dit is echter geven toegang tot één of meerdere secties van het CMS. noodzakelijk, omdat het voor een administrator mogelijk moet zijn om deze • Administrator - Heeft het recht om alles te doen gegevens handmatig aan te passen. Het wachtwoord van de gebruikers is overigens door een MD5-hash beveiligd, waardoor deze voor niemand zicht• Content Moderator - Mag enkel de website aanpassen baar is (ook niet in de database). • Wizard Moderator - Mag vragen van de Wizard aanpassen, evenals WinQs De statistieken in het CMS zijn anoniem. Dit betekent, dat de antwoorBij elke opgevraagde pagina wordt allereerst gecontroleerd of een gebruiker den op bepaalde vragen wel voor een bepaalde groep mensen bekeken kan ingelogd is. Als dit niet het geval is, wordt deze terug gestuurd naar index. worden, maar niet op het individuele niveau. Deze statistieken zijn enkel php alwaar ingelogd kan worden. Vervolgens wordt er gekeken naar de rol toegankelijk voor CMS-gebruikers met de juiste rechten. van de gebruiker, en of deze rol toegang geeft tot de pagina. Als dit niet het 5.3. BEVEILIGING VAN PERSOONSGEGEVENS

35

HOOFDSTUK 5. BEVEILIGING

Hoofdstuk 6

Tests Bij gebrek aan automatische test omgevingen voor PHP, Javascript en CSS, zoals JUnit in Java, is de manier van het testen van de code enigszins primitief. We zullen in dit hoofdstuk ingaan op de manier waarop we onze code hebben getest. Het testen van de code was een continu proces, en niet iets wat we achteraf pas gedaan hebben, toen alle code reeds voltooid was.

6.1

Wanneer een functie niet aan de verwachting voldeed, hebben we eerst de code nog eens grondig ge¨ınspecteerd om te kijken of we de fout op deze wijze konden vinden. Wanneer de fout hierdoor niet opgespoord kon worden, hebben we middels de Javascript functie alert - deze functie genereert een dialogbox, die het meegegeven argument als bericht weergeeft - stap voor stap de functie doorlopen om te zien tot welk moment de functie nog deed, wat deze hoorde te doen.

Client

Wat het debuggen van de Javascript code moeilijk maakte, is het feit, dat Aan de kant van de client kunnen er twee dingen fout gaan. Enerzijds wanneer een syntax fout gemaakt wordt, alle code in een bepaald bestand kunnen er fouten zitten in de Javascript code en anderzijds in de CSS code, niet meer uitgevoerd wordt. Dit had tot gevolg, dat het hele bestand grondig waarbij de CSS verantwoordelijk is voor de layout van de pagina. nagelopen diende te worden, wanneer zo’n situatie zich voor deed. Helaas was noch Eclipse, noch Notepad++, noch GEdit op dit gebiedt behulpzaam, omdat fouten in de syntax niet door deze programma’s geconstateerd wor6.1.1 Javascript den. Omdat de Javascript functies relatief kleine blokjes code zijn, volstond het in veel gevallen om een functie uit te voeren en te controleren of het 6.1.2 CSS gewenste resultaat voldeed aan de verwachtingen. Dit kon echter vaak niet geautomatiseerd worden, omdat veel van de Javascript functies betrekking Voor de layout van de pagina’s hebben we gebruik gemaakt van CSS. In hadden op een grafische verandering in de site. principe is het debuggen van CSS vrij simpel, omdat CSS enkel definieert 36

hoe bepaalde elementen van de pagina er uit moeten zien, en dit letterlijk in een oogopslag gecontroleerd kan worden. Het probleem op dit gebied was echter de verschillende soorten browsers, waarover een client kan beschikken.

6.2

Server

Hoewel we aan de kant van de client rekening moesten houden met het type browser, konden we de code voor de server volledig optimaliseren voor ons systeem. Daarnaast is de enige code die uitgevoerd wordt aan de kant In tegenstelling tot Javascript zijn de browser implementaties van CSS van de server PHP, wat het debuggen van de server makkelijker maakte. verre van uniform. Door W3C - World Wide Web Consortium - is er weliswaar een standaard gedefinieerd, maar niet alle browsers houden zich Op een manier, analoog aan die van het debuggen van Javascript, zijn daaraan. Gevolg is, dat wanneer de layout van een bepaalde pagina perfect we te werk gegaan met het debuggen van PHP. Als inspectie van de code is in de ene browser, het er mogelijkerwijs enorm lelijk uit ziet in een an- niets opleverde, zijn we functies gaan doorlopen met behulp van de ekko dere. We hebben al onze pagina’s dus in meerdere browsers moeten testen functie; bij het debuggen van Javascript gebruikten we hier de alert functie om er zeker van te zijn, dat het er fatsoenlijk uit ziet voor het gros van de voor. Deze ekko functie hebben we zelf geschreven, en krijgt als argument Internettende populatie. de weer te geven message mee, welke vervolgens op het beeldscherm wordt geprojecteerd door middel van het PHP commando echo. Op basis van statistieken betreffende het browser gebruik van Internetters, hebben we de volgende browsers ge¨ıdentificeerd als dusdanig populair, dat de pagina’s in ieder geval in deze browsers goed weergegeven moeten worden:

6.3

AJAX

Hoewel browser-diversiteit geen probleem was bij het debuggen van PHP, was het gebruik van AJAX dat wel. Door de manier, waarop AJAX functioneert, krijgt de server nooit de kans om ge-echo-de boodschappen op het scherm weer te geven. Wanneer er - na een AJAX request - geen correcte respons terugkwam, kon de fout eigenlijk op vijf verschillende plaatsen zitten:

• Internet Explorer 6 • Internet Explorer 7 • Firefox 2

1. In de Javascript functie, die de AJAX request doet.

• Firefox 3

2. In de PHP functie, die de AJAX request opvangt. Overigens hebben de verschillende implementaties van CSS in browsers ook enig effect gehad op de Javascript code, omdat de CSS elementen vanuit Javascript gewijzigd kunnen worden - iets wat veelvuldig gebruikt wordt door ons - en de naamgeving van deze elementen bij verschillende browsers niet volledig uniform is. 6.2. SERVER

37

3. In de PHP functie, die de AJAX request verwerkt. 4. In de PHP functie, die de respons op de AJAX request terugstuurt. 5. In de door PHP gegenereerde HTML code op de pagina. HOOFDSTUK 6. TESTS

Hoewel het doorlopen van de Javascript code door middel van alert geen probleem was, zorgde vooral het debuggen van PHP in deze gevallen voor lastige problemen, die inzicht, tijd, en geduld vergden. Vaak moest de hele AJAX respons aandachtig beschouwd worden - het probleem hiervan was, dat deze erg lelijk opgemaakt, en daarmee erg onleesbaar was - voordat de fout ontdekt werd.

6.4

Alpha tests

Op dit moment zijn er nog geen tests gedaan met ëchte¨ gebruikers. We zijn van mening, dat het op dit moment nog te weinig nut heeft om mensen het systeem te laten testen, simpelweg omdat de wizard nog in ontwikkeling is, en er vooral aan het advies-genererend deel een hoop gesleuteld kan en zal worden. Een alpha test zou hierdoor enkel betrekking hebben op de look and feel van de website en het invullen van de vragenlijst. Wij vinden, dat we beter nog een tijdje door kunnen werken - buiten het Bachelorproject - om vervolgens een volledige alpha test af te nemen met een bescheiden rond de vijftien stellen - populatie. Indien gewenst kunnen we de resultaten van een dergelijke test in de toekomst publiceren.

6.4. ALPHA TESTS

38

HOOFDSTUK 6. TESTS

Hoofdstuk 7

Evaluatie Om te beginnen hebben we de ondersteuning en inzet van de opdrachtgever als erg prettig ervaren. Er was meer dan eens per week contact middels mail of telefoon, en minimaal één keer per twee weken een vergadering over de stand van zaken. Hoewel dit voor ons stimulerend werkte, was dit intensieve contact tevens van noodzakelijk belang.

Een groter probleem was het het feit, dat de requirements, waarmee we begonnen, enerzijds onvolledig waren, en anderzijds gedurende het project vrij ingrijpend veranderd zijn. Voor het eerste ontwerp van de wizard bestond bijvoorbeeld al een stuk implementatie, toen duidelijk werd, dat de wizard er toch anders uit zou moeten komen te zien. Het werk, wat in die implementatie zat, was dus goed beschouwd verloren tijd.

Bij het begin van dit project heeft de opdrachtgever ons reeds verteld, dat er ruimte was voor eigen invulling, ideeën, en dat we mee mochten denken over hoe het systeem er uit zou komen te zien. Hoewel dat één van de factoren was, die het project voor ons meer interessant maakte dan andere opdrachten, schatten we de strekking van deze boodschap niet geheel op waarde in.

Al met al zijn we veel tijd verloren door het constant veranderen van de requirements van het systeem. Op het moment van schrijven is het systeem dan ook nog niet af. Ons eigen gevoel is, dat we hetgeen er nu staat ook in een kortere periode dan dertien weken hadden kunnen maken, als vanaf het begin duidelijk was geweest, hoe het eruit moest komen te zien. Anderzijds hebben we naar ons idee conceptueel ook zeker ons steentje bijgedragen, wat uiteraard veel tijd heeft gekost, maar waarvan de opbrengst moeilijk in het Eigenlijk kwam het er op neer, dat de opdrachtgever een idee had, maar product is te vatten. nog niets wist over de uitwerking, zowel op grafisch als technologisch vlak. Hoewel we in eerste instantie ook de grafische kant van het geheel zouden Wat we zeker hebben geleerd in dit project, is dat de communicatie tussen bekijken, werd ons al snel duidelijk, dat we daar niet goed genoeg in zijn, opdrachtgever en programmeur inderdaad in bepaalde opzichten moeizaam en voor de layout heeft de opdrachtgever dan ook een professionele designer verloopt, door een verschillende insteek, zoals reeds vaak in colleges is aangetrokken. aangegeven. Met eigen ogen hebben we kunnen aanschouwen, dat een op39

drachtgever niet altijd in kan schatten waarom iets moeilijk of juist makkelijk is, en waarom het schrijven van software zo’n bewerkelijk proces is. Ook het gegeven, dat een opdrachtgever niet precies weet wat hij wil of dit niet onder woorden kan brengen hebben we aan den lijve ondervonden, alsmede onze eigen inschattingsfouten wat betreft het conceptuele werk, dat we moesten verrichten. Door de veranderende requirements kwamen we ook niet meer uit met de planning, die we aan het begin van het project gemaakt hebben. Hoewel het eerste stukje ontwerp sneller ging, dan we dachten, kwam er vervolgens later in het project nog een heel stuk ontwerp achteraan. Hoewel we in onze planning rekening hielden met software ontwerp middels het waterval model, kwam het in de praktijk meer neer op extreme programming. De samenwerking binnen de groep leverde overigens geen problemen op. We hadden reeds in dezelfde samenstelling in eerdere projecten met elkaar samengewerkt, waardoor we op voorhand al wisten, wat we aan elkaar hadden. De werkverdeling, die we aan het begin van project gemaakt hebben, is door alle groepsleden zonder frictie nagevolgd, en iedereen was tevreden met de aan hem toebedeelde taken. Wel hadden we op voorhand betere afspraken moeten maken over naamgeving van functies en tabellen. Bij integratie van de losse componenten hadden we soms namelijk last van inconsistente naamgeving, wat refactoring tot gevolg had.

40

HOOFDSTUK 7. EVALUATIE

Hoofdstuk 8

Conclusie Bij aanvang van het project hadden we ons, naast het implementeren van de Must Haves van het MoSCoW diagram, geen bepaalde doelen gesteld. Als we zuiver kijken naar de implementatie van deze Must Haves - dit is ons niet volledig gelukt - kunnen we stellen, dat we onze doelen niet bereikt hebben, en dat het project dus eigenlijk niet volledig succesvol is verlopen. Het onderstaande overzicht toont welke ’Must Haves’ volledig en welke niet of niet volledig zijn ge¨ımplementeerd. De dik gedrukte onderdelen in dit overzicht zijn niet of slechts gedeeltelijk ge¨ımplementeerd.

• Wizard – Vragenlijst genereren – Antwoorden verwerken – Advies genereren – Beantwoorde vragenlijsten raadplegen – Adviezen raadplegen – Vragen wijzigen (enkel voor CMS-gebruikers) • Geschiedenis en statistieken

Must Haves

– Dagelijkse aanmeldingen en afmeldingen

• Account beheer

– Bezoeker statistieken

– Registreren

– Gegevens een aantal jaar bewaren

– Aanmelden

• Mediafunctionaliteit

– Gegevens wijzigen – Rol aanduiding

– Geluid

– Verzonden alerts raadplegen

– Flash 41

• Content Management Systeem – Statistieken weergeven – Alerts wijzigen – Teksten op de website wijzigen – Afbeeldingen op de website wijzigen – Geluidsfragmenten op de website wijzigen – Verwijderen / toevoegen / deactiveren / activeren accounts • Overige voorwaarden – Periodieke database backup – Vindbaarheid Google – Betaalmodule Wanneer we echter ook naar het gehele proces kijken en de initiële requirements naast het huidige systeem leggen, zien we, dat er tijdens het project conceptueel in die mate veel veranderd is, dat er van falen eigenlijk geen sprake is. Wat we niet ge¨ımplementeerd hebben, is de betaalmodule en een deel van de wizard, die conceptueel gezien op dit moment zelfs nog niet geheel uitgewerkt is. Het werk, dat wij konden doen, hebben we echter gedaan, en hoewel de requirements niet volledig ge¨ımplementeerd zijn, vinden we, dat de gestelde doelen in dit licht weldegelijk behaald zijn.

42

HOOFDSTUK 8. CONCLUSIE

Hoofdstuk 9

Aanbevelingen Het mag duidelijk zijn, dat het systeem op dit moment niet af is. Wat betreft de wizard moet er vooral nog gesleuteld worden aan het resultaat voor de gebruikers. Vooralsnog wordt het resultaat slechts getoond als conclusies uit de beantwoording van vragen; op den duur (na inmenging van psychologen in het project) kan daar textuele raadgeving aan gehangen worden. Conceptueel is daar inmiddels reeds één en ander van bekend, maar de implementatie daarvan kan nog wel enige tijd kosten. Op een bepaald moment in de tijd zal ook de betaalmodule geschreven moeten worden, hoewel we niet verwachten, dat dat erg bewerkelijk is.

Waar ook nog tijd aan besteed kan worden is het CMS, waarbij de aandacht vooral zal gaan naar datamining. Idealiter heeft de website in de toekomst meer dan duizend leden, die gezamenlijk een enorme bron van informatie betreffende relaties zijn. Hoewel het CMS nu reeds eenvoudige statistieken kan weergeven, zou dit in de toekomst nog veel geraffineerder en gedetailleerder kunnen.

Naast de wizard is tijdens het project ook de zogenaamde Quatro Stagioni Test bedacht. Omdat deze test op een compleet andere manier functioneert dan de huidige wizard willen we voorstellen om deze in de toekomst niet te zien als onderdeel van de wizard, maar als deelsysteem naast de wizard. Conceptueel zijn er dan dus drie deelsystemen, namelijk de wizard-module, de qst-module, en de winq-module, die weliswaar met elkaar communiceren om tot de meest accurate resultaten te komen, maar verder op zichzelf staande modules zijn.

Het voornaamste onderhoud zit in de content van de site, en dan in het bijzonder de vragen en anticipatie op wensen van de gebruikers. Hier zullen in de toekomst de bovengenoemde psychologen zich over moeten buigen. Code-technisch gezien zal er voornamelijk onderhoud in de vorm van bugfixes plaatsvinden. Over eventuele grotere veranderingen valt op dit moment weinig te zeggen, behalve dat de modulariteit van het systeem er voor zorgt, dat ingrijpende aanpassingen slechts invloed hebben op het deel, dat aangepast wordt.

Het werk, dat nog gedaan moet worden, is niet zuiver technisch van aard. Er zullen bij het verder ontwikkelen van zowel wizard als qst ook psychologen of relatie-deskundigen betrokken moeten worden. Dit geldt in het bijzonder voor het adviseren van gebruikers betreffende hun relatie.

43

Tot slot zal er, zodra het systeem daar klaar voor is, ook een alpha en beta test afgenomen moeten worden om te zien hoe het systeem functioneert onder daadwerkelijk gebruik. Zoals we reeds eerder aangegeven hebben, is het van belang, dat het systeem op dat moment in een dusdanig stadium van ontwikkeling zit, dat er geen grote aanpassingen of implementaties meer gedaan hoeven te worden.

44

HOOFDSTUK 9. AANBEVELINGEN

Bijlage A

Opdrachtbeschrijving

45

• koppelingen met demografische informatie (bijv. Google maps)

Ontwikkeling front- en backend NationaleRelatietest.nl Trefwoorden: php5, flash, html, xml, databases, eigen initiatief, flexibiliteit, ruime vergoeding, bonus De Nationale Relatietest is een eigentijds concept voor levenspartners omelkaar periodiekte confronteren met verwachtingen, wensen en tekortkomingen in de relatie en aldus een bijdrage te leveren aan de verbeteringen zelfs mogelijkde duurzaamheidvan relaties. Hiermee beoogt de NRT te voorzien in een vacumdat is ontstaan door de sterkafgebrokkelde rol van familie en kerken. Naast een sophisticateden flashy interactieve website wordt het NRT concept geflankeerd door een televisieprogramma, een column in een landelijkdagbladen workshops in den lande, waarin het omgaan met uitkomsten van de Test centraal staan. Een pretentieus pakket! Naintroductie in Nederlandis het de bedoelinghet concept te internationaliseren. Centraal staat de Test zelf, die viaeen webapplicatie toegankelijkis. De Test bestaat uit een vragenset voor beide partners en een wizarddie hun antwoorden verwerkt en de uitkomsten, met name ook adviezen grafisch en ondersteunddoor voice notice- weergeeft aan beide partners, omzo de confrontatiedrempel te verlagen. Antwoorden worden bewaardzodat vragen bij latere tests kunnen worden geherformuleerden nieuwe antwoorden kunnen worden vergeleken met de vroegere en aldus ookeen ontwikkelingen in de relatie (grafisch) zichtbaar worden gemaakt.

• datamining • gelaagdheidvan de vragen /geavanceerde user interface • inbouwen grafische en voice over functie • bevorderen van de vindbaarheid Wij bieden aan een duo of groepje van max 3 studenten • een uniekproject met de media-exposure grote maatschappelijke impact • veel ruimte voor eigen inbrengen initiatief • vergoedingvan 750,- p.p. + bonus • kennisverdiepingvan- en samenwerkingmet vaexperts uit een geheel andere discipline • flexibele invulling, mogelijkheidtot thuiswerkend • deskundige en zeer intensieve begeleiding

Opdracht Het ontwerpen, implementeren en testen van een hoogwaardige en zeer goedbeveiligde wizarden haar omlijstende presentatie. Behalve gebruikelijke opleveringseisen zoals uitbreidbaarheid, onderhoudbaarheiden documentatie raakt de architectuur de volgende onderwerpen: • gesloten opindividueel niveau, open opcollectief niveau • interoperabiliteit 46

BIJLAGE A. OPDRACHTBESCHRIJVING

Bijlage B

Vooronderzoek

47

Voorwoord

Beschrijving van de opdracht

In dit document zullen we het resultaat van ons vooronderzoek presenteren. De Nationale Relatietest is een eigentijds concept voor levenspartners om We zullen beginnen met een korte beschrijving van de opdracht, waarna we elkaar periodiek te confronteren met verwachtingen, wensen en tekortkomindieper in zullen gaan op de tools en technologien, die we van plan zijn om gen in de relatie en aldus een bijdrage te leveren aan de verbetering en zelfs te gebruiken. mogelijk de duurzaamheid van relaties. Hiermee beoogt de NRT te voorzien in een vacu¨ um dat is ontstaan door de sterk afgebrokkelde rol van familie en kerken. Centraal staat de Test zelf, die via een webapplicatie toegankelijk is. De Test bestaat uit een vragenset voor beide partners en een wizard die hun antwoorden verwerkt en de uitkomsten, met name ook adviezen grafisch en ondersteund door voice notice weergeeft aan beide partners, om zo de confrontatie-drempel te verlagen. Antwoorden worden bewaard zodat vragen bij latere tests kunnen worden geherformuleerd en nieuwe antwoorden kunnen worden vergeleken met de vroegere en aldus ook ontwikkelingen in de relatie (grafisch) zichtbaar worden gemaakt. De opdracht behelst het ontwerpen, implementeren en testen van een hoogwaardige en zeer goed beveiligde wizard en haar omlijstende presentatie. Behalve gebruikelijke opleveringseisen zoals uitbreidbaarheid, onderhoudbaarheid en documentatie raakt de architectuur de volgende onderwerpen: • Gesloten op individueel niveau, open op collectief niveau • Interoperabiliteit • Koppelingen met demografische informatie • Data mining • Gelaagdheid van de vragen / geavanceerde user interface 48

BIJLAGE B. VOORONDERZOEK

• Inbouwen grafische en voice over functie • Bevorderen van de vindbaarheid

Tools In deze sectie bespreken we de verschillende tools en technologieën die we besloten hebben te gaan gebruiken, met een korte toelichting.

Webserver We hebben hier gekozen voor de open-source server Apache, van de Apache Software Foundation (http://www.apache.org/). Deze webserver is enorm populair: in april 2008 maakten meer dan 50% van alle websites gebruik van Apache. Een groot voordeel van Apache is de modulaire architectuur, die met versie 2.0 sterk is verbeterd.

Bij het kiezen van de webserver software moesten we met een aantal factoren rekening houden. Allereerst wisten we, dat de software uiteindelijk zou moeten draaien op een Ubuntu linux systeem. Dit was een eerste argument tegen het alternatief voor Apache, IIS van Microsoft. Het is namelijk niet mogelijk om IIS te gebruiken op een niet-Windows systeem. Hoewel dit eerste argument eigenlijk al afdoende is, zouden er in die mate zwaar wegende contra-argumenten kunnen bestaan, dat we beter zouden kunnen migreren naar een Windows systeem. Factoren die hierbij een rol spelen zijn kosten en de efficiëntie van de server. Omdat Apache open source is, zitten er aan het gebruik geen kosten verbonden, terwijl IIS een commercieel product is. Wat betreft efficiëntie ontlopen de twee webservers elkaar niet, waardoor de contra-argumenten niet dermate zwaar wegen om naar een Windows systeem te migreren.

Locaal gebruiken we versie 2.2.8 (onder Windows) en versie 2.2.4 (onder Linux). Op de server draaien we versie 2.2.4 (Ubuntu). 49


Database

zonder dat daar een page-refresh voor nodig is. Dit komt de snelheid en interactiviteit van de website enorm ten goede.

Als database systeem hebben we voor het open-source systeemMySQL gekozen, wat een gebruikelijke en bewezen combinatie met Apache is. Merk op, dat we niet van plan zijn om gebruik te maken van Adobe Flash Anderde database systemen als Oracle en PostgreSQL genoten niet onze of Microsoft Silverlight, maar de grafische dynamische elementen willen revoorkeur, omdat een systeem als Oracle enkel commercieel verkrijgbaar is, aliseren door een combinatie van CSS, Javascript en Scalable Vector Graphen MySQL bij ons reeds bekend was in tegenstelling tot PostreSQL. ics. We maken gebruik van MySQL 5.0.45.

Programmeertaal

Plugings / Libraries PDO PDO is een PHP klasse, die een veilige en stabiele connectie met de MySQL database maakt. Tevens zorgt deze ervoor, dat er niet meerdere dezelfde connecties met de database gemaakt worden, waardoor de database niet nodeloos belast wordt. We zijn overigens wel van plan om nog een wrapper voor deze PDO klasse te schrijven, om de functie aanroepen, die nodig zijn om een query uit te voeren, door één enkele aanroep van de wrapper gesimuleerd kunnen worden. Technisch is dit niet noodzakelijk, maar het vergroot het gebruikersgemakt en verkleind de hoeveelheid code.

Als programmeertaal is gekozen voor de scripttaal PHP. De beslissing hiervoor vloeide eigenlijk voort uit onze keuze voor Apache als webserver. Als we gekozen hadden voor IIS hadden we C# als programmeertaal kunnen gebruiken. Als we het gebruik van C# erg belangrijk hadden gevonden, had dit in alsnog een argument kunnen zijn voor het gebruik van IIS. In onze ogen zou het grootste voordeel van C# ten opzichte van PHP de mogelijkheid van object-oriëntatie zijn, echter, vanaf PHP5 is het gebruik van objecten ook binnen PHP mogelijk. Dit leidt ertoe, dat C# geen voordelen meer biedt FCKeditor Een open source PHP plugin, waarmee eenvoudige tekst ediboven PHP. Overigens hadden we met beide programmeertalen al ervaring, tors in een HTML pagina ge¨ıntegreerd kunnen worden. We denken dit met wat dus geen argument voor één van beide was. name nodig te hebben bij het CMS, dat we ook zelf gaan ontwikkelen naast de website. Het was mogelijk geweest om een bestaand (al dan niet) open source CMS, zoals Joomla of Drupal, te gebruiken, maar hier hebben we We gebruiken PHP 5.2.5 (locaal) en 5.2.3-1 (op de Ubuntu server). toch vanaf gezien, omdat de opdrachtgever enerzijds geen goede ervaringen heeft met bestaande CMSen, en wij inschatten, dat het te implementeren Technologie¨ en bij de client systeem in die mate specifiek wordt, dat integratie van een bestaand CMS We gebruiken CSS (Cascading Style Sheets) voor de opmaak en stijl geen voordelen oplevert. van de website. Verder gebruiken we JavaScript en AJAX (Asynchronous JavaScript And XML) voor de dynamiek op de pagina. AJAX kan ervoor wz jsgraphics.js Een open source Javascript plugin om divs als canvas zorgen dat verschillende informatie op de pagina weergegeven kan worden en te gebruiken en hierop afbeeldingen te tekenen. We weten nog niet predata uit de database gehaald kan worden bij verschillende gebruikers-acties, cies waarvoor en of we deze plugin gaan gebruiken, maar we kunnen ons 50


voorstellen, dat bij het weergeven van testresultaten ook grafieken moeten phpMyAdmin Database management software voor MySQL. We kunnen worden weergegeven. Om deze grafieken dynamisch te tekenen kunnen we hiermee een grafische weergave van de tabellen inzien, en zowel de content als de structuur van de database wijzigen. Dit werkt eenvoudiger dan het Javascript gebruiken, en zou deze plugin dus van pas kunnen komen. uitvoeren van alle queries in een console omgeving.

IDE Om PHP te ontwikkelen gebruiken wij de Integrated Development Environment Eclipse PDT, van Sun (http://www.eclipse.org/pdt/). Dit is een plugin voor het, vooral onder Java-programmeurs zeer populaire, Eclipse framework. Deze (open source) IDE biedt een mooie, duidelijke syntax kleuring voor onder meer PHP, HTML, CSS, JavaScript en XML. Deze werkt zowel onder Windows als onder Linux. We gebruiken versie 1.0.2. Naast bovengenoemde feature, bevat Eclipse PDT onder andere ook nog een error checker, uitstekende zoek functies, en een explorer waarin complete projecten bijgehouden kunnen worden.

Overige ondersteunende software Voorts een overzicht van andere software, die we gaan gebruiken ter ondersteuning van ons project. Notepad++ Text-editor voor Javascript editing, omdat Eclipse hierin naar ons idee tekort schiet. GEdit Text-editor om remote code te editen op de desktop. Wordt onder Linux ook gebruikt voor Javascript editing. VIM Text-editor om remote code te editen in de console. GIMP Software om de layout van de site te verwezenlijken. GIMP is een open source alternatief voor het commercieel beschikbare Adobe Photoshop en genoot vanwege kosten en platform onafhankelijkheid de voorkeur. 51


Bijlage C

Opzet requirements

52

Functionaliteit (het ’WAT’)

Rol 4: Getuigen (bij huwelijk) • Raadplegen (gedeeltelijke) weergave adviezen van wizard nav vraagstelling

Rol 1: Account (Partner-duo dat ’member’ is); in beginsel SAMEN • Aanmelden incl registreren basisgegevens; wijzigen basisgegevens

Rol 5: Gemeentelijke burgelijke stand

• Afmelden (is einde toegang, doch historie wordt wel bewaard) • Inzien gezamenlijk advies wizard nav invullingen van vragenlijsten

• Toevoegen nieuwe huwelijks inschrijvingen en geregistreerde partnerschappen

• Raadplegen van/inzage in gezamenlijke historie

• Doorgeven/muteren echtscheidingen en beindigingen GP’s • Raadpleging mbv query statistieken voor inwoners van (alleen) hun gemeente

Rol 2 (a en b): Partner X en Partner Y van deelnemend duo • Invullen (half)jaarlijkse vragenlijst (hart van het systeem) • Invullen 3- 5- of 7- jaarlijkse uitgebreide lustrum-vragenlijst

Rol 6: Administrator • Aanpassen van de (vragen op de) vragenlijsten aan partners

• Inzien persoonlijk advies nav door beiden ingevulde vragenlijsten • Query-selecties maken uit data base van stellen en individuen naar elk van de door hen ingevulde kenmerken; van sexe tot inschrijvingsduur, van type relatie tot antwoord-historie etc t.b.v statistieken en gerichte alert services

• Raadplegen individuele invul-historie van vragen/antwoorden

Rol 3: Genteresseerde bezoeker • Uitleg over voor wie de site bestemd is en hoe die werkt

• Auto-prolongatie maken van abonnements incasso’s

• Uitleg over diensten, kosten en abonnementen

• Handmatig aanpassen notificaties uit rol 7

• tellerstand bezoekers en ingeschreven accounts

• Collectieve EN gerichte mail alerts kunnen verzenden n.a.v events (bijv Valentijnsdag)

• newsboard met statistieken (anoniem) van ingeschreven accounts • info over samenlevingsvormen en (voorbeeld)contracten daaromtrent

De Wizard en automatische notificaties (per email EN sms)

• zelf inschrijven van een (ander) stel als member bij wijze van kado

• Dagelijkse listing genereren van nieuwe aanmeldingen en afmeldingen; 53

BIJLAGE C. OPZET REQUIREMENTS

• Auto alert aan administrator van accounts die meer dan 2 jaar niet zijn geraadpleegd

Opmerkingen en wensen over het HOE

• Wizard tbv verwerking vragenlijsten tot adviezen aan partners en het duo alsmede opslag van antwoorden en adviezen tbv account-historie en statistieken • Auto alerts aan members 3 dagen voor hun trouwdag en op hun inschrijvingsdag • Alert aan partner X of Y zodra de andere partner vragenlijst heeft ingevuld

• Timing tests: maand, halfjaar, jaar, 3 jaar, 5 jaar, 7 jaar (abonnement per 7 jaar!) • Pasfoto’s toevoegen van de deelnemers (bij het oppoppen van de account is altijd de ander te zien • Grafisch-intuitieve-speelse manier om vragen in te kunnen vullen, ondersteund door beschaafde soudseffects • Grafische weergave van adviezen vanuit de wizard • Geluidsweergave van adviezen uit de wizard

Randvoorwaarden en perifere functies

• Geluidsintro (gesproken uitleg door vertrouwde radiostem bij bezoek en aanmelding

• Beveiliging accounts tegen inbreuk derden • Beveiliging individuele vragenlijst en adviezen tegen inbreuk partner en derden • Automatische back up van de gehele database

• Hartslag als grafische symboliek vwb de conditie van de relatie • Email alerts naar sms van mobieltjes • Eenvoudige Alert message-generator (met steeds ververste boodschappen) bij repeterende events: trouwdag, Valentijdag, verjaardagen

• Hoge vindbaarheid site mbv tags in Google • Complexere Alert message-generator bij incidentele ingrijpende events: geboorte, overlijden dierbare, afronding studie, nieuwe baan, verhuizing, langdurige ziekte of ongeval (zowel vlak na het gebeuren -voor zover bekend- als ook met een passende timelag daarna)

• Koppeling (automatische) betaalmodule ivm registratie membership

optionele (niet primaire) functionaliteit • Activeren en blokkeren inzage optie van getuigen

• Grabbelton met wensen die de ene partner erin stopt en waar de ander random uit kan trekken.... leuke naam verzinnen voor dit fenomeen

• Vastlegging vermogensboedel (jaarlijks) bij huwelijkse voorwaarden

• Sofinummer als unieke identificatie van de individuele deelnemers 54


• Inschrijving en access to account altijd via de gezamenlijke account; Dit setje zou overzichtelijk moeten zijn op 1 web page. De meerkeuze-opties daarna door naar individuele sub-account (beide beveiligd met een apart moeten uitklappen als je bij een bepaalde vraag bent aanbeland en drukken evt de volgende vragen even uit het scherm weg, overzicht komt terug na wachtwoord) invulling van 1 hele vraag. • Bewaring gegevens tot 20 jaar na einde lidmaatschap ivm statistieken • trial membership introduceren met een aparte proeftest als gameGame hoe goed ken ik mijn partner...score vergelijken met anderen; ranking • adspirant membership indien koppel is opgegeven door derden bij wijze van kado, zelf definitief full membership activeren

Terugkerende (basis) (hoofd) vragen, evt te ontleden in deelvragen 1. wat vind je zo leuk of aantrekkelijk aan je partner (meerkeuze opties met cijfers) 2. wat vind je belangrijk in de relatie (MK+open) 3. wat mis je of vind je minder leuke aspecten aan je partner (MK+open) 4. wat zou je graag veranderd willen zien aan je partner (MK+open+ gewicht eraan) 5. hoe waardeer je je eigen leven op een schaal van 1 10 6. hoe waardeer je je relatie (1-10) 7. hoe waardeer je je partner (1-10) 8. hoe denk je dat je partner zijn of haar leven waardeert (1-10) 9. hoe denk je dat je partner zijn of haar relatie waardeert (1-10) 10. hoe denk je dat je partner jou waardeert (1-10) 55


Bijlage D

Use Cases

56

Gegevens partner 1 invullen

1.Pas de gegevens aan waar nodig op een correcte wijze 2.Wijzig de gegevens indien niet correct ingevuld Version: 0.5 3.Verzend de gegevens door op de link Wijzig te klikken Goal: Registeren van partner 1 Postconditions: De gegevens zijn aangepast in de database en partner 1 Summary: Partner 1 vult zijn gegevens in zodat deze later opgeslagen kun- ontvangt een bericht dat de wijzigingen doorgevoerd zijn. nen worden in de database. Op deze manier kan partner 1 later inloggen Author and date: Thijs Zandvliet, 4 juni 2008 met de opgegeven gebruikersnaam en wachtwoord. Verder levert de registratie informatie op welke later gebruikt kan worden voor de wizard en voor Gezamenlijke gegevens invullen statistieken. Actors: Partner 1 Version: 0.5 Preconditions: Geen Goal: Registreren van een stel Trigger: Indrukken van de Registreer knop Summary: De partners vullen informatie in welke hun beiden aangaan Steps: zodat ze als stel opgenomen kunnen worden in de database. 1. Vul de benodigde gegevens op een correctie manier in Actors: Partner 1 en Partner 2 2. Wijzig de gegevens indien niet correct ingevuld Preconditions: Partner 1 en Partner 2 hebben reeds hun gegevens ingevuld 3. Klik op Volgende tijdens de registratie Postconditions: De gegevens zijn opgeslagen in een session en partner 2 Trigger: De link Volgende aanklikken kan zijn gegevens invullen. Steps: Author and date: Thijs Zandvliet, 4 juni 2008 1.Vul de benodige gegevens op een correctie manier in 2.Wijzig de gegevens indien niet correct ingevuld 3.Verzend de gegevens door op de link Registreer te klikken Gegevens partner 1 wijzigen Postconditions: De gegevens zijn ingevoerd in de database en het stel ontvangt een bericht dat de registratie geslaagd is. Version: 0.5 Author and date: Thijs Zandvliet, 4 juni 2008 Goal: Wijzigen gegevens van partner 1 Summary: Partner 1 kan gegevens wijzigen zowel met betrekking tot zijn eigen informatie als de gezamelijke informatie met partner 2. Gegevens partner 2 invullen Actors: Partner 1 Version: 0.5 Preconditions: Partner 1 is geregistreerd en ingelogd Trigger: Wijzig persoonlijke gegevens of Wijzig gezamelijke gegevens aank- Goal: Registeren van partner 2 Summary: Partner 2 vult zijn gegevens in zodat deze later opgeslagen kunlikken nen worden in de database. Hierbij zijn de adresgegevens niet noodzakelijk Steps: 57

BIJLAGE D. USE CASES

als partner 2 samenwoont met partner 1. Op deze manier kan partner 2 later inloggen met de opgegeven gebruikersnaam en wachtwoord. Verder levert de registratie informatie op welke later gebruikt kan worden voor de wizard en voor statistieken. Actors: Partner 2 Preconditions: Partner 1 heeft reeds zijn gegevens ingevuld. Trigger: De link Volgende inklikken Steps: 1.Vul de benodigde gegevens op een correctie manier in 2.Wijzig de gegevens indien niet correct ingevuld 3.Klik op Volgende Postconditions: De gegevens zijn opgeslagen in een session en de gezamelijke informatie kan ingevuld worden. Author and date: Thijs Zandvliet, 4 juni 2008

Author and date: Thijs Zandvliet, 4 juni 2008

Inloggen

Version: 0.2 Goal: Meer rechten tot de website verkrijgen en toegang tot de eigen gegevens. Summary: Na het inloggen is het mogelijk om de wizard te doen, tests te maken, gegevens te wijzigen en meer mogelijkheden beschikbaar te krijgen welke alleen voor leden toegankelijk zijn. Actors: Geregistreerde personen Preconditions: De persoon heeft zich reeds succesvol geregistreerd op de website. Trigger: Op de button Inloggen klikken. Steps: 1.Voer gebruikersnaam in Gegevens partner 2 wijzigen 2.Voer wachtwoord in 3.Druk op de knop Inloggen Version: 0.5 Postconditions: De gebruiker is ingelogd en heeft toegang tot de delen van Goal: Wijzigen gegevens van partner 2 de site welke alleen voor leden beschikbaar zijn. Summary: Partner 2 kan gegevens wijzigen zowel met betrekking tot zijn Author and date: Thijs Zandvliet, 4 juni 2008 eigen informatie als de gezamelijke informatie met partner 1. Actors: Partner 2 Preconditions: Partner 2 is geregistreerd en ingelogd Uitloggen Trigger: Wijzig persoonlijke gegevens of Wijzig gezamelijke gegevens aankVersion: 0.2 likken Goal: De delen van de site welke alleen voor leden beschikbaar zijn verlaten. Steps: Summary: Na het uitloggen is het niet meer mogelijk om gebruik te maken 1.Pas de gegevens aan waar nodig op een correcte wijze van de mogelijkheden die alleen voor leden beschikbaar zijn. 2.Wijzig de gegevens indien niet correct ingevuld Actors: Geregistreerde personen 3.Verzend de gegevens door op de link Wijzig te klikken. Postconditions: De gegevens zijn aangepast in de database en partner 2 Preconditions: De persoon was reeds ingelogd. Trigger: Op de button Uitloggen klikken. ontvangt een bericht dat de wijzigingen doorgevoerd zijn. 58


Steps: 1.Druk op de button Uitloggen Postconditions: De gebruiker is uitgelogd en kan geen gebruik meer maken van de delen van de site die alleen voor leden beschikbaar zijn. Author and date: Thijs Zandvliet, 4 juni 2008

Wachtwoord aanvragen Version: 0.1 Goal: Een nieuw wachtwoord toekennen aan de gebruiker Summary: Als een gebruiker het wachtwoord vergeten is dan kan deze gereset worden dmv username en e-mail adres in te vullen. Actors: Geregistreerde personen Preconditions: De persoon weet de username en het e-mail adres. Trigger: Op de link Wachtwoord vergeten? klikken. Steps: 1.Klik op de link Wachtwoord vergeten? 2.Voer username en e-mail adres in 3.Druk op de button Verzenden Postconditions: De gebruiker krijgt een e-mail met een link om het wachtwoord te vernieuwen. Author and date: Thijs Zandvliet, 4 juni 2008

Contact formulier invullen Version: 0.1 Goal: Een bericht sturen naar de sitebeheerder. Summary: Als een gebruiker om wat voor reden dan ook contact wil op nemen met de sitebeheerder dan is dat mogelijk via dit formulier Actors: Elke bezoeker van de site Preconditions: geen

Trigger: Op de link CONTACT klikken. Steps: 1.Klik op de link CONTACT 2.Voer alle benodigde gegevens in 3.Druk op de button VERSTUUR Postconditions: De informatie wordt per e-mail verstuurd naar de sitebeheerder en zal afhankelijk van het type bericht behandeld worden. Author and date: Thijs Zandvliet, 27 juni 2008

Cadeaubon aanvragen Version: 0.1 Goal: Een cadeaubon voor een stel aanvragen. Summary: Als iemand een lidmaatschap cadeau wilt doen aan een stel dan is dat hiermee mogelijk. Actors: Elke bezoeker van de site Preconditions: geen Trigger: Op de desbetreffende link klikken. Steps: 1.Klik op de link 2.Voer alle benodigde gegevens in 3.Voltooi de betaalprocedure 4.Druk op de button VOLTOOIEN Postconditions: De informatie wordt opgeslagen in de database samen met een code en het stel dat de bon cadeau krijgt kan ipv een overboeking de betaling voldoen door middel van de verkregen code. Author and date: Thijs Zandvliet, 27 juni 2008

59


Bijlage E

Database Diagram

60

61

BIJLAGE E. DATABASE DIAGRAM

62

BIJLAGE E. DATABASE DIAGRAM

Bijlage F

Klassediagram

63

64

BIJLAGE F. KLASSEDIAGRAM

65

BIJLAGE F. KLASSEDIAGRAM

Bijlage G

Flowchart Wizard

66

67

BIJLAGE G. FLOWCHART WIZARD

Bijlage H

Planning

68

69

BIJLAGE H. PLANNING

Bijlage I

CMS Sitemap

70

71

BIJLAGE I. CMS SITEMAP

Bijlage J

CMS Handleiding

72

In deze bijlage wordt het gebruik van het Content Management Systeem nader toegelicht. Aan elk van de zes onderdelen van het systeem zal een sectie gewijd worden, evenals een aantal ’overige handelingen’ die buiten deze deelsystemen vallen. Met deze laatste categorie beginnen we.

Inloggen en gegevens wijzigen Om gebruik van het CMS te mogen maken, moet er een account voor je zijn aangemaakt. Een administrator van het systeem heeft hier de bevoegdheid toe. De inloggegevens bestaan uit een e-mail adres gecombineerd met een wachtwoord. Na het inloggen kom je op de homepagina (zie afbeelding J.1) en kan er gekozen worden uit één der zes categorieën.

Rechts in beeld is het bericht te lezen dat er is ingelogd, met de mogelijkheid om uit te loggen en om de eigen gegevens te wijzigen. Dit blokje is te zien vanaf elke pagina in het CMS. Figuur J.1: Home Na het klikken op ’Wijzig mijn gegevens’ kunnen op volledig intu¨ıtieve wijze de eigen gegevens gewijzigd worden. De naam en het e-mail adres kunnen gewijzigd worden, evenals het wachtwoord. Wanneer het wacht’WYSIWYG’ editor op het scherm waarin de content aangepast kan worden. woord gewijzigd wordt, dient er eerst het oude wachtwoord ingevuld te Klik vervolgens op ’opslaan’ om de tekst naar de database te schrijven. worden, gevolgd door twee maal het nieuwe wachtwoord (om typefouten te voorkomen). Wanneer alleen de naam of het e-mailadres veranderd wordt, mogen de wachtwoord-velden leeg gelaten worden. Wizard Manager Ook de ’Wizard Manager’ is een redelijk intu¨ıtief gebeuren. Zoals op afbeelding J.2 te zien is, kan er van alles aangepast worden. Het wijst In het menu ’Website Manager’, staan alle items die inhoudelijk aangepast zichzelf: secties kunnen aangemaakt, verwijderd, aangepast of verplaatst kunnen worden op de site, onder elkaar. Klik op ’wijzigen’ en vervolgens op worden. Hetzelfde geld voor subsecties en vragen. Daarnaast kunnen ook ’open editor’ om een bepaald item aan te passen. Vervolgens verschijnt er een verschillende ’ingrijpende gebeurtenissen’ (die gebruikers kunnen aanvinken

Website Manager

73

BIJLAGE J. CMS HANDLEIDING

voor het maken van een test) aangemaakt, gewijzigd en verwijderd worden. Ook kan er een zogenaamde ’dummy-test’ gemaakt worden: je vult (met getallen) antwoorden in op alle secties, om vervolgens te kijken wat het resultaat van zo’n dummy-test zou zijn. Dit om snel en eenvoudig te kunnen controleren of adviezen wel juist worden gegenereerd.

Na het doorklikken op danwel individuele, danwel collectieve WinQs, kan er uit een lijst van bestaande ’standaard’ WinQs een keuze worden gemaakt. Klik op ’wijzig’ om de betreffende WinQ te wijzigen. Er verschijnt een popup, waarin de naam van de WinQ aangepast kan worden en er een (optionele) beschrijving van de WinQ geschreven (of aangepast) kan worden. Deze beschrijving dient als eventuele toelichting naar iedereen die via het CMS WinQs aanpast. Daarnaast kan de standaard tekst van de WinQ aangepast worden. Hier kan, voor een persoonlijker noot, de naam van de gebruiker ook in verwerkt worden door de code %user% in te voegen in de tekst. Voor elke gebruiker waar de WinQ voor wordt aangemaakt, wordt het stukje %user% vervangen door zijn of haar naam.

Figuur J.2: Wizard manager

WinQs Manager Wanneer er doorgeklikt wordt naar het submenu ’WinQs Manager’, zijn er drie opties zichtbaar. Er kan enerzijds gekozen worden voor het aanpassen van individuele of collectieve WinQs, en anderzijds kan er gekozen worden om handmatig WinQs aan te maken. 74

Figuur J.3: WinQ manager


Om handmatig een WinQ aan te maken, moeten er de volgende dingen op BSN. Ook kunnen gebruikers worden gezocht met behulp van filters (net als eerder uitgelegd onder WinQs). Na het klikken op de knop ’resultaat’ gekozen worden: is er een lijst te zien met alle gebruikers die aan het filter voldoen. Klik • een datum wanneer de WinQ verzonden dient te worden vervolgens op de user_id voor de gebruikersnaam om de gegevens van deze persoon te tonen. • de geadresseerden; aan wie moet het verslag verzonden worden • het bericht zelf

Statistiek Manager

De datum wordt ingevuld in het dd-mm-jjjj formaat. Om gebruikers toe Op dit moment kunnen statistieken alleen nog per sectie (of subsectie) te voegen, klik op de knop ’toevoegen’. Een overlay zal verschijnen waarin verschillende filters toegepast kunnen worden. Klik op het pijltje naast het van de Wizard bekeken worden. Er kan een sectie gekozen worden, en een betreffende filter om deze te openen, en selecteer vervolgens de toe te passen filter toegepast worden, om de resultaten statistisch weer te geven van een waarden. Met de shift knop ingedrukt klikken selecteert een lijst, en met bepaalde gebruikersgroep over een bepaalde sectie. control ingedrukt kan aan een selectie toegevoegd worden. Wanneer de filters naar wens zijn ingevuld, klik je op de knop ’resultaat’ en vervolgens zullen alle user_id’s van de gebruikers die aan de filters voldoen, in het tekstvak weergegeven. Voor het schrijven van het bericht gelden dezelfde regels als bij de individuele en collectieve WinQs.

CMS Gebruikers Manager In dit deel zijn alle gebruikers die toegang hebben tot het CMS, te zien. Nieuwe gebruikers kunnen aangemaakt worden, bestaande gebruikers kunnen worden aangepast en verwijderd. Van gebruikers kan de naam en het e-mail adres worden aangepast, en - mits de gebruiker geen administrator is - ook de rol.

NRT Gebruikers Manager In deze sectie kunnen gegevens van leden van het NRT opgevraagd en gewijzigd worden. Ook kunnen accounts geactiveerd en gede-activeert worden. Gebruikers kunnen worden gezocht op gebruikersnaam, achternaam of 75


Bachelorproject Eindverslag

Recommend Documents