UNIVERSITY OF BOTSWANA DEPARTMENT OF COMPUTER SCIENCE

GigFinder: A Drupal-based event creation, registration, and broadcast system Mohammed Shehu 200900975 Supervisor: Dr. P. A. Mokotedi Date: April 2013
Page 1 of 53

GigFinder: A Drupal-based event creation, registration, and broadcast system Mohammed Shehu (200900975)
A Project Submitted In Partial Fulfilment of the Requirements for the Award of a Degree in Computer Science of the University of Botswana of the University of Botswana

DATE: APRIL 2013

Page 2 of 53

Certification Abstract
Event management is an activity that requires an effective and efficient way of marketing or broadcasting events to target audiences. In this project report, we look at a new system of creating, listing, categorizing, and broadcasting events: GigFinder. This report discusses its basic functional requirements, the underlying architecture, added functionality (in the form of modules), the methodology, design, test cases done, implementation details and a conclusion.

Page 3 of 53

Table of Contents
Certification .................................................................................................................................... 3 Abstract ........................................................................................................................................... 3 Table of Figures .............................................................................................................................. 6 1. INTRODUCTION ...................................................................................................................... 7 1.1 Project Definition .................................................................................................................. 7 1.1.1 Project Overview: Introduction to the study. ................................................................. 7 1.1.2 General and Specific Objectives. ................................................................................... 7 1.1.3 Scope (including target users) ........................................................................................ 8 1.1.4 Project Schedule............................................................................................................. 8 1.1.5 Resources ....................................................................................................................... 9 1.2 Methodology ......................................................................................................................... 9 1.3 Definition/Explanation of key terms and concepts, where applicable. ............................... 10 2. LITERATURE REVIEW/SURVEY ........................................................................................ 11 2.1 Benefits ............................................................................................................................... 11 Easy registration.................................................................................................................... 11 Secure Payments ................................................................................................................... 11 More Attendees ..................................................................................................................... 11 Custom Registration Pages ................................................................................................... 11 Custom Reporting ................................................................................................................. 12 2.2 Facebook Events Invite ....................................................................................................... 12 2.3 Twitter ................................................................................................................................. 12 2.4 LinkedIn and Google Plus .................................................................................................. 12 2.5 Blogging .............................................................................................................................. 13 2.6 More benefits of an online Event Registration system ....................................................... 13 3. SYSTEM INVESTIGATION & ANALYSIS .......................................................................... 15 3.1 Functional/Processing Requirement Analysis .................................................................... 15 3.2 Data Analysis ...................................................................................................................... 15 3.2.1 Data reading and writing .............................................................................................. 17 3.2.2 Data storage (databases, file systems) ......................................................................... 17 3.3 Input Requirement Analysis ............................................................................................... 17 3.4 Output Requirement Analysis ............................................................................................. 17 3.5 Interface Requirement Analysis .......................................................................................... 18 3.6 Dynamic model specification of the system ....................................................................... 20 Page 4 of 53

3.6.1 User Registration ......................................................................................................... 20 3.6.2 Event Creation ............................................................................................................. 20 3.6.3 Event Signup ................................................................................................................ 21 3.6.4 Registrant Notification ................................................................................................. 21 4. DESIGN .................................................................................................................................... 22 4.1 Functional design specification........................................................................................... 22 4.1.1 Processing .................................................................................................................... 22 4.1.2 Communication ............................................................................................................ 22 4.1.3 APIs.............................................................................................................................. 23 4.2 Interface Design specification............................................................................................. 23 4.3 Input design specification (forms, etc.)............................................................................... 26 4.4 Output design specification (report layouts). ...................................................................... 27 4.5 Database/file and data structures design specification........................................................ 27 Global data structure ............................................................................................................. 27 Temporary data structure ...................................................................................................... 27 Database description ............................................................................................................. 27 5. IMPLEMENTATION AND EVALUATION .......................................................................... 28 5.1 Implementation Environment: ............................................................................................ 28 5.2 Documentation: ................................................................................................................... 28 5.2.1 Detailed description of specific program modules and associated data files/ database implemented on the system design. ...................................................................................... 28 display.info................................................................................................................................ 29 display.module .......................................................................................................................... 30 display_help .......................................................................................................................... 31 display_block_info ................................................................................................................ 31 display_block_view .............................................................................................................. 32 Queries .................................................................................................................................. 32 Theming ................................................................................................................................ 32 5.2.2. User Manual: Detailed description of how to use the implemented system ............... 33 5.3 System Testing: ................................................................................................................... 33 5.4 System Evaluation: ............................................................................................................. 33 5.4.1 Strengths & Limitations ............................................................................................... 34 6. CONCLUSION ......................................................................................................................... 35 APPENDICES .............................................................................................................................. 36 APPENDIX A: Detailed description of specific program modules.......................................... 36 Page 5 of 53

APPENDIX B: User Manual .................................................................................................... 39 APPENDIX C: Testing Summary ............................................................................................ 49 REFERENCES ............................................................................................................................. 52

Table of Figures
Figure 1: GigFinder Class Diagram .............................................................................................. 16 Figure 2: A snapshot of the Event Calendar page......................................................................... 18 Figure 3: A snapshot of the log out link, also showing current online users ............................ 19 Figure 4: A snapshot of the Event Creation page ......................................................................... 19 Figure 5: DFD of GigFinder Registration Process ....................................................................... 20 Figure 6: GigFinder Event Creation DFD .................................................................................... 20 Figure 7: GigFinder Event Signup DFD ....................................................................................... 21 Figure 8: GigFinder Registrant Notification DFD ........................................................................ 21 Figure 9: The Compression Process ............................................................................................. 22 Figure 10: Communication between client and server ................................................................. 23 Figure 11: A snapshot of the home page ...................................................................................... 24 Figure 12: A snapshot of an event description page ..................................................................... 25 Figure 13: A snapshot of the event creation page ......................................................................... 26 Figure 14: Snapshot of custom module-created blocks ................................................................ 28 Figure 15: Snapshot of the 4 links visible to Visitors ................................................................... 40 Figure 16: Snapshot showing some of the listings on the site ...................................................... 41 Figure 17: Snapshots showing the Navigation and Login boxes .................................................. 41 Figure 18: Snapshot showing the footer as seen by Visitors ........................................................ 42 Figure 19: Snapshot of the Calendar ............................................................................................. 43 Figure 20: Snapshot of the Contact Page ...................................................................................... 44 Figure 21: Snapshot of the Create New Account Link ............................................................. 45 Figure 22: Snapshot of new user account creation ....................................................................... 45 Figure 23: Snapshot of the header as seen by Registered Members ............................................. 45 Figure 24: Snapshot of the Add Event link ............................................................................... 46 Figure 25: Snapshot of the Title, Event Type & Date fields ........................................................ 46 Figure 26: Snapshots of the Price and Venue fields ..................................................................... 47 Figure 27: Snapshot of the Event Body & Summary text fields................................................... 47 Figure 28: Snapshot of Event Banner upload box ........................................................................ 48 Figure 29: Snapshot of Event Capacity text field ......................................................................... 48 Figure 30: Snapshot of default Signup settings ............................................................................ 48 Figure 31: Snapshot of Save and Preview buttons ................................................................ 48

Page 6 of 53

1. INTRODUCTION
This chapter outlines the project aims and sets its context. The reader should be able to gain a clear picture of what area the project is in, the rationale for doing the work, the aims of the project and the approach that has been taken.

1.1 Project Definition

Event management is the application of project management to the creation and development of festivals, events and conferences. It involves studying the intricacies of the brand, identifying the target audience, devising the event concept, planning the logistics and coordinating the technical aspects before actually launching the event (Ramsborg, Miller, Breiter, Reed, & Rushing, 2008).

1.1.1 Project Overview: Introduction to the study.

Young adults with healthy social lives usually undergo a familiar routine during weekends, whereupon they call or text their peers to find out what events are taking place on that particular night. The desire to have a central point where this target audience could check to see exactly what the night has in store for them was the main motivation behind the building of this website. The decision to have it on an online platform was due to the fact that modern research indicates that a majority of the targeted young adults spend a significant amount of time online - an average of 16 hours per month (Go-Gulf, 2012). This points to the conclusion that in order to ensure the maximum reach among this target demographic, the system would have to be easily accessible via such implements as smart-phones and tablets, as well as desktops for those with home/institutional internet access.

1.1.2 General and Specific Objectives.

The System should: Allow people to create events, complete with text, banners/flyers, contact information, and Google Maps direction information, if available. Allow visitors to an event page (hereby known as Visitor(s)) to register, or RSVP, for the event. Allow event creators to reserve the right to registration, i.e. Moderation. Offer different levels of access to the editing section of an event, based on permission rights of the Members. Allow an event node (every piece of content on a Drupal site is known as a node) to take guest contact details, and to disseminate information/reminders via SMS and/or email. Display a Calendar of Events, populated with some of the user created events. Clicking on an event should take the user to the events page, where they can view details, register for the event, contact the hosts/organizers, etc. Allow for Facebook integration: a majority of users already have Facebook accounts, and so it would make the sign-up process easier if they could just use their accounts to sign up for membership to the site. If possible and within time constraints, have a mobile version of the system deployed that can be accessed on any capable mobile phone browser.

Page 7 of 53

1.1.3 Scope (including target users)

This project will mainly cover the Web-design domain, specifically in the Drupal Content Management System area, with a touch of E-commerce and Internet Marketing. It will involve coding in the form of creating new Drupal modules to improve the sites form/functionality; this is mainly done in PHP. The e-commerce aspect, as outlined above, will appear in the form of membership fees for users who wish to use some of the more enhanced features of the site (e.g. increased limit of attendees for any one event, additional social media integration, etc.). For internet marketing, this will come in the form of advertising columns on the site for other companies who wish to expand their presence on the site. This could also come from Google Ads, and over the course of the project I will determine how best to integrate ads into the site to minimize clutter and avoid hampering the main content, i.e. the events themselves. This will mainly be done in HTML and JavaScript, and some PHP might be involved.

1.1.4 Project Schedule

The project schedule is as follows:
Task Task Name # 1 Download & Install Drupal 2 Configure System Modules 3 Configure EventRelated Modules 4 Testing 5 User Evaluation 6 Exporting & Creation of Portable Copy of System 7 Final Tests & Uploading Onto Local Server 8 Documentation 9 Submission 10 Final Presentation Duration Start Date 1 5 7 65 23 1 1/1/2013 8:00 /2013 8:00 1/7/2013 8:00 1/15/2013 8:00 1/23/2013 8:00 2/28/2013 8:00 2/28/2013 8:00 3/18/2013 8:00 4/15/2013 8:00 4/22/2013 8:00 Finish Date Dependency % Complete 1/1/2013 N/A 100 16:00 1/8/2013 1 100 16:00 1/15/2013 1 100 16:00 4/15/2013 1, 2, 3 100 16:00 2/22/2013 4 0 16:00 2/28/2013 4 100 16:00 3/6/2013 16:00 3/22/2013 16:00 4/19/2013 16:00 4/26/2013 16:00 6 100

5 5 5

5 8 9

100 0 0

Table 1: Project Schedule

Page 8 of 53

1.1.5 Resources
The implementation of this system will take place entirely using Drupal 7, as opposed to Joomla, WordPress, or other CMSes, mainly because Im better versed in Drupal than the others, and also because Drupal has some powerful modules that will help in the implementation of the System. Furthermore, Drupal has a wide support base made up of many open source programmers worldwide that can be queried should I run into any hitches. Drupal, by default, will require knowledge of PHP, MySQL and HTML, and so these web technologies will inevitably be employed in the course of the installation and configuration of the Drupal site itself. The Drupal installation to be used in the creation of the site will be nestled under the XAMPP web development environment, which can be installed on either a Linux or Windows operating system. Since the site will be hosted online and most web servers use Linux, my knowledge of Linux OS, with regards to web development (both cultivated during my 3month stint at DCDMC, an IT consulting company), will come in handy. In all, these are some of the major resources that will be used: A Linux/Windows workstation, in order to test some of the modules and functionality before uploading them to a local hosting server.

1.2 Methodology
For this study, Literature review and Web searching were employed in determining the suitable software engineering approach for this project, a position which eventually fell to Iterative and Incremental development. In addition to those two, a case study of other event management websites, as well as other Drupal-based websites was carried out in order to acquire a general knowledge of how the final website was going to look and perform. The easy navigation and allround easier maintenance of Drupal was weighed against the steep learning curve, and it was finally determined that the benefits far outweighed the risk. Iterative and Incremental development is at the heart of a cyclic software development process developed in response to the weaknesses of the waterfall model. It starts with an initial planning and ends with deployment (implementation) with the cyclic interactions (i.e. analysis, design, etc) in between. Iterative development assumes we will make mistakes, we will need feedback, and we will need several iterations before we get it right, as this process takes into account the reality that we almost never get anything completely right the first time. At first, we will get a lot of feedback. Gradually, with each iteration, the output from each phase stabilizes and we need to do less rework. Both iterative and incremental development are essential parts of the various agile software development frameworks. The basic idea behind the agile method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. Page 9 of 53

The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase. The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a critical iterative project a formal Software Design Document may be used. The analysis of each iteration is based upon user/self-feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results. Because the System will consist of several modules working in tandem to achieve the final objectives, a lot of testing will take place in order to perfect the functionality of the site. Each new module added will have to be tested for bugs, speed, performance and a host of other factors, including clashes with other already installed modules. Thus, this methodology is ideal for the System, as it ensures that constant feedback is gainfully employed in determining which modules to use and which to discard.

1.3 Definition/Explanation of key terms and concepts, where applicable.

PDA - Personal Digital Assistant; a portable computing device. Creator A person who creates an event on GigFinder Visitor A person who signs up for an event on GigFinder GigFinder Refers to the name of the Drupal-based event creation, registration, and broadcast system. More importantly, the front-end website used to manipulate it. Database Refers to the MySQL database which contains all information about the GigFinder modules installed, the users (creators and visitors) in the system, and the events and all their corresponding details.

Page 10 of 53

2. LITERATURE REVIEW/SURVEY
According to Fryatt (2012), marketing on social media can be a very sticky proposition. It's not like the old days of broadcast marketing when you could just throw money into advertising to push your message to thousands or even millions of people and expect that name recognition alone would do the trick (Fryatt, 2012). It therefore follows that the event creation and management process has to be approached from a more robust perspective. A person who wants to organize an event, conference, seminar or faces a large workload. To organize an event, paper work, the creation and sending of invitations and the registration of people will have to be performed (Eventish, 2011). Big events require even more resources (Publisher, 2011), such that nowadays, an increasing number of event organizers opt for comprehensive online event registration and event management software solutions to make use of the inherent economic savings. These fully featured event management solutions suit all kinds of event planners with various requirements (Ann, 2011). Some of the main benefits of online event registration and online event management are as follows:

2.1 Benefits Easy registration

Online event management software and/or websites make it easier for attendees to sign up. It is both easy and convenient for prospective attendees to register at any time and from anywhere in the world (Ann, 2011).

Secure Payments
Event planners face a real challenge with payment processing. To avoid problems, online registration websites provide secure payment opportunities that support multiple payment gateways. As a result, organizers can sell tickets online and the registrants have multiple payment options to choose from (Ann, 2011).

More Attendees
Online event management services provide organizers with several key features that boost attendance. There are a lot of event promotion tools available to help them spread the word about their event, including press releases, guest blog posts and video & image sharing sites (Odden, 2010). The more people hear about the event, the more attendees they will have (Ann, 2011).

Custom Registration Pages

Organizers may add their brand logo and use specific themes to create professional looking registration pages in just a few minutes (Ann, 2011).

Page 11 of 53

Custom Reporting
Event organizers gain the ability to evaluate the success of their events. This enables them to access different reports from anywhere at any time, which helps in planning upcoming events (Ann, 2011). It is also possible to store report information online to you be easily accessed in the future (Zeik, 2011). There are several avenues that a prospective event organizer can use to advertise their event. These are explained in the following subsections.

2.2 Facebook Events Invite

The Facebook events page is a great tool to get people to sign up or at least take notic e of ones events, where they can find out more for themselves (CerVentus, 2009). In order to successfully promote events with social media and particularly via Facebook, exact goals need to be set and a strategy needs to be defined to reach them (Publisher, 2011). But whatever the goal, there are 5 ways to take advantage of the Facebook Event feature: 1. The creation of a fan page for the event with a custom Welcome tab encouraging users to like the page. It is important that this process be done well in time in order to maximize awareness. 2. The creation of an event inside the fan page, filling it with information, details and a link to the website and/or ticketing platform. 3. The sending out of RSVP invitations to the Facebook friends and page fans. 4. The addition of a like box and a share button on the event website. 5. Cheap, incredibly effective and targeted Facebook ads (Publisher, 2011).

2.3 Twitter
Though Facebook is the market leader in social media (Sharma, 2012), (Ohm, 2012) & (Kallas, 2012) , some swear by Twitter as the best way to promote events with social media even though one will need to invest more time and effort in Twitter promotion than that of Facebook (Publisher, 2011). The steps involved are as follows: 1. The creation of a unique event hashtag. 2. Not overwhelming followers with too many ad tweets 3. Asking for Retweets in order to reach more prospects. (Again, not to be overdone). 4. The sharing of exclusive content and giveaways. 5. The promotion of events with social media live, i.e. tweeting interesting info during the actual event.

2.4 LinkedIn and Google Plus

Although not as powerful as the latter two, LinkedIn and the newcomer Google Plus have a plenty tools to promote events with social media. LinkedIn can be used to create events and Page 12 of 53

invite connections; note that once someone RSVPs to your event, it shows up on the home profile of everyone that that person is connected to, further spreading the message. Google Plus can also be utilized by creating a business page for the event and sharing it with the organizers circles, as well as placing G+ and +1 icons on the website (Publisher, 2011).

2.5 Blogging
Another way to promote events with social media is blogging. Topics should preferably be about the website, and it should share news, info, details, photos and anything connected with the event (Publisher, 2011).

The abovementioned methods are all good ways to reach out to ones desired audience when it comes to event creation and promotion, but for the purposes of this project, we will stick to using a simple Drupal website to create and promote events. Eschewing the other methods does not limit the benefits that can be attained, because due to Drupals inbuilt capacity to be extended using user-contributed modules, the Facebook Event aspect and Twitter connectivity can be added into the site.

2.6 More benefits of an online Event Registration system

Online registration not only improves efficiencies and eliminates unnecessary paperwork, but also maximizes participation and improves marketing capabilities while allowing participants to sign up when and where it is most convenient for them from any Internet-enabled computer (Active Network, n.d.). For event organizers, extra benefits include time-saving, free/paid online registration and secure online payment processing 24/7, while for the participants, they benefit from improved customer support, access to discounts and the ability to receive emails and other types of notifications (Active Network, n.d.). To achieve all this, one needs to make use of a software development methodology that allows for rapid changes to the base Systems code based on feedback. Since this is designed to be a mostly interactive system, each of the interactive functionalities have to be tested as soon as theyre integrated into the system by way of modules. Thus, a methodology that calls for the whole system to be completed before it can be tested, such as the traditional Waterfall method, will not suffice. A more feasible option would be the Agile Software Development Methodology. Agile is one of the big buzzwords of the IT development industry (Waters, 2007). Coined by the Agile Manifesto in 2001 (Beck & al, Manifesto for Agile Software Development, 2001), it is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, crossfunctional teams (Wikipedia, 2012). It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change (Wikipedia, 2012). Agile methods break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames (time boxes) that typically last from Page 13 of 53

one to four weeks. Each iteration involves a cross functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration (Beck, Embracing Change with Extreme Programming, 1999). Multiple iterations might be required to release a product or new features. According to (Ambler, n.d.), some of the valued features of Agile Development include the following: Individuals and Interactions in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming. Working software working software will be more useful and welcome than just presenting documents to clients in meetings. Customer collaboration requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.

Responding to change agile development is focused on quick responses to change and continuous development.

Page 14 of 53

3. SYSTEM INVESTIGATION & ANALYSIS

3.1 Functional/Processing Requirement Analysis
Minimally, the System should: Allow for user registration on the site Accept relevant Event details as input, such as title, date, price, etc Be able to store and retrieve said Event details for display to screen Allow event creators to reserve the right to registration, i.e. Moderation. Offer different levels of access to the editing section of an event, based on permission rights of the Members. Allow an event node (every piece of content on a Drupal site is known as a node) to take guest contact details, and to disseminate information/reminders via SMS and/or email. Allow for Facebook integration: this would make the sign-up process easier. Display a Calendar of Events, populated with some of the user created events. Clicking on an event should take the user to the events page, where they can view details, register for the event, contact the hosts/organizers, etc. For development, the System will minimally require the following: PHP 5.2+ MySQL 4.0+ Apache Web Development Environment Drupal 7.0 CMS

3.2 Data Analysis

Any file/database requirements there are should be documented. GigFinder consists of four main classes, namely the Visitor, Creator, Event and Admin classes, of which the Event class is the most pertinent with regards to the purpose and functionality of the system. Following below is the class diagram pertaining to the system:

Page 15 of 53

Figure 1: GigFinder Class Diagram

Visitor The Visitor class contains the username and password attributes, which are both string-based. The username of the Visitor entity is a unique one site-wide, and acts as a primary key during sorting. The password used has to be at least 6 characters long in order to improve user profile security. The profile picture attribute is an optional one, and takes in a file of type jpg, png or gif. The maximum file size is 10MB. The canCreateEvent attribute is used to categorize the different profile types on the site into groups of who can create events and who cannot. The Visitor class does not allow for the profile owner to create events, but allows one to sign up for an event.

Creator Similar to the Visitor class, the Creator class is different in that it does allow one to create and delete events that one has created. A Creator cannot delete the events created by another user. In addition, a creator can view a list of all the events that they have created. Admin The Admin class contains all the capabilities of the Creator, except that an Admin can view and delete ALL files on the site, if they so choose. Event The most important class of all, the Event class consists of a Title (a unique one used to identify the event), Date (the start and end dates of the event. The end date is optional), Time (start and Page 16 of 53

optional finish time), Venue, Price, Capacity (where 0 means an unlimited amount) and Banner (a compulsory field where the Creator uploads an image file subject to certain size and format restrictions).

3.2.1 Data reading and writing

A large chunk of the input that the System will work with will be provided by the user (Member), using a keyboard/any other acceptable form of text input. This information will include event details, such as the description, the associated banner, the time and venue of the event, as well as any pertinent contact details. All this information will be written to a server-side MySQL database, and when the details are to be displayed to the screen, all information will be read from the database and aggregated by Drupal according to the node IDs, where the node refers to the event in question.

3.2.2 Data storage (databases, file systems)

During installation of Drupal, choices of which type of database to use are offered. These choices include MySQL, PostgreSQL, SQLite, and more. With GigFinder, we will be using a MySQL database for the purposes of this project. This is because it is a widely recognized and utilized database type, and allows for the system to be ported to different OS environments (e.g. Windows, Linux or Mac).

3.3 Input Requirement Analysis

Inputs: Title of Event to be created Date, venue and time of Event Maximum number of allowed registrants Contact details of Event creator Event banner Google Maps information pertaining to location of the venue (optional)

3.4 Output Requirement Analysis

A listing of the event on the main page, after reading the stored inputs from the Systems database A display of the location of the Event venue, assuming correct Google Maps longitudes and latitudes Text remainders to registrants, depending on the settings specified by the Members (Event creators)

Page 17 of 53

3.5 Interface Requirement Analysis

As defined in Section 1.3 of this document, the system will cater to two main types of users: Creators (who create the events that are displayed on the site), and Visitors (who view and sign up for the events). As such, the Visitor interface requirements are as follows: Ability to view all listed events in an organized, coherent form (e.g. bullet-pointed listing of events) Ability to click on individually listed events in order to find out more information about them. Ability to view all events on the Event Calendar, and to click on event days on the Calendar, which subsequently lead to more detailed information on the selected event.

Figure 2: A snapshot of the Event Calendar page

In addition to the abovementioned abilities, the Creator interface requirements would be expanded to include the following: The ability to log in and out of their user accounts on the site

Page 18 of 53

Figure 3: A snapshot of the log out link, also showing current online users

The ability to create an event through a specialized interface that allows for the insertion of elements necessary to any event (e.g. banner image, venue and price information, date, and time). The ability to edit a previously created event, either for correctional purposes or to update users on changes to the event. The ability to delete a previously created event. Note that all creators have the right to delete their events, and the site administrator has the right to delete the creation of any event on the site, if deemed necessary.

Figure 4: A snapshot of the Event Creation page Page 19 of 53

3.6 Dynamic model specification of the system 3.6.1 User Registration

The registration process on the website is captured in the following data flow diagram:

Figure 5: DFD of GigFinder Registration Process During registration, a normal user (Visitor) is prompted to specify a username and password, as well as to upload an image that will be used as a profile picture. This information is stored in the database and is subsequently access when the user logs in to their profile.

3.6.2 Event Creation

The event creation process is summarized through the following data flow diagram:

Figure 6: GigFinder Event Creation DFD

Once a Visitor has registered to become a member on the site (Creator), they gain the ability to create events to be listed on the website. The process involves the specification of the event Title, Event Type, Date, Time, Venue, Price, Capacity, and Banner. All information Page 20 of 53

pertaining to the event is stored in the sites database, and from there retrieved to be listed as a new event on the home page or Event Listings page.

3.6.3 Event Signup

The event sign-up process on GigFinder is summarized below:

Figure 7: GigFinder Event Signup DFD A user on the site first open the Event Description page for a particular event and clicks on the Signup link at the bottom. Note that this process can be bypassed by simply clicking the link directly in the events teaser box on the home page. This then takes them to a page where they Create a Signup, and that change is then reflected in the database by incrementing the signup figure for that particular event. All event signups can be managed by the creator of the event.

3.6.4 Registrant Notification

The notification feature, wherein an event registrant is notified of updates to the event via email and/or text, is summarized as follows:

Figure 8: GigFinder Registrant Notification DFD To manage signups, an event creator first enters the administrative area of their profile and lists all signups for a particular event. From this panel, the Creator may choose to delete registrants as necessary. Furthermore, the Creator may notify event registrants via email or text as to updates on the event itself. Page 21 of 53

4. DESIGN
4.1 Functional design specification 4.1.1 Processing
The system will perform a number of processing functions, outlined as follows: Compression: Since each event (node) will come with the option of uploading a banner image to represent the event, it is necessary that the System compresses the images before uploading, in order to save disk space on the file-system. This also has the added benefit of improving loading times of webpages.

Figure 9: The Compression Process Calculation of Statistics: Each event will have a text field showing the number of people who have signed up to the event as at that particular point in time. This helps to give an idea of how popular an event is, and/or whether there is still space for new registrants/guests. Depending on available functionality, a countdown of days till the event can also be integrated in order to give a visual representation of the impending date of the event. Searching: A search bar will be added on each page of the site, in order to facilitate the searching of any events on the site that have been created. Searching will be done using name/keyword(s), and will be performed by doing a sweep of the database to find any matches. Sorting: Listing of events on the main page will be done according to descending chronological order, i.e. from the latest created events going backwards. In other words, new events will be listed first before older ones.

4.1.2 Communication
Because the System will be web-based, an element of networking comes into play. Information requested from the system will be sent through the Internet, utilizing both the IP address of the client (user) and server. A small diagram illustrated the process:

Page 22 of 53

Figure 10: Communication between client and server

4.1.3 APIs
Drupal is mostly PHP and HTML based, and so extensive usage of the PHP API will be employed in all areas, most especially the processing and communication aspects. This is because webpages generated by Drupal are done using PHP (and HTML, to an extent), which maximizes security and flexibility: new information can be appended to dynamically created web pages on the fly. In addition, some of the features considered for addition (like the countdown ticker) will require extensive use of JavaScript and Flash.

4.2 Interface Design specification

The user interface of the GigFinder will be divided into three main sections: The Home Page, the Event Description Page and The Event Creation/Editing Page. The Homepage will list ALL the Events created so far, as well as a truncated version of their descriptions showing only the date, time, venue and contact details.

Page 23 of 53

Figure 11: A snapshot of the home page As can be noted from the above snapshot, the events already created will be displayed in a grid format, with three events per row. The title for each event (which doubles as a link to its description page) is places at the top of the events respective display box. The event banner follows directly below, and the summary of the events details are next (e.g. date and time). An option to sign up for the event is placed at the bottom of the display box, and at the bottom right of the display box is a button titled Read More, which redirects to the event description page.

The Event Description Page of any one Event will contain more information than that shown in its teaser on the Home Page. This page will allow for a longer description, as well as any further pertinent information that the creator wishes to be known by potential attendees.

Page 24 of 53

Figure 12: A snapshot of an event description page This page also lists the user that submitted the event for listing (in this case, the admin), and also allows one to add a new event depending on whether that user has the correct site privileges (i.e. is a signed up user).

The Event Creation/Editing Page is the most important as this is where all Events will be created before they are posted. It will provide fields where the necessary information about an event can be filled in, such as text fields for the name, venue, and contact details, and a compulsory image field that will allow a creator to upload an Event banner which improves visibility of the Event on the Home Page. This page will also double as the editing page in the event that the creator clicks on the appropriate button (essentially an Edit Event button), wherein the information initially entered can be altered according to the creators wishes.

Page 25 of 53

Figure 13: A snapshot of the event creation page

4.3 Input design specification (forms, etc.)

A tabulated summary of the input design specification follows below: Page Homepage Calendar Element Search box Login box Input Needed: Type Search string: Text Username: Text Password: Text (hidden) Any Add Event overlay Title: Text Event Type: Selection Date (From): Date Selection Time (From): Text Date (To): Date Selection Time (To): Text Table 2: Input design specification Page 26 of 53

4.4 Output design specification (report layouts).

Homepage: Listing of events in grid form, with each event being ensconced in a box displaying only a summary of the event. Each teaser box displays a grey border around it to differentiate between the currently selected event and the others. Event Listings: Listing of all events on the site in order of last created to oldest created. Again, a teaser showing only minimal information meant to tempt users into reading more. Calendar: A jQuery display of all events on the site in a calendar form, making it easier for users to visualize the dates of multiple events concurrently.

4.5 Database/file and data structures design specification Global data structure
The array of all events listed on the site is located in the database and is accessible to all modules during execution. This applies to sorting, deletion/addition, classification, visual rendering and/or any other type of management that is to be done on the events. E.g., a module that collects all the events on the site, sorts them by alphabetical order and displays them in a jQuery frame on the homepage would be able to access the array of all events on the site in order to perform that task.

Temporary data structure

Temporarily stored information will include the likes of usernames and passwords, which will be stored in cookies, small text files that are accessed during the course of website navigation. This allows for user browsing sessions to be stored and retrieved at a later time.

Database description
The SQL database of the site will be one of the most useful resources utilized by the system. This is because it stores all pertinent information regarding user profiles, events and their respective details, module information, temporary information in the form of cache tables, visual theme data, administrative settings, and the locations of uploaded files on the system. Cache tables in the database will be identified by the prefix cache_. These tables can be deleted as needed and will be rebuilt by the website during the course of execution. All third party modules installed on the website will create a table in the database, and the table prefix will be the name of the module followed by a hyphen, e.g. the Registration module will have the following tables: registration_entity, registration_state and registration_type. Information about users will be stored with columns for the username, password (hashed), user ID (primary key), email address and signature (optional).

Page 27 of 53

5. IMPLEMENTATION AND EVALUATION

5.1 Implementation Environment:
For the implementation of this system, the Linux OS environment was used as it provided a more robust platform upon which to test out the production website, as well as making it relatively easier to manage, edit and implement any new changes (as compared to the Windows alternative). The web-development server software used was Apache, and the specifications of the hardware upon which the system is installed are as follows: Processor: Intel Pentium Dual CPU RAM: 4GB System type: 32-bit Operating System

5.2 Documentation: 5.2.1 Detailed description of specific program modules and associated data files/ database implemented on the system design.

Figure 14: Snapshot of custom module-created blocks From the website, the Featured Events, Latest Logins and Latest Users blocks were custom coded and integrated into the site in the sidebar (first and second block) and footer respectively. The code involved is displayed below, with comments in the code offering explanations. Some key definitions are as follows: Hook: A hook is a PHP function that is named foo_bar(), where "foo" is the name of the module (whose filename is thus foo.module) and "bar" is the name of the hook. Each hook has a defined set of parameters and a specified result type. To extend Drupal, a module need simply implement a hook. When Drupal wishes to allow intervention from modules, it determines which modules implement a hook and calls that hook in all enabled modules that implement it (Winter & McCormick, n.d.). Module: A module is a collection of functions that link into Drupal, providing additional functionality for your Drupal installation (Xaav, 2012). Page 28 of 53

Module Names: a Drupal module has two names: A human-readable name: This name is designed to be read by humans, and should be one or a couple of words long. The words should be capitalized and separated by spaces. For example, one of the most popular Drupal modules has the human-readable name Views. A less-popular (but perhaps more creatively named) Drupal 6 module has the human-readable name Eldorado Superfly. A machine-readable name: This name is used internally by Drupal. It can be composed of lower-case and upper-case letters, digits, and the underscore character (using uppercase letters in machine names is frowned upon, though). No other characters are allowed. The machine names of the above two modules are views and eldorado_superfly, respectively.

display.info
;$Id$ name = Display description = This module provides a block that lists all of the created events, the latest users, and the latest logins. package = My Custom Modules core = 7.x files[] = display.module ;dependencies[] = autoload ;php = 5.2

The purpose of the .info file is to provide Drupal with information about a moduleinformation such as the human-readable name, what other modules this module requires, and what code files this module provides. The first line is a standard. Every .info file should begin with ;$Id$. It is the placeholder for the version control system to store information about the file. When the file is checked into Drupal's CVS repository, the line will be automatically expanded to something like this: ;$Id: display.info,v 1.1 2013/04/18 20:27:12 mshehu Exp $ This information indicates when the file was last checked into CVS, and who checked it in. The first two are required in every .info file. The name directive is used to declare what the module's human-readable name is. The description provides a one or two-sentence description of what this module provides or is used for. Among other places, this information is displayed on the module configuration section of the administration interface in Modules. The next directive is the core directive: core = 7.x. This simply declares which main-line version of Drupal is required by the module. All Drupal 7 modules will have the line core = 7.x. Page 29 of 53

Along with the core version, a .info file can also specify what version of PHP it requires.

display.module
<?php // $Id$ /** * @file * This module provides a block that lists all of the created events, the latest users, and the latest logins. It also illustrates coding standards, practices, and API use for Drupal 7. */ /** * Implements hook_help(). */ function display_help($path, $arg) { if ($path == admin/help#display') { return t('A demonstration module.'); } } /** * Implements hook_block_info(). */ function display_block_info() { $blocks = array(); $blocks['list_events'] = array('info' => t('List Events: A listing of all of the created events.'), 'cache' => DRUPAL_NO_CACHE,); $blocks['list_logins'] = array('info' => t('List Logins: A listing of some of the current logins.'), 'cache' => DRUPAL_NO_CACHE,); } /** * Implements hook_block_view(). */ function display_block_view($block_name = '') { if ($block_name == 'list_events') { $list = array(); $result = db_query("SELECT title FROM {node} WHERE type = :type LIMIT 5", array(':type' => 'event')); // Retrieve a 1-column result set as one single array. $list = $result->fetchCol(); $theme_args = array('items' => $list, 'type' => 'ol'); //theme() returns a string of HTML. $content = theme('item_list', $theme_args); $block = array('subject' => t('Featured Events'), 'content' => $content,); return $block; } $blocks['list_new_users'] = array('info' => t('List New Users: A listing of some of the new users on the site.'), 'cache' => DRUPAL_NO_CACHE,); return $blocks;

if ($block_name == 'list_logins') {

Page 30 of 53

$list = array(); $result = db_query("SELECT name, login FROM {users} ORDER BY login DESC LIMIT 5"); $list = $result->fetchCol(); $theme_args = array('items' => $list, 'type' => 'ol'); /** Where ol is ordered list (HTML) */ $content = theme('item_list', $theme_args); $block = array('subject' => t('Latest Logins'), 'content' => $content,); return $block; } }

{ $list = array(); $result = db_query("SELECT name, created FROM {users} ORDER BY created DESC LIMIT 5"); $list = $result->fetchCol(); $theme_args = array('items' => $list, 'type' => 'ol'); $content = theme('item_list', $theme_args); $block = array('subject' => t('Latest Users'), 'content' => $content,); return $block; }

if ($block_name == 'list_new_users')

display_help
Drupal defines a hook called hook_help(). The help hook is invoked (called) when a user browses the help system. Each module can have one implementation of hook_help(). Every natural language string that may be displayed to a user should be wrapped in the t() function, because the t() function is responsible for translating strings from one language into other.

display_block_info
The Block API provides the tools for hooking custom code into the block subsystem. The purpose of this hook/function is to tell Drupal about all of the blocks that the module provides. The function begins by creating an array that will hold all the blocks created. Each block in this array will have a title (e.g. list_events) and a description (info). The DRUPAL_NO_CACHE attribute specifies that this block should not be cached in the database. This is because any other option caused runtime problems with the site.

Page 31 of 53

display_block_view
A hook responsible for building the contents of the block. This hook will be called whenever Drupal tries to display the block. An implementation of hook_block_view() is expected to take one argument - the name of the block to retrieve - and return an array of data for the given name.

Queries
The most common form of query in Drupal is a static query. A static query is one that will be passed to the database nearly verbatim. Only Select queries may be static. Note that you never pass the literal value of a type in a query in order to prevent SQL injections: such values are always represented by placeholders and declared in an array which is passed in the second argument, as shown below:
$result = db_query("SELECT title FROM {node} WHERE type = :type LIMIT 5", array(':type' => 'event'));

Theming
The main function for working with the theming system is theme(). In Drupal 7, theme() takes one or two arguments: The name of the theme operation An associative array of variables to pass onto the theme operation

To format an array of strings into an HTML list, we use the item_list theme, and we pass in an associative array containing two variables: the items we want listed the type of listing we want

From theme() we get a string of HTML. Now all we need to do is assemble the data that our block view must return. An implementation of hook_block_view() is expected to return an array with two items in it: subject: The name or title of the block. content: The content of the block, as formatted text or HTML.

So in the first place we set a hard-coded, translatable string. In the second, we set content to the value built by theme().

Page 32 of 53

5.2.2. User Manual: Detailed description of how to use the implemented system
Please refer to Appendix B for the user manual.

5.3 System Testing:

The software testing approach used for this system was the black-box testing approach, where the functionality of an application (e.g. what the software does) is tested without peering into its internal structures or workings (as compared to white-box testing) (Patton, 2005). The focus is on the goals of the software with a requirements-validation approach to testing (Sehlhorst, 2006). The reason for this approach lies in the fact that many of the inner workings of the Drupal platform are obfuscated to both the developer and the user, and also because the main focus of the system is in the functionality it can provide to potential users. The test cases were built around specifications and requirements, i.e., what the application is supposed to do. Test cases were generally derived from external descriptions of the software, including specifications, requirements and design parameters. The summary of the tests carried out are presented in Appendix B:

5.4 System Evaluation:

Compared to the original objectives, all but a few have been successfully achieved. They are outlined below, as well as with reasons why they were not implemented.
OBJECTIVE STATUS Allow people to create events, complete with text, banners/flyers, contact information, and Google Maps direction information, if available. Allow visitors to an event page (hereby known as Visitor(s)) to register, or RSVP, for the event. Allow event creators to reserve the right to registration, i.e. Moderation. Offer different levels of access to the editing section of an event, based on permission rights of the Members. Allow an event node (every piece of content on a Drupal site is known as a node) to take guest contact details, and to disseminate information/reminders via SMS and/or email. DONE

DONE

DONE DONE

DONE

Page 33 of 53

Allow for Facebook integration: a majority of users already have Facebook accounts, and so it would make the sign-up process easier if they could just use their accounts to sign up for membership to the site. Display a Calendar of Events, populated with some of the user created events. Clicking on an event should take the user to the events page, where they can view details, register for the event, contact the hosts/organizers, etc. If possible and within time constraints, have a mobile version of the system deployed that can be accessed on any capable mobile phone browser.

DEFERRED TO FUTURE VERSIONS

DONE

DEFERRED TO FUTURE VERSIONS

Table 3: Evaluation of Objectives Facebook integration: This has not been successfully implemented due to the lack of reliable Facebook integration modules on the Drupal site. Most of the listed modules have significant bugs that were still under review as at the time of the implementation of GigFinder, and as such could not be used in order to maintain the integrity of the site. Mobile version of the system: As stated above, this was an after-thought that was to be implemented if time and resources allowed. Unfortunately, neither was available in enough quantity and therefore required that this feature be implemented in future deployments of GigFinder.

5.4.1 Strengths & Limitations

The strengths of the site lie in the central aggregation of information pertaining to ongoing events in and around ones local area. This allows for easier searching and registration of events on the part of site visitors, and statistics collection (attendance figures, event popularity, etc.) on the part of event creators. Limitations include the inability to access the site via mobile, which would otherwise provide a portable information bank that can be accessed from anywhere with an internet connection. Other limitations include the inability to register via Facebook, lack of a payment aspect to event registration, and long loading times due to the size of the database being used.

Page 34 of 53

6. CONCLUSION
In summary, GigFinder provides a platform where users can create, view and sign up for events. The classification of different types of users divides them into those who can view, but not create; and those who can view, create, delete and manage their own events. It utilizes a wellrounded Content Management System, Drupal, which enables increased functionality and the extension of features through the installation of third-party modules that integrate seamlessly into the site. It stores the bulk of its data in a database that is easily and dynamically updated by the relevant modules in the system, and it provides an easy way of porting the system to other OS environments. For future work on the system, a mobile version of the site is to be deployed in order to allow users with capable devices (smartphones, tablets, etc.) to access the site with the same functionality as that of the full version. In addition, an improved notification system is in order. Lastly, the ability for event creators to charge entrance fees to their event is one that would attract increased site usage and monetize the site, providing the necessary capital for future developments.

Page 35 of 53

APPENDICES
APPENDIX A: Detailed description of specific program modules
Module Name Block Description Notes Controls the visual building Is responsible for the blocks a page is constructed arrangement of content on a with. Blocks are boxes of Drupal page. content rendered into an area, or region, of a web page. Views plugin to display Enables the Event Calendar. views containing dates as Calendars. Sign-up functionality Enables users to sign up for implemented via CCK event. Notifications for sign-ups Notifies event creators about signups

Calendar

CCK Signup CCK Sign-up Notifications Color

Allows administrators to Needed to alter the color of change the color scheme of the site theme. compatible themes. Enables the use of both Needed for contact page. personal and site-wide contact forms. A Date API that can be used Used for date selection during by other modules. event creation, as well as the correct display of events on the Calendar. Enables jQuery popup Used to prevent date entry calendars and time entry mistakes, and for aesthetic widgets for selecting dates appeal. and times. Maps local user accounts to Used for Facebook user ids. Creates smoother local accounts for app users registration. when configured to do so. seamless and account

Contact

Date & Date API

Date Popup

FB User Management

Field

Field API to add fields to Enabled by default, the Field entities like nodes and users. module allows site admins to add text, number and image fields to events and other

Page 36 of 53

content types. File Defines a file field type. Works with the Field module to allow the addition of image fields (e.g. for event banners).

GMap Image List

Filter to allow insertion of a Google map into a node Provides image manipulation Enables things like cropping tools. and image compression. Defines list field types. Use The ability to select an Event with Options to create Type is due to this module. selection lists. The location module allows Used with GMap you to associate a geographic location with content and users. Users can do proximity searches by postal code. This is useful for organizing communities that have a geographic presence. Customize the destination that the user is redirected to after login. Allows administrators to Allows admins to edit links customize the site navigation and re-arrange menus sitemenu. wide. Allows content to be The basic building block of submitted to the site and any Drupal site. displayed on pages. Defines selection, check box Evident and radio button widgets for creation. text and numeric fields. Displays the Drupal administration interface in an overlay. Describes relationships E.g. relates the Date field in a between entities. Calendar entry to the corresponding Date field in the event. during event

Location

Login Destination

Menu

Node

Options

Overlay

Relation

Page 37 of 53

Simplenews System

Send newsletters to Used for sending notifications subscribed email addresses. to attendees. Handles general configuration administrators. site E.g. allows one to change the for site name.

Testing User

Provides a framework for unit and functional testing. Manages the user registration Enables classification of users and login system. on the site (Visitor, Member, and Administrator). Create customized lists and Allows an admin to select queries from your database. specific information from the database to be displayed in a section on the site. Table 4: Detailed description of specific program modules

Views

Page 38 of 53

APPENDIX B: User Manual

SYSTEM ADMINS To install this system, the following setup is recommended: Web-development server software such as Apache, XAMPP/LAMPP/WAMPP or Mowes (which was used during production of this system). The server software will need a minimum PHP version of 5.3, MySQL v4.0, FTP capability and SMTP software such as Mercury or SendMail. Not that the SMTP software may be installed as a standalone feature, and is necessary for some of the modules to function properly (e.g. Notification, Mail, etc.) A server PC with at least 2GB available hard-disk space, 2GB RAM and a Dual Core processor. The systems total size is approximately 300MB. INSTALLATION Assumptions: You are able to configure your local server software You have phpMyAdmin, with admin rights to create and delete databases

Extract the contents of the GigFinder.zip file into the relevant folder on your server (e.g., if using Mowes, this folder would be C:/mowes/www/; with XAMPP it would be C:/xampp/htdocs. Substitute for the correct letter of the drives location). Start up your server software (Mowes/XAMPP/LAMPP) and ensure that the Apache and MySQL features are running correctly. This can usually be verified by going to http://localhost/ and checking there. Once you have verified that both features are working, go into your phpMyAdmin and upload the database SQL file. Ensure that you have the necessary administrator rights to do so. If you are setting up this system on a remote server, you will need to alter the settings.php file to reflect the correct host address. To do this: Open the GigFinder folder and navigate to sites, then default. In there, you should find the settings.php file. Open this file in Notepad or any text-processor of your choice. Next, scroll down to lines 218 224. You will need to update the information relating to these lines as necessary: Name of database, username, password, host address, port number (default blank value should do), driver (the default mysql should suffice) and prefix (optional). Save the file. Navigate to http://localhost/gigfinder. If all instructions were followed, the site should load properly.

SETTING UP TEMP FOLDERS Page 39 of 53

When installing the website, the temp folder settings may differ according to which OS environment you are installing the system in. As such, this setting will need to be customized as well to ensure proper functionality of the website. The following instructions apply: Log on to the website as an admin Navigate to the Configuration page (gigfinder/admin/config) Under Media, click on the File system link Customize the following values: o Public file system path - A local file system path where public files will be stored. This directory must exist and be writable by Drupal. This directory must be relative to the Drupal installation directory and be accessible over the web. o Private file system path - An existing local file system path for storing private files. It should be writable by Drupal and not accessible over the web. o Temporary directory - A local file system path where temporary files will be stored. This directory should not be accessible over the web.

NORMAL USERS If you are a Visitor, then you can navigate the site as you would any other site. The sections of the site are described below: On the home page, there are 4 links at the very top of the page, namely HOME, VIEW ALL EVENTS, EVENT CALENDAR and CONTACT. Clicking on HOME from anywhere on the site will simply redirect you to the home page.

Figure 15: Snapshot of the 4 links visible to Visitors

The VIEW ALL EVENTS link redirects to a page where all the events created on the site are listed in chronological order, starting with the latest one. Clicking on the title of an event takes you to the Events Description Page, where you can find out more information on the event.

Page 40 of 53

Figure 16: Snapshot showing some of the listings on the site

To the right of the Events page, there is a Navigation box that contains the links to the Create Event (available if youre logged in) and Contact pages. Below that is the Login box. This box is only relevant if you wish to sign up to become a member (see SETTING UP AN ACCOUNT ON GIGFINDER)

Figure 17: Snapshots showing the Navigation and Login boxes

The footer of each page is divided into three (3) sections. The first section Whos Online lists a few of the users who are online at that particular time. The second column, Whos New, lists a few of the users that have recently signed up to become members (Creators). And the final column contains the same four links that are found at the very top of the page (i.e. Home, Events, Calendar and Contact).

Page 41 of 53

Figure 18: Snapshot showing the footer as seen by Visitors

The Calendar page provides a visual representation of the timeline upon which all the events on the site fall. In other words, each Event is represented as a Day on the Calendar, and if you click on that particular Day on the Calendar, you will be redirected to its Event Description page.

Page 42 of 53

Figure 19: Snapshot of the Calendar

The Contact page allows for users to send in suggestions, comments and/or criticisms about the site or their experiences to the site administrators. To do this, a form needs to be filled, and your Name and Email Address have to be supplied along with your submission. As to the actual message, the Subject and the Message can be filled in, Page 43 of 53

after which the Send message button is clicked to send it in. All messages are stored on the database and are reviewed by the administrators at their discretion.

Figure 20: Snapshot of the Contact Page

SETTING UP AN ACCOUNT ON GIGFINDER

Page 44 of 53

All pages on the site, with the exception of the homepage, allow for a Visitor to register an account on the site (thereby making you a Creator) via the Login Box on the right (assuming one is not already logged on). The following instructions apply: Click on the Create account link located just below the password field in the Login box.

Figure 21: Snapshot of the Create New Account Link At the User account page, enter the username you wish to use. Note that spaces are allowed, and punctuation is not allowed except for periods, hyphens, apostrophes, and underscores. Enter your email address in the field below that. Click on Create new account when done.

Figure 22: Snapshot of new user account creation A welcome message will be sent to the supplied email address with further instructions on how to login. Follow these instructions to gain access to the site as a Registered Member. Notice that when logged in as a Registered User, a new link appears in the header of the site, namely Add Event. This link allows you to access the Event creation page from any section of the site.

Figure 23: Snapshot of the header as seen by Registered Members

CREATING AN EVENT ON GIGFINDER Page 45 of 53

As a Creator, you now have the ability to create your own events for listing. Conversely, it also allows you to delete any events you have created that are either completed or otherwise cancelled. The following instructions apply: Assumption: You are logged onto the site as a Registered User or as an Administrator. From any section of the site, click on the Add Event link at the very top of the page.

Figure 24: Snapshot of the Add Event link

At the Create Event page, enter the details of the Event you wish to create, such as the Title and the Start and End Dates. You may select the Event Type if you wish.

Figure 25: Snapshot of the Title, Event Type & Date fields

Specify the Price and the Venue.

Page 46 of 53

Figure 26: Snapshots of the Price and Venue fields

Type in more detailed information about the event. You may also click on the Edit Summary link to give a short synopsis of the Event, which will be displayed on the Event Listing page (accessed by clicking on View All Events in the header of any page). Enter as much information as you feel is pertinent in the Body text field. Note that this field can be left blank if desired.

Figure 27: Snapshot of the Event Body & Summary text fields

Upload an event banner. Allowed file formats are PNG, JPG & GIF. The maximum file size is 10MB.

Page 47 of 53

Figure 28: Snapshot of Event Banner upload box

Specify the event capacity if desired. Leaving it blank will mean that theres no limit to how many people can sign up for the event. Specifying a number limits this number.

Figure 29: Snapshot of Event Capacity text field

Leave the Signup settings as they are:

Figure 30: Snapshot of default Signup settings

You may click on Preview in order to see how the final Event will look like; alternatively, you may just click on Save if you are satisfied with it

Figure 31: Snapshot of Save and Preview buttons Reloading the home page should reflect the fact that a new event has been added.

Page 48 of 53

APPENDIX C: Testing Summary

Requirement Tests run Results

Allow people Create event with no banner Expected Result: to create events, uploaded Error: Banner is mandatory complete with text, and must be added. banners/flyers and contact information Actual result: As expected Attempt to upload banner Expected Result: with wrong image type (e.g. Error: Banner must be jpg, TIFF) png, or gif. Actual result: As expected Create event with no Title Expected Result: given Error: Title of event is mandatory and must be added. Actual result: As expected Create event with no date or Expected Result: time specified Error: Date of event is mandatory and must be specified. Actual result: As expected Create event with no Price Expected Result: specified Error: Price is mandatory and must be added. Actual result: As expected Create event with no Expected Result: additional information (Venue, Contact detail, Event Nothing: Event Type, Venue, Contact Details, Capacity are Type, Capacity) NOT mandatory and can be omitted. Actual result: As expected Allow visitors Click on the Signup link of Expected Result: to an event page an event using a non-admin Be redirected to the Create a (hereby known as Page 49 of 53

Visitor(s)) to sign up profile for the event.

Signup page Actual result: As expected

Allow event Click on an event created by Expected Result: creators to reserve the the current profile in use See a Manage signups link right to registration, above the event banner that i.e. Moderation. redirects to a page listing all signups to that event Actual result: As expected Offer different Click on an event description levels of access to the page sing a non-admin editing section of an profile and attempt to edit it event, based on permission rights of the Members. Allow an event FEATURE node (every piece of ADDED content on a Drupal site is known as a node) to take guest contact details, and to disseminate information/reminders via SMS and/or email. Allow for FEATURE Facebook integration: ADDED a majority of users already have Facebook accounts, and so it would make the signup process easier if they could just use their accounts to sign up for membership to the site. NOT YET Expected Result: Should NOT be able to see the Edit event link Actual result: As expected

NOT

YET

Display a Click on an event day Calendar of Events, within the Calendar populated with some of the user created events. Clicking on an event should take the user to the events Click on an empty day in

Expected Result: Redirection to the event description page of the Event Actual result: As expected Expected Result: Page 50 of 53

page, where they can the Calendar Nothing happens view details, register Actual result: As expected for the event, contact the hosts/organizers, Create a new Event via Add Expected Result: etc. new event New Event shows up on the calendar at the specified date Actual result: As expected Delete an event from the site Expected Result: Event is removed from the Event Calendar Actual result: As expected If possible and N/A (Mobile Version of site N/A (Mobile Version of site within time not deployed in this release) not deployed in this release) constraints, have a mobile version of the system deployed that can be accessed on any capable mobile phone browser. Table 5: Testing Summary

Page 51 of 53

REFERENCES
Active Network. (n.d.). The Top 10 Benefits of Online Registration for You and Your Participants. Retrieved from Active Network: http://www.activenetwork.co.nz/eventmanagement-resources/articles/top-10-benefits-of-online-registration.htm Ambler, S. W. (n.d.). Examining the Agile Manifesto. Retrieved October 14, 2012, from AmbySoft: http://www.ambysoft.com/essays/agileManifesto.html Ann. (2011, May 11). Advantages Of Online Event Management. Retrieved from Eventish: http://blog.eventish.com/2011/05/11/advantages-of-online-event-management/ Beck, K. (1999). Embracing Change with Extreme Programming. Computer, 32(10), 70-77. Beck, K., & al, e. (2001). Manifesto for Agile Software Development. Retrieved from Agile Manifesto: http://agilemanifesto.org/ CerVentus, D. (2009, March 11). How to Market Your Events Online (ie BarCampKL). Retrieved from ENTRERENEURS.MY: http://www.entrepreneurs.my/how-to-marketyour-events-online-ie-barcampkl/ Eventish. (2011, October 9). Online Event Management and Registration Software. Retrieved from Eventish: http://blog.eventish.com/2012/10/09/online-event-management-andregistration-software/ Go-Gulf. (2012, Feb 2). How People Spend Their Time Online [Infographic] . Retrieved from Go-Gulf: http://www.go-gulf.com/blog/online-time/ Kallas, P. (2012, August). Top 10 Social Networking Sites by Market Share of Visits [August 2012] . Retrieved from DreamGrow: http://www.dreamgrow.com/top-10-socialnetworking-sites-by-market-share-of-visits-august-2012/ Odden, L. (2010). Tasty Ideas to Maximize Online Marketing for Events. Retrieved from Top Rank Marketing: http://www.toprankblog.com/2011/01/maximize-event-marketing/ Ohm, L. (2012, October 12). Which Is The Best Marketing Platform: Facebook Or Twitter? Retrieved from Social Strand Media: http://socialstrand.com/2012/10/12/which-is-thebest-marketing-platform-facebook-or-twitter/ Patton, R. (2005). Software Testing (2nd ed.). Sams Publishing. Publisher. (2011, November 29). How To Cut Event Budget Without Compromising Its Success? Retrieved from Eventish: http://blog.eventish.com/2011/11/29/how-to-cut-event-budgetwithout-compromising-its-success/ Publisher. (2011, December 12). How to Successfully Promote Events with Social Media? Retrieved from Eventish: http://blog.eventish.com/2011/12/12/how-to-successfullypromote-events-with-social-media/ Ramsborg, G., Miller, B., Breiter, D., Reed, B. J., & Rushing, A. (2008). Professional meeting management: Comprehensive strategies for meetings, conventions and events (5 ed.). Kendall/Hunt Publishing. Page 52 of 53

Sehlhorst, S. (2006, January 13). Software Testing Series: Black Box vs White Box Testing. Retrieved from Tyner Blain: http://tynerblain.com/blog/2006/01/13/software-testingseries-black-box-vs-white-box-testing/ Sharma, N. (2012, February). Battle of the Social Media Giants: Facebook Vs. Twitter Vs. Google+. Retrieved from Socialnomics: http://www.socialnomics.net/2012/02/21/battleof-the-social-media-giants-facebook-vs-twitter-vs-google/ Waters, K. (2007, February 10). What Is Agile? (10 Key Principles of Agile). Retrieved from All about Agile: http://www.allaboutagile.com/what-is-agile-10-key-principles/ Wikipedia. (2012, October 2). Agile software development. Retrieved from Wikipedia, the free encyclopedia: http://en.wikipedia.org/wiki/Agile_software_development Winter, J., & McCormick, McCormick&Winter: explained S. (n.d.). Drupal Hooks Explained. Retrieved from http://www.mccormickandwinter.com/blog/drupal-hooks-

Xaav. (2012, May 31). Creating modules - a tutorial: Drupal 7.x. Retrieved from Drupal.org: http://drupal.org/node/1074360 Zeik, M. (2011, March 8). 9 Benefits of an Online Event Marketing Reporting System. Retrieved from Promotion!: http://www.promotion1.com/blog/bid/55219/9-Benefits-of-an-OnlineEvent-Marketing-Reporting-System

Page 53 of 53