3-7-2012
Eerste examinator: Marten Wensink
Scriptie
CMS als basis voor
websites
1
Managementsamenvatting
De huidige website van Aquadis is verouderd en daarnaast lastig om te onderhouden. Er is in opdracht van Aquadis een nieuwe website ontwikkeld die gebruik maakt van de laatste technische ontwikkelingen. De kennis die hiermee opgedaan wordt, zal de organisatie helpen bij het verbeteren van de dienstverlening naar haar klanten.
Om het onderhoud van de website van Aquadis gemakkelijker te maken, zal er een CMS
(contentmanagementsysteem) worden geïmplementeerd. Aanbevolen wordt om de Community Edition van DotNetNuke te gebruiken als CMS. Dit CMS is gratis, er zijn veel modules voor
beschikbaar en er is veel documentatie over te vinden. Verder sluit dit CMS geheel aan bij de tools die op dit moment binnen Aquadis gebruikt worden.
Dit project heeft de volgende resultaten opgeleverd.
- Er is een functioneel ontwerp voor de website opgesteld. - Er is een technisch ontwerp voor de website opgesteld.
- Het design van de website is omgezet in een template die gebruikt wordt binnen DotNetNuke
- Er zijn een aantal custom modules ontwikkeld, namelijk:
Het via de sociale media delen van artikelen
Twitter-feed
Facebook-widget
DotNetNuke is geïmplementeerd met de bovenstaande extra modules. Ook is er een contactformulier geïmplementeerd.
2
Inhoudsopgave
Managementsamenvatting ... 1 Voorwoord ... 4 1. Inleiding ... 5 2. Project ... 6 2.1 Context ... 6 2.2 Probleemstelling ... 6 2.3 Doelstelling ... 62.4 Analyse van de huidige situatie ... 7
2.5 Aanpak ... 8
2.5.1 Prioriteiten van de producten ... 8
2.5.2 Planning ... 9 3. Opdrachtomschrijving ... 10 3.1 Onderzoek ... 10 3.2 Functioneel ontwerp ... 10 3.3 Technisch ontwerp ... 10 3.4 Website ... 11 4. CMS-onderzoek ... 12 4.1 Minimale eisen ... 12 4.1.1 Ongeschikte systemen ... 12
4.1.2 De vijf geselecteerde contentmanagementsystemen... 12
4.1.3 Functionele eisen en wensen ... 13
4.2 De vergelijking ... 14
4.2.1 Vergelijking van de interfaces ... 15
4.2.2 Conclusie ... 21
5. Functioneel ontwerp ... 23
5.1 Actoren ... 23
5.2 Use cases ... 23
5.3 Uitwerkingen van de use cases ... 26
5.3.1 Uitwerking “Nieuwe pagina toevoegen” ... 26
5.3.2 Uitwerking “Via de sociale media een deelbaar artikel invoegen” ... 33
6. Grafisch ontwerp ... 37
7. Technisch ontwerp ... 38
3
7.2 Architectuur ... 39
7.2.1 Algemeen ... 39
7.2.2 Architectuur voor de modules... 40
7.3 Ontwikkeling modules ... 40
7.3.1 TwitterFeed ... 41
8. Code ... 43
8.1 Template-pagina voor de skin ... 43
8.2 SqlDataProvider ... 44
8.2.1 SaveSocialHtmlText ... 44
8.2.2 dbo.UpdateSocialHtmlText ... 45
8.2.3 Script om tabellen te genereren... 46
9 Conclusie ... 47
10 Bronvermeldingen ... 48
Bijlage 1: Plan van aanpak ... 49
1. Managementsamenvatting ... 51 2. Inleiding ... 52 3. Projectopdracht ... 53 3.1 Context ... 53 3.2 Doelstelling ... 53 3.3 Probleemstelling ... 53 3.4 Opdrachtformulering... 54 3.5 Op te leveren producten ... 54 4. Aanpak ... 55 4.1 Vereiste vakkennis ... 55 4.2 Methoden en middelen ... 55 4.3 Prioriteiten ... 55 4.4 Risico’s ... 56 5. Planning ... 57 5.1 Activiteiten ... 57 5.2 Mijlpalenplanning ... 57 6. Bedrijfs- en persoonsgegevens ... 58 7. Bronvermelding ... 59 Bijlage 2: Evaluatie ... 60
4
Voorwoord
Na een aantal maanden van schrijven en bijschaven is uiteindelijk mijn scriptie klaar. Met veel plezier heb ik bij Aquadis in Woerden gewerkt om alles zo goed mogelijk af te ronden. Hopelijk zonder dat ik iemand te kort doe, zou ik graag in het bijzonder een aantal mensen willen bedanken.
Mijn dank gaat allereerst uit naar mijn afstudeerbegeleider van de Hogeschool Utrecht, de heer Wensink, voor het aanstrepen van de taalfouten en het advies met betrekking tot het project. Ten tweede wil ik mijn bedrijfsbegeleider, de heer de Jong, bedanken voor de goede sfeer en de begeleiding.
5
1. Inleiding
Dit is de afstudeersciptie van Susanne van Schaik, een studente Technische Informatica bij de Hogeschool Utrecht. Ik zit in het vierde jaar en hoop in augustus 2012 af te studeren. Mijn
afstudeerproject voer ik uit bij Aquadis, een ICT-bedrijf in Woerden. Ik koos voor dit bedrijf, omdat het alleereerst dichtbij huis is (een niet te onderschatten voordeel) en omdat ik vanuit mijn vorige stage goede ervaring heb opgedaan met het .NET framework en C#. Aangezien Aquadis alleen oplossingen levert, die gebaseerd zijn op Microsofttechnologie, leek dit mij een goed stagebedrijf om meer met het .NET framework te doen.
Mijn opdracht was om een nieuwe website voor Aquadis te ontwikkelen. Er waren een aantal eisen die aan de nieuwe site gesteld werden en er moest een goed CMS (contentmanagementsysteem) voor de site geselecteerd worden. Met een contentmanagementsysteem kan men een website beheren zonder veel technische kennis.
In hoofdstuk 2 wordt nader ingegaan op het project, de doelstelling en volgt er een analyse van de huidige sitatie. In hoofdstuk 3 wordt de opdracht omschreven. In hoofdstuk 4 is het CMS-onderzoek uitgewerkt. De resultaten met betrekking tot de ontwikkeling van de website komen in hoofdstuk 5, 6, 7 en 8 aan bod. Tenslotte wordt de conclusie besproken in hoofdstuk 9.
6
2. Project
2.1 Context
Dit project wordt uitgevoerd bij Aquadis, een IT dienstverlener. Aquadis bestaat op het moment van schrijven 10 jaar en is gespecialiseerd in het maken van oplossingen voor bedrijven met behulp van Microsoftproducten. De klanten van Aquadis bevinden zich in diverse sectoren, zoals telecom, logistiek en banken. Geleverde producten variëren van (simpele) websites tot automatisering van bedrijfsprocessen. De werkzaamheden van de afdeling vinden zowel intern als extern plaats. Als afstudeerder ben ik werkzaam binnen de afdeling “.NET ontwikkeling”. De afdeling bestaat uit 6 personen die er fulltime werken.
2.2 Probleemstelling
De huidige website van Aquadis is aan vernieuwing toe. Het grafisch ontwerp is een paar jaar oud en als men de inhoud van de website wil veranderen, moet men handmatig een pagina bewerken. Voor het bewerken van de pagina is HTML-kennis nodig, want er is nog geen CMS geïmplementeerd. Om het onderhoud te vergemakkelijken, zal er dus een CMS voor de website geselecteerd en geïmplmenteerd moeten worden. Verder is Aquadis van plan het CMS voor toekomstige klanten te gebruiken, als zij een nieuwe website willen.
Verder is er ooit een nieuw layoutontwerp voor de website van Aquadis gemaakt (als Photoshop-bestand), maar is nooit gebruikt voor de huidige website en moet nog omgezet worden naar HTML en CSS.
2.3 Doelstelling
Het doel van dit project is om allereerst een goede website voor Aquadis te maken. Hiervoor moet eerst het juiste CMS gekozen worden. Zoals al eerder is aangegeven, wil Aquadis het CMS in de toekomst ook gaan gebruiken voor klanten. Vaak bouwt Aquadis een systeem voor klanten en soms willen deze klanten graag een integratie zien tussen hun eigen website en het systeem. Door hierbij een CMS te gebruiken kan Aquadis zichzelf veel werk besparen. Het doel is dus ook om voor bepaalde klanten een betere werkwijze te creëeren. Voor mijzelf is het doel om mijn diploma te halen. Om dit te bereiken, is het van belang dat het project goed uitgevoerd wordt. Het project “goed” uitvoeren, betekent dat minstens alle must-haves in het project voltooid zijn. Hierdoor worden uiteindelijk ook de belangen van Aquadis behartigd. De must-haves, should-haves en could-haves van het project zijn beschreven in hoofdstuk 2.5.1.
7
2.4 Analyse van de huidige situatie
Dit is een afdruk van de huidige website van Aquadis:
Er is een aantal aspecten dat mij gelijk opviel.
- De header is minder dan 800 pixels breed. Blijkbaar is dit design gemaakt in de tijd dat er nog niet veel computers waren met een hogere resolutie.
- De breadcrumbs zijn niet correct toegepast. De breadcrumbnavigatie (of kruimelpad) wordt aangegeven met de zin “U bevindt zich hier”.
Breadcrumbs zijn vooral handig als er veel doorgeklikt wordt bij pagina’s. Als men bijvoorbeeld op de pagina over de ontwikkelomgeving is en dan vervolgens klikt op een link (op de pagina zelf) naar een andere pagina, is het handig dat er bovenin weergegeven staat welke pagina’s men bezocht heeft. Bij
8 breadcrumbs is deze weergave hiërarchisch: het begint altijd bij home (of index) en daarna volgen eventueel de andere pagina’s. Afhankelijk van de pagina’s die een bezoeker heeft bezocht, wordt deze volgorde steeds langer (KRUG 2005, 65). Bij de screenshot van de Ontwikkelomgeving-pagina zou de breadcrumb eigenlijk moeten luiden: “U bevindt zich hier: Home - Ontwikkelomgeving”. Deze “fout” wordt bij de andere pagina’s ook gemaakt.
2.5 Aanpak
Voor het project is een plan van aanpak gemaakt (zie bijlage 1)
Om uit te vinden welk CMS geïmplementeerd moet worden, zal moeten worden onderzocht welk CMS het beste past bij Aquadis. Hiervoor zullen de eisen en wensen van de opdrachtgever in kaart gebracht moeten worden. Voor de vergelijking koos ik vijf contentmanagementsystemen, omdat er veel contentmanagementsystemen bestaan en de vergelijking niet te groot moest worden.
Als bekend is welk CMS het meest voldoet aan de criteria van de organisatie (in dit geval zijn dat de medewerkers van Aquadis omdat de website de gehele organisatie aangaat), kan het functioneel ontwerp opgesteld worden. Er zullen functionaliteiten zijn die door de opdrachtgever als wenselijk beschouwd worden, maar niet bij het CMS zitten. Deze functionaliteiten zullen geïmplementeerd worden als extra modules. Het technisch ontwerp zal toelichten hoe deze functionaliteiten gerealiseerd worden voor de website van Aquadis.
Het functioneel ontwerp en technisch ontwerp dienen ook als documentatie voor het geval de website in de toekomst doorontwikkeld zal worden.
2.5.1 Prioriteiten van de producten
Voor dit project zullen verschillende producten opgeleverd worden. Niet alle producten hebben dezelfde prioriteit. Voor dit project is beperkte tijd beschikbaar en daarom is er een MoSCoW-analyse gemaakt om te bepalen welke producten het belangrijkst (en minder belangrijk) zijn. De prioriteiten zijn opgesteld in overleg met de opdrachtgever.
Absolute must-haves voor het project zijn:
- Een onderzoek naar 5 verschillende contentmanagementsystemen met een conclusie - Een functioneel ontwerp
- Een technisch ontwerp
- Een implementatie van het CMS
- Een implementatie van de nieuwe layout voor de website - Een scriptie
9 Should-haves voor het project zijn:
- Een module om vragenlijsten voor cliënten op te stellen. - Een contactformulier
- De mogelijkheid om sociale media aan de website te koppelen.
- Een module die het mogelijk maakt om de website ook op mobieltjes en andere devices goed te bekijken. Bij sommige contentmanagementsystemen zit deze functionaliteit er al
standaard bij, dus het hangt af van het onderzoek hoeveel werk dit zal opleveren. Could-haves voor het project zijn:
- Een gebruikersvriendelijke interface voor het beheergedeelte van de website. Ook dit hangt af van welk CMS wordt gebruikt.
2.5.2 Planning
Hieronder staan de opleverdata van de producten en de geplande uren weergegeven. Opleverdatum Geplande uren Titel
8 maart 2012 16 Concept plan van aanpak
29 maart 2012 176 Onderzoek contentmanagementsystemen
5 april 2012 6 CMS kopen/downloaden/installeren
13 april 2012 110 Functioneel ontwerp
20 april 2012 32 Eerste versie van de scriptie
27 april 2012 16 Website PSD omzetten naar HTML en CSS
3 mei 2012 96 Technisch ontwerp
18 mei 2012 32 Tweede versie van de scriptie
11 juni 2012 32 Derde versie van de scriptie
3 juli 2012 60 Definitieve versie van de scriptie
10
3. Opdrachtomschrijving
De opdracht kan in een aantal deelopdrachten opgedeeld worden. Per deelopdracht wordt een product opgeleverd. Het afstudeerproject heeft alleen betrekking op de website van Aquadis en zal dus niet gericht worden op andere applicaties. Kort samengevat houdt de opdracht in dat er op basis van een CMS (dat het beste uit het CMS-onderzoek komt, zie hoofdstuk 7) een website voor Aquadis ontwikkeld moet worden, die voldoet aan de eisen van de opdrachtgever (Jeroen de Jong).
3.1 Onderzoek
De eerste deelopdracht is het onderzoek naar verschillende contentmanagementsystemen. Er moet een vergelijking gemaakt worden tussen 5 (gesteld door de opdrachtgever) verschillende
contentmanagementsystemen die gebaseerd zijn op het .NET framework. Bij deze vergelijking moet vooral gelet worden op de gebruikersvriendelijkheid van het CMS, de mate waarin men zelf het CMS kan aanpassen en de functionaliteiten met betrekking tot sociale media en mobiele websites. Het CMS dat hierbij het beste blijkt te zijn, zal vervolgens de basis vormen voor de nieuwe website.
3.2 Functioneel ontwerp
De nog te ontwikkelen website moet voldoen aan een aantal eisen van het bedrijf en het is aan de stagiare om deze eisen (en wensen) boven tafel te krijgen. Door middel van gesprekken met de opdrachtgever worden deze eisen (en wensen) verkregen. Op grond hiervan kan een functioneel ontwerp gemaakt worden. Dit document legt de functionaliteiten van de website vast en zal met name de functionaliteit van de extra modules beschrijven.
3.3 Technisch ontwerp
Het technisch ontwerp zal de structuur van de website beschrijven (welke pagina’s en mappen zijn er), laten zien hoe de extra modules zijn geïmplementeerd en hoe het CMS zelf geïmplementeerd is.
11
3.4 Website
Voor de website moeten de volgende dingen gedaan worden: het CMS moet geïnstalleerd worden, het ontwerp voor de layout moet omgezet worden naar HTML en CSS en vervolgens naar een skin (of theme) voor de website en de extra modules moeten geschreven worden. Het functioneel en
technisch ontwerp moeten ook up-to-date gehouden worden, als de website in de praktijk ervan gaat afwijken.
12
4. CMS-onderzoek
4.1 Minimale eisen
In het CMS-onderzoek heb ik vijf potentiële contentmanagementsystemen vergeleken. De vergelijking begon in feite al bij het bepalen welke contentmanagementsystemen meegenomen moesten worden in de vergelijking. Er zijn behoorlijk veel contentmanagementsystemen op de wereld. Om in aanmerking te komen voor de vergelijking moet het CMS aan de volgende eisen voldoen:
- Het CMS moet gebaseerd zijn op het .NET framework (want Aquadis is Microsoft partner). - Het CMS moet up-to-date zijn. (ik kwam bijvoorbeeld contentmanagementsystemen tegen
die niet meer geüpdatet waren sinds 2003, dat is te lang geleden)
- Het CMS moet ook voor klanten bruikbaar zijn. Zo moet er rekening gehouden worden met gebruikers zonder technische ervaring.
- Het CMS moet op een server van Aquadis gehost kunnen worden.
4.1.1 Ongeschikte systemen
Op grond hiervan valt al een groot aantal contentmanagementsystemen af. Rainbow Portal1 heeft bijvoorbeeld sinds 2003 geen update meer gehad, dus deze viel af. N2CMS2 is vooral gericht op developers en zal daarom niet meegenomen worden in de vergelijking: ook niet-technische mensen moeten er mee kunnen werken. Orchard3 zag er veelbelovend uit, maar op het moment van
schrijven van deze scriptie wordt op de featureslijst niet duidelijk gemaakt welke features geïmplementeerd zijn en welke slechts gedeeltelijk.
Dit maakt het ongeschikt om voor andere klanten te gebruiken. Microsoft SharePoint kwam ook in aanmerking. Dit is niet in de eerste plaats een CMS, maar men kan er wel sites mee maken. Echter zitten er veel andere features bij die niets meer met websites te maken hebben. SharePoint is eigenlijk te geavanceerd om alleen maar als CMS gebruikt te worden. Het is dan ook niet een CMS, maar een DMS (documentmanagementsysteem). Aquadis is ook niet van plan om met SharePoint aan de slag te gaan, dus er is geen reden om SharePoint te gebruiken.
4.1.2 De vijf geselecteerde contentmanagementsystemen
Uiteindelijk kwam ik tot vijf contentmanagementsystemen die (op het eerste gezicht) geschikt leken voor Aquadis: Kentico, DotNetNuke, Sitefinity, Umbraco en MonoX. De meeste
1
Rainbow Portal http://www.rainbowportal.net/site/1/home.aspx geraadpleegd op 18-4-2012 2
N2 Open Source CMS http://n2cms.com geraadpleegd op 18-4-2012
13 contentmanagementsystemen hadden verschillende edities of pakketten om te kopen en/of te gebruiken. Per CMS heb ik toen bepaald welk pakket het meest geschikt zou zijn voor Aquadis. Hierbij keek ik vooral hoe noodzakelijk de functionaliteiten waren, die per pakket werden aangeboden.
4.1.3 Functionele eisen en wensen
Om de vijf contentmanagementsystemen te vergelijken, maakte ik gebruik van de volgende criteria: - Degene die de website moet onderhouden, hoeft geen HTML-kennis te hebben. Met andere
woorden: om een nieuwe pagina te maken, of om de inhoud van de website te veranderen, moet er geen HTML getypt worden. Het CMS moet dat voor zijn rekening nemen.
- Het moet mogelijk zijn om pagina’s, artikelen, plaatjes en filmpjes toe te voegen. - Er moet een mogelijkheid zijn om vragenlijsten op te stellen voor klantonderzoek - Er moet een koppeling komen met sociale media, waaronder Facebook, Google Plus,
LinkedIn, Twitter en YouTube.
- Het CMS moet uitbreidbaar (te modificeren) zijn. Er moeten eigen modules (uitbreidingen) voor het CMS geschreven kunnen worden. Het beschikbaar stellen van de broncode van het CMS is een groot voordeel ten opzichte van de CMS’en die dat niet doen.
- Het CMS moet niet te duur zijn (maximaal 5000 EUR eenmalig of jaarlijks 1000 EUR). - Help-functie voor het administratiegedeelte.
- Het moet mogelijk zijn meerdere sites te beheren in het CMS.
- Er moet een mogelijkheid zijn om meerdere talen te gebruiken voor de site. Hierbij gaat het eigenlijk om alle talen. Ze hoeven er niet bij geleverd zijn, maar als er een nieuwe taal nodig is, moet deze toegevoegd kunnen worden (met behulp van bijvoorbeeld het installeren van een extra talenpakket).
Niet elk criterium weegt even zwaar. De belangrijkste criteria zijn de prijs, de mogelijkheid om het CMS uit te breiden, het beheren van meerdere sites en het hebben van meerdere talen. De andere criteria kan men beschouwen als een pluspunt, als het CMS (in ieder geval) aan de belangrijkste voldoet.
14
4.2 De vergelijking
Voor de vergelijking selecteerde ik per CMS eerst de meest geschikte editie.
Zo heeft Kentico bijvoorbeeld drie edities: base ($1999), ultimate ($4999) en enterprise marketing ($14999). De ultimate en enterprise edities bevatten functionaliteiten die niet echt nodig zijn. Zo kan de enterprise marketing editie bijhouden welke pagina’s de gebruikers bezoeken en vervolgens de weergave van content hierop aanpassen. Dit is een mooie feature, maar deze is vooral nuttig voor sites met veel pagina’s met verschillende soorten inhoud of webwinkels. De website die voor Aquadis gemaakt zal worden, zal een bedrijfswebsite zijn. Er zullen niet honderden pagina’s zijn en de inhoud zal grotendeels zakelijk zijn. Deze feature zou dus voor de website van Aquadis niet veel nut hebben. Voor klanten met grote websites kan het wel van nut zijn. Een andere feature van de ultimate en enterprise marketing editie was de mogelijkheid om een eigen community op te zetten. Aquadis wil geen eigen community (ook wel een sociaal netwerk genoemd), maar juist integratie met bestaande sociale media. Een eigen community vraagt meer onderhoud en mensen moeten zich ervoor
registreren (niet iedereen is daar bereid toe). Van Kentico bleek dus de base editie het meest geschikt.
DotNetNuke biedt twee edities: de gratis open-source community editie en de betaalde
professionele editie ($2449 per jaar). De gratis editie kan wel commercieel gebruikt worden, maar men kan er dan geen support bij ontvangen. De professionele editie heeft die support uiteraard wel. Andere features die de professionele editie wel heeft en de community editie niet zijn: het hebben van een webshop, mogelijkheden tot het maken van mobiele websites en workflows voor
documentmanagement. Nu had de opdrachtgever aangegeven het CMS niet te willen gebruiken voor documentmanagement, maar de mogelijkheid om de site ook geschikt te maken voor mobieltjes leek interessant.
Sitefinity van Telerik heeft behoorlijk veel functionaliteit, maar het hangt wel van de editie af. De goedkoopste edities hebben veel beperkingen. Bij de small business editie kan er maar één admin zijn (de opdrachtgever vindt dit geen probleem), kan men maar 50 pagina’s hebben en 1000 content items. Dit zijn geen beperkingen die een klant zou willen, zeker niet als men er voor moet betalen ($499). Een andere grote beperking is dat in deze versie geen formulieren gebruikt kunnen worden. De meeste websites hebben tenminste wel één contactformulier. De standaard versie zal meer aan de eisen voldoen. Bij deze zijn het aantal pagina’s en de content items onbeperkt. Er kunnen
formulieren gebruikt worden (een belangrijk voordeel ten opzichte van DotNetNuke). Sitefinity biedt ook een aantal pakketten zoals Mobile (voor mobiele websites) en eCommerce (voor webshops). Automatische aanpassing voor mobiele browsers zou mooi zijn, dus het mobile pakket erbij kopen is te overwegen. De prijs komt dan op $3998 (zonder mobile pakket was het $1999).
Umbraco is, net zoals DotNetNuke, open-source. Er is geen speciale betaalde editie, maar men kan pakketten kopen met extra functionaliteit. Het CMS-gedeelte is gratis. Een aantal features van Umbraco zijn de integratie met Microsoft Word en het vertalen van teksten. Het biedt ondersteuning voor verschillende soorten media (zoals Flash, plaatjes, documenten en video’s). Over de
laatstgenoemde feature beschikken alle vijf de contentmanagementsystemen. Een extra pakket van Umbraco dat interessant lijkt, is Contour. Met Contour kan men formulieren en vragenlijsten opstellen. Andere pakketten met bijvoorbeeld content staging lijken niet noodzakelijk voor een site
15 zoals Aquadis. Bij content staging wordt de geschreven inhoud voor de website eerst in een soort testomgeving gezet, voordat deze op de daadwerkelijke website komt. Dit wordt vaak gebruikt bij websites die veel redacteuren hebben. Aangezien dit bij Aquadis niet het geval is, is content staging niet nodig. Als klanten het willen, kan men het pakket er altijd nog erbij kopen. Het Umbraco CMS met het Contour pakket kost 99 euro.
Het laatste CMS in de vergelijking is MonoX. MonoX kan men gratis gebruiken, maar het is niet open-source. Hun edities zijn niet ingedeeld op grond van functionaliteit. De CNR licence ($99) zorgt er alleen maar voor dat men het copyrightgedeelte van MonoX kan verwijderen. Met de source editie ($2999) kan men de broncode verkrijgen. MonoX richt zich vooral op het maken van een systeem dat een eigen community kan onderhouden. Het CMS bevat namelijk features zoals gebruikersprofielen, gebruikersgroepen (en dan niet voor security, maar zodat gebruikers publiekelijk kunnen laten zien bij welke groep ze horen), fotoalbums en tijdlijnen (zoals bij Facebook). Standaard CMS-features zijn er ook, zoals een HTML-editor en de mogelijkheid om zoekopdrachten op de website uit te voeren.
4.2.1 Vergelijking van de interfaces
Aan het eind heb ik deze verschillende pakketten met elkaar vergeleken en besproken met de opdrachtgever. MonoX is vroegtijdig afgewezen omdat het vooral gericht is op het zijn van een sociaal platform en dat is voor de website van Aquadis overbodig. Als men van dit CMS gebruik zou willen maken, moet men eerst het social platform eruit proberen te halen en het is de vraag of dat lukt.
16 Interface van Umbraco
Umbraco heeft een simpele interface, vraagt wat gewenning, maar na een paar minuten kan men er wel mee overweg (als men de icoontjes onderin gevonden heeft). Umbraco is vooral gebouwd voor de technische gebruikers. Er is geen ondersteuning voor meerdere websites maar men kan wel makkelijk de site verdelen over verschillende mappen.
Hieronder zijn de icoontjes van de interface van Umbraco uitvergroot. Niet elk icoontje is even logisch. Bij een interface moet men proberen om zoveel mogelijk gebruik te maken van conventies (KRUG2005, 34). Een voorbeeld van het gebruik van conventies is een vergrootglas in een
beeldbewerkingsprogramma. In bijna elk beeldbewerkingsprogramma (Photoshop, GIMP, Microsoft Paint) is de tool om in en uit te zoomen een vergrootglas. Makers van deze programma’s maken er gebruik van om beter naar de gebruiker te communiceren welk icoontje waarvoor dient.
Het is niet altijd mogelijk om conventies te gebruiken, maar in dit geval wel. Het icoontje voor content is een potlood en een papier en dat wordt vaak geassocieerd met het schrijven van teksten. In dat geval is op een goede manier gebruik gemaakt van een conventie. Het icoontje van media zal men wellicht herkennen van Windows Picture Viewer en is ook herkenbaar. Een soort gezicht voor Users zullen de meeste gebruikers wel begrijpen, maar bijvoorbeeld het toverstokje kan enige verwarring opwekken. In het geval van Umbraco is het toverstokje bedoeld voor functionaliteiten die met de ontwikkelaar (developer) te maken hebben. De meeste mensen zullen zo’n toverstokje
17 eerder associëren met een wizard. Ook de gekleurde bal voor Settings is niet handig. De kleuren ervan doen vermoeden dat het te maken heeft met de vormgeving van de website, maar met Settings kan men ook scripts en talen instellen en dat is dus niet alleen vormgeving.
Interface van Sitefinity
Sitefinity heeft juist een interface die veel van de verschillende functionaliteiten laat zien. Met behulp van drop-down-menu’s kan de gebruiker pagina’s en dergelijke toevoegen. De trial versie van Sitefinity standard edition laat zien dat er in ieder geval geen ondersteuning is voor het beheren van meerdere sites met Sitefinity. Men kan wel nieuwe projecten starten (en deze dan apart beheren via hun eigen dashboard), maar in het dashboard is het niet mogelijk om het beheer van alle sites tegelijk te doen. Het maken van een formulier verliep gemakkelijk en is zeker een pluspunt. Er is namelijk een form builder ingebouwd en met deze kan men tekst boxen en andere invoervelden op een blanco stuk slepen. Het lijkt veel op de manier om formulieren te maken in Visual Studio. Aangezien ik veel met Visual Studio heb gewerkt, wordt het door mij als “gemakkelijk” ervaren. Als men het formulier heeft gemaakt, kan men het op elke willekeurige pagina invoegen en ook hergebruiken.
18 Interface van Kentico
Kentico heeft ongeveer dezelfde functionaliteit als Sitefinity. Sitefinity heeft echter ook nog integratie met sociale media en Kentico niet. In Kentico kunnen wel efficiënt meerdere websites beheerd worden. Kentico lijkt op een soort “ontwikkelomgeving in de browser”. De navigatie (bovenin) is verdeeld in tabjes om het overzicht te behouden. Als men een wijziging aanbrengt aan de tekst of het ontwerp van de website, kan men de wijzigingen direct zien.
19 De interface van Kentico doet denken aan die van Microsoft Word (links).
In dit programma is de navigatie bovenin ook in tabjes opgedeeld en is er links de mogelijkheid om naar verschillende hoofdstukken te gaan (in Kentico zijn dat de pagina’s).
Dezelfde soort indeling gebruiken als andere programma’s is ook een voorbeeld van het gebruik van conventies.
Gebruikers van Microsoft Word zullen de indeling van Kentico’s interface
herkennen. Zo zullen ze waarschijnlijk minder tijd nodig hebben om met de interface leren om te gaan.
20 Interface van de DotNetNuke Community Edition
Van DotNetNuke heb ik zowel de community als de professional editie uitgeprobeerd. Ze zien er nagenoeg hetzelfde uit (alleen is de grote banner bij de professionele editie blauw in plaats van rood). Het verschil is dat de professionele editie wat meer features heeft. Deze zijn ondergebracht bij vooral de Admin en Host menu’s. Een groot voordeel van de interface is dat men “gelijk” de site die men maakt, ziet. Zo ziet men gelijk het effect van de bewerkingen die men uitvoert. Bij Umbraco en Sitefinity ontbrak dit, al was er wel een mogelijkheid om een preview te krijgen van de bewerking. Hierbij ziet men echter alleen de content area en niet de hele pagina.
21 4.2.2 Conclusie
De prijs van de verschillende systemen speelde ook een rol bij de vergelijking. De gratis versies hadden hierbij een streepje voor. Van de betaalde systemen had Kentico het voordeel dat er verschillende websites beheerd konden worden. Echter is het de vraag of hier wel succesvol eigen modules voor geschreven kunnen worden. Kentico heeft mogelijkheden om templates en eigen documenttypes in de browser te maken en te bewerken. Ze proberen de ontwikkeling van een website “in de browser” te houden. Sitefinity had bijvoorbeeld nog Sitefinity Thunder om integratie te hebben met Visual Studio.
Uiteindelijk heb ik een korte tabel samengesteld, die de belangrijkste verschillen laat zien. Hieronder is de tabel weergegeven. Al deze contentmanagementsystemen voldeden aan de meeste eisen. De gewenste features die (links) in deze tabel staan, zijn de features die ze juist van elkaar doen verschillen. Kentico DotNetNuke (Community Edition) DotNetNuke (Professional Edition) Sitefinity (Standard) Umbraco Nieuwsbrieven Ja Ja Ja Ja Nee Meerdere talen Ja Ja Ja Ja Ja Online formulieren
Ja Nee Nee Ja Voor 99 euro
kan men hier een pakket voor aanschaffen. Beheer van meerdere websites Ja Ja Ja Nee Nee Site aanpassen voor mobieltjes en andere devices ja Ja Ja Voor $1999
extra kan men het mobile pakket erbij kopen. Nee Integratie met sociale media
nee Nee nee Ja (met
Twitter, Facebook, LinkedIn, Google+ en meer) Nee
Open source nee ja ja nee ja
Prijs
$1999 eenmalig, vervolgens $599 per jaar
gratis $2998 per jaar $1999 eenmalig, vervolgens $399 per jaar
22 De belangrijkste criteria om het juiste CMS te kiezen waren de prijs, de mogelijkheid om het CMS uit te breiden, het beheren van meerdere sites en het hebben van meerdere talen.
Als geen rekening gehouden wordt met de prijs, is Kentico de beste keuze voor Aquadis. Het ontbreken van integratie met sociale media (wat Sitefinity wel heeft) is een minpunt, maar het criterium om meerdere websites te kunnen beheren vindt de opdrachtgever belangrijker.
In overleg met de opdrachtgever kwamen we uit op de community editie van DotNetNuke. De prijs bleek de cruciale factor te zijn. DotNetNuke biedt meer functionaliteiten dan het andere gratis CMS (Umbraco) in de vergelijking. Een aantal functionaliteiten biedt DotNetNuke niet (zoals de
formulieren en mobiele websites), maar er zijn veel extra modules die men erbij kan kopen (en sommige zijn gratis). Zo zijn er bijvoorbeeld modules voor formulieren tussen de $75 en $100, wat nog steeds goedkoper is dan Sitefinity of Kentico.
Er zijn ongeveer 600.000 sites die DotNetNuke gebruiken.4 Doordat er zoveel mensen gebruik van maken, is er veel informatie over te vinden. Veel mensen die een CMS overwegen, zullen het weleens tegengekomen zijn. Potentiële klanten hebben liever een product waar ze weleens van gehoord hebben, dan een onbekend CMS. Er is ook veel documentatie beschikbaar over het ontwikkelen met DotNetNuke, zodat men veel kan opzoeken bij het schrijven van modules.
23
5. Functioneel ontwerp
In het functioneel ontwerp staat de functionaliteit van de website beschreven in de vorm van use cases, activiteitendiagrammen en wireframes. De wireframes laten zien hoe de verschillende functionaliteiten grafisch vormgegeven kunnen worden. Er was een kleine discussie over wat allemaal precies in het functioneel ontwerp beschreven moest worden en wat niet, aangezien DotNetNuke een vrij groot systeem is. Het beschrijven van alle functionaliteiten zou erg veel tijd kosten en ten koste gaan van de websiteontwikkeling. In DotNetNuke heeft men nog een aantal aanvullende tools, die niet direct met contentmanagement te maken hebben: het toevoegen van extensies, site log en geavanceerde instellingen voor de server. Uiteindelijk is besloten om vooral de contentmanagementfunctionaliteiten van DotNetNuke te beschrijven en de extra modules die voor dit project gemaakt en geïnstalleerd worden. Zo zal het functioneel ontwerp niet te groot worden en toch compleet zijn. Het functioneel ontwerp dient namelijk ook ter documentatie als men gebruik gaat maken van het systeem en de gebruiker bijvoorbeeld hulp nodig heeft bij het toevoegen van een pagina of het veranderen van de layout.
In deze scriptie wordt alleen een selectie van bepaalde stukken van het functioneel ontwerp getoond. Het functioneel ontwerp is namelijk te lang (77 pagina’s) om volledig opgenomen te worden in deze scriptie.
5.1 Actoren
Voor de website wordt een onderscheid gemaakt tussen twee actoren: de bezoeker (actornummer A1) en de beheerder (actornummer A2). De opdrachtgever heeft aangegeven dat gebruikers zich niet hoeven te registreren om content van de website te bekijken. Uiteraard moet de beheerder wel een geregistreerde gebruiker zijn. Verder dient de beheerder administratorrechten binnen DotNetNuke te hebben om de site te onderhouden.
5.2 Use cases
Om het overzicht te bewaren, is het use case diagram in twee delen opgedeeld. Het eerste diagram geeft een groot deel van de functionaliteiten weer die vanuit DotNetNuke worden geboden.
24 Alleen de beheerder heeft rechten om deze use cases te gebruiken.
25 Het tweede diagram toont de use cases die door het kopen of schrijven van DotNetNuke modules gerealiseerd worden.
26
5.3 Uitwerkingen van de use cases
De use cases zijn allemaal op dezelfde manier uitgewerkt. Eerst volgt er een use case beschrijving met een scenario van de interactie tussen de gebruiker en het systeem. Vervolgens wordt het scenario weergegeven in een activiteitendiagram om te laten zien welke beslissingen er voor het systeem plaatsvinden. Verder worden per use case een aantal wireframes getoond om te laten zien hoe het er grafisch uitziet.
5.3.1 Uitwerking “Nieuwe pagina toevoegen”
Hieronder volgt de uitwerking van de use case “Nieuwe pagina toevoegen”. Met deze use case kan de beheerder een pagina voor de website toevoegen.
5.3.1.1 Use case
Versie NR 0.1
Auteur Susanne van Schaik
Use case Nieuwe pagina toevoegen
Actoren Beheerder (A2)
Samenvatting De beheerder maakt een pagina aan.
Preconditie Geen
Hoofdscenario 1. De actor gaat naar de “Add page” pagina.
2. Het systeem toont een formulier om een pagina toe te voegen. 3. De actor vult relevante gegevens voor de nieuwe pagina in. 4. Het systeem slaat de gegevens op.
5. Het systeem verwijst de actor door naar de Page Settings pagina (pagina-instellingen).
Postcondities Het systeem heeft de gegevens opgeslagen. Alternatief scenario 1
met betrekking tot stap 3
[“ongeldige invoer”] Bij ongeldige invoer geeft het systeem de melding dat de velden correct ingevuld moeten worden.
Met “ongeldige invoer” wordt het leeglaten van een veld of het invoeren van verkeerde data bedoeld.
Het systeem stuurt de actor terug naar het formulier om pagina’s toe te voegen (stap 2) en de actor kan de velden die incorrect waren ingevuld, alsnog invullen.
27 5.3.1.2 Activiteitendiagram
28 5.3.1.3 Wireframe
Hieronder volgt het schermontwerp van het formulier om pagina’s toe te voegen. Het formulier is in meerdere tabbladen opgedeeld.
5.3.1.3.1 Page Details
Bij Page Details kunnen algemene zaken van de pagina worden ingesteld. Het formulier heeft de volgende invoervelden:
1. Page Name (vereist om in te voeren): De paginanaam is de naam van de pagina die gebruikt zal worden voor het navigatiemenu. Het systeem zal deze naam ook gebruiken voor het beheren van pagina’s.
2. Page Title (optioneel): Deze paginatitel zal bovenin bij de titel van de webbrowser zichtbaar zijn.
3. Description (optioneel): Een beschrijving van de pagina.
4. Keywords (optioneel): Deze sleutelwoorden kunnen door zoekmachines gebruikt worden om de pagina te indexeren. Woorden dienen gescheiden te worden door een komma. 5. Tags (optioneel): Men kan tags toevoegen door ze uit een lijst te selecteren.
6. Parent Page (default is Admin): Hiermee kan men aangeven of de pagina die men aanmaakt een subpagina is van een andere pagina (de parent).
7. Insert Page (default is after): Hiermee kan men aangeven of de pagina ergens voor of na of aan het eind toegevoegd moet worden (in de navigatie).
29 8. Page Before/After (defaultwaarde is Page Management): men kan alleen uit deze lijst iets
selecteren als bij nr. 7 before of after is ingevuld. Hier moet men dan aangeven voor of na welke pagina de nieuwe pagina ingevoegd moet worden.
9. Template Folder (defaultwaarde is Templates/): hier kan men een map specificeren voor het gebruik van templates.
10. Page Template (defaultwaarde is Default): Met deze lijst kan men een template voor de pagina selecteren.
11. Include in menu (bij default aangevinkt): met dit vinkje geeft de actor aan of de pagina wel of niet zichtbaar moet zijn in het navigatiemenu.
5.3.1.3.2 Copy Page
Bij het tabblad Copy Page kan men aangeven dat de nieuwe pagina een kopie moet zijn van een reeds bestaande pagina. Er is één lijst om uit te selecteren:
1. Copy page from (default is none specified): met deze lijst selecteert de actor een pagina om van te kopiëren.
5.3.1.3.3 Permissions
Bij permissions kan de actor bepalen welke gebruikers de pagina wel of niet mag bekijken en bewerken. Voor de website van Aquadis zullen er geen geregistreerde gebruikers zijn (behalve de beheerder), maar het zou onvolledig zijn om dit gedeelte van het formulier niet op te nemen in dit document.
30 Bij elke gebruikersgroep kan men aanvinken of de pagina bekeken (view page) en/of bewerkt (edit page) mag worden. De gebruikersgroep Administrators kan altijd alle pagina’s bekijken en bewerken. All Users heeft betrekking op alle gebruikers.
Registered Users zijn de gebruikers die een account bij de site hebben.
Subscribers zijn gebruikers die een soort abonnement bij de site hebben (dit wordt voor Aquadis niet gebruikt).
Translator heeft betrekking op de vertaalprogramma’s die de pagina vertalen.
Unauthenticated Users: bij deze gebruikers heeft een administrator aangegeven dat ze niet geautoriseerd zijn (verbannen van de site).
Men kan zelf ook gebruikersgroepen maken in DotNetNuke (in het systeem worden ze roles genoemd). Om te testen is er een rol aangemaakt die “nieuwe rol” heet. Deze kan men ook aanvinken.
Men kan ook nog specifiek een gebruikersnaam toevoegen om bij een individuele gebruiker aan te geven of deze de pagina mag zien of bewerken.
5.3.1.3.4 Advanced Settings
Voor de pagina zijn nog een groot aantal gevanceerde instellingen beschikbaar. Dit formulier is opgedeeld in twee delen: Appearance en Other Settings.
31 Het eerste deel gaat over het uiterlijk van de pagina (appearance). Het formulier heeft de volgende velden:
1. Icon Link Type (default is File): Men kan selecteren of een icoontje voor de pagina een bestand van de site is of een plaatje dat door het systeem (System Image) in gebruik is. 2. File Location (default is Root): Men kan een locatie selecteren waar het icoontje zich zou
bevinden.
3. File Name (default is none specified): Uit deze lijst kan de actor een bestand kiezen om als icoontje voor de pagina te dienen.
4. Image (default is About_16x16_Standard.jpg): (als de actor System selecteerde bij veld 1, krijgt hij of zij deze keuzemogelijkheid)
5. Large Icon Link Type (default is File): Men kan voor een pagina een groter icoon selecteren, ook hier kan men kiezen tussen File of System Image.
6. File Location (default is Root): Hier kan men de locatie (map) selecteren voor een groter icoon.
7. File Name (default is none specified): Uit deze lijst kan de actor een bestand kiezen om als groter icoon voor de pagina te dienen.
8. Image (default is About_16x16_Standard.jpg): Als de actor System Image geselecteerd had, kan hij of zij een plaatje van het systeem uitkiezen.
32 9. Page Skin (default is none specified): De actor kan een skin (layout) voor de pagina
selecteren.
10. Page Container (default is none specified): Voor de pagina kan de actor ook een container selecteren. Een container is een opmaak die men voor een module kan maken.
11. Disabled: Door deze checkbox aan te vinken, kan de actor de pagina (tijdelijk) op non-actief zetten, zodat gebruikers deze pagina nog niet kunnen zien.
12. Refresh Interval: Met dit veld kan de gebruiker instellen na hoeveel seconden de pagina automatisch moet verversen. Dit veld moet leeggelaten worden om het verversen uit tezetten.
13. Page Header Tags (optioneel): Hier kan men in HTML een aantal tags invoegen die in de header geplaatst worden, zoals meta tags.
Ten slotte volgt er nog een deel met overige instellingen:
14. Secure: Als de actor dit aanvinkt, geeft hij of zij aan dat de pagina gebruik moet maken van een SSL-verbinding. Deze optie is er alleen als een administrator heeft aangegeven dat er gebruik gemaakt kan worden van een dergelijke verbinding.
15. Site Map Priority (default is 0.5): Met een cijfer tussen 0 en 1 wordt aangegeven hoe belangrijk deze pagina is, ten opzichte van andere pagina’s van de website. Dit helpt de zoekmachine Google om de pagina’s in de juiste volgorde op de ranglijst te plaatsen.
16. Start Date (optioneel): Door deze startdatum in te vullen, kan men instellen de pagina pas te laten zien op de ingevoerde datum. Men kan deze datum ook kiezen met de kalender
ernaast.
17. End Date (optioneel): Door de einddatum van de pagina in te vullen, kan men instellen dat de pagina niet meer zichtbaar mag zijn na een bepaalde datum.
18. Link Type (default is none): Als de actor de pagina wil laten doorverwijzen naar iets anders (een URL, een pagina in het CMS of een bestand) kan dat hier ingesteld worden. Er kan ook aangevinkt worden of deze verwijzing permanent is. Als de verwijzing niet permanent is, wordt verwacht dat de actor de wijziging na verloop van tijd verwijdert.
33 5.3.2 Uitwerking “Via de sociale media een deelbaar artikel invoegen”
Sommige artikelen moeten via de sociale media (sites zoals Facebook en Twitter) gedeeld kunnen worden en andere niet. De beheerder kan per artikel aangeven bij welke sociale media het gedeeld kan worden.
5.3.2.1 Use case
In DotNetNuke wordt elke vorm van inhoud “module” genoemd. Dit kan simpele tekst zijn, of
componenten met andere functionaliteit (zoals een lijst of een eventlog). Deze modules kan men ook zelf ontwikkelen. Deze use case beschrijft een module die voor de website ontwikkeld is, namelijk de module om een artikel toe te voegen dat via de sociale media gedeeld kan worden.
Versie NR 0.1
Auteur Susanne van Schaik
Use case Via de sociale media een deelbaar artikel invoegen
Actoren Beheerder (A2)
Samenvatting De beheerder voegt een artikel in dat via verschillende sociale media gedeeld kan worden.
Preconditie Het systeem is in Edit-modus.
Hoofdscenario 1. De beheerder selecteert de module om toe te voegen. 2. De beheerder voert de relevante gegevens in.
3. Het systeem slaat de gegevens op.
Postcondities Geen
Alternatief scenario 1 met betrekking tot stap 2
[“ongeldige invoer”] Bij ongeldige invoer geeft het systeem de melding dat de velden correct ingevuld moeten worden.
Het systeem maakt de wijzigingen ongedaan en de actor kan de incorrect ingevulde velden opnieuw invullen.
Met “ongeldige invoer” wordt het leeglaten van een niet-optioneel veld of het invoeren van verkeerde data bedoeld.
34 5.3.2.2 Activiteitendiagram
35 5.3.2.3 Wireframe
Hieronder volgt het wireframe (schermontwerp) van de use case.
Het formulier op de wireframe heeft de volgende invoervelden.
1. Editor (bij default Rich Text Editor): hier kan men het type editor kiezen. De rich text editor is geavanceerder dan de basic text box. In de richt text editor kan men opmaakstijlen
gebruiken en kan men hyperlinks invoegen (bij de basic text box kan men alleen tekst zonder opmaak invoegen).
2. Content (optioneel): De inhoud van de module, hier kan men tekst en plaatjes invoegen. 3. Can be shared with (optioneel): hier kan de beheerder selecteren via welke social media de
module deelbaar moet zijn.
Voor de gebruiker (die niet de beheerder is) zal het artikel er zo uit te komen te zien.
Onderin worden een aantal icoontjes getoond om het artikel te delen via sociale media. Hoeveel icoontjes er staan, hangt af welke sociale media de beheerder bij het maken (of bewerken) van het artikel heeft aangevinkt.
36 Bij dit artikel kan gedeeld worden via Twitter, Facebook, LinkedIn en Google Plus.
37
6. Grafisch ontwerp
Voor het grafisch ontwerp van de website heb ik het ontwerp gebruikt, dat een jaar geleden voor Aquadis gemaakt is, maar nooit geïmplementeerd. Het template past goed bij de huisstijl die het bedrijf heeft aangenomen (veel wit, nadruk op simpelheid). Ik heb het template eerst omgezet naar HTML en CSS en vervolgens als een skin in DotNetNuke geïmplementeerd.
38
7. Technisch ontwerp
In het technisch ontwerp wordt weergegeven hoe de functionaliteiten (die in het functioneel ontwerp zijn opgesteld) geïmplementeerd zullen worden. Ook wordt de structuur van DotNetNuke weergegeven.
De basis van de website voor dit project is een installatie van de community edition van DotNetNuke 6.1.5.
7.1 Portalen en modules
DotNetNuke is een framework en een manier om dit framework uit te breiden is het installeren of (zelf) schrijven van modules. Deze modules worden op pagina’s geplaatst. De pagina’s zijn geordend per portal. Binnen één DotNetNuke-installatie kunnen duizenden portals (afhankelijk van de
serverhardware) aangemaakt worden. Een portal kan men beschouwen als een aparte site binnen een DotNetNuke-installatie. De beheerder van alle portalen bepaalt welke modules beschikbaar zijn voor welk portaal.
Het schema hieronder geeft een betere impressie van de positie van modules in een DotNetNuke installatie (WASH 2007, 7):
Het bepalen of een gebruiker is ingelogd, de layout van de pagina en wat er op de pagina te zien is, wordt door DotNetNuke gedaan. De modules voeren alleen specifieke taken uit, die betrekking hebben op de functionaliteit waarvoor ze gemaakt zijn.
39 Binnen DotNetNuke wordt eigenlijk elke vorm van inhoud die men kan toevoegen een “module” genoemd. Deze kan men zelf schrijven, maar er zijn al veel bestaande modules. De “simpelste” module is tekst. Deze kan men door middel van een HTML-editor invoegen. Geavanceerdere modules (vaak ook naar verwezen als “extensies”) kunnen op elke pagina toegevoegd worden, net zoals de HTML-module. Er zitten standaard 25 van deze modules bij DotNetNuke. Voorbeelden van deze modules zijn banners (voor adverteren), FAQs en weblogs. Ook de module om modules toe te voegen wordt als een module op zich beschouwd. Naast de 25 standaardmodules zijn er op internet veel modules te vinden die door andere bedrijven geschreven zijn. Deze third-party modules kan men op een aantal sites kopen (zoals de DotNetNuke store).
7.2 Architectuur
7.2.1 AlgemeenDe software (DotNetNuke) wordt op een server geïnstalleerd. Clients kunnen via internet deze server benaderen en krijgen een DotNetNuke-webpagina te zien. DotNetNuke maakt gebruik van een relationele database voor het laden en opslaan van gegevens.
40 7.2.2 Architectuur voor de modules
Voor een module kan men de applicatie opdelen in drie lagen. In deze lagen kunnen zich meerdere componenten bevinden. Het lijkt erop dat de simpele tekst-module van DotNetNuke niet voldoet aan dit lagenmodel maar dit is wel het geval. De interface om de tekst te bewerken maakt deel uit van de presentatielaag (net zoals de component die de tekst toont). De tekst wordt opgeslagen in de
database en dit gebeurt met behulp van objecten in de businesslaag die communiceren met de data access layer.
De presentatielaag bevat de user controls. Hierbij kan men denken aan de grafische interface en tekstboxen en knoppen.
De businesslaag bevat de code achter de presentatielaag. Hier worden de beslissingen genomen over wat bijvoorbeeld een module gaat doen.
De onderste laag, ofwel de data access layer, bevat data providers die communiceren met de onderliggende database. In dit geval wordt gebruik gemaakt van een SQL database.
7.3 Ontwikkeling modules
Om een module in DotNetNuke te schrijven, maakt men user controls aan die erven (inherit) van de klassen PortalModuleBase en ModuleSettingsBase. Van modules kunnen meerdere instanties bestaan en het is niet de bedoeling dat de data van de ene module zomaar gedeeld wordt met de andere. Daarom is het nodig tabellen in de database voor de module aan te maken en moet elke module zijn eigen ModuleID hebben (WASH 2007, 20).
41 Als bij DotNetNuke een module verwijderd wordt, worden alle instanties op elke pagina verwijderd. Om de juiste module te selecteren, wordt hiervoor ook gebruik gemaakt van het ModuleID.
Doorgaans wordt er bij modules onderscheid gemaakt tussen View (de gebruiker bekijkt de module), Edit (de gebruiker bewerkt data van de module) en Settings (de gebruiker bewerkt instellingen van de module).
Voor de website van Aquadis zullen de volgende modules geschreven worden:
- SocialHtmlText (een via de sociale media deelbaar artikel invoegen: deze module is een uitbreiding van de standaard HTML module in DotNetNuke)
- TwitterFeed - FacebookWidget
7.3.1 TwitterFeed
In deze scriptie zal de TwitterFeed-module toegelicht worden.
7.3.1.1 Database-ontwerp
Om de gegevens voor een Twitterfeed op te slaan, is er één tabel in de database nodig. Om tweets van een gebruiker te laten zien, moet het systeem een gebruikersnaam van een Twitter-account hebben en het aantal tweets dat men wil laten zien.
Deze tabel staat los (zonder relaties met andere tabellen) in de DotNetNuke-database.
De zwarte puntjes voor de velden betekent dat er geen null in het veld mag voorkomen. De ruit geeft aan dat het veld de primaire sleutel van deze tabel is. De tabel voor de Twitterfeed heeft de volgende velden:
1. TwitterModuleID(int, primary key): een identifier voor een Twitterfeed-module. Dit veld heeft de waarde van het ModuleID, dat uniek is voor elke ingevoegde module binnen DotNetNuke.
2. Username (varchar): Een Twitter-gebruikersnaam om tweets van te laten zien.
42 7.3.1.2 Klassendiagram
Er moeten klassen aangemaakt zijn voor de Settings (een klasse die afstamt van ModuleSettingsBase en een Settings-klasse voor de interface) omdat DotNetNuke het anders niet als een module
tolereert. Echter kan bij de TwitterFeed worden volstaan met Edit (voor het bewerken van gegevens zoals gebruikersnaam, wachtwoord en aantal tweets). Daarom zijn de klassen voor Settings (Settings en TwitterFeedSettingsBase) leeg.
De Load en Save functies van TwitterFeedModuleBase communiceren via de SQLDataProvider-klasse met de database. Het laden van de data gebeurt op grond van het ModuleID dat
TwitterFeedModuleBase erft van PortalModuleBase. Bij het opslaan worden naast het moduleID, de username en numberOfTweets meegegeven.
Met stereotypen is aangegeven welke plaats deze klassen hebben in het lagenmodel voor een module (zie 10.2.2). De Edit-, View- en Settings-klasse behoren tot de presentatielaag
(<<presentation>>), TwitterFeedModuleBase, PortalModuleBase, TwitterFeedSettingsBase en ModuleSettingsBase behoren tot de businesslaag (<<business>>).
43
8. Code
8.1 Template-pagina voor de skin
Hieronder volgt een stuk code van de templatepagina. Deze pagina bevat alle HTML voor de skin. Op deze pagina zijn placeholders geplaatst voor bepaalde content areas van DotNetNuke. Men kan op verschillende “panes” inhoud toevoegen. Hier zijn dat het SocialMediaPane, het ContentPane, het LeftPane, het CenterPane, het RightPane en het BottomPane.
<div id="Content"> <div id="Panes"> <div id="LogoRow">
<div class="LogoRowRight"> <div id="Login">
<dnn:LOGIN ID="LOGIN1" CssClass="LoginLink" runat="server" /> | <dnn:USER ID="USER1" runat="server" />
<dnn:LANGUAGE runat="server" id="dnnLANGUAGE" showMenu="False" showLinks="True" /> </div>
<div id="SocialMediaPane" runat="server"></div> </div>
</div>
<div id="Breadcrumb"><dnn:TEXT runat="server" id="dnnTEXT" CssClass="Intro" Text="You are here:" ResourceKey="Breadcrumb" /><dnn:BREADCRUMB ID="dnnBreadcrumb"
runat="server" RootLevel="0" Separator="<span class="Sep"></span>" /></div> <div id="ContentPane" runat="server"></div>
<div id="LeftPane" runat="server"></div> <div id="CenterPane" runat="server"></div> <div id="RightPane" runat="server"></div> <div id="BottomPane" runat="server"></div> </div>
Door middel van CSS worden de panes op de juiste plek gezet. Op deze panes kan men verschillende soorten modules plaatsen. Deze template behoort tot de presentatielaag.
44
8.2 SqlDataProvider
8.2.1 SaveSocialHtmlText
De SqlDataProvider-klasse bevat functies om gegevens te laden of op te slaan in een database. Hieronder is een voorbeeld weergegeven voor het opslaan van data voor een SocialHtmlText-module. De parameters in de functie dienen opgeslagen te worden in de SocialHtmlText-tabel. De parameters van deze functie komen overeen met de velden in de tabel.
public void SaveSocialHtmlText(int moduleID, string htmlText, bool twitter, bool facebook, bool linkedIn, bool googlePlus)
{
SqlDataReader sdr = SqlHelper.ExecuteReader(ConnectionString,
"dbo.GetSocialHtmlTextByModuleID", moduleID); if (sdr.HasRows)
{
SqlHelper.ExecuteReader(ConnectionString, "dbo.UpdateSocialHtmlText", moduleID, htmlText, twitter, facebook, linkedIn, googlePlus);
} else {
SqlHelper.ExecuteReader(ConnectionString, "dbo.AddSocialHtmlText", moduleID, htmlText, twitter, facebook, linkedIn, googlePlus);
} }
Bij het programmeren van de modules probeerde ik zoveel mogelijk dezelfde manier van programmeren aan te houden als DotNetNuke zelf. Voor communicatie met de database wordt uitsluitend gebruik gemaakt van stored procedures, dus dit heb ik ook voor de modules gebruikt. Met behulp van stored procedures worden de queries naar de database uitgevoerd.
Eerst wordt met SqlDataReader gekeken of er al een SocialHtmlText-module is met hetzelfde moduleID. Als dit het geval is, moet er een record bijgewerkt worden met de stored procedure dbo.UpdateSocialHtmlText.
Als er nog geen record is met het moduleID, moet er een nieuw record aangemaakt worden met de stored procedure dbo.AddSocialHtmlText.
45 8.2.2 dbo.UpdateSocialHtmlText
Hieronder volgt de code voor de stored procedure om een record in de SocialHtmlText-tabel te updaten. De parameters van de functie SaveHtml (zie 11.2.1) worden aan deze procedure gegeven. De parameters kan men in een stored procedure herkennen aan het apenstaartje (@) ervoor.
CREATE PROCEDURE [dbo].[UpdateSocialHtmlText]
@ModuleID int,
@Content varchar(MAX),
@ShareWithTwitter bit,
@ShareWithFacebook bit,
@ShareWithLinkedIn bit,
@ShareWithGooglePlus bit AS
UPDATE dbo.SocialHtmlText SET [Content] = @Content,
[ShareWithTwitter] = @ShareWithTwitter,
[ShareWithFacebook] = @ShareWithFacebook,
[ShareWithLinkedIn] = @ShareWithLinkedIn,
[ShareWithGooglePlus] = @ShareWithGooglePlus WHERE [SocialHtmlModuleID] = @ModuleID
46 8.2.3 Script om tabellen te genereren
Als een module geïnstalleerd wordt, moeten de tabellen aangemaakt worden. Dit kan de gebruiker handmatig doen, maar het is veel handiger om daarvoor een script uit te laten voeren. Elke module heeft een soortgelijk script en wordt door DotNetNuke automatisch uitgevoerd bij het installeren van de module. Het script hieronder genereert de tabel voor de TwitterFeed-module.
Als de tabel al bestaat wordt deze verwijderd en opnieuw aangemaakt.
IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[TwitterFeed]') AND type in (N'U'))
DROP TABLE [dbo].[TwitterFeed] GO USE [dotnetnuke] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO SET ANSI_PADDING ON GO
CREATE TABLE [dbo].[TwitterFeed](
[TwitterModuleID] [int] NOT NULL,
[Username] [varchar](50) NOT NULL,
[NumberOfTweets] [int] NOT NULL,
CONSTRAINT [PK_TwitterFeed] PRIMARY KEY CLUSTERED
(
[TwitterModuleID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] GO
SET ANSI_PADDING OFF GO
47
9 Conclusie
Er zijn veel contentmanagementsystemen om uit te kiezen. Uiteindelijk waren vooral de prijs en de mate waarin men het CMS kan aanpassen de belangrijkste factoren voor de keuze. De community editie van DotNetNuke bleek hiervoor het meest geschikt te zijn.
Tijdens deze afstudeerstage heb ik veel over het ontwikkelen van modules voor DotNetNuke geleerd. Om modules te schrijven, dient men zich aan een aantal regels te houden. Zo moet er een klasse zijn die afstamt van PortalModuleBase en één die van ModuleSettingsBase afstamt. Verder dient men zich aan het drielagenmodel te houden (presentatielaag, businesslaag en data access layer). Dit houdt de code overzichtelijk.
Na het progragrammeren van de modules ben ik een stuk wijzer geworden. Hieronder volgt een aantal aanbevelingen die nuttig zijn voor mensen die aan de slag willen met het ontwikkelen van modules van DotNetNuke. Ik heb deze dingen op de “langzame manier” ontdekt (omdat ik aan het begin niet veel wist over DotNetNuke), dat wil zeggen: na het maken van een aantal fouten had ik de kennis vergaard om een effectiever met DotNetNuke te werken. Door rekening te houden met deze aanbevelingen kan men veel tijd besparen.
- Als men een module gaat testen op een server dient deze geïnstalleerd te worden (net zoals de andere modules van DotNetNuke). Gebruik scripts om de tabellen en stored procedures te genereren (en vergeet ook de Uninstall-scripts niet om ze weer te verwijderen bij het deïnstalleren van de module).
- Om ervoor te zorgen dat een module goed geïnstalleerd wordt, moet men een install-package voor de module maken. DotNetNuke beveelt hiervoor MSBuildTasks aan
(https://github.com/loresoft/msbuildtasks) . Een install-package wordt gecompileerd als men het project van de DotNetNuke module bouwt in Release-modus (een publish van de
solution werkt niet).
- De Twitter API accepteert geen URLs die geen top level domain bevatten (zoals .nl of .com). Voor de SocialHtmlText-module wilde ik dat de URL van het artikel gedeeld werd. Bij het debuggen (op localhost) bleef het URL-veld leeg, maar op de server werkte het wel.
48
10 Bronvermeldingen
KRUG 2005: Krug (2005). Don’t make me think (1e druk). Berkeley: New Riders. WASH 2007: Washington (2007). DotNetNuke 4.0 Module Developers Guide (Part 1)
49
Bijlage 1: Plan van aanpak
Susanne van Schaik Aquadis
50
Inhoudsopgave
1. Managementsamenvatting ... 51 2. Inleiding ... 52 3. Projectopdracht ... 53 3.1 Context ... 53 3.2 Doelstelling ... 53 3.3 Probleemstelling ... 53 3.4 Opdrachtformulering... 54 3.5 Op te leveren producten ... 54 4. Aanpak ... 55 4.1 Vereiste vakkennis ... 55 4.2 Methoden en middelen ... 55 4.3 Prioriteiten ... 55 4.4 Risico’s ... 56 5. Planning ... 57 5.1 Activiteiten ... 57 5.2 Mijlpalenplanning ... 57 6. Bedrijfs- en persoonsgegevens ... 58 7. Bronvermelding ... 5951
1. Managementsamenvatting
De afstudeeropdracht die in dit document beschreven wordt, zal binnen de .NET afdeling van Aquadis worden uitgevoerd. Binnen deze afdeling is er behoefte aan meer expertise op het gebied van contentmanagementsystemen die gebaseerd zijn op het .NET framework. Aquadis had al een CMS op het oog, maar men wil weten of er nog betere systemen zijn om te gebruiken. De nieuwe kennis en ervaring die dit project zal opleveren, hoopt de opdrachtgever (Jeroen de Jong) te kunnen benutten bij het leveren van betere service aan de klanten van Aquadis.
De feitelijke probleemstelling is dat de huidige website van Aquadis lastig in onderhoud is. Het gebruik van een nieuw CMS zal dat eenvoudiger moeten maken. Verder is er een nieuw grafisch ontwerp voor de website gemaakt, maar dat is nooit geïmplementeerd. Er zijn ook nog andere eisen en wensen die aan de website toegevoegd moeten worden, maar deze moeten eerst gespecificeerd worden.
Om het project goed uit te voeren, zal eerst een vergelijking tussen verschillende
contentmanagementsystemen (die gebruik maken van het .NET framework) gemaakt moeten worden. Het CMS dat het meest geschikt blijkt te zijn, zal de basis vormen voor de nieuwe website voor Aquadis. Om de functionaliteit van de website vast te leggen, zal een functioneel ontwerp gemaakt worden. Het technisch ontwerp zal de structuur van de website weergeven en laten zien hoe het CMS geïmplementeerd is.
Het afstudeerproject heeft alleen betrekking op de website van Aquadis en zal dus niet gericht worden op andere applicaties. De op te leveren producten zijn: een vergelijking tussen verschillende contentmanagementsystemen, een functioneel ontwerp, een technisch ontwerp, een scriptie en een nieuwe website voor Aquadis (met een geïmplementeerde layout).
De benodigde kennis voor deze afstudeeropdracht heeft vooral betrekking op contentmanagementsystemen, C# en het .NET framework.
52
2. Inleiding
Dit document beschrijft het plan van aanpak voor de afstudeeropdracht van Susanne van Schaik. Voor het bedrijf Aquadis zal een nieuwe website ontwikkeld worden die gebaseerd is op een
contentmanagementsysteem. Eerst zal onderzoek gedaan worden naar welk CMS het meest geschikt is om te gebruiken. Hierbij zullen de eisen en wensen van de opdrachtgever (Jeroen de Jong) en de organisatie in beschouwing worden genomen. Vervolgens zal de website ontwikkeld worden en getest worden door verschillende medewerkers.
Het afstudeerproject is definitief goedgekeurd als de docentbegeleider het afstudeercontract (dat bijgevoegd is bij dit document) heeft ondertekend.
53
3. Projectopdracht
3.1 Context
De afstudeeropdracht vindt plaats binnen de .NET afdeling van Aquadis. De afdeling bestaat uit 6 personen die er fulltime werken. Aquadis is een dienstverlener in de ICT, gespecialiseerd in het maken van oplossingen met diverse Microsoft producten. Men maakt er vooral maatwerksoftware op basis van .NET technologie en de meeste afgeleverde producten zijn web-applicaties. De werkzaamheden van de afdeling vinden zowel intern als extern plaats.
Het project heeft relaties met de gehele organisatie omdat het de website van Aquadis betreft. Deze zal gebruikt worden voor reclame, werving van personeel, het uitbouwen van technische kennis en social media.
3.2 Doelstelling
Binnen de .NET afdeling Aquadis is al een tijd vraag naar meer expertise op het gebied van contentmanagementsystemen die gebaseerd zijn op het .NET framework. Het onderzoek naar verschillende contentmanagementsystemen zal hierin voorzien. Aquadis had al een CMS op het oog (DotNetNuke), maar men wil toch weten of er betere systemen zijn. Door de jaren heen heeft Aquadis weleens aanvragen gekregen om een CMS te implementeren en daarom heeft men besloten om hier meer ervaring mee op te doen. De opdrachtgever hoopt met deze nieuwe kennis en ervaring de klanten van Aquadis betere service te kunnen leveren. Verder wil men ook dat de website van Aquadis vernieuwd wordt, zodat deze een betere indruk maakt op (potentiële) klanten. Het is ook de bedoeling om sociale media bij de website te implementeren om meer reclame te maken of
personeel te werven.
Aquadis kiest voor contentmanagementsystemen die gebaseerd zijn op het .NET framework omdat ze Microsoft partner is.
3.3 Probleemstelling
De huidige website van Aquadis is lastig in onderhoud omdat er geen CMS is geïmplementeerd. Als men de inhoud van de website wil wijzigen, moet men handmatig de pagina bewerken en de tekst en dergelijke in HTML typen.
Om het onderhoud makkelijker te maken, zal een CMS geïmplementeerd moeten worden. Er is ooit een nieuw layoutontwerp gemaakt (als Photoshop-bestand), maar dit ontwerp is niet in de huidige website verwerkt. Het zal dus ook de bedoeling zijn om het ontwerp om te zetten naar HTML en te implementeren in het systeem.
54 Naast het bouwen van de site moeten ook technische specificaties worden opgesteld en moet er een functioneel en technisch ontwerp worden gemaakt. Eerst moet worden nagegaan welk CMS een waardevolle aanvulling zal zijn voor de dienstverlening van Aquadis . Dit CMS zal dan gebruikt worden om de nieuwe website te ontwikkelen. Vervolgens moeten de eisen en wensen van de opdrachtgever in de website verwerkt worden (zoals koppelingen met sociale media, vragenlijsten en andere features).
3.4 Opdrachtformulering
In het kort houdt de afstudeeropdracht in dat er eerst een vergelijking tussen 5 verschillende content management systemen (die gebruik maken van het .NET framework) gemaakt moet worden. Bij deze vergelijking zal vooral gelet worden op de gebruikersvriendelijkheid van het CMS, de mate waarin men zelf het CMS kan aanpassen en de functionaliteiten met betrekking tot sociale media en mobiele websites. Het CMS dat het meest geschikt blijkt te zijn voor Aquadis moet vervolgens de basis
vormen voor de nieuwe website. Deze nog te ontwikkelen website moet voldoen aan een aantal eisen van het bedrijf en het is aan de stagiaire om deze eisen (en wensen) boven tafel te krijgen. Indien mogelijk moeten al deze eisen en wensen geïmplementeerd worden.
Om de functionaliteit van de website vast te leggen, zal een functioneel ontwerp gemaakt worden. Het technisch ontwerp zal de structuur van de website weergeven (welke pagina’s er zijn en welke modules worden geïmplementeerd) en laten zien hoe het CMS geïmplementeerd is.
Het afstudeerproject heeft alleen betrekking op de website van Aquadis en zal dus niet gericht worden op andere applicaties.
3.5 Op te leveren producten
Uiteindelijk zullen een aantal producten opgeleverd worden, namelijk:
Een vergelijkend rapport over verschillende contentmanagementsystemen met daarin een onderbouwde keuze die het meest geschikt is voor Aquadis. In de vergelijking wordt vooral rekening gehouden met de prijs van het CMS, de gebruikersvriendelijkheid en de
mogelijkheid om eigen modules te maken.
Een functioneel ontwerp, hierin staan de functionaliteiten per use case beschreven.
Een technisch ontwerp, hierin wordt beschreven hoe het CMS geïmplementeerd is en welke modules toegevoegd zijn.
De nieuwe website voor Aquadis (met een geïmplementeerde layout)
