GAMIFICATION OF ONLINE AFFILIATE...

SCHOOL OF COMPUTER SCIENCE

GAMIFICATION OF ONLINE

AFFILIATE MARKETING

AUTHOR: PAUL OGBEIWI DEGREE PROGRAMME: SOFTWARE ENGINEERING (MEng) SUPERVISOR: DR. KUNG-KIU LAU

ABSTRACT

PROBLEM STATEMENT Gamification is the application of gaming dynamics (such as fantasy, competition, receiving awards) into non-gaming contexts, in a bid to increase user engagement in a product, service, or campaign. The main purpose of this project is to implement gamification in the form of a website called Cuepenny, that uses the business model of online affiliate marketing. However, gamification alone may not ensure the constant addition of new customers; therefore the concept of viral looping has also been applied. The viral loop involves the steps that a new user goes through between purchasing or signing up to a product/service, and inviting other users to do the same. If both concepts are implemented properly, then viral looping attracts new customers, and gamification keeps them.

APPROACH After gathering functional and nonfunctional requirements using the MoSCoW model, I began to construct high level conceptual representations of the software architecture; starting with use-case diagrams, to the domain model, and then the design model (following the grasp principles); with each step edging closer to the final software implementation. These helped in ensuring that all angles were covered with respect to developing a well structured and maintainable website. I also had to construct the database architecture in a similar fashion; starting with an entity relationship (ER) model, to the relational model, and then the physical model (actual code implementation of database). This resulted in a database that was efficient and fully normalised (minimised size). A site map was created to comprehend the number of web-pages that would be needed for the website, and the flow between them. The web-pages (and other software files) were then divided up and implemented in 7 cycles of the incremental model; which is akin to multiple cycles of the waterfall model. After each cycle of development, the software was tested using unit and integration testing. At the end of the project, the website was tested for compatibility on different web-browsers and device formats, and then evaluated by users.

CONCLUSION The compulsory requirements for the website were all implemented. However, if the website is to be optimised for a massive user base, certain modifications and additions would have to be made to the website. On the bright side, the statistics from the user evaluation indicates that the there is a chance for a gamified online affiliate marketing platform to have some success.

1

ACKNOWLEDGEMENTS I would like to thank my supervisor Dr Kung-Kiu Lau for his short worded but precise style of guidance. I would also like to thank all my family and friends who have directly, or indirectly contributed to the completion of this report and project. Most importantly, I would like to thank the Lord Jesus Christ for guiding me through all these stressful years that I have attended the University of Manchester.

2

CONTENTS CHAPTER 1. INTRODUCTION 8

1.1 PROJECT OVERVIEW 8

1.2 GAMIFICATION 8

1.2.1 MCDONALD’S MONOPOLY 8

1.2.2 KHAN ACADEMY 9

1.3 VIRAL LOOPING 10

1.4 CUEPENNY - AIMS AND OBJECTIVES 11

1.4.1 AFFILIATE MARKETING 11

1.4.3 IMPLEMENTING GAMIFICATION 11

1.4.4 IMPLEMENTING VIRAL LOOP 14

1.5 TOOLS 14

CHAPTER 2. REQUIREMENTS SPECIFICATION 16

2.1 MoSCoW 16

2.2 STAKEHOLDERS 16

2.3 DOMAIN MODEL 17

CHAPTER 3. SOFTWARE DESIGN 18

3.1 DESIGN MODEL & GRASP PRINCIPLES 18

3.2 ENTITY RELATIONSHIP (ER) MODEL 19

3.3 RELATIONAL MODEL & NORMALISATION 19

3.4 PHYSICAL MODEL (DATABASE SETUP) 20

CHAPTER 4. SOFTWARE DEVELOPMENT 21

4.1 PLAN 21

4.2 FILES CREATED 23

3

4.3 TECHNICAL IMPLEMENTATIONS 24

4.3.1 LANDING PAGE 24

4.3.2 SIGN UP 24

4.3.3 LOGIN 25

4.3.4 SECURITY CONSIDERATIONS 25

4.3.5 USER PROFILE 25

4.3.6 BROWSE USERS 26

4.3.7 DISCOVERY 27

4.3.8 SUBSCRIPTION 27

4.3.9 NEWSFEED 28

4.3.10 USER PAYMENT AND AWARDS 28

4.3.11 CLICK VALIDATION 29

4.3.12 TOP UP AND WITHDRAWAL 29

4.3.13 ACID TRANSACTIONS 30

4.3.14 REFERRALS 31

4.3.15 CROSS-BROWSER AND CROSS-PLATFORM COMPATIBILITY 31

4.3.16 STATS BAR 32

CHAPTER 5. TESTING AND EVALUATION 33

5.1 UNIT TESTING 33

5.2 INTEGRATION TESTING 34

5.3 COMPATIBILITY TESTING 35

5.4 USER EVALUATION 36

CHAPTER 6. REFLECTION AND CONCLUSION 40

6.1 OBJECT ORIENTED PROGRAMMING (OOP) 40

6.2 DATABASE DENORMALISATION 40

4

6.3 CONCLUSION 40

BIBLIOGRAPHY 41

APPENDIX A. USE CASE DIAGRAM 45

APPENDIX B. DOMAIN MODEL 46

APPENDIX C. DOMAIN MODEL KEY 47

APPENDIX D. SUMMARISED DESIGN MODEL 48

APPENDIX E. ER MODEL 49

APPENDIX F. ER MODEL KEYS 50

APPENDIX G. RELATIONAL MODEL 52

5

LIST OF FIGURES AND TABLES FIGURE 1. McDONALD’S GAMIFICATION 9

FIGURE 2. THE VIRAL LOOP 10

FIGURE 3. CUEPENNY DESCRIPTION 11

FIGURE 4. USE-CASE DIAGRAM 17

FIGURE 5. DOMAIN MODEL 17

FIGURE 6. DESIGN MODEL 18

FIGURE 7. ER MODEL 19

FIGURE 8. RELATIONAL MODEL 20

FIGURE 9. SETTING UP DATABASE 20

FIGURE 10. OUTLINE OF PROJECT PLAN USING INCREMENTAL MODEL 21

FIGURE 11. SITE MAP SHOWING ALL PROJECT FRONT-END WEB-PAGES 22

TABLE 1. LIST OF CREATED FILES 23

FIGURE 12. LANDING PAGE 24

FIGURE 13. CLIENT SIGNUP FORM ERROR PROMPT 24

FIGURE 14. USER PROFILE 26

FIGURE 15. BROWSING A LIST OF EXPLORERS 26

FIGURE 16. THE DISCOVER BUTTON ON DREECE INDUSTRIES’ PROFILE (CLIENT) 27

FIGURE 17. THE SUBSCRIBE BUTTON ON DAVID OLANIYI’S PROFILE (EXPLORER) 27

FIGURE 18. GENERAL NEWSFEED 28

FIGURE 19. EXPLORER ALERTED OF SUCCESSFUL WITHDRAWAL 29

FIGURE 20. FUNCTION TO INCREASE ACCOUNT BALANCE OF USER 30

FIGURE 21. REFERRAL CODE SHOWING TIME OF CREATION 31

6

FIGURE 22. EXPLORER STATS BAR WITH ANNOTATIONS 32

FIGURE 23. CLIENT STATS BAR WITH ANNOTATIONS 32

FIGURE 24. EXAMPLE RUN OF getLevelTest() FUNCTION ON BROWSER CONSOLE 33

TABLE 2. INTEGRATED TESTING EXAMPLES FOR EACH CYCLE 34

FIGURE 25. CLIENT’S NEWSFEED IN THE 3 PROVIDED VIEWS 35

FIGURE 26. QUESTIONNAIRE STATISTICS FOR QUESTION 1 36





7

CHAPTER 1. INTRODUCTION

1.1 PROJECT OVERVIEW In a bid to sustain and increase revenue, businesses are always looking for ways to increase customer participation and satisfaction. As a result, concepts such as gamification and viral looping have been studied and applied by some of the most successful businesses in the world. As someone with entrepreneurial instincts, I decided to apply these concepts to a business model that I have had interest in; online affiliate marketing. These concepts will be applied to the business model in the form of a website called Cuepenny. Another area of interest in this project, is the application of interesting software engineering processes and models; such as the incremental software development model. On this report, the application of these highlighted concepts are fully explained and shown; but first, let’s get a brief introduction to some of them.

1.2 GAMIFICATION The global gaming industry is estimated to be worth £69 billion (UKIE, 2014); we do not really need much convincing that humans love games. The reason we love games so much is because we have an innate desire for: fantasy; competition; being successful; socialising; discovery; fun (Scirra, 2013). Gamification is the application of gaming dynamics into non-gaming contexts, to increase user participation in a service, product or project (Bright, 2014). Gamification has proved to be successful in areas that really have nothing to do with gaming, as shown in the following examples.

1.2.1 MCDONALD’S MONOPOLY

McDonald's is one of the world's biggest fast-food restaurants. You may disagree, but I assume that when we hear “McDonald's”, we think "food", not "gaming". Yet they make use of gamification by introducing the McDonald's Monopoly game which usually lasts a month. The game is explained in Figure 1. The game gets you to come back to McDonald’s by providing instant small prizes to give you the winning feeling; however, with the allure of winning the big prizes, people keep going back for more (Bhasin, 2011). People who do not even like McDonald's may end up going there just to win prizes. Proof of success? For the month of October 2011 (when they held the promotion), revenues rose 6.1% in Asia and Pacific regions, 5.2% in the U.S. and 4.8% in Europe when compared to the previous month (Woodley, 2011).

8

FIGURE 1. McDONALD’s GAMIFICATION

McDonald's Monopoly is an example of gamification in the physical realm; what about gamification of software?

1.2.2 KHAN ACADEMY

Khan Academy is an example of gamification in the field of education. Its aim is to get people to enjoy learning. Khan Academy contains thousands of videos in which Salman Khan (founder) teaches on subjects such as science, maths, and more. The website acts like a video game by generating practice problems and rewarding good performance with badges (Thompson, 2011). Proof of success? Khan Academy started in 2006, and from 2010 to 2012, it averaged 6 million unique visitors per month, and they collectively solved more than 750 million problems (about 2 million per day). Due to its effectiveness and accessibility, it is now used in more than 20,000 classrooms around the world (Noer, 2012). Who ever thought learning could be so fun? These examples show that well implemented gamification serves the purpose of increasing customer participation in the business. However, every business also wants to acquire more customers, while retaining their current customers. Gamification alone may not be able to attract a lot of new users to your business. To rectify this weakness, this project also uses a concept called viral looping.

9

1.3 VIRAL LOOPING According to Google, when something becomes viral, it is circulated rapidly and widely from one internet user to another (Viral, no date). This is a dream for most new businesses desiring quick exposure. For this to happen, the business model has to be structured in such a way that allows the user to complete the viral loop. This loop involves the steps a user goes through between entering the site, and inviting more users to the site (Hayes, 2013).

FIGURE 2. THE VIRAL LOOP

The steps shown along the viral loop in Figure 2 are:

1. User signs up to your product/website. 2. They are offered a small incentive for sharing it. 3. The incentive works. They tell their friends an incentive to sign up. 4. The incentive works. Their friends sign up. 5. New sign ups continue the cycle. Your business grows.

This form of marketing is responsible for the viral success of some major businesses. Facebook, for example, is no fun without friends on it; that in itself is an incentive to invite others to join facebook. Therefore Facebook encourages you to invite your friends to sign up. Those new sign ups then repeat the loop; facebook quickly got viral as a result. When the viral loop is combined with gamification, they can form a lethal partnership; viral looping attracts, gamification keeps.

10

1.4 CUEPENNY - AIMS AND OBJECTIVES We all know how new businesses that want popularity mostly struggle to get their product/services known to the world. Would it not be great if immediately you started a business, you were able to present it to some business enthusiasts who were able to quickly assess your business, and "pass on a good word" to their peers if they liked your business? This is the essence of what affiliate marketing is about.

1.4.1 AFFILIATE MARKETING

An affiliate is a person, or organisation that has been officially attached to another person or organisation. Affiliate marketing is a style of marketing in which affiliates bring customers to the businesses, and are given a commission for each customer that performs a ‘successful transaction’ with the businesses (Rebecca, 2010). There are multiple definitions of what a successful transaction may be, and it is dependent on the businesses. This gives rise to a variety of business models under affiliate marketing that can exist both offline and online. One of such models is the online Pay Per Click (PPC) business model. This business model is used by globally acclaimed companies such as Google and Facebook; they become affiliates of lots of smaller organisations (Hayes, 2014). These organisations can then advertise on these affiliate’s platform, and have to pay the affiliates a certain amount for every valid click (from a potential customer) that the affiliate brings (WordStream, no date). This project focuses on the gamification of the PPC business model of affiliate marketing.

1.4.3 IMPLEMENTING GAMIFICATION

The aim of this project is to develop a gamified website called Cuepenny that implements PPC; and is built for a massive user base, that allows clients to share their businesses/projects that the affiliates on Cuepenny are itching to discover. Cuepenny is centered around the theme of the affiliates discovering the clients; therefore ‘explorer’ has been chosen as a more fitting term for affiliates. The diagram sequence in Figure 3 gives a more indepth description of how Cuepenny works. Explorers can only get paid by making discoveries that attract the attention of other explorers. Therefore to increase their chances of making good discoveries, an explorer can subscribe to view the future discoveries of another ‘competent’ explorer. Having subscribers increases an explorer's potential earnings, because his discoveries now have an eagerly awaiting audience. It should be clear that on Cuepenny, the explorers are both the market and the marketers.

11

FIGURE 3. CUEPENNY DESCRIPTION.

1. A client (blue) owns a web page and signs-up to Cuepenny. Explorer (yellow)

signs up to Cuepenny to get paid for their marketing services.

2. When an explorer “discovers” a client (yellow arrow), the client’s profile is

shared to the other explorers on Cuepenny (black arrows). The client usually offers a financial incentive to explorers so they can be shared on Cuepenny.

12

3. If other explorers show interest in the client by either sharing, or accessing the

client’s web-link (red arrows), the discoverer (explorer) gets awarded some money from the client (blue arrow) and ranking points.

4. These ranking points determine the "level" of the explorer, which gives a quick

idea of how good an explorer is. A high level can be advantageous to the explorers when it comes to gaining subscriptions (green arrows) from other explorers.

FIGURE 3. CUEPENNY DESCRIPTION.

13

A higher level also gives one a sense of achievement, and could instil loyalty in the explorer. The anticipation of acquiring the prestige and allure of being a high level explorer could give some explorers something to look forward to.

1.4.4 IMPLEMENTING VIRAL LOOP

To implement a viral loop, the explorers are awarded a significant number of ranking points for each new sign up they bring to Cuepenny. Clients are awarded a limited number of free clicks (in the form of free money) for each new sign up they bring to Cuepenny. To aid existing Cuepenny users in inviting new users, upon successfully signing up, points are awarded to any new explorer that has been referred by an existing user; while some free clicks are awarded to any new client that has been referred.

1.5 TOOLS

Zend Server

To speed up development and testing time, I will not be using an online web server to host the website; I would have to upload modified web pages each time to the server before I can carry out any tests. Therefore I would be using a development Apache server that I can install unto a laptop, called the Zend Server (Zend Server, no date).

PHP 5

PHP is the server-side scripting language that the web-pages will use to communicate with the server (PHP 5 Tutorial, no date).

MySQL

A MySQL database would be responsible for storing all of Cuepenny's data. This database would be hosted in the Zend Server, and PHP can be used to communicate with the database to store, retrieve and modify data (SQL Tutorial, no date).

PHPSTORM

The website would be developed on an Integrated Development Environment (IDE) called PHPStorm. Since PHP is the most significant programming language I would be using for this project, it makes sense to use an IDE optimised for PHP (JetBrains, 2000).

HTML 5

This is the client-side scripting language that I would use to add data to my web pages (HTML Tutorial, no date).

14

CSS3

Used to design and structure the web pages to make them more aesthetically pleasing. CSS3 would also be used to develop a responsive website that can be viewed on variable sized screens (CSS Tutorial, no date).

AJAX

This enables the web pages to communicate with the Zend Server in the background; this avoids having to refresh the web pages before seeing new content from the database (AJAX Tutorial, no date).

JQUERY

Javascript is a client-side scripting language that can be used to dynamically change the contents of web-page after it has already been loaded. JQuery is a javascript library (jQuery Tutorial, no date) that achieves:

● Advanced visualisations that cannot be created using only CSS3. ● Writing less Javascript, and still being more productive while developing the

website. ● Easy implementation of Ajax.

BOOTSTRAP

To increase development speed, I will be using Bootstrap (HTML, CSS, and JavaScript framework) to design the front-end of the website. The front-end is the part of the website that directly interfaces with the user (Otto, no date).

GOOGLE DRIVE

This is a cloud storage service that provides users with cloud storage space and allows them to remotely and ubiquitously upload and access their files (Griffith, 2014). It also allows me to automatically synchronise files in a folder on my hard-drive (local repository) with a clone folder on the cloud. This serves as an automatic backup system for my code and database, which guards against complete loss of work. Additionally, if I ever made large changes to any files, and I want to revert back to a previous version of the file, Google Drive enables this (Google, no date).

15

CHAPTER 2. REQUIREMENTS SPECIFICATION

2.1 MoSCoW Before developing the website, I needed to know what would go on the website. Using the MoSCoW method (Haughey, 2015), I gathered functional & non-functional requirements, and listed them in order of priority as shown below.

MUST HAVE

These include requirements that Cuepenny must have for this project to be considered a success. Examples of such requirements are:

● Explorers can discover clients, and share them to all Cuepenny users. ● Explorers get paid the CPC (cost per click) for every unique click they bring to the

client’s websites.

SHOULD HAVE

These are requirements that should be implemented on the website, but the project success does not depend on them. These include:

● Website is perfectly viewable from all sizes of devices. ● Users cannot spam clicks (only the first click requires payment).

COULD HAVE

These are requirements that could be implemented if the above requirements have been implemented and there is some spare time available. These include:

● Users can communicate with each other via Private Message ● Users customise their own pages.

WON’T HAVE

These requirements can be implemented in the future after this project has been submitted.

● Tutorial system to help new users understand how to best use Cuepenny. ● A forum where users can communicate and help each other out on topics related to

Cuepenny.

2.2 STAKEHOLDERS Now that project requirements have been specified, the main actors (stakeholders) in Cuepenny can be identified, and the interactions (use cases) that these actors perform in

16

Cuepenny can be realised. These use cases can then be used to begin the design of the architecture of the software (ConceptDraw, no date). There are three actors in Cuepenny; visitors, clients and explorers. Their use cases can be represented in a use case diagram as shown in Figure 4; which is only a subset of the constructed use case diagram. The full use case diagram can be found in Appendix A.

FIGURE 4. USE-CASE DIAGRAM. Use cases are enclosed in the bubbles, and are

connected to the actors that perform them by the lines attached to them. Here both explorers and clients can ‘login’, however only clients can ‘top-up’.

2.3 DOMAIN MODEL The domain model is an abstract representation of the proposed software, using domain classes (Fowler, no date). Domain classes represent tangible and intangible aspects of Cuepenny. The domain model is an intermediate step between the realised use-cases and the actual architecture of the software. This allows the domain model to be independent of the programming languages that could be used to implement the software. Figure 5 shows a subset of the constructed domain model. The full domain model can be found in Appendix B; along with instructions on how to read it in Appendix C.

FIGURE 5. DOMAIN MODEL. Domain classes are enclosed in the boxes. Arrows show the interaction between the domain classes. This shows that: a visitor can sign up as either an explorer or client; clients can own links; and an explorer can discover a client’s link.

17

CHAPTER 3. SOFTWARE DESIGN

3.1 DESIGN MODEL & GRASP PRINCIPLES The design model is an abstract representation of the software solution for Cuepenny’s domain model (Felici, 2004). This is more specific to the programming languages and allows for direct implementation into code. This model consists of the software classes and the interactions between them that make up the back-end of the project; the back-end carries out all of the major computational tasks for the website, although it never directly interfaces with the user. Due to all the variables and functions involved in each software class, the design model for this project is very large. Therefore I have only provided a subset of the design model in Figure 6. A summary of the full design model has also been provided in Appendix D. Details of all software classes are provided later in Section 4.2.

FIGURE 6. DESIGN MODEL. Each box represents a software class. At the top of the box

is the class title; followed by its variables; and then its functions at the bottom. The dotted arrow shows an interaction that occurs between the two classes.

The design model has been created in way that adheres to the GRASP principles of software engineering. These are a set of tried, tested and approved principles for assigning responsibilities to classes in a way that the system code is maintainable and sustainable (Rao, no date). One of such principles is the Expert principle; this states that all responsibilities should be placed in the classes that provide the necessary information. The design model (as shown in Figure 6) adheres to this principle by ensuring that each class only contains information and functions related to the class.

18

3.2 ENTITY RELATIONSHIP (ER) MODEL Now that we have an idea how we would design our software, we cannot begin to implement the software solution until we have designed our database (MySQL). This is because the software implementation needs to interact with the database. We can begin the design of the database using the ER model, which is a conceptual (easy to understand) representation of the database, showing all the entity types and the relationships between them (SmartDraw, 1994). An entity type is a notion or concept in the real world that has an independent existence. It can be tangible (e.g. a user) or intangible (e.g. clicks). Figure 7 shows a subset of the ER diagram; Appendix E shows the full ER model for Cuepenny, followed by Instructions on how to read the ER model in Appendix F.

FIGURE 7. ER MODEL. The rectangular boxes represent the entity types. The bubbles

attached to them represent their attributes/properties. The diamond box in the middle of the diagram is the relationship between the two entity types. In this case, it shows

that many ‘Account Activity’ can be made by one ‘User’.

3.3 RELATIONAL MODEL & NORMALISATION The relational model is a textual representation of the ER model. This is one step closer to the implementation of the database, and makes it easier for the programmer to write a programme that sets up the database. The ER model can be converted to a relational model by using a 7 step algorithm as outlined by Elmasri (2011). A portion of the relational model for Cuepenny can be seen in Figure 8; the full relational model is in Appendix G. To keep the size of the database at a minimum, we want to make sure that every piece of data in the database appears only once; the process of doing this is called normalisation (Nixon, 2014: 219). This process is important because if data appears multiple times in a database, it could lead to inconsistencies and inefficiency. Every time we update that piece of data, we have to make sure it is also updated everywhere else it may be found in the database; this could be time consuming. Luckily, following the previously mentioned 7 step algorithm leads to a fully normalised database design.

19

FIGURE 8. RELATIONAL MODEL. Entity types are represented as rows of their

attributes. The arrow shows a shared attribute (relationship) between the entity types. In this case, the ‘explorerID’ is the same as the ‘userID’.

3.4 PHYSICAL MODEL (DATABASE SETUP) This model is a coding implementation and contains actual specifications for the ‘physical’ structure of the database (1KeyData, no date). We can derive this model by implementing the relational model with the server-side programming language of our choice; which is PHP in this case. This model contains specific information such as attribute value type (e.g. text, numbers), attribute size, attribute default values, and attribute indexing (to allow for quick search and identification). Entity types are saved as ‘tables’ in the database, and their attributes are saved as ‘columns’ in the tables, and entities are saved as ‘rows’ in the tables. The physical model of the database can be created in MySQL by entering a set a commands specifying the table names, and the column details. All the tables for the database are created in the submitted setup.php file. This file contains other setup information necessary to connect with MySQL. When the file is run on a local web browser, the database should be setup, and we should see a screen similar to Figure 9.

FIGURE 9. SETTING UP DATABASE.

20

CHAPTER 4. SOFTWARE DEVELOPMENT

4.1 PLAN Now that we have setup the database, we can now begin to develop the software that would communicate with it. My development activities have been structured using the incremental development (or multi-waterfall) model. This allows me to complete developing the project in multiple cycles; cycles in which I can develop working mini-versions of the whole system (ISTQB, 2015). Each cycle uses the waterfall model, which consists of separate and distinct phases of specification and development (CCSU, 2011). I begin by defining specifications for that cycle, before developing and testing. After which I evaluate the cycle, and write down events and reflections in a log book. This development style enables me to have a clear plan for the project, while still allowing some flexibility in case I wanted a change of plans. I use the incremental model because the full waterfall model is very rigid and will not allow me such flexibility. Figure 10 gives an outline of how this project was planned.

FIGURE 10. OUTLINE OF PROJECT PLAN USING INCREMENTAL MODEL. Each box

represents a cycle (period). The scroll shows the structure of each cycle.

21

Before deciding on what work to do in each cycle, we first have to decide on the look and flow of the website. The flow relates to connections between pages on the website. Remember that the design model explained in Section 3.1 contains mostly the backend classes that work in the background; we also need classes that would directly interact with the user (frontend classes). Figure 11 features a sitemap (or flow chart) that shows the connections (traffic flow) between the front-end classes (Gliffy, 2015). It also highlights which web pages the different types of users can access.

FIGURE 11. SITE MAP SHOWING ALL PROJECT FRONT-END WEB-PAGES. Any visitor

can access the web pages located in the top half of site map; however, only members can access the bottom half web pages.

Now that I had a ‘list’ of all the web pages and classes to develop for the project, it became time to split their development into cycles (following the incremental model). Each cycle lasted about a ‘week of implementation’, and I finished the development of the project in 7 cycles. For each web-page that I developed in a cycle, I had to implement the corresponding backend classes that allowed the web-pages communicate with the database.

22

4.2 FILES CREATED The following list of files were created for Cuepenny. In Table 1 below, a brief explanation of the function of each file (program) is provided. This is provided mainly as a point of reference for any files that will be mentioned in the Section 4.3 (technical implementations). The cycle in which each file was created is also stated.

TABLE 1. LIST OF CREATED FILES.

CYCLE FILES (.php) FUNCTION

1 functions Sets up and manages connection with MySQL database.

1 header Holds navigation menu and controls user access.

1 index Landing page in which users can login or signup.

1 logout Closes the user’s session, and redirects them to landing page.

2 own_profile Provides the user with all their current statistics (feedback).

3 browse_users Displays brief information of each Cuepenny user.

3 other_user_profile Displays the profile of another Cuepenny user.

3 clicksManager Validates and saves details of important clicks on the database.

4 newsfeed Updates the user with current activity on Cuepenny.

5 changeBalance Handles a change in the account balance of the user.

5 refer Provides a referral code for the user to share to potential sign-ups.

6 level Handles calculations relating to the explorer points.

7 sessions Manages the user session during login and logout.

7 subscribe Provides functions related to subscriptions.

7 user Used to add, modify or collect user information.

7 clicks Provides functions related to clicks.

7 balance Securely manages transactions involving a user’s account balance.

7 link Manages events related to a client’s links.

7 referral Contains functions that handles referral code creation and retrieval.

23

4.3 TECHNICAL IMPLEMENTATIONS

4.3.1 LANDING PAGE

This would be the first page that a visitor would see on their first visit to Cuepenny. A user would also see this page if they are not logged in to Cuepenny. I have made this as simple as possible to understand, and navigate from. This page leads seamlessly into the login and signup pages without even having to load the pages from the database. Using JQuery, I am able to pre-load all these pages and allow quick navigation for the user. On this page a new user is prompted to sign up as either a client or an explorer; clicking on either option would go to the corresponding signup form. An existing user could simply choose to login.

FIGURE 12. LANDING PAGE

4.3.2 SIGN UP

Depending on the user’s choice, the user is navigated unto the respective signup screen. From there the user can enter their details into an HTML signup form, and then submit. Potential clients can enter their web-pages through these forms. If the user enters invalid entries, or fails to enter necessary information, the user is prompted to enter the correct values (Figure 13). If the submission is valid, then the user is automatically logged into Cuepenny.

FIGURE 13. CLIENT SIGNUP FORM ERROR PROMPT - ALL FIELDS WERE NOT ENTERED

24

4.3.3 LOGIN

This feature is implemented by setting up PHP sessions, which stores information on the web browser. When a user logs in, a session variable can be set up to show that the user has logged in. This variable can then be accessed and checked by any program on the web (Zend) server that calls the session using the session’s unique ID (Nixon, 2014: 312). This enables us to prevent non-members from directly accessing certain Cuepenny pages. To login, on the landing page, the user can click the ‘Login’ menu item and enter their username and password in the provided HTML form. After clicking submit, we use PHP to collect the entries, ready for validation. To validate the username and password of a user, we use PHP to query the database to check if there is an existing user with the same username and password. If the entries are valid, a session is created for the user, and the user is logged in; else, the user is prompted of a login failure (similar to the signup failure shown in Figure 13).

4.3.4 SECURITY CONSIDERATIONS

● PREVENTING SQL INJECTIONS (Nixon, 2014: 263): Information collected from the signup and login HTML forms are sent to or checked with the database. To prevent malicious users from using this to send commands to the database and compromise its data, I have provided a PHP function in functions.php called sanitiseString(). It gets rid of any characters in a piece of text from the forms that could directly invoke a response from the database.

● PASSWORD HASHING (Nixon, 2014: 307): It would be wise to not store user’s passwords as plaintext in the database; in the case of a break in, a hacker could view all the passwords of the users. Therefore the entered passwords have been hashed using the SHA1 hashing PHP function. A hash is a seemingly random piece of text that can be generated from the passwords of the users; this is what gets saved in the database. Whenever a user logs in, his password is hashed and checked with the saved hash in the database; if they are the same, then the user is logged in.

4.3.5 USER PROFILE

This is where the user gets to view all their accumulated statistics, which have been stored in the database since they joined Cuepenny. The stats are collected from the database using user.php, and then stored as session variables to prevent the frequent retrieval of this data. The user profile also highlights some personal information of the users, as shown in Figure 14. It is an online representation of the user, and is what the Cuepenny public gets to see. Therefore, for the user, the more impressive the statistics, the better.

25

FIGURE 14. USER PROFILE

4.3.6 BROWSE USERS

A user can browse all other Cuepenny users, and be given brief information of each (Figure 15). This information is collected from the database using user.php, and displayed on a HTML table. The users are placed into separate lists of explorers and clients. Clicking on a user will display their profile; providing more information on the user. From the profile a user can then subscribe to the explorer, or discover the client.

FIGURE 15. BROWSING A LIST OF EXPLORERS.

26

4.3.7 DISCOVERY

An explorer can discover a client when the explorer goes to the client’s profile, and clicks ‘discover’ on the client (Figure 16). JQuery then uses Ajax to send information (in the background) to clicksManager.php, which uses PHP to add the new discovery to the database. This discovery gets published to the newsfeed of all users on Cuepenny.

FIGURE 16. THE DISCOVER BUTTON ON DREECE INDUSTRIES’ PROFILE (CLIENT).

4.3.8 SUBSCRIPTION

An explorer can subscribe to another explorer by going to the explorer’s profile, and clicking ‘subscribe’ on the explorer (Figure 17). JQuery then uses Ajax to send information (in the background) to clicksManager.php, which uses PHP to add the new subscription to the database. This subscription gets published to the newsfeed of all users on Cuepenny.

FIGURE 17. THE SUBSCRIBE BUTTON ON DAVID OLANIYI’S PROFILE (EXPLORER).

27

4.3.9 NEWSFEED

This displays all relevant Cuepenny activity to the users. This is implemented in newsfeed.php; it collects information about relevant clicks/events (discoveries and subscriptions) from the database using clicks.php, and outputs them in two separate lists: general and subscription newsfeed. The general newsfeed shows all of the retrieved activity information (Figure 18); while the subscription newsfeed displays only activity from the user’s subscriptions. It is from here that user’s can receive payment for their discoveries.

FIGURE 18. GENERAL NEWSFEED

4.3.10 USER PAYMENT AND AWARDS

After a user discovers a client and shares the client on the general newsfeed, they can get awarded some points and get paid when other users view the client’s profile (via the discovery) and click on the client’s web-link. After another user clicks on the discovered client’s link, clicksManager.php validates the click, and awards the referring user the deserved points and payment.

28

4.3.11 CLICK VALIDATION

● PREVENTING MULTIPLE DISCOVERIES: A client can only be discovered once by an explorer; therefore to prevent a client being discovered multiple times by the same explorer, the ‘discover’ button is deactivated when the user clicks it. Moreover, for next time, before the client’s profile is loaded, PHP checks the database to see if the explorer who wants to view the profile has discovered the client already. If they have, then the ‘discover’ button is pre-deactivated.

● PREVENT LINK CLICK SPAMMING: When a user clicks on a client’s link, that click for that specific link is saved in the database. However, to minimise the number of clicks stored in the database, only the first of such clicks is saved. Any payments received from such a click is only received once for the first time.

● PREVENTING SELF PAYMENT: A user could possibly ‘pay themselves’ by clicking on the links of their own discoveries. To prevent this, whenever a user clicks on the links of a discovery, clicksManager.php checks the click to ensure that the discoverer is not the same person as the clicker. If they are the same, then no payments or points are awarded.

4.3.12 TOP UP AND WITHDRAWAL

A user can change their account balance by topping it up (clients) or withdrawing their earnings (explorers). On the changeBalance.php webpage, the user can enter the amount they want to withdraw or top up on the HTML form, and submit it. After submission, the amount that the user enters is validated (not too little or too much) on the same webpage; the user is then alerted of the success/failure of the transaction (Figure 19). The file balance.php is used to update the database following the transaction.

FIGURE 19. EXPLORER ALERTED OF SUCCESSFUL WITHDRAWAL

29

4.3.13 ACID TRANSACTIONS

ACID transactions outline the characteristics that every important database transaction (such as topping up account balance) should have, so as to leave the database in a correct state even in the case of failure (Rouse, 2006; Nixon, 2014: 230). ACID stands for the following:

● ATOMICITY: Either all the transaction instructions work, or none of them do. ● CONSISTENCY: If there is a failure in the middle of the transaction, the database

must be returned to its last correct state. Every completed transaction should also leave the database in a correct state.

● ISOLATION: Any uncompleted transaction must not affect the outcome of other uncompleted transactions.

● DURABILITY: A completed transaction must be saved in the database in such a way that a later failure would not revert it.

MySQL implements this feature using the BEGIN, COMMIT, and ROLLBACK commands. Before a transaction, we send BEGIN to MySQL; letting it know we are beginning an important transaction. Once we have finished entering all the transaction code, we send a COMMIT; indicating the end of the transaction. If there is a mistake or failure in any transaction code before we COMMIT, we use ROLLBACK to return it back to its last correct state; satisfying the atomicity and consistency criteria. Unless MySQL COMMITs, it does not save anything in the database. And when it COMMITs, the transaction gets saved permanently in the database; satisfying the isolation and durability criteria. Figure 20 shows an example implementation of ACID transactions in balance.php.

FIGURE 20. FUNCTION TO INCREASE ACCOUNT BALANCE OF USER. BEGIN and COMMIT commands placed in try statement (line 13 - 25). If it fails, then we call

ROLLBACK in catch statement (line 26-29). Transaction code placed between BEGIN and COMMIT commands (line 16-19).

30

4.3.14 REFERRALS

To implement the viral loop, the users are provided with ‘referral codes’ that they could share to potential users. If any of these potential users sign up using that code, both the new user and the referring user are awarded some money or points. On the refer.php webpage, a user is provided with a referral code. This code has been created by referral.php, saved in the database, and displayed to the user. Each time the user reloads the webpage, if the code has not yet been used, then the same unused code is displayed; as shown in Figure 21. However, if the code is used by a new sign up, then a new code is created for the user to share to another potential user.

FIGURE 21. REFERRAL CODE SHOWING TIME OF CREATION

4.3.15 CROSS-BROWSER AND CROSS-PLATFORM COMPATIBILITY

Cross-browser compatibility refers to the compatibility of the website to different web browsers; ideally, the website should behave the same on all the different web browsers, even though they require different coding styles. While cross-platform compatibility refers to how compatible the website is with the variable screen sizes of different platforms (e.g. desktops, smartphones). Using a framework such as Bootstrap afforded me the luxury of not worrying too much about compatibility issues. Bootstrap allows you to easily design your website in a way that it behaves responsively to different screen size requirements. It also provides design code that is already compatible with the major web browsers; such as Firefox, Internet Explorer, Google Chrome (Otto, no date). However, it is not perfect; there were a few instances where I had to edit the behaviour of certain aspects of the website on the different web browsers.

31

4.3.16 STATS BAR

To prevent the user from having to switch to their personal profile all the time just to view their statistics/feedback, a stats bar which contains all the most important statistics for the user is provided. The statistics are retrieved from the database using user.php, and are updated every time any web-page is reloaded. To make the update process more instantaneous, for some statistics on the stats bar, JQuery is used in sessions.php to immediately update a statistic caused by a recent event (e.g. a discovery). Figure 22 and 23 provide more information.

FIGURE 22. EXPLORER STATS BAR WITH ANNOTATIONS

FIGURE 23. CLIENT STATS BAR WITH ANNOTATIONS

32

CHAPTER 5. TESTING AND EVALUATION

5.1 UNIT TESTING This involves testing the smallest units of the website by writing a short program to test the function of the units, producing a pass/fail result (Rouse, 2007; Zilberfeld, 2013). Two such small units that were thus tested were the getLevel() and getRank() functions located in level.php. They output the level and rank of the user respectively, when provided with the user’s points. As an example, the unit testing of the getLevel() function is described below. To test getLevel() , another function called getLevelTest() was written in test.php. The levels and the number of points required to achieve them were created using a ‘level generating algorithm’. The getLevelTest() function works by running this algorithm to produce the points for each level, and feeding these points to getLevel(); and checking that the results from getLevel() are the same as those from the level generating algorithm. If the results are ever dissimilar, getLevelTest() would stop running and output the message ‘ERROR IN FUNCTION’ on the web browser console. getLevelTest() runs for the first 1000 levels, and if this test ran to completion, then the test was passed. An example output from getLevelTest() is shown in Figure 24. The getRank() function was tested in a similar fashion using the getRankTest() function written in test.php.

FIGURE 24. EXAMPLE RUN OF getLevelTest() FUNCTION ON BROWSER CONSOLE. On

each line, the ‘Level’ value had to be the same as the ‘Test’ value. An error message would be output if this was not always the case.

33

5.2 INTEGRATION TESTING This involved joining all the separate implemented units together and testing for defects (Techopedia, 2016). It made perfect sense to perform this test at the end of each development cycle, because I could test how the new implementations behaved with the rest of the existing system; each test was passed. Depending on the complexity of the linkages between the separate units, there could be errors; however if all the unit tests had passed correctly before this point, then all the separate systems ought to work seamlessly together. I have provided a short sample of integration tests performed for each development cycle, along with a short description of the cycle’s main implementations, in the table below.

CYCLE 1 (Login, SignUp) CYCLE 2 (User Profile) CYCLE 3 (Users, Clicks)

A valid login in index.php should correctly identify the user and direct them to the incomplete own_profile.php file, displaying the correct user details and statistics in a HTML list.

Now that own_profile.php is completed, a user login or sign up from index.php should still lead to all the correct user details being displayed; this time in a fanciful design.

All users display on browse_user.php, along with the name of the viewing user. However, any clicks the viewing user performs on themselves should not be saved in the database by clicksManager.php.

CYCLE 4 (Newsfeed) CYCLE 5 (Balance, Referrals)

CYCLE 6 & 7 (Level, Rank)

-A discovery or subscription made by a user on other_user_profile.php should appear on the newsfeed.php for all the other users. -Any clicks the viewing user performs on themselves from newsfeed.php, should not be saved on the database by clicksManager.php.

-A valid transaction on changeBalance.php should cause an instant change on the stats bar in header.php. -A successful referral ought to be saved in the database by referral.php, and the participating users awarded points or money from level.php or balance.php respectively.

-When the user views their profiles on own_profile.php, it should display the correct level and rank calculated from their points by level.php. -A complete test of the system to ensure that the website functions without defects.

TABLE 2. INTEGRATED TESTING EXAMPLES FOR EACH CYCLE.

34

5.3 COMPATIBILITY TESTING One of the aims of this project (as shown in Section 2.1) was to create a website that was cross-platform and cross-browser compatible. To test the cross-browser compatibility, I ran the website on the three major web browsers to ensure they ran correctly. I also ran the website on screen sizes that represented the view from smartphones and tablets. Figure 25 shows an example of a user's newsfeed in the three different views this website provides.

FIGURE 25. CLIENT’S NEWSFEED IN THE 3 PROVIDED VIEWS. Ordered from top to

bottom in descending order of size.

35

5.4 USER EVALUATION For this part, I designed a questionnaire (using Google forms) which was used to check two things: the perceived usefulness of gamification on the field of online affiliate marketing; and the usability of the website (how easy it is to use and understand). To reach a wider audience, the questionnaire was made quite short and direct. For each question in the questionnaire, the user had to provide a score between 1 (bad) and 10 (good). There were a total of 33 participants within the 18-30 age range, and their occupations ranged from students, to interns, to full-time employees. They were asked to imagine they were the owner of a new business looking to increase traffic to their web pages; then they had to answer the questions. We will walk through and discuss the statistics for each question. In the bar graphs below, the vertical axis is for number of votes, while the horizontal axis is for the scores.

QUESTION 1. HOW LIKELY ARE YOU TO LOOK FOR ONLINE ADVERTISING?

FIGURE 26. QUESTIONNAIRE STATISTICS FOR QUESTION 1. AVERAGE SCORE: 7.30.

The average score for this question is quite high (score 7.30), and reflects the high use of online advertising; which has a market size of at least £84 billion (Lunden, 2014). A user stated that they preferred other advertising methods such as television adverts; but from the graph, it is obvious that the majority of users would very likely consider some form of online advertising. With the number of people online forecasted to increase from 3.3 billion today to 5 billion by 2020, it is easy to understand why a lot of people would consider online advertising (Shingles and Trichel, 2014; Internet World Stats, 2015).

36

QUESTION 2. HOW INTERESTED WOULD YOU BE IN USING ONLINE AFFILIATE MARKETING?

The concept of affiliating marketing was explained to the user before they answered this question. The average score of 6.42 in Figure 27 shows that less people are willing to try the online affiliate marketing sector. However, Figure 27 also shows that most people voted highly, with score 7 clearly standing out with the most votes.


QUESTION 3. HOW INTERESTED WOULD YOU BE IN USING A GAMIFIED ONLINE AFFILIATE MARKETING SERVICE?


The concept of gamification was explained to the participants before they answered this question. The average score for this question is slightly higher than that of question 2. However, even though most people voted highly in Figure 28, it also shows the voting to be

37

more varied than in the previous questions, therefore no score clearly stands out. In fact, score 5 (moderately likely) has received the joint highest votes for the first time. More encouragingly though, more people in Question 3 than in Question 2 have stated they would very likely (score 10) try a gamified service.

QUESTION 4. IF YOU WERE EVER TO USE ONLINE AFFILIATE MARKETING, WHAT IS THE LIKELIHOOD THAT YOU WOULD USE A GAMIFIED SERVICE OVER ESTABLISHED SERVICES?


This is a more interesting question; because this will show the likelihood of people choosing my gamified service over the more established popular services. For this question, we have our lowest average score with 6.33. This is understandable because our participants may feel that more established services are that way because they clearly work. They may also not be confident about using a service they are not very familiar with. In Figure 29, for the second time, we see that score 5 (moderately likely) received the joint highest votes; even more votes than in Question 3. To help our understanding, it may have been better if I had asked the users if they were already familiar with popular gamified services; they may have had a bad experience.

QUESTION 5. WHAT WOULD YOU RATE THE USABILITY OF THE WEBSITE?

Usability is a quality attribute that assesses how easy user interfaces are to use (Nielsen, 2012). The users were given a list of 13 instructions to follow when they used the website, and they were asked to rate the usability of the website based on their experience. Thankfully, most of the users (as shown in Figure 30) thought the website had great usability, with a high average score of 7.64 (maybe being too nice?). One of the low scores

38

(score 4) came from a participant who stated the grayscale of the website made it hard for him to see letters sometimes. That could be looked into in the future.


39

CHAPTER 6. REFLECTION AND CONCLUSION

6.1 OBJECT ORIENTED PROGRAMMING (OOP) Although the website was designed following the GRASP principles, these principles work best on software that is fully Object Oriented (OO). Cuepenny is not an object oriented website, even though PHP allows for OOP. The benefits of using OOP includes: easy maintenance; code reuse; good adaptability; easy for other programmers to understand code (Bradley, 2013). Mid way through this project, I attempted to convert the website to OO design; however, with 20+ files of code and a looming deadline, I decided that this would be a conversion that is best done in the future after the deadline.

6.2 DATABASE DENORMALISATION The database for this website was normalised (Section 3.3), which maximised the efficiency of saving data to the database because you only had to save a piece of data in one location (no duplication); this usually involves saving different related fields of data in different locations. However, as the number of users grows, normalisation is not very scalable when all users’ web browsers attempt to simultaneously retrieve data from the database. This is because retrieval from a fully normalised database forces MySQL to perform expensive operations to connect all the separate and related pieces of data back together. If this situation ever arose in the future, denormalisation is the solution (Nixon, 2014: 226). Denormalisation involves duplicating data into various locations that it is frequently retrieved from; although the database becomes bigger, denormalisation reduces the workload per user request on MySQL.

6.3 CONCLUSION From the requirements gathered using MoSCoW model, I completed all the ‘Must’ and ‘Should’ requirements in the given time. I learned the importance of having such strict plans before hand (in a waterfall style) because it gave me a solid foundation to begin working from. However, in the real world, requirements change all the time; therefore, tweaking the waterfall model to an incremental model allowed me be adaptable. Finally, as shown before, gamification can prove to be successful in some instances. However, looking at the results from the questionnaire, it seems like the vast majority of people are not fully convinced about its effectiveness; even though they may be interested in trying gamified services. Perhaps only well implemented gamification is capable of increasing user engagement in a business concept. I conclude from this experience, that the hardest and most crucial part of any project such as this, is deciding on how to implement gamification on the chosen concepts.

40

BIBLIOGRAPHY 1. 1KeyData (no date) Physical Data Model. Available at:

https://www.1keydata.com/datawarehousing/physical-data-model.html (Accessed: 24 April 2016).

2. AJAX Tutorial (no date) Available at: http://www.w3schools.com/ajax/ (Accessed: 24 April 2016).

3. Bhasin, K. (2011) How McDonald’s monopoly game became so ridiculously successful. Available at:

http://www.businessinsider.com/mcdonalds-monopoly-facts-2011-10?IR=T (Accessed: 24 April

2016).

4. Bradley, S. (2013) Can object oriented principles be applied to web design? Available at:

http://vanseodesign.com/web-design/object-oriented-principles/ (Accessed: 20 April 2016).

5. Bright, S. (2014) 8 Surprising Gamification Statistics | DigitalChalk Blog. Available at:

http://www.digitalchalk.com/blog/8-surprising-gamification-statistics (Accessed: 24 September

2015).

6. CCSU (2011) Software processes. Available at: http://www.cs.ccsu.edu/~stan/classes/CS530/Slides11/Ch2.pdf (Accessed: 3 May 2016).

7. ConceptDraw (no date) UML Use Case Diagram Example Social Networking Sites Project | UML Use

Case Diagram Example. Services UML Diagram. ATM system | UML Use Case Diagram Example -

Estate Agency | Use Case Sample. Available at:

http://www.conceptdraw.com/examples/use-case-sample (Accessed: 8 September 2015).

8. CSS Tutorial (no date) Available at: http://www.w3schools.com/css/default.asp (Accessed: 24 April

2016).

9. Domain model (2015) in Wikipedia. Available at: https://en.wikipedia.org/wiki/Domain_model

(Accessed: 4 April 2016).

10. Elmasri, R. (2011) Relational database design by ER- and EER-to- relational mapping. Available at:

http://tinman.cs.gsu.edu/~raj/4710/f11/Ch09.pdf (Accessed: 5 April 2016).

11. Felici, M. (2004) Software design and class diagrams. Available at:

http://www.inf.ed.ac.uk/teaching/courses/seoc/2011_2012/notes/SEOC04_notes.pdf (Accessed:

24 April 2016).

12. Fowler, M. (no date) P of EAA: Domain model. Available at:

http://martinfowler.com/eaaCatalog/domainModel.html (Accessed: 24 April 2016).

13. Gliffy (2015) Create site maps. Available at: https://www.gliffy.com/uses/web-site-map-software/


14. Google (no date) Google drive - cloud storage & file backup for photos, Docs & more. Available at:

https://www.google.com/drive/ (Accessed: 24 April 2016).

41

15. Gravytrain (2014) Digital Marketing Blog: Could Gamification improve your SEO campaigns?

Available at: http://www.gravytrain.co.uk/blog/gamification-improve-seo-campaigns/ (Accessed:

24 September 2015).

16. Griffith, E. (2014) Who’s winning the cloud storage wars? Available at:

http://fortune.com/2014/11/06/dropbox-google-drive-microsoft-onedrive/ (Accessed: 12

February 2016).

17. Haughey, D. (2015) MoSCoW Method. Available at:

https://www.projectsmart.co.uk/moscow-method.php (Accessed: 4 September 2015).

18. Hayes, M. (2013) So, What is a Viral Loop? Available at: http://growthdevil.com/viral-loop/

(Accessed: 30 September 2015).

19. Hayes, S. (2014) The Top 22 Pay-Per-Click PPC Advertising Networks. Available at:

http://www.metalsoftware.com/ppc-advertising-networks (Accessed: 24 September 2015).

20. HTML Tutorial (no date) Available at: http://www.w3schools.com/html/default.asp (Accessed: 24

April 2016).

21. Internet World Stats (2015) World Internet users statistics and 2015 world population stats.

Available at: http://www.internetworldstats.com/stats.htm (Accessed: 18 December 2015).

22. ISTQB (2015) What is Incremental model- advantages, disadvantages and when to use it? Available

at:

http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-wh

en-to-use-it/ (Accessed: 6 April 2016).

23. Jacobson, H. (2013) Gamification in Marketing: Lessons from the Khan Academy Website. Available

at:

http://searchenginewatch.com/sew/opinion/2303233/gamification-in-marketing-lessons-from-th

e-khan-academy-website (Accessed: 25 September 2015).

24. JetBrains (2000) PhpStorm IDE: JetBrains PhpStorm. Available at:

https://www.jetbrains.com/phpstorm/ (Accessed: 24 April 2016).

25. JQuery Tutorial (no date) Available at: http://www.w3schools.com/jquery/ (Accessed: 24 April

2016).

26. Lunden, I. (2014) Internet ad spend to reach $121B in 2014, 23% of $537B total ad spend, ad tech

boosts display. Available at:

http://techcrunch.com/2014/04/07/internet-ad-spend-to-reach-121b-in-2014-23-of-537b-total-ad-

spend-ad-tech-gives-display-a-boost-over-search/ (Accessed: 19 April 2016).

27. MoSCoW (2016) in Wikipedia. Available at: https://en.wikipedia.org/wiki/MoSCoW_method


42

28. Nielsen, J. (2012) Usability 101: Introduction to usability. Available at:

https://www.nngroup.com/articles/usability-101-introduction-to-usability/ (Accessed: 19 April

2016).

29. Nixon, R. (2014) Learning PHP, MySQL, JavaScript, CSS & HTML5: A step-by-step guide to creating

dynamic Websites. 3rd edn. United States: O’Reilly Media, Inc, USA.

30. Noer, M. (2012) One man, One computer, 10 Million students: How khan academy is Reinventing

education. Available at:

http://www.forbes.com/sites/michaelnoer/2012/11/02/one-man-one-computer-10-million-studen

ts-how-khan-academy-is-reinventing-education/ (Accessed: 9 November 2015).

31. Otto, M. (no date) Designed for everyone, everywhere. Available at: http://getbootstrap.com/


32. PHP 5 Tutorial (no date) Available at: http://www.w3schools.com/php/ (Accessed: 24 April 2016).

33. Rao, D. (no date) GRASP design principles. Available at:

https://www.cs.colorado.edu/~kena/classes/5448/f12/presentation-materials/rao.pdf (Accessed:

6 April 2016).

34. Rebecca (2010) Affiliate marketing for beginners. Available at:

http://www.smarta.com/advice/sales-and-marketing/sales/affiliate-marketing-for-beginners/


35. Rouse, M. (2006) What is ACID (atomicity, consistency, isolation, and durability)? - definition from

WhatIs.Com. Available at: http://searchsqlserver.techtarget.com/definition/ACID (Accessed: 15

April 2016).

36. Rouse, M. (2007) What is unit testing? - definition from WhatIs.Com. Available at:

http://searchsoftwarequality.techtarget.com/definition/unit-testing (Accessed: 16 April 2016).

37. Scirra (2013) Game design: 8 kinds of fun. Available at:

https://www.scirra.com/tutorials/434/game-design-8-kinds-of-fun (Accessed: 2 April 2016).

38. Shingles, M. and Trichel, J. (2014) Tech trends 2014, industrialized crowdsourcing. Available at:

http://dupress.com/articles/2014-tech-trends-crowdsourcing/#end-notes (Accessed: 18

December 2015).

39. SmartDraw (1994) Entity relationship diagram - common ERD symbols and Notations. Available at:

https://www.smartdraw.com/entity-relationship-diagram/ (Accessed: 24 April 2016).

40. SQL Tutorial (no date) Available at: http://www.w3schools.com/sql/default.asp (Accessed: 24 April

2016).

41. Staniforth, J. (2015) The Latest Trends in Marketing: Search Engine Optimisation, Mobile Strategy

and Gamification. Available at:

http://digitalmarketingmagazine.co.uk/articles/the-latest-trends-in-marketing-search-engine-opti

misation-mobile-strategy-and-gamification/1989 (Accessed: 24 September 2015).

43

42. Techopedia (2016) What is integration testing? - definition from Techopedia. Available at:

https://www.techopedia.com/definition/7751/integration-testing (Accessed: 16 April 2016).

43. Thompson, C. (2011) How khan academy is changing the rules of education. Available at:

http://www.wired.com/2011/07/ff_khan/ (Accessed: 2 April 2016).

44. UKIE (2014) The games industry in numbers. Available at: http://ukie.org.uk/research (Accessed: 2

April 2016).

45. usability (2013) System usability scale (SUS). Available at:

http://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html (Accessed: 8

April 2016).

46. Use case (2015) in Wikipedia. Available at: https://en.wikipedia.org/wiki/Use_case (Accessed: 8

September 2015).

47. Viral (no date) Available at:

https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=define

%20viral (Accessed: 2 April 2016).

48. Woodley, K. (2011) Monopoly Sends McDonald’s Directly to Profits. Available at:

http://investorplace.com/2011/11/mcdonalds-monopoly-same-store-sales/#.VgP_KflVhBc

(Accessed: 24 September 2015).

49. WordStream (no date) What is PPC? Learn the basics of pay-per-click (PPC) marketing. Available at:

http://www.wordstream.com/ppc (Accessed: 24 April 2016).

50. Zend server (no date) Available at:

http://www.oracle.com/technetwork/topics/php/zend-server-096314.html (Accessed: 24 April

2016).

51. Zilberfeld, G. (2013) Why you need unit testing in web development. Available at:

http://www.creativebloq.com/web-design/testing-times-10134991 (Accessed: 2 May 2016).

44

APPENDIX A. USE CASE DIAGRAM

45

APPENDIX B. DOMAIN MODEL

46

APPENDIX C. DOMAIN MODEL KEY SYMBOL NAME AND MEANING

DOMAIN CLASS - Represents tangible and intangible aspects of Cuepenny e.g. things (web-link), roles (explorer), incidents (click), and interactions (subscription).

INTERACTION - The arrow connects two domain classes, and has an attached phrase that shows the interaction between the two classes. The given symbol shows that a car has a tire.

MULTIPLICITIES - Shows the number of participants from each domain class that can carry out this interaction at any 1 time. The given symbol shows that 1 car has multiple tires. Can be read both ways: multiple are on 1 car. * represents ‘multiple’.

COMPOSED - The class on which the arrow is incident on, is composed of the class producing the arrow. The given symbol shows that 1 car is composed of multiple tires.

47

APPENDIX D. SUMMARISED DESIGN MODEL All the variables and functions have been removed to provide a smaller, easy to understand design model. The interactions between the software classes are illustrated by the dotted arrows. The class on which the dotted arrow is incident is used by the class that produces the arrow.

48

APPENDIX E. ER MODEL

49

APPENDIX F. ER MODEL KEYS

SYMBOL AND NAME MEANING

Notion or concept in the real world that has an independent existence. It can be tangible (e.g. a user) or intangible (e.g. clicks). An entity type can have multiple entities e.g. Paul, David, John are all entities of the entity type ‘User’.

A particular property value of an entity type.

The attribute of an entity type that serves to uniquely identify its entities.

This occurs when two entity types share an attribute.

Entity type that has no key attributes of its own. Its existence is dependent on the existence of another specific entity type.

The attribute of a weak entity type that serves to partially identify its entities. Its entities can be uniquely identified when this key is combined with the key attribute of the entity type it depends on.

The relationship that ties a weak entity type to the entity type it depends on.

50

PARTICIPATION CONSTRAINT

Every entity in E2 participates in relationship R (total participation). Some entities in E1 may not participate in R (partial participation).

CARDINALITY RATIO

This ratio specifies the maximum number of relationship instances that an entity type can participate in. In this case, 1 instance of E1 can be related to multiple instances (N) of E2 in relationship R.

51

APPENDIX G. RELATIONAL MODEL Entity types are tangible and intangible real world concepts, and are represented in the relational model as rows of their attributes. The arrows show shared attributes (relationships) between entity types. Some attributes were removed to allow the diagram to fit the page; the most relevant attributes are shown.

52

GAMIFICATION OF ONLINE AFFILIATE...

Documents

Transcript of GAMIFICATION OF ONLINE AFFILIATE...