Bruikbaarheid van een alomtegenwoordig sociaal verenigingsplatform Tom De Vilder

Promotor: prof. dr. ir. Frank Gielen Begeleiders: ir. Dieter Blomme, ir. Olivier Deschrijver Masterproef ingediend tot het behalen van de academische graad van Master in de toegepaste informatica

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

Voorwoord Tijdens mijn 2 jaar als web praeses van de Vlaamse Economische Kring had ik al eens een webapplicatie moeten maken en onderhouden. Daarnaast moest ik af en toe de webapplicaties van de andere Gentse studentenverenigingen gebruiken. Dan al viel het mij op dat er heel grote verschillen waren en dat er eigenlijk maar weinig applicaties waren die over de hele lijn goed scoorden. Dat kwam dan nog onder andere omdat de meeste, zo niet alle, webapplicaties nog volledig in HTML geschreven werden en dus enkel statische inhoud konden weergeven. De webverantwoordelijken moesten dus al redelijk wat tijd spenderen aan het up-to-date houden van de applicatie, waardoor er meestal maar weinig tijd overblijft om verder te ontwikkelen. De afgelopen jaren is er echter een duidelijke tendens naar dynamische webapplicaties. Deze zijn moeilijker om te ontwikkelen, maar des te gemakkelijker te onderhouden. Het was dus hoog tijd om eens na te gaan of de studentenverenigingen deze tendens volgen. Daarnaast is het de bedoeling dat er wordt nagegaan wat er nu allemaal wel en niet thuis hoort in een sociale netwerkapplicatie. Tot slot is het de bedoeling om een prototype te ontwikkelen van hoe het wel zou moeten, zowel van de desktopapplicatie als van de bijhorende mobiele applicatie.

-I-

Dankwoord Om te beginnen zou ik Prof. dr. ir. Frank Gielen willen bedanken. Hij heeft mij de mogelijkheid gegeven om een masterproef te schrijven over een onderwerp dat ik zelf heb voorgesteld. Er kruipt heel veel tijd in een masterproef. Als je een onderwerp hebt dat je echt interesseert, gaat alles veel vlotter. Daarnaast zou ik graag Dieter Blomme bedanken. Als begeleidende assistent heeft hij talloze uren gespendeerd aan het nalezen en bijsturen van mijn werkstuk. Vervolgens wil ik Frederic Blockeel, de webverantwoordelijke van de VEK, en Brecht Neyrinck, de webverantwoordelijke van de VTK, bedanken voor de uitgebreide rondleiding doorheen de back-end van hun respectievelijke webapplicatie. Tot slot wil ik mijn ouders, vrienden en kennissen bedanken voor de morele steun, het testen van het prototype en het nalezen van dit werkstuk.

- II -

Toelating tot bruikleen "De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef." "The author gives permission to make this master dissertation available for consultation and to copy parts of this master dissertation for personal use. In the case of any other use, the limitations of the copyright have to be respected, in particular with regard to the obligation to state expressly the source when quoting results from this master dissertation."

Handtekening auteur/ Autograph author

31/05/2010

- III -

Afkortingen ASP = Active Server Pages CAPTCHA = Completely Automated Public Turing-test to tell Computer and Humans Apart CMS = Content Management System CSS = Cascading Style Sheets HTML = HyperText Markup Language ICT = Internet- en CommunicatieTechnologie XHTML = eXtensible HyperText Markup Language PHP = Personal Home Page PHP: Hypertext Preprocessor SQL = Structured Query Language WYSIWYG = What You See Is What You Get

- IV -

Inhoudstafel VOORWOORD........................................................................................................................................................... I DANKWOORD ..........................................................................................................................................................II TOELATING TOT BRUIKLEEN ......................................................................................................................... III AFKORTINGEN ..................................................................................................................................................... IV INHOUDSTAFEL......................................................................................................................................................V 1 VISIE.........................................................................................................................................................................1 1.1 MISSIE .................................................................................................................................................................1 1.2 DOELGROEP.........................................................................................................................................................1 1.2.1 Het praesidium van een studentenvereniging .............................................................................................1 1.2.2 De leden van de studentenvereniging .........................................................................................................1 1.2.3 Sponsors .....................................................................................................................................................1 1.3 SLEUTELTECHNOLOGIE EN -FEATURES ................................................................................................................1 1.3.1 Sleuteltechnologie.......................................................................................................................................1 1.3.2 Sleutelfeatures ............................................................................................................................................1 1.4 CRUCIALE PRODUCTFACTOREN ...........................................................................................................................2 1.4.1 Beveiliging ..................................................................................................................................................2 1.4.2 Bruikbaarheid:............................................................................................................................................2 1.4.3 Gebruikersinterface ....................................................................................................................................2 1.4.4 Prestatie......................................................................................................................................................2 1.4.5 Schaalbaarheid:..........................................................................................................................................2 2 STATE OF THE ART ANALYSE .........................................................................................................................3 2.1 ONDERZOEK NAAR DE BRUIKBAARHEID VAN BESTAANDE SOCIALE VERENIGINGSPLATFORMEN .........................3 2.1.1 Bruikbaarheid voor de eindgebruikers .......................................................................................................3 2.1.1.1 Algemene indrukken............................................................................................................................................. 3 2.1.1.2 Startpagina ............................................................................................................................................................ 3 2.1.1.3 Menu..................................................................................................................................................................... 4 2.1.1.4 Activiteiten ........................................................................................................................................................... 4 2.1.1.4.1 Kalenderoverzicht......................................................................................................................................... 5 2.1.1.4.2 Lijstoverzicht................................................................................................................................................ 5 2.1.1.4.3 Mogelijkheid tot exporteren.......................................................................................................................... 5 2.1.1.4.4 Een kalender in de zijbalk............................................................................................................................. 5 2.1.1.5 Fotoboek ............................................................................................................................................................... 6 2.1.1.6 Sponsors / Partners................................................................................................................................................ 6 2.1.1.6.1 Sponsorpagina .............................................................................................................................................. 6 2.1.1.6.2 Sponsors in de zijbalk................................................................................................................................... 7 2.1.1.7 Andere .................................................................................................................................................................. 7 2.1.1.7.1 Positieve punten............................................................................................................................................ 7 2.1.1.7.2 Negatieve punten .......................................................................................................................................... 8

2.1.2 Bruikbaarheid voor de beheerders .............................................................................................................8 2.1.2.1 Types van sites...................................................................................................................................................... 8 2.1.2.1.1 Statische webapplicaties ............................................................................................................................... 8 2.1.2.1.2 Dynamische webapplicaties.......................................................................................................................... 8 2.1.2.2 Analyse van bestaande dynamische webapplicaties.............................................................................................. 9 2.1.2.2.1 Activiteiten ................................................................................................................................................... 9 2.1.2.2.2 Fotoalbum..................................................................................................................................................... 9 2.1.2.2.3 Communicatie............................................................................................................................................. 10 2.1.2.2.4 Recruitment ................................................................................................................................................ 10 2.1.2.2.5 Diversen...................................................................................................................................................... 10

2.1.3 Mobiele applicatie ....................................................................................................................................10 2.2 INTELLECTUELE EIGENDOMSRECHTEN (IPR'S) ..................................................................................................11 2.2.1 UGent CAS ...............................................................................................................................................11 2.3 STANDAARDEN ..................................................................................................................................................11 2.3.1 Mobiele webapplicaties ............................................................................................................................11 3 REQUIREMENTS DOCUMENT ........................................................................................................................13 3.1 FUNCTIONELE VEREISTEN..................................................................................................................................13 3.1.1 Algemeen ..................................................................................................................................................13

-V-

3.1.2 Navigatie...................................................................................................................................................13 3.1.3 Startpagina ...............................................................................................................................................13 3.1.4 About - sectie ............................................................................................................................................13 3.1.5 Activiteiten - sectie....................................................................................................................................14 3.1.5.1 Overzicht ............................................................................................................................................................ 14 3.1.5.2 Individuele pagina per activiteit.......................................................................................................................... 14 3.1.5.3 Wekelijkse informatieblaadje ............................................................................................................................. 15

3.1.6 Fotoboek ...................................................................................................................................................15 3.1.7 Sponsors ...................................................................................................................................................15 3.1.8 Studie ........................................................................................................................................................15 3.1.8.1 Samenvattingen................................................................................................................................................... 15 3.1.8.2 Verkochte boeken/cursussen............................................................................................................................... 16

3.1.9 Andere.......................................................................................................................................................16 3.2 KWALITATIEVE VEREISTEN ...............................................................................................................................16 3.2.1 Beveiliging ................................................................................................................................................16 3.2.2 Bruikbaarheid...........................................................................................................................................16 3.2.3 Gebruikersinterface ..................................................................................................................................17 3.2.4 Prestatie....................................................................................................................................................17 3.2.5 Schaalbaarheid.........................................................................................................................................17 4 FUNCTIONAL DESIGN DOCUMENT ..............................................................................................................18 4.1 USE CASES ........................................................................................................................................................18 4.1.1 Use Case index .........................................................................................................................................18 4.1.2 Sleutelcomponenten van de Use Cases .....................................................................................................19 4.1.2.1 Aanmaken account.............................................................................................................................................. 19 4.1.2.2 Commentaar bij een foto plaatsen....................................................................................................................... 20 4.1.2.3 Fotoalbum toevoegen.......................................................................................................................................... 21 4.1.2.4 Foto's toevoegen / beheren.................................................................................................................................. 22 4.1.2.5 Kalender bekijken ............................................................................................................................................... 22 4.1.2.6 Samenvatting beoordelen.................................................................................................................................... 23 4.1.2.7 Samenvatting opladen......................................................................................................................................... 23 4.1.2.8 Pagina aanpassen ................................................................................................................................................ 24 4.1.2.9 Beheerderrechten beheren................................................................................................................................... 24 4.1.2.10 Activiteiten beheren .......................................................................................................................................... 25 4.1.2.11 Sponsors beheren .............................................................................................................................................. 26

4.1.3 Use Case diagram ....................................................................................................................................27 4.2 SITE MAP ..........................................................................................................................................................28 4.2.1 Beoogde desktopapplicatie .......................................................................................................................28 4.2.2 Prototype desktopapplicatie .....................................................................................................................29 4.2.3 Mobiele Applicatie....................................................................................................................................30 4.3 WIREFRAMES ....................................................................................................................................................31 4.3.1 Desktopapplicatie .....................................................................................................................................31 4.3.1.1 Template ............................................................................................................................................................. 31 4.3.1.2 Centrale inhoudsgedeelte .................................................................................................................................... 32 4.3.1.2.1 Startpagina / Activiteitenpagina.................................................................................................................. 32 4.3.1.2.2 About VEK................................................................................................................................................. 32 4.3.1.2.3 Statuten....................................................................................................................................................... 33 4.3.1.2.4 VEK-lied .................................................................................................................................................... 34 4.3.1.2.5 Huidig praesidium ...................................................................................................................................... 34 4.3.1.2.6 Alle praesessen ........................................................................................................................................... 35 4.3.1.2.7 Vorige praesidia.......................................................................................................................................... 35 4.3.1.2.8 Sponsors ..................................................................................................................................................... 36 4.3.1.2.9 Yucca.......................................................................................................................................................... 37 4.3.1.2.10 Yucca huren.............................................................................................................................................. 38 4.3.1.2.11 Yucca (prijslijst) ....................................................................................................................................... 38 4.3.1.2.12 Doop ......................................................................................................................................................... 39 4.3.1.2.13 Doop (reglement)...................................................................................................................................... 39 4.3.1.2.14 Weekinfo .................................................................................................................................................. 39 4.3.1.2.15 Kalender (maand) ..................................................................................................................................... 40 4.3.1.2.16 Kalender (maand in lijstvorm) .................................................................................................................. 40 4.3.1.2.17 Kalender (week) ....................................................................................................................................... 41 4.3.1.2.18 Kalender (dag) .......................................................................................................................................... 41 4.3.1.2.19 Inschrijvingen ........................................................................................................................................... 41 4.3.1.2.20 Cel Didactiek ............................................................................................................................................ 42 4.3.1.2.21 Leden Cel Didactiek ................................................................................................................................. 42 4.3.1.2.22 Boekenverkoop (planning) ....................................................................................................................... 43 4.3.1.2.23 Boekenverkoop (verplichte cursussen) ..................................................................................................... 43

- VI -

4.3.1.2.24 Boekenverkoop (andere)........................................................................................................................... 44 4.3.1.2.25 Meldpunt................................................................................................................................................... 44 4.3.1.2.26 Samenvattingen opladen ........................................................................................................................... 44 4.3.1.2.27 Samenvattingen ........................................................................................................................................ 45 4.3.1.2.28 Homo Economicus ................................................................................................................................... 45 4.3.1.2.29 Den Toog .................................................................................................................................................. 46 4.3.1.2.30 Fotoboek (overzicht)................................................................................................................................. 47 4.3.1.2.31 Fotoboek (album) ..................................................................................................................................... 48 4.3.1.2.32 Fotoboek (foto) ......................................................................................................................................... 49 4.3.1.2.33 Links......................................................................................................................................................... 50 4.3.1.2.34 Contact...................................................................................................................................................... 50

4.3.2 Mobiele applicatie ....................................................................................................................................51 4.3.2.1 Startpagina .......................................................................................................................................................... 51 4.3.2.2 About VEK ......................................................................................................................................................... 52 4.3.2.3 Kalender.............................................................................................................................................................. 52 4.3.2.4 Fotoboek (overzicht)........................................................................................................................................... 53 4.3.2.5 Fotoboek (album)................................................................................................................................................ 54 4.3.2.6 Fotoboek (foto) ................................................................................................................................................... 55

4.4 KLASSENDIAGRAM ............................................................................................................................................56 5 PROOF OF CONCEPT.........................................................................................................................................57 5.1 DESKTOPAPPLICATIE .........................................................................................................................................57 5.1.1 Joomla! .....................................................................................................................................................57 5.1.2 Gebruikte Extensies ..................................................................................................................................57 5.1.2.1 JA_Purity ............................................................................................................................................................ 57 5.1.2.2 Community Builder v1.2.2 ................................................................................................................................. 58 5.1.2.2.1 Algemeen.................................................................................................................................................... 58 5.1.2.2.2 Instelling van de component ....................................................................................................................... 59 5.1.2.2.3 Beheer van de component........................................................................................................................... 62 5.1.2.3 JEvents v1.5.4..................................................................................................................................................... 63 5.1.2.3.1 Algemeen.................................................................................................................................................... 63 5.1.2.3.2 Instellingen van de component ................................................................................................................... 64 5.1.2.3.3 Beheren van de component......................................................................................................................... 67 5.1.2.4 JoomGallery v1.5.0.5.......................................................................................................................................... 67 5.1.2.4.1 Algemeen.................................................................................................................................................... 67 5.1.2.4.2 Instellingen van de component ................................................................................................................... 68 5.1.2.4.3 Beheren van de component......................................................................................................................... 68 5.1.2.4.3.1 Algemeen ........................................................................................................................................... 68 5.1.2.4.3.2 Afbeeldingen opladen......................................................................................................................... 69

5.2 MOBIELE APPLICATIE ........................................................................................................................................70 5.2.1 Osmobi......................................................................................................................................................70 5.2.2 Omzetting naar de mobiele applicatie ......................................................................................................70 6 TESTPLAN.............................................................................................................................................................71 6.1 METHODOLOGIE ................................................................................................................................................71 6.1.1 Deelnemers ...............................................................................................................................................71 6.1.1.1 Studenten hoger onderwijs.................................................................................................................................. 71 6.1.1.2 Andere ................................................................................................................................................................ 71

6.1.2 Voorkennis en training .............................................................................................................................71 6.1.3 Procedure .................................................................................................................................................71 6.2 FUNCTIONELE TESTEN .......................................................................................................................................72 6.2.1 De scenario's ............................................................................................................................................72 6.2.2 De metrieken.............................................................................................................................................72 6.2.2.1 Aantal afgeronde scenario's ................................................................................................................................ 72 6.2.2.2 Kritieke fouten .................................................................................................................................................... 72 6.2.2.3 Niet-kritieke fouten............................................................................................................................................. 73 6.2.2.4 Aantal clicks om het juiste onderdeel te bereiken ............................................................................................... 73 6.2.2.5 Subjectieve evaluaties......................................................................................................................................... 73 6.2.2.6 Benodigde tijd..................................................................................................................................................... 73

6.2.3 Doelstellingen...........................................................................................................................................73 6.2.3.1 Aantal afgeronde scenario's ................................................................................................................................ 73 6.2.3.2 Foutvrijheid......................................................................................................................................................... 73 6.2.3.3 Aantal clicks om het juiste onderdeel te bereiken ............................................................................................... 73 6.2.3.4 Subjectieve evaluaties......................................................................................................................................... 73 6.2.3.5 Benodigde tijd..................................................................................................................................................... 73

6.3 KWALITATIEVE TESTEN .....................................................................................................................................74 6.3.1 Inlogmodules ............................................................................................................................................74 6.3.2 Formulieren ..............................................................................................................................................74

- VII -

6.3.3 XHTML validatie ......................................................................................................................................74 6.3.4 Prestatie....................................................................................................................................................74 7 TESTRESULTATEN ............................................................................................................................................75 7.1 DESKTOPAPPLICATIE .........................................................................................................................................75 7.1.1 Functionele eisen ......................................................................................................................................75 7.1.1.1 Front-end ............................................................................................................................................................ 75 7.1.1.2 Back-end ............................................................................................................................................................. 75

7.1.2 Kwalitatieve eisen.....................................................................................................................................75 7.1.2.1 Inlogmodules ...................................................................................................................................................... 75 7.1.2.2 Formulieren......................................................................................................................................................... 75 7.1.2.3 XHTML validatie ............................................................................................................................................... 76 7.1.2.4 Prestatie .............................................................................................................................................................. 76

7.2 MOBIELE APPLICATIE ........................................................................................................................................76 7.2.1 Functionele eisen ......................................................................................................................................76 7.2.2 Kwalitatieve eisen.....................................................................................................................................77 8 CONCLUSIE ..........................................................................................................................................................78 8.1 ANALYSE...........................................................................................................................................................78 8.2 DESKTOPAPPLICATIE .........................................................................................................................................78 8.3 MOBIELE APPLICATIE ........................................................................................................................................78 9 BIJLAGEN .............................................................................................................................................................79 9.1 BIJLAGE A - AFBEELDINGEN 'STATE OF THE ART' ANALYSE..............................................................................79 9.2 BIJLAGE B - FIGUREN PROOF OF CONCEPT ........................................................................................................86 10 REFERENTIES..................................................................................................................................................103

- VIII -

1 Visie 1.1 Missie Een gebruiksvriendelijke webapplicatie ontwikkelen waarop het praesidium van een studentenvereniging zijn leden kan informeren, hun interne werking kan stroomlijnen en waarop communicatie tussen de leden wordt opengesteld. Deze webapplicatie moet gemakkelijk te onderhouden zijn door personen die niet in de IT geschoold zijn. Daarnaast worden de mogelijkheden onderzocht om deze webapplicatie uit te breiden naar diverse types van consumenten elektronica zoals smartphones, de iPad, … De eindgebruiker moet te allen tijde kunnen beschikken over de meest recente informatie en moet deze snel en gemakkelijk kunnen vinden.

1.2 Doelgroep 1.2.1 Het praesidium van een studentenvereniging De klant moet de applicatie volledig zelf kunnen onderhouden en eventueel uitbreiden. De inhoud van de webapplicatie moet dus gemakkelijk aanpasbaar zijn voor personen die geen kennis hebben over PHP, SQL en zelfs X(HTML).

1.2.2 De leden van de studentenvereniging De belangrijkste eindgebruikers zijn de leden van de studentenvereniging. Zij verwachten een applicatie waarop zij zich kunnen informeren over de komende activiteiten en ze foto's kunnen bekijken van afgelopen activiteiten. Daarnaast willen zij ook de mogelijkheid om met elkaar en het praesidium te communiceren.

1.2.3 Sponsors De sponsors zijn het tweede soort eindgebruikers. Zij betalen om naambekendheid te verwerven. Dus willen zij een goede zichtbaarheid overheen een zo groot mogelijk deel van de applicatie bekomen.

1.3 Sleuteltechnologie en -features 1.3.1 Sleuteltechnologie • De site moet modulair zijn, het mag maar weinig moeite vergen om later extra functionaliteiten toe te voegen en deze volledig in het bestaande geheel te integreren. • Zoveel mogelijk content moet dynamisch gegenereerd worden. • Er moet een mobiele versie van de site gemaakt worden, de sleutelfeatures die ook belangrijk zijn voor het mobiele deel, zullen aangeduid worden met [mobiel].

1.3.2 Sleutelfeatures • Gemakkelijke en snelle navigatie [mobiel] • Een overzichtelijke kalender [mobiel] -1-

• Bij het invoeren van een nieuwe activiteit moet de mogelijkheid er zijn om deze te exporteren naar de FK-databank en/of een facebook activiteit aan te maken • Mogelijkheid tot communicatie tussen de leden [mobiel] • Een aantrekkelijk, gemakkelijk te gebruiken fotoalbum [mobiel]

1.4 Cruciale productfactoren 1.4.1 Beveiliging • Enkel het huidige praesidium en een eventuele externe administrator mogen toegang hebben tot het administratie gedeelte van de webapplicatie. • De gebruikersaccounts moeten voldoende tegen externe inbreuk beschermd worden. • Gevoelige informatie moet altijd versleuteld verstuurd worden. • Alle invulformulieren en dergelijke moeten grondig tegen spam beveiligd worden • Pogingen tot malafide invoer mogen de databank en bij uitbreiding de applicatie niet aantasten.

1.4.2 Bruikbaarheid: • Vanaf de startpagina moet een gebruiker binnen de 5 clicks elke sectie van de desktopapplicatie kunnen bereiken. Voor de mobiele applicatie mag dit maximaal 3 zijn. • Elke pagina moet interpreteerbaar zijn door de meest gebruikte browsers (bvb Mozilla Firefox, Internet Explorer, Google Chrome, ...). • Het ontstaan van broken links (= links die naar onbestaande pagina's wijzen) moet zo veel mogelijk uitgesloten worden. • Voor het mobiele gedeelte moet de tekstuele input van de gebruiker tot het uiterste minimum beperkt worden.

1.4.3 Gebruikersinterface • De desktopapplicatie moet geoptimaliseerd worden voor een schermresolutie van 1024x768 pixels. • Bij de mobiele applicatie moet alles goed zichtbaar zijn op een monitor met heel beperkte afmetingen.

1.4.4 Prestatie Elke pagina moet op een desktop of laptop met een breedband internetconnectie binnen de seconde geladen zijn. De mobiele applicatie moet de volgende punten zo veel mogelijk minimaliseren: • de throughput (down- en upload) • het gebruikte geheugen op het mobiele toestel • de gebruikte rekenkracht op het mobiele toestel

1.4.5 Schaalbaarheid: Eventuele uitbreidingen in de toekomst mogen de functionaliteit van de nu ontwikkelde webapplicatie niet kunnen in gevaar brengen.

-2-

2 State Of The Art Analyse 2.1 Onderzoek naar de bruikbaarheid van bestaande sociale verenigingsplatformen Om de bruikbaarheid van de bestaande sociale verenigingsplatformen in kaart te brengen, werd er geopteerd om de websites van de studentenverenigingen overkoepeld door het FaculteitenKonvent (FK) en de website van de studenten economie in Leuven onder de loep te nemen. Er is een duidelijk verschil tussen de verenigingen van faculteiten waar men een basis omtrent programmeren en/of webdesign meekrijgt en deze waar dit niet het geval is. Naast de scholing die men krijgt, kan dit ook verklaard worden door het interessegebied van de studenten aan deze faculteiten. De eerstgenoemden zullen eerder geneigd zijn om hun kennis over webdesign zelfstandig uit te breiden. Bepaalde delen van een site zijn enkel beschikbaar wanneer de eindgebruiker ingelogd is. Dit zal altijd weergegeven worden door [ingelogd] wanneer er met een lijst gewerkt wordt. Er is een apart deel voorzien om het administratiegedeelte van de sites van de twee grootste verenigingen te bespreken. Deze back-end wordt gebruikt door de beheerders, de webmaster en eventueel ook de rest van het praesidium om de inhoud van de site aan te passen. Enkel de webapplicatie van de VEK [33] is uitgebreid met een beperkt mobiel gedeelte. (Meer hierover later. Ik wacht hierover nog altijd op antwoord van de webmaster.)

2.1.1 Bruikbaarheid voor de eindgebruikers 2.1.1.1 Algemene indrukken De site met de slechtste gebruikerservaring is deze van de Geologica [11] . Deze is voor het grootste deel opgebouwd met het wikipedia framework. Dit komt amateuristisch over en beperkt de mogelijkheden van de site. De website van de Politeia [24] gebruikt het IPBoard framework dat normaal gezien uitsluitend voor fora wordt gebruikt. Dit komt ook amateuristisch over, maar het is toch al beter dan de vorige. Het grootste probleem met beide sites is dat de functionaliteit beperkt wordt door de mogelijkheden van beide raamwerken, wat ook de uiteindelijke bruikbaarheid van de site aantast.

2.1.1.2 Startpagina De startpagina bepaalt de eerste indruk die gebruikers van een site krijgen. Net deze pagina’s zijn dikwijls heel amateuristisch opgebouwd. Bij de sites van Chemica [1] en VDK [32] komt de gebruiker eerst op een welkomstpagina, voor men naar de uiteindelijke startpagina kan. Dit kan nuttig zijn wanneer de eindgebruiker al direct voor een keuze gesteld wordt, bvb taal, verschillende delen van de site, ... Dit is echter niet het geval, er is telkens maar 1 link voorzien naar de uiteindelijke startpagina, waardoor het nut van deze welkomstpagina's in twijfel mag getrokken worden. Bij bepaalde sites bevat het centrale inhoudsgedeelte: • bijna enkel sponsors (Figuur 67 & Figuur 68) • een onoverzichtelijke lijst van de komende activiteiten (VDK [32] ) • te overheersende afbeeldingen (GBK [8] ) • geen of verouderde nieuwsberichten (Lombrosiana [19] ) -3-

• te veel informatie (Geografica [10] ) De site van de VTK [39] heeft wel een heel goede startpagina . Hier wordt een duidelijke lijst met de voorbije en toekomstige activiteiten weergegeven. Bij de toekomstige activiteiten staat een link om in te inschrijven. Er moet aangeduid worden tot wanneer men kan inschrijven. Elke voorbije activiteit kan via een 5-sterrensysteem beoordeeld worden en er is een link naar eventuele foto's.

2.1.1.3 Menu Een gemakkelijke navigatie doorheen de site is onontbeerlijk. Informatie is waardeloos indien de gebruiker deze niet snel en gemakkelijk kan vinden. De meeste sites gebruiken een traditioneel menu. Dit wil zeggen dat er bovenaan of aan de linkerzijde een, al dan niet uit- en inklapbare, lijst staat met beschrijvende namen die bij het aanklikken doorverwijzen naar de desbetreffende pagina's van de applicatie. De site van het KMF (Figuur 69) werkt echter met een groot aantal afbeeldingen die naar de verschillende delen van site leiden. De ene site structureert zijn menu op een betere manier dan de andere. Een aantal sites werken met een menu dat slechts uit één laag is opgebouwd, waardoor: • ofwel de website slechts een beperkt aantal pagina's kan bevatten • ofwel het menu vervalt in een lange en onoverzichtelijke lijst van items. De sites die wel met submenu's werken, doen dit evenmin altijd succesvol. Enerzijds zijn de categorieën in het hoofdmenu niet altijd even duidelijk, anderzijds worden elementen in een submenu geplaatst die niet echt bij de desbetreffende categorie passen. Men moet goed opletten dat het menu niet te uitgebreid wordt. De navigatie kan hierdoor namelijk stroever verlopen. Uit onderzoek blijkt dat er per niveau van het menu maximaal 7 (±2) items mogen zijn (Saaty en Ozdemir 2003 [42] . Zo moet men bijvoorbeeld bij de categorie activiteiten afwegen of men al dan niet een apart item voorziet voor: • elk type van activiteit en/of • de belangrijkste activiteiten (tijdens de aangewezen periode) Op de site van de VTK [39] bestaan de submenu's uit 1 aparte rij, met daarin alle items. Voor dit submenu is plaats vrijgehouden net onder het hoofdmenu. Eens men met de muisaanwijzer over een item uit het hoofdmenu gegaan is, blijft dit submenu staan. Een nieuw submenu verschijnt maar wanneer er over een ander item uit het hoofdmenu gegaan wordt. Hier hoeft men dus geen rekening te houden : • of het submenu niet te kort zichtbaar is zodat men moeilijk kan navigeren • of het juist te lang zichtbaar is en zo te lang over andere inhoud blijft hangen.

2.1.1.4 Activiteiten Veruit het belangrijkste onderdeel van de website qua inhoud, is het aanduiden van de komende activiteiten. Het is dan ook uitermate bedroevend om vast te stellen dat de kwaliteit hiervan bij de meeste sites sterk te wensen overlaat. Naast de naam van de activiteit moet ook nog de volgende informatie meegegeven worden: • de datum • het beginuur • de locatie • eventueel het einduur -4-

Bij de betere sites is verschijnt een pagina van de individuele activiteit door te klikken op naam van deze activiteit. Op deze pagina staan verdere gegevens over de activiteit, zoals: • een uitgebreide beschrijving • een afbeelding (bvb. een affiche) • een kaartje (bvb. Google Maps) [39] waarop de locatie staat aangeduid Op de site van de VEK [18] kan er via facebook-connect zelfs rechtstreeks een reactie geplaatst worden op de facebook pagina van de desbetreffende activiteit. De uitgebreide weergave van de kalender kan op twee manier gebeuren. Vooreerst is er een maandoverzicht zoals op een kalender (Figuur 20). Daarnaast wordt er ook gewerkt met een lijstoverzicht (Figuur 21).

2.1.1.4.1 Kalenderoverzicht Net zoals bij een maandkalender worden de activiteiten hier in tabelvorm weergegeven. Voor elke dag is er een cel waarin de dag van de maand en de activiteiten, eventueel samen met de locatie en het beginuur, vermeld worden. De grootste fout hier is dat de kalender slecht gedimensioneerd wordt. Sommige zijn te klein (Figuur 71), waardoor het geheel onduidelijk is. Een andere (Figuur 72) breidt soms uit tot buiten het toegewezen gebied omdat de kolommen te breed worden. Dit is op zich al niet aanvaardbaar. Daarenboven ontbreekt een schuifbalk, waardoor de informatie in de meest rechtse kolom(men) verloren gaat. Er zijn gelukkig ook kalenders die dat wel goed doen (Figuur 73). Om de verschillende types activiteiten gemakkelijk uit elkaar te kunnen houden, krijgen deze soms elk een kleurcode mee. De beste sites gingen nog een stapje verder en voorzien de mogelijkheid om op de types activiteiten te filteren (Figuur 72). Dit wordt met een dropdown menu gedaan of via checkboxes (Figuur 75), wat de selectie van verschillende types tegelijk gemakkelijk maakt.

2.1.1.4.2 Lijstoverzicht De tweede voorstelling is een chronologische lijst van de komende activiteiten. Ook hier kan bij de betere op het type van activiteit gefilterd worden (Figuur 74 & Figuur 75). Bij de meeste sites wordt een vast aantal activiteiten of een bepaald aantal komende weken weergegeven. Er is er echter ook één waar je zelf kan bepalen hoe ver er in de toekomst gekeken wordt (Figuur 74). Het is bij sommige ook mogelijk om de voorbije activiteiten apart of samen met de komende weer te geven (Figuur 75). Bij dit type voorstelling waren geen fouten aanwezig die het vermelden waard zijn.

2.1.1.4.3 Mogelijkheid tot exporteren Een mooi extraatje is dat de kalender bij de 2 meest technisch onderlegde verenigingen (VTK [39] & WiNA [41] ) geëxporteerd kan worden voor: • iCal • Atom • een RSS stroom

2.1.1.4.4 Een kalender in de zijbalk Op een pak sites is een block element aanwezig op elke pagina, dat gelinkt is aan de kalender. Het meest gebruikte type toont de eerstvolgende activiteiten (Figuur 77), bijvoorbeeld de activiteiten van die dag, de 5 eerstkomende (belangrijke) activiteiten, ... Dit heeft als voordeel dat de gebruiker te allen tijde met één oogopslag op de hoogte is en dus niet naar de kalender moet -5-

gaan. Ook hier leidt de naam van de activiteit via een klik naar zijn eigen pagina. Niet alle sites vermelden hier de datum en het beginuur (Figuur 76). Het nut van dit block element is dan veel lager, omdat men toch naar de kalender of de pagina van de individuele activiteit moet om deze informatie te achterhalen. Het tweede type is een kleine versie van de kalender (Figuur 78), waarin de dag van de maand numeriek vermeld wordt. Wanneer de muisaanwijzer boven een dag met activiteiten staat, verschijnt er een vak met de activiteiten van die dag naast de muisaanwijzer. Dit type is evenmin heel bruikbaar om te weten wat juist wanneer te doen is. Het enige wat men snel kan zien is op welke dag er minstens 1 activiteit plaatsvindt. Voor meer info moet men met de muisaanwijzer over elke individuele dag gaan en zelfs daar loopt het fout. Over het algemeen wordt het beginuur niet vermeld in de weergegeven informatiebalk.

2.1.1.5 Fotoboek Het fotoboek, ook wel fotoalbum genaamd, wordt door velen als het tweede belangrijkste deel van de webapplicatie genoemd. Over het algemeen zijn de fotoboeken voor de eindgebruikers zeer gebruiksvriendelijk. Via een overzicht kan genavigeerd worden door de thumbnails of men kan de vergrote versies één na één bekijken. Een aantal verenigingen ([1] Filologica [7] Geografica [6], Geologica [11] Slavia [10] [27] VGK [34] VTK [39] bieden op hun site de mogelijkheid om op elke foto of op het gehele album een reactie te plaatsen. Om misbruik tegen te gaan kan dit enkel wanneer men ingelogd is of door het invullen van een CAPTCHA. De sites van Dentalia [3] en VPPK [38] maken echter van geen van beide voorzorgsmaatregelen gebruik. De meeste sites proberen om de foto's van voorgaande jaren beschikbaar te houden, voor zover de beschikbare opslagruimte dat toelaat. Via een dropdown menu of een submenu wordt de navigatie tussen de verschillende jaren gemakkelijk gemaakt. Twee sites (Figuur 79 & Figuur 80) die met een content management systemen (CMS) werken, hebben hun plug-in voor het fotoboek niet goed ingesteld. Er is namelijk een link aanwezig die naar een bovenliggend niveau leidt, dat niet kan/mag weergegeven worden. Bij KHK [18] worden alle foto's op een extern fotoboek gehost, hoogst waarschijnlijk omdat het toevoegen van foto's gemakkelijk is en het gebruik gratis is. Het probleem hier is dat men voor de hele webapplicatie nu afhankelijk is van een extra externe partij en dat men niet vrij de lay-out van het fotoboek kan bepalen, functionaliteiten kan beheren, ... Het voordeel hiervan is dat deze externe fotoboeken over het algemeen heel gebruiksvriendelijk zijn. Voor verschillende content management systemen bestaan er plug-ins die toelaten gemakkelijk bepaalde externe fotoboeken in de applicatie te integreren. De migratie naar een nieuwe applicatie verloopt op dit vlak dan heel vlot.

2.1.1.6 Sponsors / Partners Als laatste belangrijk onderdeel is er de zichtbaarheid van de sponsors/partners. Zoals eerder vermeld zijn er twee sites waarbij hun startpagina vrijwel enkel sponsors bevat. De sponsors zullen daar zeer dankbaar om zijn. De gemiddelde gebruiker heeft hier echter geen boodschap aan.

2.1.1.6.1 Sponsorpagina Elke site heeft een aparte pagina voor de sponsors. De meeste tonen gewoon een lijst met logo's met een link naar ofwel een eigen pagina over het bedrijf, ofwel de (plaatselijke) site van het bedrijf zelf. Als enige uitzondering is er Dentalia [3] . Hun applicatie toont niet enkel de logo's, maar voorziet ook plaats om informatie over het bedrijf weer te geven.

-6-

Het kan ook nuttig zijn om een link te voorzien naar een pagina die bedrijven uitleg verschaft over hoe sponsor te worden. Voorlopig hebben maar 3 sites (Dentalia [3] Filologica [7] en WiNA [41] dit gedaan.

2.1.1.6.2 Sponsors in de zijbalk Bijna alle sites voorzien ook weer een block element om (een deel van) de sponsors altijd zichtbaar te houden. Wanneer hierin niet overdreven wordt, is dit zeker niet storend. Wanneer je een hele waslijst aan logo's laat zien, is men fout bezig. Chemica [1] en Ekonomika [5] hebben hier een mooie oplossing voor gevonden. Om de gebruikte ruimte door het block element in te perken, houden ze eventueel de hoofdsponsors altijd zichtbaar, maar laten ze de rest van de sponsors met een roterende beweging van boven naar beneden (of omgekeerd) in het block element glijden. Zo krijgt elke sponsor zijn zichtbaarheid, zonder dat ze allemaal tegelijk weergegeven worden.

2.1.1.7 Andere 2.1.1.7.1 Positieve punten • een mogelijkheid tot online inschrijven voor bepaalde activiteiten [ingelogd] • een item in een (sub)menu dat linkt naar een pagina met alle activiteiten waarvoor men zich kan/moet inschrijven • een link in het hoofdmenu naar de aparte recruitment/stage site • een menu-item 'Pers', voor bvb krantenartikels, ... die de vereniging aanbelangen • een archief van alle uitgegeven maandboekjes / weekinfo's • een multimedia sectie met de collectie van de affiches van alle vorige jaren en bijvoorbeeld audiobestanden van cantusliedjes • een schachtensectie met doopinfo • een pagina met allerlei links, zoals: o webpagina's van andere kringen van dezelfde faculteit in andere steden o de FK webpagina met de links naar de websites van de FK kringen o de facebook en twitter pagina o alumniverenigingen, UGent-sites • een pagina met belangrijke locaties, tevens aangeduid op een kaartje (Google Maps) • een inzendsectie voor roddels, samenvattingen, ... • mogelijkheid tot het online bestellen van boeken [ingelogd] bijvoorbeeld met behulp van de UGent CAS login • een contactpagina met o een invulformulier (met eventueel een dropdown menu met daarin de verschillende functies binnen het praesidium of de leden van het praesidium) o info van de bankrekening • spelletjes • zoekertjes • een lijst van alle praesessen • een overzicht van het huidige praesidium en een synthese van de vorige praesidia • studiehulp: samenvattingen, opgeloste oefeningen, examenvragen, ... -7-

• contactinfo jaarverantwoordelijken en de studentenvertegenwoordigers ( in de faculteitsraad) • een gastenboek / forum • een poll in een block element

2.1.1.7.2 Negatieve punten • de link naar de externe recruitment-site staat enkel op startpagina • de samenvattingen staan gedeeltelijk op een aparte site, die door een extern persoon onderhouden wordt • recruitment is één van de vele menu-items (komt minder professioneel over) • praesidiumpagina's per functie • een 'You are here' referentie die gewoon de naam van de pagina herhaalt (Figuur 81) • kalender: verjaardagen van alle geregistreerde gebruikers zijn zichtbaar • het fotoboek is enkel toegankelijk wanneer men ingelogd bent (WiNA [41] ) • block element met de laatste 3 posts op het gastenboek • block element met de onderliggende menu-items van het hoofdmenu waarin men zich bevindt • block element met de Facebook "plug-in" van het studentencafé • block element met de top 3 van de 20 populairste liedjes • block element dat altijd toont in welk menu men zit en de items van het submenu toont

2.1.2 Bruikbaarheid voor de beheerders Om het onderhoud van een webapplicatie voor studentenverenigingen vlot te laten verlopen, zou eigenlijk ieder lid van het praesidium de mogelijkheid moeten hebben om die aanpassingen te doen die op zijn/haar functie betrekking hebben. Zo moet elk praesidiumlid bijvoorbeeld een activiteit aan de kalender kunnen toevoegen, aanpassen en zelfs verwijderen.

2.1.2.1 Types van sites 2.1.2.1.1 Statische webapplicaties Oudere webapplicaties zijn nog niet opgebouwd met behulp van een dynamische ontwikkelingstaal en databanken. Elke letter die op de websites te zien is moet daar in HTML code opgezet worden. Aangezien niet iedereen geleerd heeft om HTML code te schrijven, zal meestal elke aanpassing aan een webpagina door de webmaster zelf moeten worden uitgevoerd. Hierdoor duurt het mogelijks langer vooraleer nieuwe inhoud online komt. De extra informatiestroom verhoogt ook de kans op fouten door miscommunicatie. Wanneer we de fora buiten beschouwing laten, dan werken 3 van de 26 onderzochte webapplicaties (KMF [17] , KHK [18] en Lombrosiana[19] ) nog uitsluitend met statische pagina's. De fora worden niet meegerekend, aangezien deze van nature uit dynamisch zijn.

2.1.2.1.2 Dynamische webapplicaties Een veel betere oplossing is om bijvoorbeeld met php, asp, asp.net, python, ... te werken. Deze zijn in staat om data naar een databank te schrijven en uit een databank te lezen. Zo kan men niet enkel pagina's schrijven die de informatie uit de databank beschikbaar stellen aan de

-8-

eindgebruiker, maar kan men bepaalde personen de mogelijkheid geven om via aan webpagina de informatie in de databank aan te vullen, aan te passen en/of te verwijderen. Het gebruik van databanken heeft ook als extra troef dat informatie centraal opgeslagen wordt en kan opgeroepen worden op verschillende pagina's. Hierdoor is de kans veel kleiner dat men geconfronteerd wordt met tegenstrijdigheden en dus moeten de beheerders daar minder tijd aan spenderen. De andere 23 van de 26 verenigingen hebben een dynamische webapplicatie. Er is zelfs een duidelijke trend richting content management systemen (CMS). Vooral het CMS Joomla! [16] wordt gebruikt, maar ook 2 maal Drupal [4] .

2.1.2.2 Analyse van bestaande dynamische webapplicaties Ik had de mogelijkheid om de back-end van de webapplicatie van 2 studentenverenigingen (VEK [33] & VTK [39] ) te overlopen met de desbetreffende webmaster. Beide verenigingen waren deze nog volop verder aan het ontwikkelen, maar er waren al een pak functionaliteiten aanwezig. De back-end wordt toegankelijk gemaakt via een apart administratie gedeelte voorzien in de applicatie. Bij de VTK is deze back-end het meest uitgebreid, wat niet verwonderlijk is wanneer men weet dat zij sterk geschoold worden in de informatica en dat naast de 3 ICT verantwoordelijken er ook een groep actieve medewerkers is die continu de site verder ontwikkelen. Op de meeste pagina's waren zoekfuncties en dergelijke beschikbaar om het gebruik van de admin pagina's gemakkelijker te maken. Een aantal pagina's worden wel nog (gedeeltelijk) rechtstreeks met HTML geschreven, omdat het type inhoud te sterk varieert. Dit wordt wel tot het uiterste minimum beperkt. Hier zou men nog moeten zoeken naar een goede WYSIWYG (What You See Is What You Get) interface om het onderhoud van deze pagina's eenvoudiger te maken.

2.1.2.2.1 Activiteiten Via een formulier wordt elk bevoegd lid de mogelijkheid geboden om activiteiten toe te voegen, aan te passen en te verwijderen. Het gebruik van HTML code is hier niet nodig. Alles wordt in gewone tekst in het formulier ingegeven, waarna deze informatie in een databank wordt opgeslagen. Deze databank wordt dan gebruikt om de kalender en het bijhorende block element te genereren. Er is zelfs de mogelijkheid om een inschrijving te openen voor de desbetreffende activiteit (VTK [39] ). Men kan dan onder andere het volgende bepalen: • het maximum aantal inschrijvingen • of men iemand mag meenemen • of er een wachtlijst moet toegevoegd worden • eventuele betalingsmodaliteiten Een aantal statistieken in verband met de voorbije activiteiten worden bijgehouden op de webserver, bvb de kosten, inkomsten, hoeveelheden drank, ... Zo is er meer continuïteit naar de volgende jaren doordat informatie als deze niet verloren gaat. (VTK [39] )

2.1.2.2.2 Fotoalbum Foto's toevoegen aan een (nieuw) album is ongelofelijk gemakkelijk. Men selecteert een zipbestand, met daarin de foto's. Daarnaast moet worden aangegeven aan welk bestaand album de -9-

foto's moeten toegevoegd worden of er een nieuw album moet aangemaakt worden. Vervolgens op de 'verzenden'-knop klikken en alles wordt automatisch verder geregeld. Het is bij de applicatie van de VTK [39] zelfs mogelijk om een album aan een bestaande activiteit te linken, zodat de eindgebruiker dit album gemakkelijk kan vinden.

2.1.2.2.3 Communicatie Via de selectie van bepaalde (of alle) studierichtingen en -jaren kan men gemakkelijk een mail sturen naar een bepaalde groep leden. Zo kan er eenvoudig en op een heel gerichte wijze naar de leden gecommuniceerd worden. Via een checkbox op het profiel van de eindgebruiker, kan deze aangeven of deze al dan niet mails wil ontvangen. (VTK [39] Men kan ook surveys opstellen en deze online ter beschikking stellen. Zo kan men de leden de mogelijkheid geven om hun mening over bepaalde zaken, zoals grote activiteiten, te geven. Nu is dit nogal omslachtig. Men moet eerst een survey aanmaken en dan één voor één vragen hieraan toevoegen. Een beter systeem is echter al in volle ontwikkeling. (VTK [39] )

2.1.2.2.4 Recruitment Alle info omtrent recruitment zit bij beiden op een aparte dynamische webapplicatie. Deze van de VTK is speciaal het vermelden waard. Bedrijven krijgen daar een login die hen de mogelijkheid geeft om zelf de informatie die over hen op site staat aan te passen. Zij kunnen tevens online de CV-gids opvragen indien zij hiervoor betaald hebben.

2.1.2.2.5 Diversen Om dit onderdeel af te ronden, nog een aantal zaken die niet tot het hoofddoel van de webapplicatie behoren. Deze functionaliteiten maken het dagelijks bestuur van de VTK [39] heel wat eenvoudiger, dus werden deze aan hun webapplicatie toegevoegd. Een applicatie die het organiseren van shiften sterk vereenvoudigt. Men kan gemakkelijk een shift toevoegen in een leeg tijdsblok en bepalen hoeveel personen per shift nodig zijn. Het praesidium kan zich dan gemakkelijk inschrijven voor één of meerdere shiften. De boekhouding wordt volledig bijgehouden en bijgewerkt via de webapplicatie. Ieder praesidiumlid kan een onkostennota indienen en aangeven of deze al dan niet al terugbetaald werd. De penningmeesters hebben alle functionaliteiten voor handen om de boekhouding te regelen. Facturen kunnen op een eenvoudige manier opgesteld worden aan de hand van een formulier. Deze data wordt dan naar een databank weggeschreven. Het is mogelijk om via een LaTeX template deze data op te halen en er een pdf van te genereren. Zo worden automatisch facturen opgemaakt. Men kan een factuur ook rechtstreeks als betaald inschrijven in de voornoemde boekhouding.

2.1.3 Mobiele applicatie Alhoewel er steeds meer smartphones en dergelijke op de markt komen waarmee men van overal op het internet kan surfen, moet er toch vastgesteld worden dat maar 1 vereniging een mobiele versie van zijn applicatie gemaakt heeft. Op de mobiele versie van de applicatie van de VEK [33] kan een gebruiker het gastenboek bekijken, een reactie op het gastenboek plaatsen en de toekomstige activiteiten bekijken. Spijtig genoeg werkt het deel met de toekomstige activiteiten niet meer. Door een aanpassing aan de databank van de desktopapplicatie, werkt de mobiele applicatie met een SQL query die

- 10 -

niet meer geldig is. Daarnaast heb ik enkel van de webverantwoordelijke vernomen dat er een mobiele applicatie is. Nergens wordt de URL naar deze mobiele versie geadverteerd. Tot slot nog een grote fout: de link in de sponsorbanner opent een nieuwe pagina. Dit mag nooit gebeuren op een mobiel toestel zonder de expliciete toestemming van de gebruiker.

2.2 Intellectuele eigendomsrechten (IPR's) 2.2.1 UGent CAS Het enige meldenswaardige op dit vlak is de Centrale Authenticatieservice (CAS) [29] van de UGent [28] . Deze kan gebruikt worden om de verschillende login faciliteiten op de webapplicatie te realiseren. Nu heb je veelal een login op de website, eentje op het forum, ... Het zou stukken gemakkelijker zijn voor een groot deel van de eindgebruikers moesten zij overal hun UGent login kunnen gebruiken. Daarnaast kan deze service gebruikt worden om er voor te zorgen dat enkel personen die geassocieerd zijn met de UGent toegang krijgen tot bepaalde delen van de site en dat er grote zekerheid is over de identiteit van de gebruiker. Om van deze service gebruik te mogen maken is men verplicht zich te. Om zich te kunnen registreren moet men al over een UGent login beschikken. Men wordt immers via deze CAS geleid voordat men het registratieformulier te zien krijgt. Voor een deel van de attributen is geen speciale toestemming nodig, zoals bijvoorbeeld e-mail, voornaam, naam, ... De meer gevoelige attributen kunnen enkel verkregen worden mits toestemming. Hiervoor moet men een gegronde motivatie voorzien in de aanvraag.

2.3 Standaarden 2.3.1 Mobiele webapplicaties De kwaliteit van de gebruikservaring van het web via een mobiel toestel hangt sterk af van de bruikbaarheid van de website, de browser en het toestel zelf. In dit deel wordt gefocust op de bruikbaarheid van websites in relatie met mobiele toestellen. (W3C [21] [20] & [21] ) De meest relevante best practices: • voorzie enkel minimale navigatie bovenaan de pagina's • voorzie consistente navigatiemechanismen • houdt URL's zo kort mogelijk • weeg het aantal links op pagina's af tegenover het aantal nodige clicks om de gewenste pagina te bereiken • maak het doel van elke link zo duidelijk mogelijk • gebruik geen pop-ups en laad alles in hetzelfde venster, tenzij de gebruiker hier expliciet toestemming voor geeft • gebruik geen automatische verversing zonder de gebruiker daar eerst over te informeren • gebruik zo weinig mogelijk externe bronnen • beperk een pagina tot wat de gebruiker gevraagd heeft • beperk een pagina in afmeting een grootte • voorzie liefst maar 1 scrollrichting - 11 -

• zorg ervoor dat belangrijke data weergegeven wordt voor data van secundair belang • gebruik geen grote of hoge resolutie afbeeldingen • herschaal afbeelding aan de serverzijde • zorg ervoor dat informatie met kleur ook zonder kleur beschikbaar is • zorg voor voldoende contrast tussen achter- en voorgrond kleuren • zorg er bij gebruik van een achtergrondafbeelding voor dat de inhoud leesbaar blijft • voorzie een korte omschrijvende paginatitel • gebruik geen frames • gebruik liefst geen tabellen en zeker geen geneste tabellen of tabellen voor de lay-out • voorzie een tekstueel alternatief voor elk niet tekstueel element • vertrouw niet op ingebedde scripts en objecten • maak documenten die valideren op gepubliceerde formele grammatica's • gebruik geen absolute afmetingen (zoals pixels) • voorzie omschrijvende foutboodschappen en een manier om weg te navigeren • vertrouw niet op het beschikbaar zijn van cookies • beperk het aantal toetsaanslagen tot het uiterste minimum o gebruik zo weinig mogelijk tekstuele input o voorzie voorgeselecteerde standaardwaarden waar mogelijk • label alle controle-elementen in formuleren en link deze expliciet aan elkaar • zorg ervoor dat de labels goed gepositioneerd staan ten opzichte van het controleelement waar ze naar verwijzen

- 12 -

3 Requirements Document In dit document zullen alle gewenste functionaliteiten opgesomd worden. Er zal tevens aangeduid worden of deze in het te ontwikkelen prototype al zullen geïmplementeerd worden. De functionaliteiten die in het prototype moeten, zullen aangeduid worden door [prototype]. Daarnaast moet er ook rekening gehouden worden met een aantal kwalitatieve vereisten van de webapplicatie. Deze moeten sowieso gelden, prototype of niet.

3.1 Functionele vereisten 3.1.1 Algemeen Om het geheel niet te druk te maken, moet het aantal en de grootte van de block elementen steeds zo klein mogelijk gehouden worden. Er moet een duidelijke link voorzien worden naar de recruitment website. Deze moet op zo veel mogelijk pagina's weergegeven worden. Een persoon, zonder enige kennis van webdesign, moet de volledige inhoud van de webapplicatie kunnen aanpassen. Wie wat kan aanpassen moet afhangen van de functie binnen het praesidium.

3.1.2 Navigatie Zoals eerder besproken is het ontwikkelen van een menustructuur niet zo eenvoudig als men wel denkt. Het aantal items per menuniveau wordt bij voorkeur beperkt tot 7. Uitzonderlijk kan er tot 9 items gegaan worden. Submenu's moeten de rest van de pagina zo min mogelijk verstoren.

3.1.3 Startpagina De startpagina moet een duidelijk overzicht geven van de eerstkomende activiteiten. Een belangrijke activiteit moet extra in de verf gezet kunnen worden, zonder dat deze te sterk gaat overheersen. Indien een activiteit met online inschrijvingen werkt, moet een link daarnaar bij de respectievelijke activiteit voorzien worden. Er moet ook aangeduid worden tot wanneer de inschrijving loopt.

3.1.4 About - sectie Er moeten een aantal pagina's voorzien worden die meer uitleg verschaffen over: • de studentenvereniging [prototype] • de statuten • het dagelijks bestuur o uitgebreid voor het huidige jaar o een synthese van elk vorig jaar • het clublied

- 13 -

• een eventueel studentencafé met o de prijslijst o de locatie en een kaartje o info over de verhuur, tijdens periodes dat het café normaal gesloten is • een eventuele doop

3.1.5 Activiteiten - sectie Elke individuele activiteit moet automatisch kunnen geëxporteerd worden naar de FK databank. Ook moet automatisch een facebook evenement kunnen aangemaakt worden. Er moet tevens een pagina komen waarop alle activiteiten gegroepeerd worden, waarvoor men zich kan/moet inschrijven. Dit om de gebruiker een gemakkelijk overzicht te geven. Maximaal twee activiteiten die als belangrijk staan aangeduid, zouden een rechtstreekse link moeten krijgen in het menu. De eerstvolgende 5 activiteiten uit de 4 komende weken moeten te allen tijde zichtbaar zijn, samen met hun locatie, datum en beginuur. Als er zo minder dan 5 activiteiten gevonden worden, moet er gezocht worden naar activiteiten die als belangrijk staan aangeduid. Indien deze activiteiten nog moeten plaatsvinden, dan moeten de eerstkomende ook weergegeven worden. Het maximaal aantal van 5 komende activiteiten blijft evenwel gelden. Deze volledige lijst moet chronologisch gerangschikt worden.

3.1.5.1 Overzicht De gebruiker moet een duidelijk overzicht van de komende activiteiten kunnen zien [prototype]. Dit overzicht moet hij aan zijn persoonlijke voorkeur kunnen aanpassen. Zo moet deze kunnen kiezen welke types van activiteiten hij te zien krijgt, standaard moeten dit alle types zijn. Daarnaast moet de gebruiker ook de mogelijkheid krijgen om een tijdspanne aan te geven waarbinnen hij de komende activiteiten wil zien. De verschillende keuzes zijn per dag, per week of per maand. De verschillende types van activiteiten moeten duidelijk van elkaar onderscheiden worden. In dit overzicht moet naast de naam van de activiteit, ook de volgende informatie goed zichtbaar zijn: • de datum • het beginuur • de locatie • eventueel het einduur, indien daar plaats voor is De naam van de activiteit moet een link bevatten naar een activiteitenpagina.

3.1.5.2 Individuele pagina per activiteit Op deze individuele pagina per activiteit [prototype] moet alle informatie uit het overzicht nog eens herhaald worden. Daarnaast moeten de volgende onderdelen nog extra kunnen toegevoegd worden: • een uitgebreide beschrijving • een afbeelding (bvb. een affiche) met optioneel een link naar een grote versie • een kaartje waarop de locatie staat aangeduid • een link naar het bijhorende fotoalbum - 14 -

3.1.5.3 Wekelijkse informatieblaadje De meeste verenigingen delen elke week een infoblaadje uit met de activiteiten van de huidige week. Dit infoblaadje moet in pdf-formaat online komen. Alle links die naar de nieuwste versie verwijzen zouden bij het succesvol opladen automatisch moeten aangepast worden. Er moet een pagina voorzien worden, waar alle gebruikers een lijst krijgen van de informatieblaadjes van het lopende academiejaar. Van hieruit moeten ze elk van deze blaadjes kunnen bekijken en downloaden. Voor de beheerder moet dezelfde pagina beschikbaar zijn, maar zij moeten een overzicht krijgen van alle jaren.

3.1.6 Fotoboek Er moet een overzichtelijk fotoboek beschikbaar zijn, waarin de verschillende albums in omgekeerd chronologische volgorde weergegeven worden [prototype]. De albums van vorige jaren moeten beschikbaar blijven en gemakkelijk bereikbaar zijn. Foto's toevoegen zou kinderspel moeten zijn. Men duidt het album aan waaraan men de foto's wil toevoegen of men maakt een nieuw album aan. De foto's zouden, indien nodig, automatisch moeten herschaald worden naar de ingestelde afmetingen van het fotoboek. De verschillende pagina's zouden volledig automatisch gegenereerd moeten worden. Elke beheerder moet tevens een bepaalde foto kunnen verwijderen. Het moet mogelijk zijn voor ingelogde gebruikers om op elke foto commentaar te geven. Beheerders moeten deze gemakkelijk kunnen verwijderen. Dit verwijderen moet geregistreerd worden, zodat misbruik opgespoord kan worden.

3.1.7 Sponsors De sponsors verwachten zichtbaarheid op 2 fronten. Om te beginnen moeten de belangrijkste sponsors op elke pagina met hun logo aanwezig zijn. Zij hoeven niet allemaal tegelijkertijd zichtbaar te zijn, maar moeten een evenredig deel van de tijd aan bod komen. Daarnaast moet er een aparte sponsorpagina komen, waar de naam, het logo en een woordje uitleg over de bedrijfsactiviteiten te vinden zijn.

3.1.8 Studie Pagina's over de volgende aspecten moeten zeker voorzien worden: • studentenvertegenwoordiging o wat doen ze o jaarverantwoordelijken o verslagen van vergaderingen (oplaadbaar door bevoegde beheerders) • een meldpunt • samenvattingen • exameninfo • de boeken/cursussen die door de studentenvereniging verdeeld worden

3.1.8.1 Samenvattingen Voor een ingelogde gebruiker moet het mogelijk zijn om: • een samenvatting op te laden naar de webserver • de beschikbare samenvattingen eenmalig te beoordelen - 15 -

De gemiddelde score van een samenvatting moet voor iedereen zichtbaar zijn.

3.1.8.2 Verkochte boeken/cursussen Er zullen 2 types van boeken/cursussen verkocht worden. Enerzijds zijn er deze die voor een bepaald opleidingsonderdeel vereist zijn. Daarnaast zal men ook boeken aanbieden, die niet verplicht zijn, maar wel interessant kunnen zijn voor de studenten. Voor elk boek of elke cursus moet de huidige voorraad zichtbaar zijn.

3.1.9 Andere • Een pagina met links naar relevante externe sites o een overkoepelende organisatie o de faculteit o een alumnivereniging o facebook pagina o ... • Een pagina met contactinformatie van de beheerders. • Een gastenboek waar men anoniem (voor de gebruikers) een bericht kan achterlaten. • Een pagina waar men alle uitgegeven maandblaadjes kan terugvinden, onderverdeeld per jaar. • Een poll die (bijna) altijd zichtbaar is. • De mogelijkheid om (een deel van) de geregistreerde gebruikers te mailen. • Spelletjes

3.2 Kwalitatieve vereisten 3.2.1 Beveiliging • Enkel het huidige praesidium en een eventuele externe administrator mogen toegang hebben tot het administratie gedeelte van de webapplicatie. • De gebruikersaccounts moeten voldoende tegen externe inbreuk beschermd worden. • Gevoelige informatie moet altijd versleuteld verstuurd worden. • Alle invulformulieren en dergelijke moeten grondig tegen spam beveiligd worden • Pogingen tot malafide invoer mogen de databank en bij uitbreiding de applicatie niet aantasten.

3.2.2 Bruikbaarheid • Vanaf de startpagina moet een gebruiker binnen de 5 clicks elke sectie van de desktopapplicatie kunnen bereiken. Voor de mobiele applicatie mag dit maximaal 3 zijn. • Elke pagina moet interpreteerbaar zijn door de meest gebruikte browsers (bvb Mozilla Firefox, Internet Explorer, Google Chrome, ...). Dit wil zeggen dat er moet naar gestreefd worden om zo veel mogelijk pagina's te hebben die valideren als XHTML 1.0 Transitional. Op mobiele toestellen is het mogelijk dat een pagina helemaal niet wordt weergegeven indien deze niet valideert als XHTML. • Het ontstaan van broken links (= links die naar onbestaande pagina's wijzen) moet zo veel mogelijk uitgesloten worden. Dit is extra belangrijk voor de mobiele versie, omdat - 16 -

mobiele toestellen en/of hun browser niet altijd een 'terug'-knop hebben. Hierdoor kan de gebruiker vast komen te zitten op de weergegeven foutpagina. • Voor het mobiele gedeelte moet de tekstuele input van de gebruiker tot het uiterste minimum beperkt worden.

3.2.3 Gebruikersinterface • Voor de desktopapplicatie moet er rekening gehouden worden met de kleinste schermresolutie die nog veel gebruikt wordt, namelijk 1024x768 pixels (w3schools [40] ). De hele applicatie moet geoptimaliseerd worden met deze resolutie in het achterhoofd. • Bij de mobiele applicatie moet alles goed zichtbaar zijn op een monitor met heel beperkte afmetingen.

3.2.4 Prestatie Elke pagina moet op een desktop of laptop met een breedband internetconnectie binnen de seconde geladen zijn. De mobiele applicatie moet de volgende punten zo veel mogelijk minimaliseren: • de throughput (down- en upload) • het gebruikte geheugen op het mobiele toestel • de gebruikte rekenkracht op het mobiele toestel

3.2.5 Schaalbaarheid Eventuele uitbreidingen in de toekomst mogen de functionaliteit van de nu ontwikkelde webapplicatie niet in gevaar kunnen brengen.

- 17 -

4 Functional Design Document 4.1 Use Cases 4.1.1 Use Case index ID

Naam

1 2 3

Aanmaken account Commentaar bij foto plaatsen Fotoalbum toevoegen

4

Foto's toevoegen/beheren

5 6 7 8 9

Kalender bekijken Samenvatting beoordelen Samenvatting opladen Pagina aanpassen Beheerderrechten beheren Sponsors beheren Activiteiten beheren

10 11

Primaire uitvoerder Gebruiker Gebruiker

Scope

Complexiteit

Prioriteit

Intern Intern

Hoog Gemiddeld

1 2

Gebruiker / Beheerder Gebruiker / Beheerder Gebruiker Gebruiker Gebruiker Beheerder Webverantwoordelijke Beheerder Beheerder

Intern

Gemiddeld

1

Intern

Gemiddeld

1

Intern Intern Intern Intern Intern

Gemiddeld Gemiddeld Hoog Hoog Hoog

1 2 2 1 1

Intern Intern

Hoog Hoog

1 1

Tabel 1 - Use Case index

- 18 -

4.1.2 Sleutelcomponenten van de Use Cases 4.1.2.1 Aanmaken account Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 1 Aanmaken account De gebruiker maakt een account aan op de webapplicatie, die hem zal toelaten om bepaalde zaken extra te kunnen. Gebruiker 1. Op de startpagina krijgt de gebruiker de mogelijkheid om een account aan te maken. 2. Hij zal een unieke gebruikersnaam, een wachtwoord, zijn voornaam, zijn naam, zijn e-mailadres en een CAPTCHA moeten invullen. 3. Een activatiemail wordt naar het opgegeven e-mailadres gestuurd. 4. Na het volgen van deze link wordt de account geactiveerd en kan de gebruiker inloggen. Als de gebruiker een fout maakt bij het invoeren van de gegevens (stap 2), mag de registratie niet verdergaan. Alles wat al ingevuld was, moet dat blijven. De onderdelen waar het fout ging moeten aangeduid worden. De mogelijkheid bestaat dat de gebruiker de activatiemail (stap 3) niet ontvangen heeft. De gebruiker moet dus de mogelijkheid hebben om de activatiemail opnieuw te laten versturen.

Tabel 2 - Use Case 1: Aanmaken account

- 19 -

4.1.2.2 Commentaar bij een foto plaatsen Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 2 Commentaar bij een foto plaatsen Een ingelogde gebruiker kan bij om het even welke foto een commentaar plaatsen. Gebruiker 1. De gebruiker logt in op de webapplicatie. 2. Hij surft naar het fotoboek. 3. Hij kiest een album en bladert door de foto's. 4. Bij elke foto staat een formulier waarop hij zijn commentaar kan invullen. Indien hij de commentaar wil plaatsen klikt hij op de 'verzend'-knop. 5. De informatie wordt naar de server gestuurd en de commentaar wordt in de databank opgeslagen. 6. De pagina laadt (gedeeltelijk) opnieuw en toont de foto met de nieuw toegevoegde commentaar. Indien de gebruiker niet ingelogd is (stap 1) dan mag deze het formulier, om een commentaar, te plaatsen niet te zien krijgen Indien door een fout bij de server de commentaar niet kon toegevoegd worden (stap 5), laadt de fotopagina opnieuw. De commentaar die de gebruiker wilde toevoegen is al ingevuld in het desbetreffende formulier. Zodoende moet de gebruiker enkel op de 'verzend'-knop klikken om opnieuw te proberen. Er verschijnt ook een melding dat het toevoegen van de commentaar niet gelukt is.

Tabel 3 - Use Case 2: Commentaar bij een foto plaatsen

- 20 -

4.1.2.3 Fotoalbum toevoegen Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 3 Fotoalbum toevoegen Een gebruiker kan een nieuw fotoalbum toevoegen aan vooraf bepaalde categorieën. Een beheerder kan overal een nieuw fotoalbum toevoegen. Gebruiker / Beheerder 1. De gebruiker / beheerder logt in op de webapplicatie 2. Hij gaat naar het fotoboek en van daaruit naar een gebruikersmenu. 3. Daar kiest hij ervoor om een nieuw fotoalbum toe te voegen. Gewone gebruikers kunnen enkel albums aanmaken binnen bepaalde categorieën, dus enkel deze categorieën kunnen door hen gekozen worden. 4. De gebruiker/beheerder kiest een categorie en een naam en klikt op de 'verzenden' knop. 5. De server maakt de nodige wijzigingen om aan de aanvraag te voldoen. 6. Na het succesvol aanmaken van het nieuwe album wordt de gebruiker terug naar het gebruikersmenu van het fotoboek geleid. Indien door een fout bij de server het fotoalbum niet kon toegevoegd worden (stap 5), laadt de pagina opnieuw zoals deze was op het moment net voor het verzenden (stap 4). Zodoende moet de gebruiker/beheerder enkel op de 'verzend'-knop klikken om opnieuw te proberen. Er verschijnt ook een melding dat het toevoegen van het fotoalbum niet gelukt is.

Tabel 4 - Use Case 3: Fotoalbum toevoegen

- 21 -

4.1.2.4 Foto's toevoegen / beheren Use Case Element Nummer Naam Beschrijving

Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 4 Foto's toevoegen / beheren Een gebruiker kan foto's toevoegen aan een album gecreëerd onder vooraf bepaalde categorieën. Een beheerder kan overal nieuwe foto's toevoegen. Gebruiker / Beheerder 1. De gebruiker / beheerder logt in op de webapplicatie 2. Hij gaat naar het fotoboek en van daaruit naar een gebruikersmenu. 3. Daar kiest hij ervoor om foto's aan een fotoalbum toe te voegen. Gewone gebruikers kunnen enkel foto's aan albums toevoegen binnen bepaalde categorieën, dus enkel deze fotoalbums kunnen door hen gekozen worden. 4. De gebruiker/beheerder kiest het album, de foto's en eventueel een naam voor de foto's en klikt op de 'verzenden' knop. 5. De server maakt de nodige wijzigingen om aan de aanvraag te voldoen. 6. Na het succesvol aanmaken van het nieuwe album wordt de gebruiker terug naar het gebruikersmenu van het fotoboek geleid. Indien door een fout bij de server de foto's niet konden toegevoegd worden (stap 5), laadt de pagina opnieuw zoals deze was op het moment net voor het verzenden (stap 4). Zodoende moet de gebruiker/beheerder enkel op de 'verzend'-knop klikken om opnieuw te proberen. Er verschijnt ook een melding dat het verzenden niet gelukt is.

Tabel 5 - Use Case 4: Foto's toevoegen / beheren

4.1.2.5 Kalender bekijken Use Case Element Nummer Naam Beschrijving

Primaire uitvoerder Basic Flow

Beschrijving 5 Kalender bekijken De gebruiker krijgt een overzicht van de activiteiten. De weergave kan hij gedeeltelijk aan zijn eigen voorkeur aanpassen. Hij kan de tijdspanne kiezen en het type van activiteiten. Gebruiker De gebruiker surft naar de 'kalender'-pagina en kan daar naar believen tussen de aangeboden weergaves kiezen.

Alternate Flows Tabel 6 - Use Case 5: Kalender bekijken

- 22 -

4.1.2.6 Samenvatting beoordelen Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 6 Samenvatting beoordelen Een ingelogde gebruiker kan de samenvattingen beoordelen. Het gemiddelde hiervan wordt publiek weergegeven. Gebruiker 1. De gebruiker logt in op de webapplicatie 2. Hij surft naar de 'samenvattingen'-pagina. Op deze pagina kan hij elke samenvatting eenmalig beoordelen. 3. De server voert de nodige taken uit om de beoordeling door te voeren. 4. Na de beoordeling laadt de pagina (gedeeltelijk) opnieuw en wordt het nieuwe gemiddelde weergegeven. Als er een fout aan de serverzijde optreedt (stap 3), wordt de pagina opnieuw geladen en verschijnt een melding dat de beoordeling mislukt is.

Tabel 7 - Use Case 6: Samenvatting beoordelen

4.1.2.7 Samenvatting opladen Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 7 Samenvatting opladen Een ingelogde gebruiker kan 1 samenvatting per keer naar de webserver opladen. Gebruiker 1. De gebruiker logt in op de webapplicatie 2. Hij surft naar de 'samenvattingen'-pagina. Hier is een link voorzien naar de 'oplaad'-pagina om een nieuwe samenvatting op te laden. 3. De gebruiker selecteert daar het bestand dat hij wil opladen en klikt op de 'verzend'-knop. 4. De server voert de nodige taken uit om de samenvatting op de server te plaatsen. 5. Na het succesvol verzenden wordt de 'samenvattingen'-pagina opnieuw geladen met de nieuwe lijst samenvattingen. Als er een fout aan de serverzijde optreedt (stap 4), wordt de 'oplaad'pagina opnieuw geladen zoals deze was op het moment net voor het verzenden (stap 3). Zodoende moet de gebruiker/beheerder enkel op de 'verzend'-knop klikken om opnieuw te proberen. Er verschijnt ook een melding dat het opladen niet gelukt is.

Tabel 8 - Use Case 7: Samenvatting opladen

- 23 -

4.1.2.8 Pagina aanpassen Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 8 Pagina aanpassen Een bevoegde beheerder moet de inhoud van een bepaalde pagina kunnen aanpassen Beheerder 1. Een beheerder logt in op de beheerdersectie van de webapplicatie. 2. Hij navigeert daar naar de pagina die hij wil aanpassen. 3. Hij verandert de inhoud van het formulier naar believen en klikt daarna op de 'verzend'-knop. 4. De server voert de nodige taken uit om de aangepaste pagina op te slaan. 5. Bij succesvol verzenden laadt het aangepaste formulier opnieuw met de melding dat de aanpassing geslaagd is. Als er een fout aan de serverzijde optreedt (stap 4), wordt de pagina opnieuw geladen met het aangepaste invulformulier. Er verschijnt een melding dat het aanpassen niet gelukt is.

Tabel 9 - Use Case 8: Pagina aanpassen

4.1.2.9 Beheerderrechten beheren Use Case Element Nummer Naam Beschrijving

Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 9 Beheerderrechten beheren Een webverantwoordelijke kan elke gebruiker bepaalde beheerderrechten geven of afnemen, ook van een eventuele andere webverantwoordelijke. Webverantwoordelijke 1. De webverantwoordelijke logt in op de beheerdersectie van de webapplicatie. 2. Hij gaat naar het gebruikersbeheer en selecteert de gebruiker waarvan hij de rechten wil aanpassen. 3. Hij wordt naar een nieuwe pagina geleid waar hij de rechten kan aanpassen. Wanneer hij op de 'verzend'-knop klikt, wordt deze aanpassing doorgestuurd. 4. De server voert de nodige taken uit om de aangepaste rechten op te slaan. 5. Bij het succesvol aanpassen laadt de 'gebruiksbeheer'-pagina opnieuw met een bericht dat de aanpassing succesvol is doorgevoerd. Als er een fout aan de serverzijde optreedt (stap 4), wordt de beheerpagina van de gekozen gebruiker opnieuw geladen met de aanpassingen van de webverantwoordelijke. Er verschijnt een melding dat het aanpassen niet gelukt is.

Tabel 10 - Use Case 9: Beheerderrechten beheren

- 24 -

4.1.2.10 Activiteiten beheren Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 10 Activiteiten beheren Een bevoegde beheerder kan naar believen nieuwe activiteiten toevoegen of bestaande activiteiten aanpassen en verwijderen. Beheerder 1. Een beheerder logt in op de beheerdersectie van de webapplicatie. 2. Hij surft dan naar de pagina waar hij de activiteiten kan beheren. 3. Daar klikt hij op 'activiteit toevoegen' of op het icoon naast een bestaande activiteit om deze aan te passen of verwijderen. 4. a) Indien hij een activiteit probeert te verwijderen verschijnt een popup met de vraag of de beheerder zeker is dat hij de activiteit wil verwijderen. b) Indien hij een activiteit wil toevoegen verschijnt een leeg formulier. Als hij een bestaande activiteit wil aanpassen verschijnt hetzelfde formulier, maar dan ingevuld met de informatie die al beschikbaar was in de databank. De beheerder maakt de vereiste aanpassing aan de inhoud van het formulier en klikt op de 'verzend'-knop. 5. De server voert de nodige taken uit om de wijziging op te slaan. 6. Bij het succesvol beheren van een pagina verschijnt de vernieuwde beheerpagina van de activiteiten met een melding dat de aanpassing succesvol is doorgevoerd. Als er een fout aan de serverzijde optreedt (stap 5), gebeurt het volgende: Bij het verwijderen van een activiteit laadt de beheerpagina opnieuw. Bij het aanpassen of aanmaken van een activiteit verschijnt de pagina uit stap 4b met de aangepaste inhoud. Er verschijnt telkens een melding dat de aanpassing niet gelukt is.

Tabel 11 - Use Case 10: Activiteiten beheren

- 25 -

4.1.2.11 Sponsors beheren Use Case Element Nummer Naam Beschrijving Primaire uitvoerder Basic Flow

Alternate Flows

Beschrijving 11 Sponsors beheren Een bevoegde beheerder kan naar believen nieuwe sponsors toevoegen of bestaande sponsors aanpassen en verwijderen. Beheerder 1. Een beheerder logt in op de beheerdersectie van de webapplicatie. 2. Hij surft dan naar de pagina waar hij de sponsors kan beheren. Daar klikt hij op 'sponsor toevoegen' of op het icoon naast een bestaande sponsor om deze aan te passen of te verwijderen. 3. a) Indien hij een sponsor probeert te verwijderen verschijnt een popup met de vraag of de beheerder zeker is dat hij de sponsor wil verwijderen. b) Indien hij een sponsor wil toevoegen verschijnt een leeg formulier. Als hij een bestaande sponsor wil aanpassen verschijnt hetzelfde formulier, maar dan ingevuld met de informatie die al beschikbaar was in de databank. De beheerder maakt de vereiste aanpassing aan de inhoud van het formulier en klikt op de 'verzend'-knop. 4. De server voert de nodige taken uit om de wijziging op te slaan. 5. Bij het succesvol beheren van een pagina verschijnt de vernieuwde beheerpagina van de sponsors met een melding dat de aanpassing succesvol is doorgevoerd. Als er een fout aan de serverzijde optreedt, gebeurt het volgende: Bij het verwijderen van een sponsor laadt de beheerpagina opnieuw. Bij het aanpassen of aanmaken van een activiteit verschijnt de pagina uit stap 3b met de aangepaste inhoud. Er verschijnt telkens een melding dat de aanpassing niet gelukt is.

Tabel 12 - Use Case 11: Sponsors beheren

- 26 -

4.1.3 Use Case diagram

Figuur 1 - Use Case Diagram

- 27 -

4.2 Site Map 4.2.1 Beoogde desktopapplicatie

Figuur 2 - Sitemap

- 28 -

4.2.2 Prototype desktopapplicatie

Figuur 3 - Sitemap prototype desktopapplicatie

- 29 -

4.2.3 Mobiele Applicatie

Figuur 4 - Sitemap mobiele applicatie

- 30 -

4.3 Wireframes 4.3.1 Desktopapplicatie 4.3.1.1 Template

Figuur 5 - Wireframe Desktop 'Template'

- 31 -

4.3.1.2 Centrale inhoudsgedeelte 4.3.1.2.1 Startpagina / Activiteitenpagina

Figuur 6 - Wireframe Desktop 'Startpagina / Activiteitenpagina'

4.3.1.2.2 About VEK

Figuur 7 - Wireframe Desktop 'About VEK'

- 32 -

4.3.1.2.3 Statuten

Figuur 8 - Wireframe Desktop 'Statuten'

- 33 -

4.3.1.2.4 VEK-lied

Figuur 9 - Wireframe Desktop 'VEK-lied'

4.3.1.2.5 Huidig praesidium

Figuur 10 - Wireframe Desktop 'Huidig praesidium'

- 34 -

4.3.1.2.6 Alle praesessen

Figuur 11 - Wireframe Desktop 'Alle praesessen'

4.3.1.2.7 Vorige praesidia

Figuur 12 - Wireframe Desktop 'Vorige praesidia'

- 35 -

4.3.1.2.8 Sponsors

Figuur 13 - Wireframe Desktop 'Sponsors'

- 36 -

4.3.1.2.9 Yucca

Figuur 14 - Wireframe Desktop Yucca

- 37 -

4.3.1.2.10 Yucca huren

Figuur 15 - Wireframe Desktop 'Yucca (huren)'

4.3.1.2.11 Yucca (prijslijst)

Figuur 16 - Wireframe Desktop 'Yucca (prijslijst)'

- 38 -

4.3.1.2.12 Doop

Figuur 17 - Wireframe Desktop 'Doop'

4.3.1.2.13 Doop (reglement)

Figuur 18 - Wireframe Desktop 'Doop (reglement)'

4.3.1.2.14 Weekinfo

Figuur 19 - Wireframe Desktop 'Weekinfo'

- 39 -

4.3.1.2.15 Kalender (maand)

Figuur 20 - Wireframe Desktop 'Kalender (maand)'

4.3.1.2.16 Kalender (maand in lijstvorm)

Figuur 21 - Wireframe Desktop 'Kalender (maand in lijstvorm)'

- 40 -

4.3.1.2.17 Kalender (week)

Figuur 22 - Wireframe Desktop 'Kalender (week)'

4.3.1.2.18 Kalender (dag)

Figuur 23 - Wireframe Desktop 'Kalender (dag)'

4.3.1.2.19 Inschrijvingen

Figuur 24 - Wireframe Desktop 'Inschrijvingen'

- 41 -

4.3.1.2.20 Cel Didactiek

Figuur 25 - Wireframe Desktop 'Cel Didactiek'

4.3.1.2.21 Leden Cel Didactiek

Figuur 26 - Wireframe Desktop 'Leden Cel Didactiek'

- 42 -

4.3.1.2.22 Boekenverkoop (planning)

Figuur 27 - Wireframe Desktop 'Boekenverkoop (planning)'

4.3.1.2.23 Boekenverkoop (verplichte cursussen)

Figuur 28 - Wireframe Desktop 'Boekenverkoop (verplichte cursussen)'

- 43 -

4.3.1.2.24 Boekenverkoop (andere)

Figuur 29 - Wireframe Desktop 'Boekenverkoop (andere)'

4.3.1.2.25 Meldpunt

Figuur 30 - Wireframe Desktop 'Meldpunt'

4.3.1.2.26 Samenvattingen opladen

Figuur 31 - Wireframe Desktop 'Samenvattingen opladen'

- 44 -

4.3.1.2.27 Samenvattingen

Figuur 32 - Wireframe Desktop Samenvattingen

4.3.1.2.28 Homo Economicus

Figuur 33 - Wireframe Desktop 'Homo Economicus'

- 45 -

4.3.1.2.29 Den Toog

Figuur 34 - Wireframe Desktop 'Den Toog'

- 46 -

4.3.1.2.30 Fotoboek (overzicht)

Figuur 35 - Wireframe Desktop 'Fotoboek (overzicht)'

- 47 -

4.3.1.2.31 Fotoboek (album)

Figuur 36 - Wireframe Desktop 'Fotoboek (album)

- 48 -

4.3.1.2.32 Fotoboek (foto)

Figuur 37 - Wireframe Desktop 'Fotoboek (foto)'

- 49 -

4.3.1.2.33 Links

Figuur 38 - Wireframe Desktop 'Links'

4.3.1.2.34 Contact

Figuur 39 - Wireframe Desktop 'Contact'

- 50 -

4.3.2 Mobiele applicatie 4.3.2.1 Startpagina

Figuur 40 - Wireframe Mobiel 'Startpagina'

- 51 -

4.3.2.2 About VEK

Figuur 41 - Wireframe Mobiel 'About VEK'

4.3.2.3 Kalender

Figuur 42 - Wireframe Mobiel 'Kalender'

- 52 -

4.3.2.4 Fotoboek (overzicht)

Figuur 43 - Wireframe Mobiel 'Fotoboek (overzicht)'

- 53 -

4.3.2.5 Fotoboek (album)

Figuur 44 - Wireframe Mobiel 'Fotoboek (album)'

- 54 -

4.3.2.6 Fotoboek (foto)

Figuur 45 - Wireframe Mobiel 'Fotoboek (foto)'

- 55 -

4.4 Klassendiagram

Figuur 46 - Klassendiagram

- 56 -

5 Proof of Concept 5.1 Desktopapplicatie 5.1.1 Joomla! Voor de ontwikkeling van de desktopapplicatie werd het CMS Joomla! gekozen. Een CMS gebruiken heeft als voordeel dat de inhoud volledig van de vormgeving gescheiden kan worden. Zo moeten de personen die later de site verder gaan onderhouden er enkel voor zorgen dat de inhoud up-to-date blijft. Deze scheiding zorgt er ook voor dat wanneer men niet meer tevreden is over de look van de site, men enkel de CSS bestanden moet aanpassen en de volledige site zal de nieuwe lay-out krijgen. Een tweede voordeel van een CMS is dat, mede door de voornoemde scheiding, complete leken nu een webapplicatie kunnen onderhouden. Door middel van WYSIWYG interfaces en formulieren kan namelijk eenvoudig inhoud toegevoegd, aangepast en verwijderd worden. Via formulieren wordt tevens de functionaliteit van de verschillende extensies geregeld. Joomla! heeft daarenboven een zeer grote community. Hierdoor zijn er tal van gratis extensies beschikbaar, die de nood om zelf te programmeren zeer sterk reduceren. Er zijn ook heel veel fora waar men met vragen terecht kan. Het is tegenwoordig mogelijk om een heel uitgebreide site te bouwen zonder zelf 1 letter te moeten programmeren. Men kan componenten, modules, plug-ins en templates downloaden en op een applicatie installeren. Componenten, modules en plug-ins verzorgen de functionaliteiten van applicatie. Een template bepaalt de volledige lay-out van de applicatie, een nieuwe template verandert dus in 1 keer de volledige look. De beheerder moet dan hooguit nog de CSS bestanden een beetje aanpassen aan de huisstijl.

5.1.2 Gebruikte Extensies 5.1.2.1 JA_Purity JA_Purity is een template die standaard in Joomla! aanwezig is. Via het templatebeheer moet deze enkel als 'default' ingesteld worden. Het HTML bestand en het CSS bestand zijn beide een klein beetje aangepast. CSS bestand ... h1.logo-text a { ... left: 70px;

// Deze waarde werd van 0px naar 70px gezet, omdat anders deze text over het logo verscheen.

} p.site-slogan { ... left: 70px;

// Deze waarde werd van 0px naar 70px gezet, omdat anders deze text over het logo verscheen.

} ...

- 57 -

HTML bestand ... sitename(); if ($tmpTools->getParam('logoType')=='image'): ?>

"><span>

getParam('logoText'))=='') ? $config->sitename : $tmpTools->getParam('logoText'); $sloganText = (trim($tmpTools->getParam('sloganText'))=='') ? JText::_('SITE SLOGAN') : $tmpTools->getParam('sloganText'); ?>

"><span>

/* Deze code werd toegevoegd om zowel de afbeelding van het logo weer te geven als de logoText en de logoSlogan */

"><span>

...

5.1.2.2 Community Builder v1.2.2 5.1.2.2.1 Algemeen Met de Community Builder (CB) component en modules [2] kan het registratieformulier uitgebreid worden. Daarnaast kan men extra velden en tabs toevoegen aan de gebruikersprofielen, men kan moderatoren aanstellen om de gebruikers te helpen beheren, ... Zo kan de informatie die relevant is voor de vereniging gevraagd worden bij de registratie en weergegeven worden op het profiel van de gebruikers. Via de verschillende gebruikersgroepen van Joomla! kan men bepalen wie gebruikersprofielen kan zien en zelfs wie welke tabs op profielen kan zien. De belangrijkste 2 delen van deze extensie zijn de component die het registratieformulier en de profielen verzorgt en een nieuwe inlog module, die verplicht moet gebruikt worden. Deze zijn de enige 2 delen die in het prototype verwerkt zitten.

- 58 -

5.1.2.2.2 Instelling van de component

Figuur 47 - Instellingen Community Builder: Algemeen

Figuur 48 - Instellingen Community Builder: Registratie (1/2)

- 59 -

Figuur 49 - Instellingen Community Builder: Registratie (2/2)

Figuur 50 - Instellingen Community Builder: Ledenlijst

- 60 -

Figuur 51 - Instellingen Community Builder: Profielen

Figuur 52 - Instellingen Community Builder: Afbeeldingen

- 61 -

Figuur 53 - Instellingen Community Builder: Moderatie

Figuur 54 - Instellingen Community Builder: Connecties

Figuur 55 - Instellingen Community Builder: Integratie

5.1.2.2.3 Beheer van de component Er is een eigen 'User Management' voorzien. Hier kan je net zoals in het gebruikersbeheer van Joomla! zelf bepalen welk gebruiksniveau elke gebruiker heeft, of hun registratie al dan goedgekeurd is en een gebruiker eventueel blokkeren. Bij 'Tab Management' kan men de beschikbare tabs in- of uitschakelen en nieuwe tabs aanmaken. Sommige van deze tabs zijn rechtstreeks gelinkt aan andere plug-ins en kunnen maar gebruikt worden indien deze plug-ins effectief geïnstalleerd zijn. Zo is er bijvoorbeeld al een tab voorzien voor een forum plug-in.

- 62 -

Onder 'Field Management' zijn alle aangemaakt velden beschikbaar en kan men zelf vrij velden aanmaken. Voor elk veld kunnen een hele reeks instellingen aangepast worden, namelijk • in- of uitgeschakeld • de rangorde • de tab waaronder het hoort • verplicht in te vullen • op het profiel zichtbaar • bij registratie in te vullen • mogelijkheid tot zoekopdrachten op de inhoud • ... Er kunnen via 'List Management' lijsten worden aangemaakt van de gebruikers. Men kan bijvoorbeeld een lijst maken van iedereen die in een veld een bepaalde waarde heeft ingegeven en dit dan nog eens bijvoorbeeld alfabetisch sorteren op naam. Er kunnen meerder filter- en sorteervelden in 1 lijst gebruikt worden. Er is geen link voorzien om zo gericht te mailen, dus deze lijsten hebben weinig direct nut voor de te realiseren applicatie. 'Plugin Management' kan gebruikt worden om plug-ins te installeren, verwijderen en in- of uitschakelen. Een taalpakket installeren gebeurt bijvoorbeeld hier. Tot slot zijn er nog de 'Tools'. Hier kan men de gebruikerstabellen van Joomla! met deze van CB synchroniseren en testen uitvoeren op de verschillende tabellen die CB in de databank gebruikt.

5.1.2.3 JEvents v1.5.4 5.1.2.3.1 Algemeen De kalenderfunctie wordt verzorgd door de JEvents [14] component en de bijhorende 'Latest Events' module. Deze module zorgt er voor dat een block element ingesteld kan worden op de webapplicatie om de eerstkomende activiteiten overal zichtbaar te maken. Er werd voor deze component gekozen, omdat hij aan bijna alle eisen voldoet die aan de kalender gesteld werden, zelfs de individuele pagina per activiteit. Het enige ontbrekende element is het kaartje dat de locatie van het evenement aanduidt.

- 63 -

5.1.2.3.2 Instellingen van de component

Figuur 56 - Instellingen JEvents: Component

Figuur 57 - Instellingen JEvents: Rechten

Figuur 58 - Instellingen JEvents: Ical Import/Export

- 64 -

Figuur 59 - Instellingen JEvents: Event Editing

Figuur 60 - Instellingen JEvents: Event Daily View

Figuur 61 - Instellingen JEvents: Main Monthly Calender

- 65 -

Figuur 62 - Instellingen JEvents: Year/Category View

Figuur 63 - Instellingen JEvents: RSS

Figuur 64 - Instellingen JEvents: 'Calender' Module

- 66 -

Figuur 65 - Instellingen JEvents: 'Latest Events' Module

5.1.2.3.3 Beheren van de component Om te kunnen beginnen, moeten de 'Authorised Users' ingesteld worden. Standaard staat hier namelijk niemand die de toelating heeft om één van de andere onderdelen te beheren. Indien je bij de instelling aangeduid hebt dat iedere gebruiker die deze component mag beheren individueel moet toegevoegd worden, zal zelfs een Super Administrator niets kunnen beheren voordat hij aan deze lijst is toegevoegd met de juiste rechten. Als tweede is er 'Manage Categories'. Hier staat standaard een 'default' categorie, omdat elk evenement een categorie (= type) moet hebben. Er kunnen zo veel categorieën aangemaakt worden als men maar wil en via de aanduiding van een 'parent' categorie kan een heuse boomstructuur uitgewerkt worden. Elke categorie kan een kleurcode meekrijgen die dan als achtergrond gebruikt wordt op de eigenlijke kalender. Vervolgens kan men evenementen aanmaken en beheren onder 'Manage Events'. Zoals al vermeld moet bij elk evenement een categorie aangeduid worden. Een mooi extraatje is dat je een evenement automatisch dagelijks, wekelijks, maandelijks of jaarlijks kan laten herhalen. Een tweede extra functionaliteit is de mogelijkheid om de zichtbaarheid van evenementen te beperken tot bepaalde gebruikersgroepen. Tot slot kan men een kalender aanmaken of beheren onder 'Manage Calendars'. Bij een kalender moet altijd exact 1 categorie aangeduid worden die weergegeven zal worden. Alle categorieën die zich in de voornoemde boomstructuur onder deze 'parent' categorie bevinden zullen ook weergegeven worden op de kalender.

5.1.2.4 JoomGallery v1.5.0.5 5.1.2.4.1 Algemeen Het fotoboek is opgebouwd met JoomGallery [15] . Deze extensie voldoet aan bijna alle vereisten die aan het fotoboek gesteld worden. Het enige wat JoomGallery niet doet is

- 67 -

registreren wie een afbeelding verwijdert heeft. Aangezien afbeeldingen enkel op de back-end verwijdert kunnen worden, is de mogelijkheid tot misbruik echter zeer klein. Geregistreerde gebruikers kunnen zichzelf op afbeeldingen 'taggen', ze kunnen op elke afbeelding commentaar geven en deze beoordeeld. Geregistreerde gebruikers hebben ook de mogelijkheid om zelf foto's toe te voegen. Er zijn een hele reeks instellingen hieromtrent die misbruik van deze functionaliteit sterk kunnen inperken. Wanneer elke foto eerst moet goedgekeurd worden vooraleer deze zichtbaar wordt, zou de front-end van mogelijks misbruik normaal niets mogen merken.

5.1.2.4.2 Instellingen van de component • General Settings o Path's and Directories (Figuur 82) o Replacements (Figuur 83) o Image Processing (Figuur 84) o Back-end Upload (Figuur 85) o Additional Functions (Figuur 86) • User Access Right o User Upload (Figuur 87) o Ratings (Figuur 88) o Comments (Figuur 89) • Frontend Settings o Picture Ordering (Figuur 90) o Page Title (Figuur 91) o Header and Footer (Figuur 92) o User Panel (Figuur 93) o Popup Functions (Figuur 94) • Gallery View (Figuur 95) • Category View o General Settings (Figuur 96) o Sub-categories (Figuur 97) • Detail View (niets aan standaardinstellingen gewijzigd) • Toplists (Figuur 98) • Favourites (Figuur 99)

5.1.2.4.3 Beheren van de component 5.1.2.4.3.1 Algemeen Net zoals bij de evenementen moet ook elke foto in een bepaalde categorie (=album) geplaatst worden en via 'parent' categorieën kan opnieuw een volledige boomstructuur uitgewerkt worden. Het beheer van de categorieën gebeurt in 'Category Manager'. Als de thumbnail van een categorie zelf gekozen moet worden, dan moet dat ook hier gebeuren. De ordening van de categorieën kan ook aangepast worden.

- 68 -

In de 'Picture Manager' worden de individuele afbeelding beheert. Afbeeldingen die door geregistreerde gebruikers opgeladen werden, moeten eerst goedkeuring krijgen in dit onderdeel. Het is mogelijk om afbeeldingen die opgeladen zijn, niet zichtbaar te maken. Deze afbeeldingen kunnen wel nog gebruikt worden als thumbnail voor een categorie. Zo kan de thumbnail van een categorie bijvoorbeeld op de affiche van de activiteit gesteld worden, zonder dat die affiche ook in het album zelf zichtbaar is. Naargelang de instellingen over de ordening van de afbeeldingen, kan men de weergegeven ordening op de front-end aanpassen door de ordening op de back-end te wijzigen. Als de ordening automatisch gebeurt, bijvoorbeeld alfabetisch, dan maakt de ordening op de back-end niet uit voor de uiteindelijke weergave in de front-end. De 'Comments Manager' wordt gebruikt om de commentaren te beheren. Het IP adres van de gebruiker, de datum en tijd van aanmaken, het ID nummer van de afbeelding waarbij de commentaar hoort en een kleine thumbnail van de afbeelding worden getoond. Zoals alles in Joomla! kan men een commentaar zowel onzichtbaar maken als verwijderen. Om de beoordelingen van de afbeeldingen te beheren is er de 'Votes Manager'. Men kan de beoordelingen van alle verwijderde gebruikers laten verwijderen of alle beoordelingen voor alle afbeeldingen verwijderen. Het is ook mogelijk om rechtstreeks de CSS van de component aan te passen bij 'Customize CSS'. Tot slot is er de 'Migration Manager' die het mogelijk maakt om in één ruk alles van PonyGallery ML naar JoomGallery over te zetten. 5.1.2.4.3.2 Afbeeldingen opladen Bij het opladen van afbeeldingen moet altijd een categorie gekozen worden waartoe deze behoren en een nieuwe naam. Optioneel kan men een beschrijving en een auteur toevoegen. In de back-end bestaat ook altijd de mogelijk om transparante of geanimeerde afbeeldingen toe te voegen. Hiervoor moet men wel de bijhorende checkbox aanduiden, anders wordt geen rekening gehouden met deze types en wordt alles als een gewone afbeelding opgeladen. Als er meerdere afbeeldingen tegelijk worden opgeladen, kan men ook kiezen bij welk cijfer de automatische nummering start. Men kan op 4 verschillende manieren afbeeldingen opladen via de back-end. Ten eerste kan dit afbeelding per afbeelding gebeuren via 'Picture Upload', het aantal afbeeldingen dat zo op 1 pagina tegelijk kan opgeladen worden hangt af van de gekozen instellingen. Als tweede is er de 'Batch Upload'. Zo kan een hele reeks afbeeldingen tegelijk opgeladen worden die in een zip bestand zitten. De maximale grootte van het zip bestand hangt af van de instellingen en is dezelfde als de maximale grootte van een individuele afbeelding. Indien deze instelling dus niet al te hoog staat, zal opladen via deze optie dus vaak mislukken. Hier had de ontwikkelaar toch een apart veld mogen voorzien in de instellingen om de maximale grootte van een zip-bestand te bepalen. Vervolgens is er 'FTP Upload'. Eerst laad men de afbeelding op de server op in een bepaalde map via een FTP programma. Wanneer men dan naar 'FTP Upload' gaat ziet men daar een lijst met al deze afbeeldingen. Met de 'ctrl'- of 'shift'-toets kunnen meerdere afbeeldingen tegelijk geselecteerd worden. Automatisch staat aangeduid dat de afbeeldingen die aan een categorie worden toegevoegd uit deze FTP map worden verwijdert, dit kan echter uitgevinkt worden. Als laatste kunnen afbeeldingen opgeladen worden via een Java Applet. De beheerder kan onder 'Java Upload' via Windows Verkenner bestanden selecteren om op te laden. Wanneer men alle bestanden in de lijst geplaatst heeft, kan men deze in één keer allemaal laten opladen.

- 69 -

5.2 Mobiele applicatie 5.2.1 Osmobi Om de desktopapplicatie gedeeltelijk automatisch om te schakelen naar een mobiele versie wordt Osmobi [23] gebruikt. Osmobi wordt mogelijk gemaakt door de technologie van Siruna [26] . Siruna zelf is een spin-off van het IBBT [13] en van de UGent [28] . Men moet een plug-in en template installeren. Dankzij deze extensies, zal de webapplicatie nu zijn weergave aanpassen op mobiele toestellen. De URL van de desktopapplicatie kan ook gewoon op het mobiele toestel gebruikt worden. De applicatie herkent dat de aanvraag komt van een mobiel toestel en zal de doorgestuurde pagina automatisch aanpassen. Eens deze beide extensies geïnstalleerd zijn, kan er een nieuw project gestart worden op de website van Osmobi.

5.2.2 Omzetting naar de mobiele applicatie Bij de omschakeling van de desktopapplicatie naar de mobiele applicatie is er goed opgelet worden welke element JavaScript gebruiken. De submenu's die via JavaScript uitklappen mogen niet meer gebruikt worden. Er kan immers niet op gerekend worden dat een mobiel toestel met JavaScript overweg kan. Gelukkig is dit niet echt een probleem. De mobiele applicatie moet maar een beperkt aantal elementen bevatten, dus het menu moet sowieso afgeslankt worden. Het aantal items is zo beperkt dat ze gemakkelijk in een dropdown menu terecht kunnen. Er wordt een dropdown menu gebruikt om de plaats die het menu inneemt zo klein mogelijk te houden. Eens het menu aangepast is, moet de inhoud van de nog toegankelijke pagina's aangepast worden. Alle niet noodzakelijke elementen worden uit de mobiele versie verwijdert. Elk element dat niet meer goed werkt, omdat het bijvoorbeeld op JavaScript vertrouwd, wordt ook best verwijdert. Behalve het menu is er niets dat JavaScript nodig heeft en op de mobiele applicatie moet blijven. Indien dit wel het geval was geweest, dan moest de desktopapplicatie aangepast worden. Tot slot moet de lay-out aangepast worden aan de mobiele toestellen. Osmobi verwijdert alle tabelstructuren uit de webpagina's, dus er moet zeker voor gezorgd worden dat alles opnieuw overzichtelijk geschikt wordt. De beschikbare CSS klassen kunnen aangepast worden en nieuwe klassen kunnen aangemaakt worden. Daarnaast kunnen de marges en de 'padding' ingesteld worden om een duidelijker beeld te creëren van wat bij elkaar hoort.

- 70 -

6 Testplan Deze gebruikerstesten hebben als doel na te gaan of de applicatie voldoet aan de wensen van de eindgebruiker. De resultaten van de testen kunnen gebruikt worden om probleemgebieden te definiëren en om gericht de werking van de applicatie te verbeteren.

6.1 Methodologie 6.1.1 Deelnemers 6.1.1.1 Studenten hoger onderwijs De eerste groep testgebruikers zijn personen die op dit ogenblik of in een recent verleden hogere studies volgen / gevold hebben. Deze groep moet de belangrijkste groep eindgebruikers simuleren, namelijk de studenten aan de Faculteit Economie en Bedrijfskunde. Deze personen worden geacht al enige ervaring te hebben met gelijkaardige webapplicaties. In de rest van het testplan zal deze groep aangeduid worden als de 'studenten'.

6.1.1.2 Andere Daarnaast is er een tweede testgroep, met personen die nog nooit een gelijkaardige webapplicatie gebruikt hebben. Zij moeten een tweede groep eindgebruikers simuleren, namelijk de toekomstige studenten aan de FEB en hun ouders. Het is namelijk belangrijk dat de applicatie van de studentenvereniging ook gemakkelijk te gebruiken is voor deze groep om potentiële leden niet al vroeg af te schrikken. Deze groep zal in de rest van het testplan aangeduid worden als de 'niet-studenten'.

6.1.2 Voorkennis en training Van zowel de studenten als van de niet-studenten wordt verwacht dat ze met een computer kunnen werken. Voor de desktopapplicatie zal dan met hen vlug even de gebuikte browser overlopen worden. De studenten zullen ook de mobiele applicatie testen. Liefst met effectieve toestellen, maar hoogst waarschijnlijk zullen we ons tevreden moeten stellen met emulatoren en simulatoren. Het specifieke toestel of de specifieke emulator/simulator zal kort overlopen worden, zodat kennis over de gebruikte technologie geen factor is in het testresultaat.

6.1.3 Procedure De testen zullen plaatsvinden in de computerlokalen van de FEB. De computers die daar beschikbaar zijn, zijn normaal gezien nooit ouder dan 3 jaar. De schermresolutie tijdens de testen moet verplicht op 1024x768 pixels staan, omdat de applicatie hiervoor geoptimaliseerd zou moeten zijn. Er zal getest worden op 4 verschillende browsers, namelijk Mozilla Firefox, Internet Explorer, Google Chrome en Opera. De mobiele toestellen die zullen getest worden, zijn de Android, de IPhone en de Nokia N60. Gedurende de hele procedure blijft er 1 medewerker per 10 testpersonen aanwezig, om de gebruikers bij te staan indien er problemen optreden. Deze medewerkers moeten ook notities maken van hoe de gebruikers zich gedragen tijdens de test. Er zijn immers altijd uiterlijke kenmerken van frustratie. - 71 -

De tijd die de testpersonen aan elk scenario spenderen wordt geregistreerd. Dit is één van de maatstaven voor de gebruiksvriendelijkheid. Elke testpersoon krijgt een vragenlijst mee, waarop de verschillende testen kort staan uitgelegd en waarop hij zijn bevindingen na iedere test kort kan neerschrijven. Eens hij elke test uitgevoerd heeft, kan hij op de vragenlijst ook zijn bemerkingen kwijt over het testproces in zijn geheel. De naam van de testpersonen komt niet op deze vragenlijsten, er wordt enkel gevraagd om een gebruikersnaam op te geven. De resultaten zijn volledig anoniem.

6.2 Functionele testen 6.2.1 De scenario's De verschillende functionaliteiten die getest worden, zijn al beschreven in de Use Case scenario's. Natuurlijk worden enkel de functionaliteiten getest die in het prototype verwerkt zitten. De personen die desktopapplicatie testen, zullen gevraagd worden om: • een account aan te maken (de gebruikersnaam moeten ze op de vragenlijst noteren) • een fotoalbum toe te voegen • een afbeelding op te laden in dat album (er zullen 15 afbeeldingen met verschillende afmetingen voorzien worden, waaruit de testpersonen vrij kunnen kiezen) • deze afbeelding te beoordelen • een commentaar bij deze afbeelding te plaatsen • te zoeken welke activiteiten op een bepaalde datum plaatsvinden De testpersonen van de mobiele applicatie zal gevraagd worden om: • de commentaar bij een bepaalde foto (waarvan exact wordt uitgelegd waar deze zich bevindt) te noteren • te zoeken welke activiteiten op een bepaalde datum plaatsvinden

6.2.2 De metrieken 6.2.2.1 Aantal afgeronde scenario's Elke test vraagt dat de testpersoon ofwel iets op de applicatie toevoegt ofwel dat deze data van de applicatie op de vragenlijst invult. Een scenario wordt als afgerond beschouwt wanneer de testpersoon zelf aanduidt dat hij klaar is. Wanneer de testpersoon tijdens het scenario zo veel hulp nodig heeft dat het scenario als kritieke fout kan geëvalueerd worden, wordt het scenario ook als afgerond beschouwt.

6.2.2.2 Kritieke fouten Een kritieke fout is elke afwijking van het beoogde doel wanneer het scenario als afgerond wordt beschouwd. De testpersoon kan zich al dan niet bewust zijn van deze afwijking. De bedoeling is dat elke testpersoon de volledige test doorloopt zonder hulp te vragen. Wanneer bij een scenario toch hulp nodig blijkt, is dit een reden om dat scenario als kritieke fout te evalueren. Het is ook mogelijk dat de testpersoon een actie uitvoert, waardoor het onmogelijk wordt om het beoogde doel nog te halen, ook dit wordt als kritieke fout beschouwt. - 72 -

6.2.2.3 Niet-kritieke fouten Dit is elke fout die een deelnemer op eigen houtje kan rechtzetten of een fout die door de gebruiker niet wordt waargenomen en geen afwijking geeft in het beoogde doel. Een voorbeeld hiervan is dat de testpersoon niet de meest optimale manier gebruikt om een scenario tot een goed einde te brengen.

6.2.2.4 Aantal clicks om het juiste onderdeel te bereiken Een belangrijke maatstaf voor de gebruiksvriendelijkheid van een applicatie is het aantal keer dat een testpersoon moet klikken om een bepaald onderdeel van de applicatie te bereiken. Bij elk scenario moet de testpersoon dit aantal opgeven.

6.2.2.5 Subjectieve evaluaties Door middel van de vragenlijst die elke testpersoon moet invullen, zal informatie verzameld worden over het gebruiksgemak en de tevredenheid. Deze zullen gemeten worden aan de hand van een 7-punts Likertschaal en mogelijkheid tot commentaar.

6.2.2.6 Benodigde tijd De tijd die de testpersoon nodig heeft om elk scenario uit te voeren wordt geregistreerd. Hierbij wordt de tijd die nodig was voor de evaluatie natuurlijk niet meegerekend.

6.2.3 Doelstellingen 6.2.3.1 Aantal afgeronde scenario's Het is de bedoeling dat elk scenario door elke testpersoon wordt afgerond.

6.2.3.2 Foutvrijheid Dit is het percentage van de scenario's dat wordt afgerond zonder ook maar één fout (kritiek en niet-kritiek). 90% van de studenten moet een bepaald scenario foutvrij kunnen afronden. 70% van de niet-studenten moet een bepaald scenario foutvrij kunnen afronden.

6.2.3.3 Aantal clicks om het juiste onderdeel te bereiken Op de desktopapplicatie moet een gemiddelde van 5 clicks nagestreefd worden. Op de mobiele applicatie moet een gemiddelde van 3 clicks nagestreefd worden.

6.2.3.4 Subjectieve evaluaties Het gebruiksgemak en de tevredenheid moeten gemiddeld minstens 5,5 / 7 halen.

6.2.3.5 Benodigde tijd De beoogde gemiddelde tijd moet vastgesteld worden bij het effectief uitwerken van de scenario's.

- 73 -

6.3 Kwalitatieve testen 6.3.1 Inlogmodules De beveiliging van de verschillende inlogmodules moet 100% gegarandeerd zijn. Het mag op geen enkele manier mogelijk zijn om als een gebruiker in te loggen zonder dat je het wachtwoord weet. De datatransfers tijdens de inlogprocedure moeten degelijk geëncrypteerd worden, zodat data veilig over het netwerk kan verstuurd worden.

6.3.2 Formulieren Elk formulier moet uitvoerig getest worden. Zo moet er nagegaan worden of de aanwezige CAPTCHA's wel altijd foute invoer tegen houden. Daarnaast moet er getest worden of de CAPTCHA niet gemakkelijk met herkenningssoftware of het doorlopen van de paginabron op te lossen is. Ook moet nagegaan worden of malafide invoer wel in elk veld van elk formulier tegengehouden of weggefilterd wordt, voordat het de databank kan aantasten.

6.3.3 XHTML validatie Er moest gestreefd worden naar zo veel mogelijk pagina die valideren als XHTML 1.0 Transitional. Alle pagina's moeten daarop dan ook getest worden. Dit kan online pagina per pagina, maar er moet gezocht worden naar een testsuite die dit in 1 keer kan.

6.3.4 Prestatie Via geautomatiseerd testen kan men zowel de prestatie van de desktopapplicatie als de prestatie van de mobiele applicatie nagaan. Bij de mobiele applicatie moet getest worden hoeveel: • throughput (down- en upload) er is • geheugen er op het mobiele toestel gebruikt wordt • rekenkracht er op het mobiele toestel gebruikt wordt Enkel de totale tijd die een pagina nodig heeft om te laden is van belang bij de desktopapplicatie.

- 74 -

7 Testresultaten De tijd om tests uit te voeren was zeer beperkt. Het is daarom niet gelukt om het testplan uit te voeren zoals het hierboven beschreven staat. Al de geïmplementeerde functionaliteiten werden wel getest, maar niet volgens het testplan. Sommige kwalitatieve testen kunnen daarenboven enkel uitgevoerd worden door benchmarks, externe bedrijven en/of personen die technischer meer onderlegd zijn. Deze vielen dan ook sowieso uit de boot. Tot slot waren alle testpersonen nu al bekend met de applicatie, zodat de navigatie niet grondig getest kon worden.

7.1 Desktopapplicatie 7.1.1 Functionele eisen 7.1.1.1 Front-end Bij het aanmaken van een account werkt de e-mailverificatie niet. Er wordt vermoedt dat dit komt doordat er geen mailserver ingesteld staat of omdat de juiste gegevens over de mailserver niet beschikbaar waren. De front-end van de applicatie heeft merkt dit wel niet, aangezien deze laat weten dat er wel een mail verstuurd werd. Deze functionaliteit staat nu voorlopig uit, zodat nieuwe gebruikers zich toch kunnen registreren.

7.1.1.2 Back-end Bij een vroegere versie van JoomGallery traden soms nog fouten op bij de 'Batch-Upload'. De grote versie van de afbeelding werd soms niet aangemaakt, waardoor op de 'foto' pagina er dus geen foto stond. De nieuwe versie heeft dit probleem opgelost. Daarbij zijn er op de back-end ook geen problemen meer met de functionaliteiten.

7.1.2 Kwalitatieve eisen 7.1.2.1 Inlogmodules De inlogfaciliteiten worden geleverd door Joomla! zelf en door een veel gebruikte component met plug-in. Alhoewel men de beveiliging niet uitvoerig kunnen testen heeft, mag men er toch van uitgaan dat dit wel in orde zijn.

7.1.2.2 Formulieren Het enige formulier dat publiekelijk toegankelijk is, is beveiligd met een CAPTCHA. Er wordt gebruik gemaakt van een bekende gratis service, namelijk reCAPTCHA [25] . Zij staan er toch om bekend dat ze heel sterk SPAM tegen houden. Bij de registratieformulier wordt vermeld dat de inhoud streng gecontroleerd wordt. Er wordt inderdaad gecontroleerd of er 2 maal hetzelfde wachtwoord ingegeven wordt en of een emailadres al aan een account gelinkt is of niet. Echter, zowel de gebruikersnaam als het wachtwoord mogen geen spaties bevatten. De applicatie geeft hier echter geen foutmelding op en zegt dat een activatiemail verzonden wordt. Er werd niet getest of malafide invoer de databank kan aantasten, maar Joomla! zou dit toch automatisch moeten filteren. Dat zou anders een groot beveiligingsrisico zijn voor miljoenen applicaties.

- 75 -

7.1.2.3 XHTML validatie Geen enkele pagina valideert als XHTML 1.0 Transitional. Zelfs een waar een 'Artikel' met enkel tekst wordt weergegeven telt 5 verschillende fouten. De enige conclusie is dat er in de template een aantal al iets fout loopt. Een albumpagina van het fotoboek genereert zelfs 53 fouten. Hier moet duidelijk nog aan gewerkt worden.

7.1.2.4 Prestatie Bijna elke pagina gedurende al de testen laadde binnen de seconde, zelfs diegenen met de afbeeldingen. Er was enkel af en toe een langere laadtijd wanneer een echt grote afbeelding op zijn ware grootte werd getoond. Deze kunnen tot 5 MB groot zijn, dus dat mag eigenlijk niet verwonderen. Hier kan niets aan gedaan worden, maar dat kan de gebruiker ook niet verwachten. Het probleem ligt bij de internetconnectie van de testpersonen.

7.2 Mobiele applicatie 7.2.1 Functionele eisen Zowel de kalender als het fotoboek worden vrij goed weergegeven op een mobiel toestel. Enkel bij de kalender zijn er nog redelijk wat witruimtes die niet via Osmobi weg te krijgen zijn. Ook bij de kalender lijkt de navigatie niet volledig op een rechte lijn te staan. Ook dit heeft men op allerlei manieren proberen oplossen, maar de oneffenheid bleef. Op de oude GSM's wordt de lay-out echt erbarmelijk. Deze toestellen herkennen immers geen CSS bestanden, waardoor de inhoud zowat willekeurig over het scherm staat. Elk onderdeel van de site kan binnen de 3 clicks bereikt worden.

- 76 -

7.2.2 Kwalitatieve eisen

Figuur 66 - Prestatie mobiele applicatie

Op http://ready.mobi kunnen de prestaties van een mobiele applicatie getest worden. Er wordt al een mooie score van 3,39/5 gehaald. 2 van de 7 'fails' komen door mobilisatie via de Siruna technologie. Dus over het algemeen mag gesteld worden dat de mobiele applicatie goed scoort.

- 77 -

8 Conclusie 8.1 Analyse Na een uitvoerige studie van 26 bestaande webapplicaties van studentenverenigingen is vastgesteld dat 23 daarvan al een dynamische webapplicatie hebben. Er is zelfs al een trend richting Content Management Systemen, zoals Joomla! en Drupal. Het mobiele internet is echter een nog bijna onverkend gebied voor deze verenigingen. Enkel de Vlaamse Economische Kring heeft een mobiele versie van zijn webapplicatie. Spijtig genoeg werkt daar op het moment van schrijven maar 1 onderdeel van zoals het hoort. Gezien de evolutie van de mobiele technologie zouden alle verenigingen hier toch beter werk van maken. Het is wel bemoedigend om vast te stellen dat qua inhoud de meeste verenigingen wel goed scoren. Bijna allemaal hebben ze een zeer goede basis, namelijk een duidelijke en gemakkelijk te gebruiken kalender, fotoboek en forum. De meer onderlegde kringen voegen daar nog een aantal functionaliteiten aan toe, zoals inschrijven voor activiteiten, online boeken bestellen, ... Het grote verschil zit hem echter in de back-end van de applicaties. De verenigingen die een CMS gebruiken zijn verzekerd van een goede back-end. De Vlaamse Technische Kring heeft zijn applicatie volledig zelf ontwikkeld, maar hebben toch de meest uitgebreide back-end en front-end. Een groot deel van de administratie, overdracht van kennis, ... wordt allemaal via de webapplicatie geregeld.

8.2 Desktopapplicatie Bij het ontwikkeling van het prototype is er voor gekozen om ook met een CMS te werken, namelijk met Joomla!. De belangrijkste reden om voor Joomla! te kiezen is de grote beschikbaarheid van gratis extensies. Hierdoor kan je al een zeer degelijke applicatie bouwen zonder enige kennis van onder andere php en SQL. Het enige waar je soms wat aan moet werken zijn de CSS bestanden, omdat de beschikbare templates niet altijd 100% bij jouw concept passen. Het is dus duidelijk dat met behulp van een CMS bij wijze van spreken iedereen de dag van vandaag een dynamische webapplicatie kan onderhouden en misschien zelfs opzetten.

8.3 Mobiele applicatie Via een plug-in voor Joomla!, namelijk Osmobi, wordt de desktopapplicatie zonder veel moeite omgevormd tot een mobiele applicatie. Via een gemakkelijk gebruikersinterface op de Osmobi website kan je irrelevante content verwijderen en de overblijvende content herschikken. Het menu wordt aangepast en de CSS wordt gemanipuleerd om de lay-out aan het kleinere scherm aan te passen. Ook dit kan met weinig technische kennis. Enkel de klassen van de CSS aanpassen vergt eigenlijk HTML kennis. Alle andere delen worden meer dan goed genoeg uitgelegd tijdens het mobilisatieproces. Een onafhankelijke prestatietest laat weten dat de mobiele applicatie 3,39 op 5 scoort.

- 78 -

9 Bijlagen 9.1 Bijlage A - Afbeeldingen 'State of the Art' analyse

Figuur 67: Sponsors nemen het volledig centrale inhoudsgedeelte van de startpagina in - Dentalia [3]

Figuur 68: Sponsors nemen bijna de volledige startpagina in - VEK [33]

- 79 -

Figuur 69: 'Menu' - KMF [17]

- 80 -

Figuur 70: Submenu - VTK [39]

Figuur 71: Kalender - Filologica [7]

- 81 -

Figuur 72: Kalender - VLK [37]

- 82 -

Figuur 73: Kalender - VEK [33]

Figuur 74: Lijst van activiteiten - VGK [34]

- 83 -

Figuur 75: Lijst van activiteiten - selectie van wat je wil zien - WiNA [41]

Figuur 78: Kalender Block Element Filologica [3] Figuur 77: Kalender Block Element VEK [33] Figuur 76: Kalender Block Element - Farmacie [9]

Figuur 79: Fotoboek VDK in Drupal - slecht ingestelde plug-in [32]

- 84 -

Figuur 80: Fotoboek VBK - slecht ingestelde plug-in [31]

Figuur 81: 'You Are Here' referentie Farmacie [9]

- 85 -

9.2 Bijlage B - Figuren Proof of Concept

Figuur 82 - Instellingen JoomGallery: General Settings -> Paths and Directories

- 86 -

Figuur 83 - Instellingen JoomGallery: General Settings -> Replacements

- 87 -

Figuur 84 - Instellingen JoomGallery: General Settings -> Image Processing

- 88 -

Figuur 85 - Instellingen JoomGallery: General Settings -> Backend-Upload

- 89 -

Figuur 86 - Instellingen JoomGallery: General Settings -> Additional functions

- 90 -

Figuur 87 - Instellingen JoomGallery: User Access Rights -> User Upload

- 91 -

Figuur 88 - Instellingen JoomGallery: User Access Rights -> Ratings

- 92 -

Figuur 89 - Instellingen JoomGallery: User Access Rights -> Comments

- 93 -

Figuur 90 - Instellingen JoomGallery: Frontend Settings -> Picture Ordering

Figuur 91 - Instellingen JoomGallery: Frontend Settings -> Page Title

- 94 -

- 95 -

Figuur 92 - Instellingen JoomGallery: Frontend Settings -> Header and Footer

Figuur 93 - Instellingen JoomGallery: Frontend Settings -> User Panel

- 96 -

Figuur 94 - Instellingen JoomGallery: Frontend Settings -> Popup Functions

- 97 -

Figuur 95 - Instellingen JoomGallery: Gallery View

- 98 -

Figuur 96 - Instellingen JoomGallery: Category View -> General Settings

- 99 -

Figuur 97 - Instellingen JoomGallery: Category View -> Sub-Categories

- 100 -

Figuur 98 - Instellingen JoomGallery: Toplist

- 101 -

Figuur 99 - Instellingen JoomGallery: Favourites

- 102 -

10 Referenties [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38]

Chemica: http://fkserv.ugent.be/chemica Community Builder: http://www.joomlapolis.com Dentalia: http://www.dentalia.be Drupal CMS: http://www.drupal.org Ekonomika (Economie Leuven): http://www.ekonomika.be Extended Guidelines for Mobile Web Best Practices; 2009; http://www.w3.org/TR/mwbpguidelines Filologica: http://www.filologica.be GBK: http://www.biologie-gent.be GFK: http://www.gentsefarmakring.be Geografica: http://www.geografica.be Geologica: http://www.fkgent.be/geologica/index.php HILOK: http://www.hilokgent.be IBBT: http://www.ibbt.be JEvents: http://www.jevents.net JoomGallery: http://www.en.joomgallery.net Joomla! CMS: http://www.joomla.org KMF: http://www.kmfgent.be KHK: http://fkserv.UGent.be/khk Lombrosiana: http://www.lombrosiana.be Mobile Web Application Best Practices; 2010; http://www.w3.org/TR/mwabp Mobile Web Best Practices 1.0; 2008; http://www.w3.org/TR/mobile-bp OAK: http://fkserv.UGent.be/oak Osmobi: http://www.osmobi.com Politeia: http://www.politeia-gent.be reCAPTCHA: http://recaptcha.net Siruna: http://www.siruna.com Slavia: http://www.slavia-gent.be UGent: http://www.ugent.be UGent Centrale Authenticatieservice: http://helpdesk.ugent.be/webhosting/cas.php VRG: http://www.vrg-gent.be VBK: http://fkserv.ugent.be/vbk VDK: http://www.vdk-diergeneeskunde.be VEK: http://www.vek.be, http://i.vek.be VGK (geneeskunde): http://www.vgk-online.com VGK (geschiedenis): http://www.vgkgent.be VLAK: http://www.vlak.be VLK: http://www.boerekot.be VPPK: http://www.vppk.be - 103 -

[39] [40] [41] [42]

VTK: http://www.vtk.ugent.be w3schools: http://www.w3schools.com/browsers/browsers_display.asp WiNA: http://wina.ugent.be Why the magic number seven plus or minus two; T.L. Saaty & M.S. Ozdemir; Mathematical Computer Modelling Vol 38, Issues 3-4, August 2003, p233-244

- 104 -