Team Seeker: Gamblers Anonymous meeting finder web application Information Systems Development Project

Year 2 (2014/2015)

Diploma in Information Systems

Trinity College Dublin

23rd March 2015

2 | P a g e

Abstract This document outlines how Team Seeker approached developing a mobile app for Gamblers Anonymous Ireland. Gamblers Anonymous Ireland were having trouble disseminating information about the organisation and meetings to those in need.

We reviewed the situation with a representative from Gamblers Anonymous and determined that a mobile app was the most appropriate way of responding. We proceeded to compile a list of more detailed requirements from the client and develop a mobile app on that basis.

As a result of this process we’ve delivered a mobile formatted HTML WebApp to Gamblers Anonymous using HTML5, JavaScript and jQuery Mobile that they can host on their existing servers, without imposing extra costs to upgrade their infrastructure or retrain their existing volunteer webmaster.

3 | P a g e

Acknowledgments The project team would like to give thanks to our family, friends and pets who have supported us all the way through this project with an understanding to our commitment. We would also like to give thanks to our supervisor Howard Shortt for all his guidance, encouragement and advice throughout the project. His patience and knowledge was inspirational for the whole team. We would also like to extend our gratitude to our sponsor in Gamblers Anonymous for their support and patience.

We are also indebted to Dr Simon McGinnes and all our lecturers over the past two years for their tutelage in providing us with the knowledge that was invaluable during the development of our application over the course of this year.

We hope that all those that use our web application gain something from all our hard work.

4 | P a g e

Declaration We, the undersigned, declare that this dissertation is entirely our own work and not previously submitted to Trinity College Dublin.

We agree that Trinity College Dublin may lend or make copies of this document for educational purposes, if requested.

Paul Flood ____________________________

Margaret Moore ____________________________

Bernard McGinley ____________________________

Colm Kennedy ____________________________

Peter Byrne ____________________________

5 | P a g e

Document Version History

Version Date Editor Comments

1.00 20-11-2014 Peter Document template created

1.01 3-12-2014 Peter Updated with client background

1.02 17-12-2014 Bernard Updated technologies used

1.03 19-12-2014 Paul Added Project details

1.04 12-1-2015 Margaret Added Design details

6 | P a g e

Contents Abstract ................................................................................................................................................... 2

Acknowledgments ................................................................................................................................... 3

Declaration .............................................................................................................................................. 4

Document Version History ...................................................................................................................... 5

List of Tables ........................................................................................................................................... 8

List of Figures .......................................................................................................................................... 8

List of Abbreviations ............................................................................................................................... 8

Chapter List ............................................................................................................................................. 9

1 Introduction .................................................................................................................................. 10

1.1 Client Background ................................................................................................................. 10

1.2 Overview of Project .............................................................................................................. 10

1.3 The Business Problem ........................................................................................................... 10

1.4 Objective of the project ........................................................................................................ 11

1.5 Proposed solution ................................................................................................................. 11

1.6 Existing systems and processes ............................................................................................ 12

1.6.1 Issues with current systems .............................................................................................. 12

1.7 Relationships to existing systems / integration .................................................................... 12

2 Requirements ................................................................................................................................ 14

2.1 Summary of requirements .................................................................................................... 14

2.1.1 User Stories and how they were addressed ................................................................. 14

2.2 UML Use Case Diagram ......................................................................................................... 18

2.3 Entity Relationship Diagram.................................................................................................. 19

3 Project Management .................................................................................................................... 20

3.1 Project Structure ................................................................................................................... 20

3.1.1 Project Scope ................................................................................................................ 20

3.1.2 Constraints .................................................................................................................... 21

3.1.3 Assumptions .................................................................................................................. 21

3.1.4 Critical Success Factors ................................................................................................. 21

3.1.5 Project Life Cycle ........................................................................................................... 22

3.1.4 Project Schedule ........................................................................................................... 22

3.2 Chosen methods (with reasons) ........................................................................................... 23

3.3 Project Goals ......................................................................................................................... 23

3.4 Overall project schedule (Gantt) ........................................................................................... 24

3.5 Team Organisation ................................................................................................................ 25

3.6 Team Brainstorming .............................................................................................................. 25

3.7 Communication Plan ............................................................................................................. 25

3.8 Project Close ......................................................................................................................... 26

7 | P a g e

3.9 Outline each phase (breakdown of sprints) .......................................................................... 26

3.10 Which tools were used ......................................................................................................... 27

Appery.io ....................................................................................................................................... 27

Github .............................................................................................. Error! Bookmark not defined.

AppGyver ...................................................................................................................................... 27

Brackets ......................................................................................................................................... 28

Sublime Text .................................................................................................................................. 28

Cloud 9 .......................................................................................................................................... 28

Xcode ............................................................................................................................................. 28

Android Studio .............................................................................................................................. 28

4 System design ............................................................................................................................... 29

4.1 Chosen technologies with reasons ....................................................................................... 29

Google Maps API ........................................................................................................................... 29

CSS ................................................................................................................................................. 29

Javascript .......................................................................................... Error! Bookmark not defined.

jQuery and jQuery Mobile ............................................................................................................ 29

4.2 System architecture / topology – UML deployment diagram .............................................. 30

4.3 Design history ....................................................................................................................... 37

5 Design and System testing ............................................................................................................ 38

5.1 Describe the development process used .............................................................................. 38

5.2 Discuss pros and cons of development process used ........................................................... 38

5.3 What unit / system testing was done and by whom ............................................................ 38

6 Implementation ............................................................................................................................ 39

6.1 Discuss process of making system live – data loading / rollout / user acceptance .............. 39

6.2 Illustrate and explain the main aspects of the final system ................................................. 39

7 Conclusions ................................................................................................................................... 41

7.1 Reflect on the process and the outcome .............................................................................. 41

7.2 Successes - Stories ................................................................................................................ 41

7.3 Failures - Stories .................................................................................................................... 41

7.4 Lessons Learned .................................................................................................................... 42

7.5 Further development ............................................................................................................ 42

References ............................................................................................................................................ 43

Appendices ............................................................................................................................................ 44

Unlicense ........................................................................................................................................... 44

8 | P a g e

List of Tables Table 1 Locations .................................................................................................................................. 19 Table 2 Meetings ................................................................................................................................... 19 Table 3 Team Roles ............................................................................................................................... 25

List of Figures Figure 1 UML Use Case ......................................................................................................................... 18 Figure 2 Proposed Entity Relationship Diagram ................................................................................... 19 Figure 3 Project Life Cycle ..................................................................................................................... 22 Figure 4 Version One Product Backlog .................................................................................................. 23 Figure 5 Project Gantt chart .................................................................................................................. 24 Figure 6 Project Phases ......................................................................................................................... 26 Figure 7 UML Deployment Diagram ..................................................................................................... 30 Figure 8 UML Sequence Diagram .......................................................................................................... 30 Figure 9 Home Page .............................................................................................................................. 31 Figure 10 Meeting Finder ...................................................................................................................... 32 Figure 11 Contact Us ............................................................................................................................. 33 Figure 12 Questions and Informations ................................................................................................. 34 Figure 13 News and Updates ................................................................................................................ 35 Figure 14 Site Map ................................................................................................................................ 36

List of Abbreviations G.A. Gamblers Anonymous

JS JavaScript

API Application Programming Interface

DOM Document Object Mark-up

HTML Hypertext Mark-up Language

IDE Integrated Development Environment

PMBOK Project Management Body of Knowledge

PHP An open-source server-side scripting language

JSON JavaScript Object Notation

AJAX Asynchronous JavaScript and XML

9 | P a g e

Chapter List 1. Introduction

In which we introduce the Team, the Client and the nature of the problem and proposed solution

2. Requirements In which we detail the client requirements

3. Project Management In which we detail the project management approach we took to manage the implementation of the proposed solution

4. System Design In which we detail the proposed solution

5. Design and System Testing In which we detail the development of the proposed solution

6. Implementation In which we detail the implementation of the proposed solution

7. Conclusions In which we draw our conclusions from the process and reflect on what we have accomplished

10 | P a g e

1 Introduction The Seeker team comprises of Bernard McGinley, Paul Flood, Margaret Moore, Colm Kennedy and Peter Byrne. We, as Diploma students in Trinity College Dublin, were approached by Gamblers Anonymous (GA) Leinster division, to provide a solution to a problem they have.

We came together as a team to decide a project. We had 2 on the table proposed by our team members. A more traditional choice of a consultancy timesheet and client management tool for a local Business Innovation Centre, and the Gamblers Anonymous mobile web application. The consultancy database was deemed too similar to a previous year’s project. As a team we decided that we’d be happier seeing a product of our efforts in use for a good cause.

1.1 Client Background Gamblers Anonymous Leinster are a division of the worldwide Gamblers Anonymous. The fellowship of Gamblers Anonymous came about as a result of two men meeting during the month of January in 1957. Both men began to meet regularly and as time passed neither had returned to gambling (Gamblers Anonymous, n.d.). Gamblers Anonymous now arrange regular meetings that are held in many locations around the world and through the power of attending meetings on a regular basis, it gives members of the fellowship an opportunity to get their lives back on track and an ability to lead a normal life. Almost 44% of the Irish population play the national lottery regularly. We spend over €5 billion a year on gambling and finally and most important only 1% of Irish people who need treatment for gambling addiction actually receive it (Administrator, 2011). Our aim is to help people with gambling addiction and to get make more people aware of the help and support that are out there. The biggest issue that they face is getting this information out to the public.

1.2 Overview of Project This leads us to the project at hand. Team Seeker, working with the client, identified a need for a mobile friendly information service. The purpose of this project is to provide an easier way for the person on the go to gain access to the required information that will help them understand compulsive gambling as an addiction and also give the user the required information to get them to a meeting.

With these requirements in mind, team Seeker engaged with the client to develop a mobile web application. The information and functionality contained within the web application must adhere to client’s requirements. In essence they are looking to provide a free, easy to use and navigate, mobile application, which will provide current and relevant information to the end user while maintaining their anonymity. All of these elements have been the core of the build process and have provided team Seeker with the wireframe to proceed in the development of this web application.

1.3 The Business Problem After meeting with the client, Gamblers Anonymous Leinster office, we were asked if we could develop a solution to their problem. They were looking for something that could help them answer the most asked questions in their mailbox.

Gamblers Anonymous were looking for a way to get meeting information to members and non-members alike, in a simple and clear manner and if possible get this information to a mobile device since this is now the easiest way of giving information. The information they primarily want to supply to the end-user is meeting information, location, start times, which days meetings are on, etc.

11 | P a g e

They were also looking for a way to answer the more commonly asked questions on their website, including:

1. “Where is the nearest Gamblers Anonymous meeting to me?”

2. “What do I need to do to attend a Gamblers Anonymous meeting?

3. “I need help, can I talk to someone?”

4. “I have a family member who needs help. What can I do?”

On reflection of the problem at hand, we, team ‘Seeker’ decided, in conjunction with the client representative, that we would develop a mobile web application to address this need.

1.4 Objective of the project Gamblers Anonymous (http://www.gamblersanonymous.ie) is a worldwide organization that helps people overcome gambling addiction. People from all walks of life can develop addiction. Throughout Ireland every county has G.A. meetings. These meetings are not always held in the same place or at the same time. We want people to be able to find their nearest meeting, the time it’s due to start and whether it’s been cancelled or not.

Most people these days have a smart phone or access to one. We want easy access to the G.A. on their mobile device. This will be easy to navigate and find the information that’s on the web site.

This web application will also be able to give their nearest meetings. We will be able to show this by using GPS. If the member has no GPS facility on their phone we will default to an overview of Ireland that the user can then navigate in a fashion consistent with user expectations.

Because of the nature of the site we will, as far as is practicable, have total anonymity. No information of the member will show up on the site. In addition to that we will also block ads from coming onto the screen. This will stop any gambling ads or other triggers from coming up on the site.

Anybody that looks at the web app for the first time will be able to get any literature needed before they go in to the meeting. Also on the application will be a link to the 12 steps page.

The main factor for us is to make sure that our application is like no other application currently available in Ireland. We have also been informed that whatever we produce will become the national standard for GA Ireland, as in our design and functionality will then be implemented into the current GA website.

The estimated cost of this project is €0.00

1.5 Proposed solution Gamblers Anonymous required a mobile web application that will work with data from their existing website and provide an easy to use meeting finder. Working with the client, team Seeker agreed that the web application would comprise of the following requirements:

- The web application would contain some static data including The 12 step programme, The Unity Programme, the “Just for today” quotes, FAQ’s.

- The application would have an easy to use map/meeting finder - The information supplied to the user could be updated in one location that would feed their

website and the web application - The web application would not record any user data so as to maintain their anonymity. - The web application could be used on mobile device that had internet access.

12 | P a g e

Team Seeker took these requirements on board and after careful consideration, decided that using the Appery.io framework was the best course of action to deliver a modern looking application in a timely fashion. The client agreed and the project was started. The project team also suggested that the creation of a database for all meeting information would be of considerable benefit to the project and to their existing website.

On reflection of the database proposal, the project team and the client, decided that the online database would fall outside of the scope of the original project, but would be worked on after the project had been submitted, as it would mean migrating the live site from its current shared hosting environment to a provider/package with a higher level of functionality. The team have also agreed to continue to work with the client to develop the web application to completion and to assist them with the creation and integration of the online meeting database.

1.6 Existing systems and processes Gamblers Anonymous currently have a website (www.gamblersanonymous.ie) which provides information that compulsive gamblers find useful. The website is primarily built with PHP and JavaScript.

1.6.1 Issues with current systems Unfortunately their current website is not mobile friendly. With the huge increase in the number of mobile users over the past few years, Gamblers Anonymous feel that they should provide a more suitable solution. With mobile technology being the more prevalent platform for accessing information today, their existing website is no longer suitable. Currently a person wishing to find information about a meeting would have to go through a large series of clicks to find the information they require. On a mobile device and at present this is not any easy task, which Gamblers Anonymous believe is stopping people getting the correct information regarding meeting locations and start times.

1.7 Relationships to existing systems / integration Gamblers Anonymous current website provides a large amount of information to the general public regarding compulsive gambling. This information allows people to seek help and advice and read some personal stories regarding compulsive gambling. These stories are provided by current members of their fellowship. The website is composed of primarily PHP pages with some basic JavaScript functionality, but the site is not mobile friendly. The current website is not using a CMS (Content Management System) and as a result updating information can be a lengthy task and menu pages have to be updated in numerous locations. As a result of this there is no consistency with the data in the site. The website update process is also time consuming as it requires FTP access to download a file, modify it, save it and upload.

The client has requested that information contained in the web application is to be updated in only one location on their existing website, ensuring that there is no overlap of workload and data consistency is guaranteed. The project team agreed with the client on a single place for data entry but for this to be beneficial to the existing website a Content Management System will be required for their existing website. This also falls outside of the scope of the project. The client has also expressed a desire for the web application to provide information on meetings based in the United Kingdom and Scotland. In response to this request, the project team have explained that this request will be addressed after the submission of the project to the college, when time is not a limiting factor to the projects development.

13 | P a g e

Using the existing data provided by the www.gamblersanonymous.ie website, we have added links within the web application to their website.

14 | P a g e

2 Requirements 2.1 Summary of requirements

2.1.1 User Stories and how they were addressed

As a user, I want to access the app on any mobile device, so I can always access the app

We decided to implement this requirement by developing the application as a mobile web application, allowing the user to access from any connected device, and removing the requirement to maintain a separate codebase for each potential platform

As a user, I want to get Meeting information so that I know what the meeting will be about

We decided to implement this requirement by adding an info-window to the meeting marker on the google map, as we felt this would be a familiar and natural usage for most users

As a user, I want to get up to date data so that I know have info on meetings

We decided to implement this requirement by linking the news content within the app to the live Gamblers Anonymous website

As a user, I want filter on start time, so that I can easily find meetings I will be able to attend

We decided to implement this requirement by running the markers array through a filter based on the current time before re-populating the page.

As a user, I want filter pinning, so I can find the next or nearest pinning meeting

We decided to implement this requirement by setting a custom icon on pinning meetings on the map

As a user, I want filter on closed, so I can avoid open meetings

We decided to implement this requirement by setting a custom icon on closed meetings on the map

As a user, I want filter on open, so I can avoid closed meetings

We decided to implement this requirement by setting a custom icon on open meetings on the map

As a user, I want to be able to get access literature about first meeting so that know about the meeting

We decided to implement this requirement by pulling data from the existing FAQ section form the live website within the mobile application.

15 | P a g e

As a user, I want to be able to see calendar for meetings so that I know when the meetings are on

We decided to implement this requirement by adding a separate page with a table populated from the meetings array – flagged for future development

As a user, I want to be able to export Calendar ‘.ics’ file, so that I can save meetings to my local device

We decided to implement this requirement by creating a downloadable .iCal file from the meetings array – flagged for future development

As a user, I want to be able to get a one click to call helpline so that I have quick contact with a support group

We decided to implement this requirement by adding a formatted contact us page, with phone links to bring up the native phone handler on the device, phone app on mobile devices, Skype/link, etc. on desktops or tablets

As a user, I want to be able to find based on current location, so that I can find a meeting nearby wherever I am

We decided to implement this requirement by automatically centring the map on the user’s location if enabled, or on the whole of Ireland if not. Users can then manipulate the map in a manner natural to them to view surrounding meetings, zoom in or out. Or they can use the page controls to see specific days or counties

As a user, I want to see on interactive map closest meetings so that I can plan my closest meeting

We decided to implement this requirement by adding a google map to the site, and layering the meetings on this as standard markers, in order to keep the interaction as natural and conformant to user expectations as possible

As a user, I want to be able to free type a location if I don't have a GPS enabled device or I have the GPS feature disabled, so that I can find my closest meeting

We decided to implement this requirement by adding a free search text box, linked to the google maps address search field, and update the map centre point and zoom based on this – flagged for future development

As a user, I want to know my 3 closest meetings so that I have a choice of meetings

We decided this requirement was already sufficiently addressed in the interactive map above, and that the 3 meeting rule was not relevant in the context of the map application

16 | P a g e

As a user, I want to specify search range so that I can change the range to my closest meeting

We decided to implement this requirement through the use of the google maps zoom function. Meetings outside the range of the window would not be visible to the user.

As a user, I want no ads on site so that no gambling ads are on the screen

We decided to implement this requirement by hosting the app on the gamblers anonymous website, so we would have control of the hosting environment and ensure that no ads were present.

As a user, I want a low click count so that I can quickly get the information I need

We decided to implement this requirement by adding the map page as a first level subpage from the home page, and set it to automatically load the meetings for that day. We also felt that the use of different icons for the different meeting types would convey that information to the user quickly without them having to set a large number of options in advance.

As a user, I want mail link to organisers so that I can keep in touch with the organisers

We decided to implement this requirement by adding a contact link to the page, using the same contacts as on the live website.

As a user, I want easy navigation and search so that I can find what I need quickly

We decided to implement this requirement by using a standard google map, which we felt the end users would already be familiar with. We added large icons to the map to allow for ease of use for less dextrous users.

As a user, I want updated content in one location so that I can quickly see what has been updated

We decided to implement this requirement by pulling the news content from the live website

As a user, I want to maintain anonymity so that nobody know who I am

We decided to implement this requirement by pushing all the logic into the client device. All that is recorded on the GA servers is the page request.

As a user, I want easy to read font so that I can read the text

We decided to implement this requirement by defaulting to a Sans Serif font

As a user, I want no resize page for info so that everything is readable

We decided to implement this requirement setting the default font size and layout to maximise readability, preventing the user from having to manually zoom in as may be the case on a desktop styled app

17 | P a g e

As a user, I want to have buttons to a decent sized and not overlapping so that the screen is usable

We decided to implement this requirement by following good design practice

As a user, I want a scrollbar notice if meeting cancelled so that I know that the meeting is cancelled

We decided to implement this requirement by adding a ticker to the news page, pulling info from the live website

As a user, I want to have it multi language so that more than English speaking people can avail of its services

We decided to implement this requirement by adding a script to detect the user language of the device, and offer a google translate option if it’s not English – flagged for future development

As a user, I want Gam-Anon info so that I can understand the process

We decided to implement this requirement by adding a page containing this info, pulled from the live website

As a user, I want a link to 12 steps so that I have a program of recovery

We decided to implement this requirement by adding a page containing this info, pulled from the live website

As a user, I want to have a list of counselling links so that I have contact information for extra support

We decided to implement this requirement by adding a page containing this info, pulled from the live website

As a user, I want a ‘Free Time Calc’ so that I know how long it has been since my last bet

We decided to implement this requirement by linking to the existing free time calculator on the Gamblers Anonymous website

18 | P a g e

2.2 UML Use Case Diagram Below is a diagram showing how users access the different types of information from within the web application.

Figure 1 UML Use Case

The UML Use Case above shows the Seeker accessing the app to:

Check news

Find a meeting

Calculate the time since their last bet

Contact Gamblers Anonymous in their area

It also shows the Google Maps servers feeding map data to the embedded map within the app, and the Gamblers Anonymous representatives listed on the Contact Us page receiving Phone Calls or Emails

19 | P a g e

2.3 Entity Relationship Diagram By using the data below we can create the required tables and relationships. This database would have been accessed by jQuery and would return arrays of meetings based on the search criteria entered. Ultimately this was not implemented on the grounds of user privacy, as we wanted nothing server side to be aware of the users actions within the app, and due to the migration of the webserver this would have mandated, which was deemed an unreasonable imposition on the resources of Gamblers Anonymous.

Figure 2 Proposed Entity Relationship Diagram

The database itself will be made up of the following tables

Table 1 Locations

Coordinates (PK) Notes Address

Array in form [Latitude, Longitude]

String String

The Coordinates of the meeting Any special notes about the location

The address of the location

Table 2 Meetings

Weekday (PK) Starttime (PK) Coordinates (PK, FK)

IsGamanon IsPinning IsOpen

String Array in form [Hour, Minute]

Array in form [Latitude, Longitude]

Boolean Boolean Boolean

The day of the week the meeting is held

The time the meeting commences

Reference to the location in which the meeting is held

Is the meeting a Gam-Anon meeting?

Is the meeting a Pinning meeting?

Is the meeting Open?

20 | P a g e

3 Project Management

“Application of knowledge, skills and techniques to execute projects effectively and efficiently. It’s a strategic competency for organizations, enabling them to tie project results to business goals” (Project Management Institute, 2008)

Project Model

Using Project Management Body of Knowledge (PMBOK) we were able to use the five process groups: initiate plan execute, monitor and control and close the project. We used this methodology in our project management class so we used that knowledge to our advantage. The app will also be updated and maintained when the project is finished.

3.1 Project Structure

3.1.1 Project Scope We hope to implement the app by uploading it to the Gamblers Anonymous web site.

Learn about JavaScript and HTML 5 through video tutorials, and other free resources such as W3Schools.

We wanted to keep cost to a minimum by using free software.

This application is a massive change for Gamblers Anonymous moving forward. It will make it very easy to find new meetings on our navigational search engine and information for new members through the mobile first pages. This is the first web application that Gamblers Anonymous Ireland has created.

We created a storyboard and designs for the front of the app for the client to see and change as they saw fit. Using Version One to implement agile methodology we were able to alter the requirements during the execution phase.

The application will be supported on Android and iOS, on tablets and smart phones.

When the project is finished Team Seeker in partnership with the client will work on the app elements that were initially out scope of the project or that fell out of scope due to setbacks with the development and implementation. This will include training of the client and maintaining and support of the application. There is also a possibility that the application will be used in other countries.

21 | P a g e

3.1.2 Constraints Lack of programming experience.

The only experience members of the team had were the modules taken within the course, covering basic HTML, JavaScript and Visual Basic technologies.

Time.

In addition to the workload for this module, team members had to cope with the additional assignments and study necessitated by the course, as well as the 2 main coders dealing with on call and out-of-hours requirements, along with business travel throughout the year.

Budget.

As this was a college project for a voluntary fellowship there was no budget to deliver this. We had to use free student versions of applications and platforms with often limited functionality. We also could not mandate the use of licensed or commercial software as the client also has a very limited budget to work with.

3.1.3 Assumptions - That the project team will assign Thursday evenings and Saturdays to work on this project. - Issues encountered will be resolved in a timely manner. - The project charter will precisely reflect the scope. - The client will use the application when the project is completed. - The client will appoint someone outside of the project team capable of maintaining the

product once released. - The client will be available for input of information towards the project. - That the client wants a fully functional application at the end of the project. - The client wants the application to work in the Ireland. - All team members will participate equally to the project. - All team member will stay for the period of the project.

3.1.4 Critical Success Factors The most critical factor of the project was to get it finished by the 23rd of March. We also needed to use everybody’s skills to achieve our goals. Sticking to our sprints was a critical part of the success of our app; we were able to judge how well we were going in terms to the time frame of the project. Security processes and procedures must be in place before any sensitive data is accessed.

- G.A. is more accessible to people - Makes it easier to find closest meetings - One click phone support to member - No ads on the screen to stop gambling ads - No personal information stored - To have the app working on all mobile devices

22 | P a g e

3.1.5 Project Life Cycle The project was split into the five process groups of PMBOK with each having different goals and milestones. To achieve our goals we had practical milestones to reach with each person participating to move us onto the next process.

Figure 3 Project Life Cycle

3.1.4 Project Schedule

At the start of the term we decided to make a schedule for the year. After primary discussions we created a project starting point timetable for the main project achievements. Most of us had never used agile before and never had a project of this magnitude or difficulty so we thought that this would be very important for the rest of the project. We also felt that as we go on in the project and learning in various classes that the scheduling would improve. At the start of each week we each placed into a schedule the days we can work on the project our class times and holidays. With that schedule created we were able to assign tasks and get cover for people that couldn't make those dates. It was suggested that we do a minimum of 160 hours each in total. We all committed to those hours and that included Thursdays, Saturdays and working from home. Near to the end of the year we agreed to come in on Monday and Friday evenings and Sunday mornings.

The team assigned group and individual deadlines that we couldn't miss, and by achieving these gave us confidence going forward to the next one.

23 | P a g e

3.2 Chosen methods (with reasons) We researched different methodologies and tested against our project and decided that agile was the best for us. We started using this early on in the project as this was known to us through our CS2013 class. The platform that we used for agile was Version One. One of the main factors of using Version One is that it’s free.

Version One allowed us to put user stories up, assign then into sprints that were in feasible timelines and to have an overall plan going forward.

Figure 4 Version One Product Backlog

Product Backlog Sprint Backlog Weeks Potential Working App

We continued to use this cycle until the project was finished.

3.3 Project Goals Team Seeker have agreed that the goals to be completed for this project are as follows:

- Provide a working prototype web application for the client based on the client’s requirements.

- Educate the client in the ongoing maintenance and management of the application. - Produce a comprehensive document to detail the project’s development from start to finish

(submission) - Provide a presentation to the client and the college outlining the web application

functionality and demonstrating its workings. - Use the skills and techniques amassed over the past two years in college and the existing

knowledge the team and provide evidence that said knowledge was understood and used appropriately.

24 | P a g e

- Develop a web application to allow users to locate the nearest Gamblers Anonymous meeting based on their current location.

- Allow the user to do one-click calling to a predefined contact number or email address. - Allow users to search for meetings based on a drop down list of the days of the week. - Allow users to search for meetings based on a list of counties. - Provide the user with information on the meeting of their choice, including start time, room

number or any other relevant meeting information. - Provide the user with information relating to the Gamblers Anonymous 12 step programme. - Provide the user with information relating to new and updates (content to be retrieved from

the existing website). - Provide the user with information on the “Unity programme”. - Provide the user with the FAQ information already available on the existing Gamblers

Anonymous website. - Have a working prototype for the client at least 4 weeks before the presentation date (End

of February).

3.4 Overall project schedule (Gantt)

Figure 5 Project Gantt chart

25 | P a g e

3.5 Team Organisation The team was made up of five individuals with many different backgrounds and experiences. The tasks were divided out depending on the team’s strengths. The remaining tasks were then divided out into the chapters to be finished. We wanted everybody to gain experience in all aspects of the projects so we sometimes had two people working on the same section.

Table 3 Team Roles

Project Role Responsibility Team Member

Project Sponsor Client representative Liam

Documentation, Design, Coding

Additional development work Peter Byrne

Documentation, Design, Testing

Primary design work Margaret Moore

Documentation, Project Manager, Testing

Primary documentation work Paul Flood

Documentation, Coding, Testing

Primary development work Bernard McGinley

Documentation, Testing Additional design work Colm Kennedy

3.6 Team Brainstorming At our second meeting we had a brainstorming session. In brainstorming all ideas were though thoroughly and in some we took ideas and added them to our final draught. Some of the brainstorming ideas were:

1. Using app on different devices

2. Using a platform to design the app

3. Using GPS and interactive map to find meetings

4. Able to access a calendar to see meeting dates

5. Use free software to keep the app free.

6. To have links to counselling

7. To keep it ad free to block gambling ads

3.7 Communication Plan We had a few obstacles at the start of the project getting off the ground. Communications would clearly be one of the larger obstacles in our path.

At the start of the project we all sat down and discussed the best way of communicating with each other. It was decided that getting in contact through a phone was the wisest decision. We set up a group chat in WhatsApp. In this we also included our supervisor for communicating with him directly with the group. We had a few obstacles at the start of the project as we all had a lot of different assignments and another group project so we set up a WhatsApp group to keep everybody informed of what’s going on and a Google drive account to upload our documentation and notes. With most of our team in full time employment it was imperative that we kept in contact for the full course of the project.

We already had a client liaison representative that knew and dealt with the client. This worked well when the client was unavailable to come into the meetings. We had most Thursdays free so we used that free time to meet up to assign work and to see where we were in relation with the sprints. After Christmas we decided to meet up on a Saturday for a few hours to do work. On a Tuesday and

26 | P a g e

Wednesday after class we had face to face meetings to organise work for Thursday night. Bernard took meeting minutes and Paul recorded the meeting for use later in documentation and minutes. Using the minutes we were able to document when and where certain ideas came from, and were able to refer back to earlier meetings for discussions around decisions that had needed to be made. We spoke about using Skype if we needed to but we never had to use it.

Before we set up WhatsApp we used our college email account. This was ok at the start but after a while we had to browse through each email to find the relevant information so this wasn’t feasible long-term.

3.8 Project Close This is the last phase of the project life cycle. In it we finished our testing, programming and documentation. Paul made sure that all criteria was met in the correct timeframe. We handed the app over to our sponsor in G.A. We arranged a meeting with our sponsor and went through the requirements that they wanted. Future development and maintenance was discussed and expanding it to encompass England, Scotland and Wales. The application was then handed over then sponsor.

Figure 6 Project Phases

3.9 Outline each phase (breakdown of sprints) Phases / Iterations

Version 0.1 - Static content created within the Appery.io environment the app showed the current location of the user on a map of Ireland. Working with Appery.io, we found that creating the user interface was straightforward. There are some very intuitive online demonstrations. The one that was of most use was the “Using the Google Maps API” tutorial located at http://devcenter.appery.io/tutorials/using-the-google-maps-api . This gave the team a good basic understanding of how we could integrate the Google Maps API into our web application.

Version 0.2 - Created menus to control the map within Appery.io. It could zoom and centre on a specific meeting location based on a drop down menu selection, but could not dynamically assign markers. With these menu controls working but the markers causing problems we completed more reference work to try and locate solutions to our marker problem. Appery.io was proving to be a very difficult tool to use for our purposes, as what would traditionally be back-end or server side functionality, we had restricted ourselves to performing within the client device for anonymity purposes.

Version 0.3 - After 6 weeks of trying to get simple JavaScript queries to run successfully in Appery.io we, as a team, decided to abandon the appery.io platform and return to a purely textual development environment. It was proving too time consuming to continue to try and get our code to work with the Appery.io framework.

27 | P a g e

3.10 Which tools were used We chose to develop the app in HTML5 and JavaScript rather than develop native apps using Xcode or Android Studio to allow us to maintain a single code base, and to develop the application in a consistent cross-platform fashion. Any HTML5 content could be reliably displayed on any platform that supported a basic web browser.

Appery.io Appery.io is a web development platform that initially allowed us to rapidly develop the application GUI. In our initial examination it seemed to operate in a manner very similar to Visual Basic, which we had experience of from CS1104 and CS1106. Unfortunately we found that as development progressed we struggled more and more to implement application logic within the framework, and that relatively simple page manipulation was taking inordinately long times. We also struggled to interact with the Google Maps API in the desired manner via the Appery interface. After twelve weeks of trying to get our code to work and integrate into the application we discovered that this was not an easy process. The tutorials on their website were of little use as many of the tutorials are based on different version of the product and there was no uniformity within the application itself. Appery was forcing us to learn their way of applying code within their application, which would not be easy to maintain in the long run.

After long consideration and a very intense team meeting it was decided that we would scrap Appery.io and continue with a HTML5 and JavaScript solution. This decision was not taken lightly as it mean the development of the project was knocked back over two months.

This decision had a major impact on the progress of the project as we had to throw 2 months of attempted development work away.

Ultimately we abandoned this platform, and the work we had done in it, as the code it generated when exporting was not easily extended with our limited knowledge of our chosen technologies.

GitHub After abandoning Appery.io and losing the advance functionality that came with it. We moved to a git repository to hold our data.

AppGyver When the project team decided to no longer use the Appery.io wireframe, the project team were faced with finding a suitable alternative. After some investigation into the available platform tools available to the project team, we decided on using AppGyver. The tool comprises of many similar elements that Appery.io had but integrating our functionality code into AppGyver was easier than the experience we faced with its predecessor. Unfortunately team Seeker were behind on the project so it was decided that we would focus on the visual elements of the web application so that we would have something to show for the work that was already completed.

Using AppGyver we were able to produce the required page wireframe for the web applications that had a very user friendly interface. Team Seeker already had a working version (in HTML5 and JavaScript) of how the web application would work. AppGyver allowed us to apply our existing JavaScript into our newly created web application, and will ultimately allow for native app creation from our current web only content

28 | P a g e

Brackets Adobe Brackets is a free editor designed for web development, which links to the chrome browser for live display of changes made. This allowed us to work on local copies of the HTML and JavaScript files and see the impact of changes made, without having to wait for the Gamblers Anonymous Webmaster to manually load files to the website

Sublime Text Although lacking the live preview of Brackets, Sublime had many power user features that made editing large swathes of the Data Set relatively quick and painless. We made great use of its multiline editing ability.

Cloud 9 After abandoning Appery.io Cloud 9 became our next main development environment. Its cloud based nature was great for collaborative work. And it integrated with GitHub, so changes made in it were consistent with Check-ins from Sublime and Brackets users, but less advanced users could operate without needing to be fully aware of what was happening in the background.

Xcode Xcode was used purely for its iOS simulator, which allowed us to test the app on a wide variety of

iPhone and iPad models in a short space of time.

Android Studio Similarly, Android Studio was used for its android virtual device facility, allowing us to see how the

app would look on various different android display sizes.

29 | P a g e

4 System design 4.1 Chosen technologies with reasons

Google Maps API We chose the use the Google Maps API due to the wealth of documentation available for development, and for the immediate familiarity users would have. By loading the API and interacting with it locally, the only data that is transmitted is the actual raw map data that is rendered within the app. Markers, etc. are all client side only. We were able to confirm this in testing by setting devices to “Airplane Mode” with the page loaded, and continue to operate with the only visible impact being the “Sorry, we have no imagery here” warning displayed by the embedded map.

CSS CSS allowed us to develop the app quickly, without getting hung up on stylistic choices early in the process, and allowing them to be retrofitted at a later date without impacting functionality.

JavaScript JavaScript allowed us to process much of the application logic on the client side, preventing repeated calls to server-side services that may have compromised user anonymity.

jQuery and jQuery Mobile JQuery is a JavaScript library that allowed us to perform actions asynchronously, and to better manage events, user interaction and page manipulation. Using this we were able to pull the content from the existing website into the app without having to manually recreate it, and we were able to ensure that any change made to content on the live website would be reflected within the app on load.

30 | P a g e

4.2 System architecture / topology – UML deployment diagram

Figure 7 UML Deployment Diagram

Overview of system design – UML class and sequence diagrams, navigation map, wireframes for User interface

Figure 8 UML Sequence Diagram

31 | P a g e

Figure 9 Home Page

Home Page:

The home page contains a copy of the introduction on the www.gamblersanonymous.ie website.

From the home page the 4 key areas for the user are clearly defined and are mapped as follows:

Find a meeting

Contact Us

Questions and Information

News and Updates

These links bring the user to the required pages and offer an easy to follow map of the application.

32 | P a g e

Figure 10 Meeting Finder

Find a Meeting Page:

The Find a meeting page allows the user to locate meetings based on their choice of search methods

Search by Day, allows the user to show only meetings that are running the selected day.

Search by County, allows the user to search for meetings based on their county search.

The default view will show all meetings running on today. The initial zoom is set to the whole of Ireland.

As the nearest meeting maybe in a neighbouring county we decided not to filter the results by county, instead the app would zoom into the county allow the user to see neighbouring county meetings on the day selected.

In Production this was amended to include the map controls is a side panel opened via a menu button

33 | P a g e

Figure 11 Contact Us

Contact Us Page:

The Contact Us page allows the user to do one-click calls to the available numbers.

There is also the option to send an email to info@gamblersanonymous.ie, which is their monitored mailbox.

Currently these are the only contact numbers for Gamblers Anonymous Ireland.

34 | P a g e

Figure 12 Questions and Information

Questions and Information Page:

The Questions and Information page has links that allow the user access a collection of information. The information is useful for Gamblers Anonymous members, family and friends.

There is also a link to a Gam-Anon page to Ireland. This provides information for family and friends of gamblers.

The information page also links to the 12 Step program, the Unity program and the ‘Just for today’ pages.

35 | P a g e

Figure 13 News and Updates

News and Updates Page:

The New and Updates page is linked directly to the updates page on the www.gamblersanonymous.ie website. Updating the content on the website in one location was also a requirement from the client.

36 | P a g e

Figure 14 Site Map

37 | P a g e

4.3 Design history Initial designs for the app were back of the envelope type sketches with the client representative. This built up a basic blueprint that we would refine and re-implement as the development platform changed.

Our next step was to layout the design in Appery.io, which due to its drag and drop nature proceeded rapidly, with only minor changes needed to accommodate the development realities.

The same layout was then recreated by hand in the native HTML version of the app and in the AppGyver environment, as shown in section 4.2. Tweaks to layout made at this point were replicated to the native HTML environment.

The final HTML design was based on the above, with minor tweaks to better take advantage of functionality offered by the jQuery Mobile toolset.

38 | P a g e

5 Design and System testing 5.1 Describe the development process used Development followed a hybrid of waterfall and agile practices. Our initial process was very much in the waterfall style, with large chunks of time spent setting up the platform and the front end display, before launching into a series of sprints incrementally adding functionality. After our switch from Appery to native HTML5 and JavaScript we followed a much more consistent Agile approach of incremental improvements and modifications. We would deliver basic functionality to show the client, and layer on elements and additional functionality as we proceeded through sprints, with the client giving direction on features he expected to see, or that he was inspired to request through additional usage.

5.2 Discuss pros and cons of development process used The agile methodology allowed us to implement and demonstrate specific features, with minimal conflict over usage. A particular function could be written, and changes to the web page needed to implement them could be made, allowing the site to be functional almost continuously throughout the development process, and without long delays waiting for the coding team to catch up to the design team.

5.3 What unit / system testing was done and by whom Using the www.jsfiddle.net website each member of the project team was able to test each piece of code and its functionality as it was developed. The site was very useful as it gave the team the ability to test and try each section of the code in isolation. The results were instantly visible.

The stages for testing were broken down as follows

- Test the HTML5 code - Test the JavaScript for the Google Maps API - Test the Marker array creation - Test the Map clearing on each day selected - Test the information provided on each marker - Ensure that no duplicate or incorrect information was shown on each marker - Test each link and verify that the correct page shows for the users selection

39 | P a g e

6 Implementation 6.1 Discuss process of making system live – data loading / rollout / user acceptance With the two month set back in the development stage the project completion date has slipped to the end of May 2015. The client is aware of this and as a result they have agreed to a go live date of 1st June. The team have agreed that the web application will be accessible from the www.gamblersanonymous.ie home page. We are also looking at other ways of advertising this new service with other support groups. As of March 23rd the system is not live and is still in development stage. Team Seeker have agreed with the client that a number of members will be the user test group and they will have access to the web application from 23rd May onwards.

The current data loading process will be maintained by a member of team Seeker until a written support manual is completed and presented to the client. All web application static data will be retrieved from the existing website. In relation to meeting data, a member of team Seeker will provide the client with the required support until the official handover on 1st June.

The results from the user acceptance testing is to be documented and discussed by team Seeker and any bug fixes will be addressed in a timely manner. If there are any major bugs team Seeker have agreed to work through the resolution stage until the client is happy with the end product.

If there are any feature changes or enhancements that the client would like, we have agreed that these fall outside the scope of the project and can be addressed in the future but the work may or may not be carried out by team Seeker. We will however aid the client as best we can.

As stated earlier, the current meeting information is stored in a single JavaScript file. This will be moved to an online database so that meeting information can be updated easily and in one location.

The work completed to date will be released to the client under the “unlicense” license. The team discussed the various open source licenses available to issue the software under, and determined that this gave the client the most possible freedom to use and adjust the code delivered to suit their changing requirements, and to expand the scope internationally, without needing to review and comply with any licensing requirements. This may seem a moot point, as HTTP source is always available, but as specific licenses may require the client to release any future changes under the same license this may not always be suitable. If any professional development work is later required it may be the case that the Designer or Coder will object to this restriction being placed upon them. The “unlicense” specifically sidesteps this issue by disclaiming any interest in the software upon release.

6.2 Illustrate and explain the main aspects of the final system The main aspects of the mobile web application are the use of relaxing friendly and easy to navigate menu system, the fact that data content within the web application is pulled directly from the existing website (reducing the required time to complete updates and ensuring data consistency), using JavaScript and JQuery we can isolate meeting information based on the chosen day of the week or the selected county. Using these controls we are able to manipulate the markers that populate the Google Maps, and each marker relates to a specific meeting.

By using the GPS on their mobile device, the application will zoom into their current location, or to the default address that has been supplied. From there, the user can easily see what meetings are close by or close to the supplied address. Meetings are displayed on the Google map by using different icons for meeting types, which include Open or Closed and different colours are used to display different categories including standard meeting, Pinning meeting (to celebrate anniversaries of Gamblers Anonymous members or a Gam-Anon meeting (for family and friends of compulsive gamblers).

40 | P a g e

The Meeting Finder operates on a list of meetings, which are currently stored as objects in an array. It also stores a list of counties within Ireland, also stored as objects in an array.

On loading the page, the app embeds a google map of Ireland using a jQuery ready call to insert the map into the loaded page, sets up the event listeners detailed below, and insert the list of counties into the menu controls. It then determines the current day and time, and steps through the array of meetings looking for meetings on that day, and starting after that time. It then overlays the map with these meetings locally on the device. It then checks if the user has allowed location services on their device. If so it will centre the map on the user’s location and add a marker showing their location.

The app also contains controls to allow the user to view meetings for different days of the week, to centre the map on a given county, or to return to their location. These controls operate using the HTML5 DOM Event Listener functionality to allow the map element to listen for button presses and react appropriately from within the function that created the map. We found that trying the more traditional onclick calls from the buttons directly was unreliable at updating the content. When a given day is selected the app again steps through the meetings array looking for matches for the day property, but does not filter on start time. The counties control resets the centre point and zoom of the map to the centre point of the county.

The Meetings and Counties are stored in separate .js files to allow for more flexibility in retrofitting database or JSON calls to an external source once the live website is upgraded.

The Contacts page is populated using static content currently, but will be replaced with an AJAX call once the live website is upgraded. It includes the tel: and mailto: prefixes to enable native device handling of calls or emails.

The remaining pages hosting content from the website do so using jQuery to trigger an AJAX call to load the content of a live website <div> tag into the page.

The site buttons and controls are formatted using jQuery Mobile to allow for optimal display across various device sizes, and to better emulate device native controls.

41 | P a g e

7 Conclusions 7.1 Reflect on the process and the outcome Looking back over the project as whole the team felt that while certain aspects could have been handled better, the agile approach lends itself to rapid development and response to changing user requirements. This incremental improvement in functionality is very powerful in developing applications of this nature, given the restrictions in place, and it’s clear how in a larger project with sufficient resources in place much larger projects can be brought to task to deliver highly functional software. Our biggest issue overall was our falling prey to the sunk cost fallacy, we delayed throwing out the work we’d performed in Appery.io, because we felt like we’d spent too much time on it already to start over. In the end, the project delivered is of a higher value to the client do to its standards compliance, and low barrier to management

7.2 Successes - Stories One of the key successes of the project was the ability to integrate our JavaScript and jQuery code so that we could create an array of meetings and present them into the Google Maps. This was the basis of the whole project and the team are delighted to see it working correctly. Filtering the meetings per day gives the end user just the right information they require without being overloaded with unnecessary data. The user is then able to select any day of the week and the meetings that are available on that day are shown.

The second biggest success was the ability to migrate our code from the Appery.io wireframe into the AppGyver application, which is a much easier to use application development tool. This alone was a great success as the team felt that we had not lost all our work because of the difficulty in getting our application to work in Appery.io.

The third and by no means the least of our success was the ability of the team to actually work as a team and pull together when things didn't work out the way we were hoping. With the loss of 2 months through development issues, we were able to pull together, identify the areas of the project that needed the most attention and as a team continue through our big setback.

7.3 Failures - Stories The uphill struggle trying to get our code to work in the Appery.io wireframe. This was a result of us working against the platform. If we had been developing in a more normal Server side language, with display only on the client this would have been much less painful

The loss of development time resulted in the team not getting to create the online meeting database. We do intend to develop a DB backend to this, although it has not yet been determined if it shall be done in MySQL on the server as part of the initial page load, or Web SQL in client side storage.

The timing of the database lectures combined with a lack of pre-existing knowledge within the team worked to prevent the team from proceeding with creating a working online database in the time available.

42 | P a g e

7.4 Lessons Learned Take time to research the platform and tools before starting the project.

Plan the project and identify roles as soon as possible

Work in pairs or smaller groups to ensure that there is no duplication on work and that the workload is shared evenly.

Communication is key throughout any project. Regular meetings with status updates is vital to ensure everyone is informed and knows what's ahead.

Identify achievable milestones throughout the project and enjoy the satisfaction when these milestones have been reached / passed.

Keep the team informed on all personal aspects that can impede the project.

Work smarter - use the knowledge from lectures and apply it to each project you are involved in.

7.5 Further development Team Seeker have agreed with the client that we will continue to work on the development of the web application after the submission date of the project to Trinity College. We have also agreed that we will work with their current webmaster on the implementation of a meeting database that will allow for easier updating of meeting information in one location. Team Seeker, in conjunction with the client have also agreed that we will work on other ‘out of scope’ requests that the client brought up in the meetings held.

Team Seeker will also document how further updates to the web application can be managed by a representative from Gamblers Anonymous. The instructions will cover all aspects of the application and maintenance and it will be part of the final handover for the completed project.

43 | P a g e

References Administrator, 2011. Facts. [Online] Available at: http://www.gambleaware.ie/index.php/facts.html [Accessed 15 11 2014].

Gamblers Anonymous, n.d. Little Red Book. s.l.:Gamblers Anonymous.

Project Management Institute, 2008. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Fourth Edition ed. s.l.:Project Management Institute.

44 | P a g e

Appendices

Unlicense This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or

distribute this software, either in source code form or as a compiled

binary, for any purpose, commercial or non-commercial, and by any

means.

In jurisdictions that recognize copyright laws, the author or authors

of this software dedicate any and all copyright interest in the

software to the public domain. We make this dedication for the benefit

of the public at large and to the detriment of our heirs and

successors. We intend this dedication to be an overt act of

relinquishment in perpetuity of all present and future rights to this

software under copyright law.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. For more information, please refer to http://unlicense.org