University of VictoriaFaculty of Engineering

SENG 499 Design Project Course

vHive: Volunteer Scheduling SoftwareSystem

Final Report

Submitted to: Dr. Issa TraoreDate: April 8, 2010

Group 12:Anna Cox V00191832Piper Gordon V00218713Erik Johnson V00201143Jeff Proctor V00190707Jason Wynja V00171241

Table of Contents

Table of Contents........................................................................... 2Summary ....................................................................................... 31 Introduction ........................................................................ 4

1.1 Problem Description............................................................ 41.2 Project Description ............................................................. 41.3 Report Scope..................................................................... 5

2 Requirements ...................................................................... 52.1 Domain Description ............................................................ 5

2.1.1 SkaFest.............................................................................. 52.1.2 Rifflandia............................................................................ 52.1.3 Fringe Festival .................................................................... 62.1.4 General Extracted Workflow .................................................. 62.1.5 Stakeholders....................................................................... 6

2.2 Core Requirements............................................................. 62.2.1 Functional .......................................................................... 62.2.2 Non-functional .................................................................... 7

2.3 Low-priority Requirements................................................... 72.3.1 Functional .......................................................................... 72.3.2 Non-functional .................................................................... 7

3.2 Technologies ............................................................................ 83.3 Use Cases ................................................................................ 9

4 Implementation (formerly titled Design) ............................. 154.1.1 Coordinator Interface ......................................................... 154.1.2 Volunteer Interface............................................................ 164.1.3 Mobile Interface ................................................................ 18

4.3 Features ......................................................................... 194.3.1 Volunteer ......................................................................... 194.3.2 Coordinator ...................................................................... 204.3.3 Mobile Interface ................................................................ 20

4.4 Security .......................................................................... 215 Testing .............................................................................. 216 Problems Encountered....................................................... 217 Conclusion......................................................................... 218 Recommendations ............................................................. 22

Summary

vHive is a solution to coordinating short events with many volunteers. Inspired by localmusic and theatre festivals and helped along by input from the coordinators of thosefestivals, this web application was designed and developed. The feature set was to stayas basic as possible while still meeting the needs of volunteers and their coordinators, soto avoid a steep learning curve. Display of the features and interaction with the systemwas also to stay very simple and adhere to popular standards. The system wasdeveloped in Python with the Django framework, with SVN for version control and anSQLite database. A mobile interface was also developed for added convenience. Securityand ease of use were two important goals of vHive. The main objectives were met, whileleaving room for vHive to improve.

1 Introduction

1.1 Problem Description

Volunteer coordination is a time consuming and difficult task to manage. Small eventsand festivals that rely on volunteers are subject to large amounts of overhead managingthose volunteers. The time needed to learn a new system makes current softwareproducts irrelevant for short events. As a consequence, coordinators of these eventsresort to using a mixture of spreadsheet applications, text-editing applications, calendarapplications, e-mail communication, databases, and paper-based systems. Largeamounts of time are spent managing schedules, coordinating users, and maintainingcommunication.

Coordinators for the Victoria Fringe Festival, Ska Fest and Rifflandia were contacted.Based on this communication, it was determined that there is a need for a simple,effective volunteer management system. Currently the disconnect between thevolunteers' desires and the coordinators' constraints forces traditional communicationmediums to be strained. Large amounts of e-mail and other two-way communication isgenerated while trying to ascertain everybody's availability. This wastes valuable timeand is ineffective during the course of a short term event. As a result of the largedifferences in schedule availability between volunteers, creating schedules is a non-trivialtask for an event coordinator.

During the course of an event it is difficult for a Coordinator to handle shift adjustmentsand changing availabilities. As a result, volunteers may skip shifts that they are nolonger able to attend without notifying the coordinator.

The current systems used to manage volunteers are inadequate. There is a need for arobust, scalable solution able to handle large numbers of volunteers over the duration ofevents and provide facilities for easier management of volunteers and schedulingconcerns. Current systems provide large feature sets and steep learning curves and arenot productive for a volunteer coordinator to learn and apply due to the short timeline ofthe events that we are targeting. A solution is needed that provides minimal learningwith efficiency and effectiveness.

1.2 Project Description

This project was not industry-directed and therefore no formal set of requirements wereavailable at the start of the project. Our main goals were to make it easier forcoordinators to manage volunteers and to make it easier for volunteers to sign up forevents and to manage their volunteering effort.

The project was inspired by the many arts and cultural events in Victoria, BC. Throughour own volunteer experience as well as contacting local event coordinators, it wasperceived that there was a need for a computer system which could streamline thevolunteer process.

A web application was decided upon to allow users to easily get started using thesystem. No downloading or installing steps are required. Using the web also allowsaccess to the same information from multiple locations and devices.

1.3 Report Scope

This report outlines the processes followed from requirements gathering, brainstorming,through design, and implementation. Due to time constraints, not all features wereimplemented. Future work is also discussed.

2 Requirements

Event coordinators of local events Ska Fest, Rifflandia, and the Fringe Festival werecontacted to gather a sense of workflow and requirements. Requirements were dividedinto core and low-priority based on how important they were to the overall functioningand usability of the system.

2.1 Domain Description

Through informal interviews and communication, an idea of the event volunteeringprocess emerged. Information from several sources are outlined here. In addition, thesehave been combined below to outline a general workflow common to some short-termevents.

2.1.1 SkaFest

• Volunteers email the coordinator via an email address posted on the eventwebsite.

• Volunteers fill out a form or email the coordinator their information. This mayinclude availability, certificates, past experience (number of years volunteeringfor SkaFest), name, and contact information.

• The coordinator gathers this information for all volunteers and uses it to make anoverall shift schedule

2.1.2 Rifflandia

• Volunteers download word document on the event website. They then fill this outand email or fax it to the coordinator.

• The coordinator enters this information for all volunteers into a Googlespreadsheet.

• Information in the spreadsheet includes the volunteer's name, whether theywere a good volunteer in the past or not, whether they have been contacted ornot, their age, phone number, email address, availability (pre- and duringevent), preferred tasks, t-shirt size, and total hours.

• The coordinator maintains one spreadsheet with volunteer information, one witha calendar for headquarters scheduling, one with the volunteer shift schedule,and a calendar for parties and deliveries.

2.1.3 Fringe Festival

The Fringe Festival has been hiring a new coordinator each year. Therefore a shortlearning curve is extremely important. Multiple systems for storing information are usedwhich are not connected.

• The coordinator starts with a spreadsheet of all of the shifts that need to befilled.

• A volunteer night is held where each volunteer signs up for shifts on paper.• New volunteers are asked to fill out an information form.• Volunteers may also sign up online.• The coordinator inputs all of the gathered information into a shift spreadsheet.• An online record of volunteers is kept which cannot be edited.

2.1.4 General Extracted Workflow

According to the information above, a general workflow has been determined.

• Volunteers contact the coordinator via email to inquire about the event.• Volunteers fill out a form regarding their contact information, availability, and

other event-specific information that has either been emailed to them, they havepicked up, or they have downloaded from the event website.

• The event coordinator manually enters this information into a spreadsheet -either online or not.

• The coordinator must match this new information with information about pastvolunteers.

2.1.5 Stakeholders

We have identified two unique stakeholders for our application: event coordinators, andevent volunteers. The main motivation for coordinators to use our system would be toreduce the amount of time they spend recruiting and coordinating volunteers. On theother hand, the main motivation for volunteers to use our system would be to have easyaccess to event information such as schedules.

2.2 Core Requirements

Core requirements were extracted from the workflows outlined above as well as personalvolunteer experience.

2.2.1 Functional

1. Volunteer information form which can be customized by the event coordinator.a. Default fields in a standard form.b. Coordinator is able to add additional fields to the form.

2. Online data entry by volunteers.3. Coordinators and volunteers have an account which they sign into.

a. Coordinators approve volunteer signups.4. Linkage of data sources.

a. Able to access volunteer information from the calendar.b. Able to email volunteers from their information.

5. Calendar for volunteer shifts.

a. Coordinator is able to create, view, and sort shifts.b. Volunteer can view and sign up for available shifts.

6. List of volunteers available to the coordinator.a. sort the list based on parameters.

2.2.2 Non-functional

1. Usability (intuitive and limited number of features).a. Less than one hour learning curve.

2.3 Low-priority Requirements

Low-priority requirements were extracted from the above workflows as well as ideas ofwhat would be useful and make the system more attractive and usable.

2.3.1 Functional

1. Multiple calendars which would allow the coordinator to separate volunteer shiftsfrom employee shifts and parties.2. Assignment of volunteers to a group which would allow the coordinator to emailgroups or to assign privileges by group. For instance, allow veteran volunteers priorityfor shift-signup.3. Mobile interface for the coordinator.4. Email capabilities incorporated into the list of volunteers.5. See detailed volunteer information by clicking on a volunteer in the list ofvolunteers.6. Communication between volunteers.

a. Coordination of dropped shifts (allows volunteers to take shifts dropped byothers).

b. Volunteers may contact each other to discuss events or shift swapping.7. System that allows volunteers to view and sign up for multiple events/festivals, anddiscuss events with other volunteers.

a. Connection of volunteer data between events to minimize volunteer dataentry.

2.3.2 Non-functional

1. Security.2. Privacy.

3 Design

3.1 System Overview

We proceeded with an initial design based on the core requirements of the system. Asolution was required that was accessible via the Internet. We chose to design anapplication which would display in a standard web browser. To allow coordinators greaterfreedom with respect to mobility, we took into account the possibility of creating aninterface tailored to mobile smart-phones as well.

Due to the decision of implementing a web application, we were limited in our chosenarchitecture and implementation environment in the following ways:

• Web accessible database: Information must be accessible by the webapplication; therefore we require a technology stack that works well with adatabase in the Internet framework,

• Web server: We require a web server to serve (X)HTML pages along with,Cascading Style Sheets and JavaScript for the client side experience,

• Server processing: We require a server processing framework that is capable ofhandling the database requests along with implementing the business logic onthe server side.

With this in mind we began the design of the system as outlined below:

Figure 1 - A high level diagram of the vHive components

3.2 Technologies

Several languages/technologies were compared: Django/Python, Ruby on Rails/Ruby,Java/JSP. Python was chosen for a few reasons. First, Python has terse, expressivesyntax that leads to greater readability and programmer productivity when compared toJava. Productivity was important given the time constraints of the project. Furthermore,Python was chosen over Ruby because while Ruby contains many shortcuts forexperienced developers, Python is widely considered to be easier to learn. This wasimportant because not all of the team members were familiar with Python and Ruby atthe start.

Subversion (hosted on Google Code) was chosen as the versioning system. It was quickand easy to set up compared to a self-hosted solution, and all group members hadprevious experience using it.

SQLite was chosen as the database. It came with the Django framework and requiredminimal set up. MySQL was originally chosen but the set up process was complicatedand error-prone. Group members were having problems making sure all of the settingswere correct.

3.3 Use Cases

Several use cases were outlined to define how users would interact with the system. Thisalso served as a way to coordinate the distributed group effort and communicate ourexpectations.

UC 1: Create an eventuser: Coordinator1. Click on 'Create an Event' button on vHive homepage2. Enter event information3. Enter coordinator account information (create an account)4. Submit information

UC 2: Create Shiftsuser: Coordinator1. Login2. Click on 'Shifts' tab3. Enter shift information via the calendar

UC 3: Invite Volunteersuser: Coordinator1. Login2. Click on 'Volunteers' tab3a. Enter volunteer email addresses3b. Invite past volunteers from database4. Write a message5. Submit information

UC 4: Create a user accountuser: Volunteer1. Click on 'Create an Account' button on vHive homepage2. Fill out general form:name, username, email, phone, password (...)?3. Submit information

UC 5: Sign up for eventuser: Volunteer1. Login2. Browse the events list or search for a specific event3a. Click on the 'Sign Up' button beside the listing3b. Go to the event's homepage and click on the 'Sign Up' button4. Fill out information needed for that specific event (defined by the event's coordinator)5. Submit information6. Wait for approval

UC 6: Sign up for shiftsuser: Volunteer1. Login2. Choose an event from the 'My Events' list (that the coordinator has approved)3. Click on the 'Sign up for Shifts' link on the right hand side of the page4. Click on shifts displayed in the calendar to sign up

UC 7: View Shiftsuser: Volunteer1. Login

2a. See upcoming shifts for all events on the right hand side of the user's homepage2b. Choose an event from the 'My Events' list and see upcoming shifts on the right handside of the event homepage

UC 7: View shiftsuser: Coordinator1. Login2. Click on the 'Shifts' tab3. Click on a day of the event in the event calendar4. See all the shifts for that day: hidden events and otherwise

UC 8: Find Volunteer Information from Calendaruser: Coordinator1. Login2. View shifts (UC 7)3. Click on a username in a shift4. View the user's volunteer information

UC 9: View Volunteer Listuser: Coordinator1. Login2. Click on the 'Volunteers' tab3. See a list of the volunteers that are pending and approved for the event

3.4 User Interface Design

The initial design was created based on the requirements outlined in section 2. Duringbrainstorming sessions, we created several design drawings mimicking the user'sinteraction with the system. These inital mock-ups were the basis for development of thesystem and exposed several key areas of interest. They also provided the team with aunited vision going forward of the initial system. The next step was to begindevelopment on a second iteration prototype in HTML. Below is a sample mock-updrawing from our initial design meetings.

Figure 2 - Early interface sketches

As can been seen from the initial mock-up several elements from the requirements wereoutlined early in the design phase. Creations of Shifts, Volunteers and event informationare just a sample of the features outlined in this mock-up (Figure 2).

Similar paper prototypes were drawn up for the volunteer interface. Figure 3 shows therelationship between the volunteer homepage and the volunteer view of the eventhomepages. It was envisioned early in the process that volunteers would be able to useone account to access and manage their volunteer effort for multiple events. Initially,this was going to be the framework for social networking features such as rating events,communicating with other volunteers to discuss events, and coordinating shift switchingamongst volunteers. Due to time constraints, these additional features were notimplemented but the framework is in place which would allow expansion in this direction.

Figure 3 - Relationship between volunteer homepage and volunteer-view of an eventhomepage

3.5 Processing Design

The Django framework chosen for this project implements a strict model view controller

approach to web development. We structured our system into three components. The

view as discussed above in the User Interface section, The model which is discussed

below in section 3.6 and the controller architecture which will be discussed below.

3.5.1 Controller Architecture

The architecture of the system was required to perform several key functions toaccomplish the requirements outlined in section 2, these functions included: Login,Database submissions and retrieval of data, E-mail notifications and file uploads. Theysystem was partitioned according to these functions into related modules. The loginprocessing resided in an authorization module which the controller uses to confirm theidentity of the users on login. The Calendar and form processing interact with a set ofcontroller functions that make up the database interaction module. The e-mailnotification is a part of the controller functions and does not reside in a specific moduleit's code is included inline the controller module.

3.6 Database Design

Several key design decisions were made which affect the database design. Becausevolunteers and coordinators share most of the same information, both are classified asUsers. Coordinators are defined as users which have created an event. To simplify theapplication, coordinators may only be associated with one event. Coordinators will havepermission to create shifts for their events. Volunteers can register for events and signup for shifts.

A coordinator may want to request more information from their volunteers than thesimple user attributes requested when a volunteer signs up for the system. Thecoordinator can enter event-specific fields to include in their event registration process.The users who sign up for that event will need to enter data for these fields as part ofregistration.

Figure 4 shows the entity relationship diagram which was designed with these keydecisions in mind.

Figure 4 - An entity/relationship diagram for the database model

4 Implementation (formerly titledDesign)

4.1 User Interface

The goal was to create a simple, intuitive interface that event coordinators andvolunteers could use to support volunteering. Figure 5 shows the main vHive page whichallows coordinators and volunteers to sign up in one simple step or login to theiraccounts.

Figure 5 - The vHive main page

4.1.1 Coordinator Interface

When a coordinator logs in, they are presented with their event homepage as seen inFigure 6. Through tabs, which are a common navigation tool, they can access a calendarview or a volunteer information view. A news feed, also a common feature of Web 2.0sites, which the coordinator can post to, is used as an update tool to notify volunteers ofnew information.

Figure 6 - The coordinator-view of an event homepage

Ajax modal elements are incorporated in the calendar and volunteer tabs. These areused to allow coordinators to create shifts and view extended volunteer informationwithout navigating to a new page.

4.1.2 Volunteer Interface

The volunteer interface is very similar to the coordinator interface. This was done for tworeasons. The first reason was for consistency for cases where a user may use the systemfor both event coordination and volunteering. The second reason was that thecoordinators and volunteers have very similar feature sets so it made sense to divide thesystem into the same core pages for both types of users.

When a volunteer logs into the system, they are directed to a homepage (seen in Figure7)which displays a list of the events that they have signed up for, their upcoming shifts,and a way to browse additional events that have been created.

Figure 7 - Volunteer homepage

The list of events allows them to navigate to the individual event homepages which havea similar layout to the coordinator-view of an event homepage. If a volunteer has signedup for the event, they are presented with the event information, a list of the shifts theyhave signed up for, and a read-only view of the news feed. If they have not signed upfor the event (they are browsing), they see a "sign up for this event" option rather thana shift list.

Volunteers have a similar calendar view to coordinators. This can be seen in Figure 8.The differences are the actions allowed on the calendar. Whereas coordinators cancreate shifts and view extended shift information by clicking and dragging on thecalendar or clicking on a shift, respectively, volunteers can sign up for shifts by clickingon a shift. In addition, their calendar view contains shifts for all of the events that theyhave signed up for.

Figure 8 - Coordinator-view calendar

The Manage Info tab allows volunteers to edit their basic information as well as event-specific information.

4.1.3 Mobile Interface

The mobile interface provides a reduced feature set for coordinators. Two factors weretaken into account when deciding upon the available actions and the design: the reducedscreen real estate available on a mobile device, and the frequency that actions would beused.

After logging into the mobile interface, coordinators are brought to a view of thenewsfeed which can be seen in Figure 9. Using tabs, they can navigate to a read-onlyday-view of the event calendar, and a list of volunteers.

Figure 9 - Mobile interface newsfeed

4.3 Features

The following is a list of the features which were implemented in our current version ofthe system.

4.3.1 Volunteer

The system allows volunteers to become a member of certain events, and viewinformation entered by the coordinator. The interface allows the volunteer to seepreviously set up shifts and sign up for those of his or her choosing.

vHive Home Page• The volunteer can sign up for vHive• The volunteer can log in to your volunteer vHive account

Home Page• Search and Browse events• View all shifts the volunteer has signed up for• View events the volunteer has signed up for• Access Event Pages

Manage Shifts Page

• All shifts created by the coordinator can be viewed• The volunteer may sign up for a shift by clicking on it in the calendar

Manage Info Page• Keep your information up to date, including specific custom fields for each event

Event Pages• Sign up for an event

◦ The volunteer will be requested to fill out custom fields specified by thecoordinator

• View shifts the volunteer has signed up for (with that event)• View event information page and message board

4.3.2 Coordinator

The system allows a coordinator to create and event and enter all of its relevantinformation. The coordinator may customize the shift calendar, and view which shiftshave not been filled.

vHive Home Page• Create an event, filling out event information and required custom fields• Log in to coordinator account

Event Home Page• View event information and unfilled shifts• View, add and delete event messages that broadcast to volunteers• Edit the event information

Calendar Page• Create new venue and role choices• Create shifts by specifying volunteer role, venue, number of volunteers, start

and end times• View shifts on the week calendar and view their specific information.

Volunteer Page• View, sort and search volunteers• View volunteer information• Send email messages

4.3.3 Mobile Interface

A reduced feature set is available via the mobile interface. The mobile interface may onlybe used by coordinators who have already established an event. This interface supportsthe following actions:

• Log in• View, add, and delete event messages• View shift information on a read-only day-view calendar• View volunteers• View volunteer information

4.4 Security

A number of security precautions were taken to protect user identity. Users are requiredto log into the system using an email address and password. A cryptographic hashfunction (SHA256) was used in conjunction with salting to protect the passwords storedin the database. User login is done over HTTPS to protect passwords as they are sentover the wire.

During login, a randomly generated token is stored in a browser cookie to authenticatethe user for regular application traffic. The random number generator chosen is suitablefor cryptographic purposes (meaning it's not a pseudo-random number generator withpredictable sequences).

5 Testing

Due to time constraints, user testing was only performed with the Ska Fest coordinatorrather than with all initially contacted coordinators.

The coordinator was shown the coordinator and volunteer interfaces and the mobileinterface. A typical workflow for setting up an event and inviting volunteers wasperformed. The coordinator made several suggestions for additional features:

• coordinator approval for shift cancellation• coordinator approval for event registration• payment required for use of the vHive system.

Most of the requests were taken into consideration at the beginning of design but werenot implemented due to time constraints.

6 Problems Encountered

The main problem encountered that prevented some features from being implementedwas the time constraints of the project. The initial feature list was ambitious for thethree-month timeline considering the other responsibilities of the group members.

Using the SQLite database for group development caused some problems. The databasewas a single binary file which was included in the versioning system. As such, there wasno way to merge conflicts so some data was overwritten between checkins. This hadsome impact on ongoing feature testing as certain database versions either had to besaved on the local harddrive or data had to be re-entered to test certain features.

7 Conclusion

Our system facilitates coordination of volunteers by empowering both the coordinatorand volunteer. Instead of communicating through paper schedules and vast emailthreads, the coordinator can simply communicate what shifts need to be filled online. Itenables the volunteer to reply asynchronously with coordinators by easily signing up forwhatever shifts have not been filled. This eliminates many of the extremely time-consuming tasks of the coordinator. Furthermore, it gives an online database of all theevent and volunteer information which is even accessible via a smart phone when thecoordinator is on site.

In the time given for the design and implementation of this project, much wasaccomplished. The resulting web application has the basic features necessary to alleviatesome of the burden of coordinating a volunteer-driven event. By staying in touch withpotential end-users, the interface was kept simple and intuitive. Encouraging feedbackwas received through user testing and during presentations of the application (ondemonstration day and in the local entrepreneurial competitions). The next steps to takewith vHive are clear and the future possibilities are many.

8 Recommendations

In our user testing it was suggested that the following features should be implementedto make the application more useful:

• coordinator approval for shift cancellation• coordinator approval for event registration• payment required for use of the vHive system

Some additional work should also be done to make the application more secure andusable. In terms of security, while permissions are double checked on the client side,passing parameters through the page URL should be replaced by a more hidden andtamper-safe method. In terms of usability, more features should be added to thecalendar since it is the main feature of the system. More flexibility could be added to thecalendar such as the ability for the coordinator to create a new shift that begins duringthe time of an existing one (overlapping shifts). As well, some changes are needed forusing the new role or venue interface above the calendar. The refresh action shouldeither display the calendar in the same week that was being viewed prior to the changeor the form should employ ajax such that a refresh of the calendar is not needed. Tomake the calendars more readable, colours should be used to differentiate between filledshifts and unfilled shifts - for the coordinator, and signed up for shifts and not signed upfor shifts - for the volunteers.