With the development of the Internet, various social media platforms have emerged, resulting in a rapid growth of digital content production and its importance. Digital content is being used as a main marketing tool by many industries and higher education is not an exception. Robert Gordon University has a reputation for high employability rates due to its modern approach in both teaching and their management strategies. The university has strong online presence and it's important that digital content that is being produced is up to the highest standard.
This research report investigates current methods of tracking digital content creation process. It also provides an overview of digital content creation process related issues of RGU's marketing department. In addition to that, various concepts and technologies will be reviewed in order to provide a possible solution for tracking the workflow of digital content requests and other digital content creation process related issues.
I would like to express my sincere gratitude to all those who helped and assisted with the conduction of this thesis, with particular thanks to Kit-ying Hui, MSc project supervisor. For your time, supportive guidance, valuable advice and knowledge given throughout the project.
I would also like to thank Camilla-Erika Campbell, Jo Fleet and Sean Brosnan from RGU Marketing Department for sharing their knowledge and support in the development of this project.
Finally, I would like to thank Jussi Piirainen, Georgia Tsoraklidou, Katya Volkova, Nadia Hatni and Kaisa-Maija Tolonen for their patience, continuous support and motivation. And to my dad, thank you for always supporting and believing in me and my dreams!
Chapter 1. Introduction
This chapter provides background information about Robert Gordon University marketing department and the issues this project will investigate. It also provides an overview of this report.
Given the recent development of the Internet technology and growing importance of the digital content, the amount of the multimedia content services market has expanded (Park, Lee and Baik, 2006). Higher Education sector is one of those markets. More and more universities are using digital content and various social media platforms as a marketing tool and embracing it in their marketing strategies.
Academic institutions such as Robert Gordon University (RGU) can be analysed from a variety of perspectives such as community, an institution, a corporation, an organisation, or even as a political system. All these concepts coexist in an uneasy balance within university (Boukar and Muslu, 2013). That can generate a number of problems. In this project, the researcher will look into the content request process related issues of RGU's marketing department and investigate various concepts and technologies to build a possible solution for those issues.
RGU has a very strong online presence. The university's marketing team is actively using various social media platforms as their marketing tools. In order to successfully maintain RGU's online presence and further develop it, a large amount of digital content has to be created, updated or altered on a daily basis. When dealing with such large amount of digital content requests, it is essential to keep track of those requests in order to ensure that all requests are being fulfilled.
Despite having an abundance of academic literature focusing on different aspects of the topic, existing literature has primarily focused on content management in general. It has been identified that limited research has been carried out on issues concerning digital content request processes. Initial research has shown that there is no established procedure, software or a system that would allow to track the whole workflow of a digital content request. Thus, there is a need for a system that would track the workflow of digital content requests.
The aim of the RGU Marketing Department is to provide a high quality marketing service to support the strategic development of the University and its individual Schools. Marketing team is responsible for identifying marketing opportunities and implementing plans to generate student recruitment within the undergraduate, postgraduate and distance learning markets (RGU, 2018).
The team consists of four main sub-teams and roles as follows: the director, school marketing team, digital marketing team and web editorial team (Figure 1). In this project, the researcher will mostly focus on the digital marketing team as they are involved in the process of digital content creation and thus, digital content requests the most.
Figure 1: RGU Marketing Department.
1.3.1 High-level overview of digital content request process
Currently, digital content requests are send to either school marketing team or digital marketing officers via emails. Digital content requests are mainly made by the Schools of the university and business development department. However, requests are not limited to those two and can be made by any department within the university and also students or student societies.
The received request can circulate around different people within the marketing department and the requestor before content creators or other departments that are involved in content creation are notified of the request.
Once the content creators are notified of the request, they have to communicate with the original requestor to get further details. Proformas which are content description forms, transcriptions and consent forms are used to obtain that additional information. In addition to that information, sometimes digital content creators have to get additional content from other departments within the RGU who are also involved in the digital content creation. Once all the needed information is gathered, digital content creators can start creating the digital content. Often, content creators have to get feedback and approval not only from the original requestor, but also from digital content officers within the marketing team.
Figure 2 shows a digital content request process flow from department's perspective, while figure 3 presents actual digital content request flow. In figure 2 it can be seen that various RGU departments and external requestors are acting as requestors. Figure 3 generalises all requestors and presents it just as a “requestor”. One of the main issues with the current digital content request process is that there is no specific order to be followed to fulfil the request. The researcher has identified general flow of the digital content request within the RGU marketing team however, the order of steps presented in the figure 3 often can be changed or some steps can be skipped.
In the past, the RGU Marketing department has considered using online forms for the digital content requests, but it was decided to keep with the group emails due to the variety of requests getting through and the short time involved with resolving any issues. Some content creators within the department keep track of their requests and its progress by creating progress spreadsheets in Excel and writing to-do lists. While it can help to make the digital content creation process more organised, it can only be accessed by the creators.
Overall, the problem with this approach is that a lot of information can be lost or misunderstood due to having to send a lot of emails to different people and departments. For example, in the past RGU couldn't use some of the content as the consent forms couldn't be found. In addition to that, there is no process in place which would allow the marketing team to track request's progress. Request tracking is important to the team as it would provide necessary content-related information for digital content planning.
1.4 Aim and objectives
The aim of this project is to develop an interactive and dynamic solution that would help to overcome problems concerning the abundance of content requests and allow tracking digital content request flow.
1. Provide an overview of existing content request practices
2. Develop a pre-defined state diagram of digital content request
3. Build a web application that would track the workflow of a content request and:
design a database to store the digital content requests and track their progress.
design a UI
1.5 Structure of the report
This report is organised into five main chapters. The table below provides brief description of each chapter:
Chapter 2. Related work
This chapter will discuss existing digital content request management practices and various types of digital content requests within the universities. It will also provide an overview of Issue Tracking Systems.
2.1 Existing digital content request management practices
Most universities and businesses in general have external and internal digital content requests. In case of a university, external requests are made by the students of the universities or members of the community. These requests are usually created using online request forms that can be found on universities' website. The forms are either a part of the website or there are also various tools such as Google Forms that can be embedded into the website for external users to make a request. In addition to that, some universities are also using emails as a way of getting external content request (Appendix A). Internal requests, on the other hand, are made by the various departments within a university and usually made vie emails, phone calls or verbal communications.
There are two types of digital content requests which are content posting requests and digital content creation requests. The first type of a request is used by both external and internal requestors. An example of an external posting content request would be a student society wanting to promote one of the society's events on university's social media. Whether it is an external or internal content posting request, the aim of those requests is to promote or raise an awareness of something by using university's social media channels or website.
Digital content creation requests are made by the internal requestors. However, businesses in general, can have both internal and external digital content creation requests. The nature of this requests will vary from business to business. In this project, the researcher will only focus on the digital content requests from a university perspective. The aim of digital content creation requests is to have content created and then used for various purposes such as advertisement of specific university courses and other promotional materials, e-learning components and the enhancement of the quality and availability of relevant information for current and prospective students and business partners.
Content posting requests do not necessarily require request tracking. Usually, once the request is submitted the requestor is notified whether the request is approved or not via emails or other means of communications. With the digital content creation requests, both the requestors and digital content creators are likely to enquire about the progress of the request. Despite being requested by the internal requestors, created digital content is likely to be used by the marketing department. Thus, digital content officers and marketing managers might also want to know about the progress of the request in order to include the created content into their digital content plan.
There are request tracking systems that can provide that functionality. However, these systems are focused on tracking such things as software and web issues. There are no systems that would provide digital content request tracking.
2.2 Issue Tracking Systems
For all web content requests and issues, RGU marketing department uses JIRA Issue Tracking System that is being handled by the University's IT department. Using that system proved to be effective however, team's access to the system is very limited.
Issue Tracking Systems (ITS) which are also known as request management systems, manage issue reporting, assignment, tracking, resolution, and archiving (Bertram et al, 2010). Issue tracking and resolution is a social and collaborative process. Issue tracker acts as a communication channel between the users, developers and quality assurance (Correa et al, 2013). Requirements communication are often part of the ITS. Thus, over time ITS gathers large volumes of information (Dingsøyr and Røyrvik, 2003). This information is primarily used by software developers to support collaborative bug fixing and the implementation of new features (Bertram et al, 2010). In addition to that, it can also be used as a basis for developers daily work prioritisation indicator. However, this information is also helpful and often used by project managers and end-users for project management purposes, history tracking and overall communications. Despite the process of tracking all the information being challenging and complicated, it plays an important part in providing necessary tools for work coordination (Just, Premark and Zimmermann, 2008).
Issue trackers include means of communications about the issue. It could be in a form of comments that are presented by text fields (Anvik, Hiew, and Murphy, 2006). In some systems there are “task discussion” field that can be edited several times by various people included in the issue request process (Bertram et al, 2010). In both cases all comments and amendments are saved and resented in comment history. Often issue tracking communications involve emails, phone calls and other ways of communications (Nardi, Whittaker and Bradner, 2000).
Although this research is focusing on the digital content and not web content, ITS's issue tracking could be used as a basis for the system. It has the desired functionality such as request state tracking and it would provide necessary information to the digital content officers for digital content planning and scheduling
Another way to keep a track of issue requests is by using Microsoft Office Excel. Excel's grid structure makes it easy to maintain an issue log. It also allows to analyse and visualise various issue-related information (Westland, 2017). However, Excel only provides high-level overview of issue logs (Sieber, 2017). It does not provide any additional information that can be found in traditional ITS and does not provide an overview of the entire request workflow. In addition to that, all status updates have to be manually entered which could be challenging and ineffective when dealing with large amounts of requests and data.
Chapter 3. Problem analysis
This chapter presents an analysis of possible solutions that will be used to implement the system. In addition to that, it will outline any legal or ethical implications of the developed system.
3.3 Request tracking model
There are two main issues that RGU Marketing department faces when it comes to the digital content requests. The first issue is the abundance of digital content requests and request-related information and the inability to locate that information when needed. The second issue is the lack of awareness of what is happening with the current content creation requests and what digital content is already available. That knowledge gap makes digital content planning extremely challenging.
As it was mentioned above, ITS not only allows the tracking of the issue request, but it also gathers all the information that is associated with the request. Having that information in one place would allow both digital content creators and management to use it for more effective digital content planning and marketing strategies. It will also allow more efficient workflow prioritisation. Hence, the system that will be implemented will use ITS's issue tracking function as a basis for the digital content request progress tracking and management.
Request tracking shows at what stage request is at and its progress. It can be said that there are different stages or states of a request. Furthermore, request cannot transition onto the next stage unless the stage it is at is fully complete. Finite-state machine has similar concept. Thus, the researcher will also use it as a basis for the system.
A finite-state machine (FSM) is an abstract machine that can be in only one state at any given time. The FSM changes from one state to another as a result of some external inputs (Aaronson, 2011). An example of the finite-state machine could be a sequence of the traffic lights. Let's say the first state of the traffic light is the red light. After a certain amount of time it would transition to the next state, the green light. Once a certain amount of time passess again, it transitions to the next state, the yellow light. After that, it transitions to the red light again and the process is repeated. In this example, time is the factor that allows traffic light transition from one state to another. Thus, timer would be the input into the machine meaning that after a certain amount of time has passed, the timer notifies the traffic light and it changes its state. However, if the traffic light is at red state and the time has not reached its value, the state won't be changed.
Hence, the finite-state machine has current state, input, next state and the output once the state is reached. These translate into the traffic light example as red light being a current state, time as an input, green light as the next stage and changing from red to green and allowing cars to drive as an output. From the low-level development perspective, FMS states are nodes and transitions are edges.
Using FMS as a basis for request tracking model would allow creating a system that is organised and time-efficient. It will provide a structure for the digital content creation process and ensure that all steps are fully finished. The researcher has identified the states and the transitions that digital content request has (Figure 4). This diagram will be used for the development of the system. FMS diagram shows states of digital content request.
3.1.1 The use of FMS in the application
FMS diagram is going to be used as an indication of the progress of a digital content request. The application will be in the “Start” state when the end-user/requestor starts creating the request. The “Start” state will be considered finished when all necessary forms are filled out. Submitting the request is the input of this state (Appendix B, 7). It also represents that the request is received. Hence, allowing the application to transition to the next state. The next state, “Request reply pending” will be presented as a table of requests that can be viewed by the creators (Appendix B, 2). To move to the next state, the request has to be either rejected or accepted. If request is rejected, it moves to the “Done” state as there are no other steps in the digital content creation process that have to be done.
The acceptance of a request allows the application to transition to the next state, “Content to be created”. This state will be considered finished when all stages of digital content creation are completed.
As it was mentioned before, the FSM diagram will be used to indicate what stage the request is at, but not the stages of the actual content creation process. Despite its benefits, developed FSM diagram is linear and does not provide the flexibility that digital content creation process requires. There are various factors that affect digital content creation process. For example, a creator might be tasked to produce a video covering an event. Depending on various factors, such as a platform the video will be published on and target audience, different steps might be taken in order to create that video. Thus, the application must be flexible and allow tailoring of tasks for each request.
Thus, the researcher has developed a diagram that represents stages in the digital content creation process (Figure 5). This diagram will translate into the application as a set of tasks that are added by the creator and represent stages of the digital content creation process (Appendix B, 5 ). It was decided that creators will be adding custom tasks instead of having a standartidies list of tasks to completed to provide the flexibility that digital content creation process requires. Once the task is done it can be ticked off. When all tasks are ticked off, results are delivered and the application moves on the the next and final state “Done”.
3.2 Data storage and access
To start the digital content request process, a requestor has to provide specific information about the request. This information is the data that requestor inputs into the application. This data is used in the later stages of the digital content creation process. Thus, the data has to be stored and be retrievable. One of the solutions for data storage is Microsoft Excel or Google Sheets spreadsheets. While those are common and simple ways of storing data (Bin, 2009), it would only work if the project only required storing the data. Hence, a more flexible method which would allow data querying is required. In order to provide this functionality, a database will be used.
A database is a an organised collection of data or information which can be accessed, modified, retrieved or deleted by a computer program when required (Ullman and Widom, 1997). The basis for the request tracking system is a FMS diagram which was constructed by using graph structure. A graph data structure consists of a finite set of nodes and a set of edges. Depending on the type of a graph, edges can be ordered or unordered. Nodes represent entities that can be tracked. For example, people, accounts or requests. Comparing it to the relational database, it can be seen as a relation or a row. Edges represent relationship between the nodes and connect them.
Despite graph structure being used, the researcher will not implement the graph database as the developed graph is direct and not complicated. Graph databases are usually being used for complex hierarchical structures such as flight patterns of an airline or a large social network. Instead, a relational database will be used. Relational database uses relational model where data is organised into relations of attributes and tuples. Each tuple has a unique key. Each relation represents one type of an entity. The tuples are the instances of that type of entry while attributes are the values of those instances. Moreover, the application requires more than just a request tracking system hence, the database which will be implemented has to cover other aspects of the application, such as user information. Figure 6 illustrates an entity-relationship diagram that represents entities in the application database and relationships between them.
Stored data is accessed by the means of a Database Management Systems (DBMS). According to Connolly and Begg (2015) a DBMS is “a software system that enables users to define, create, maintain and control access to the database.” There are various DBMS, the top five are Oracle, MySQL, Microsoft SQL Server, PostgreSQL, MongoDB (DB Engines, 2018). Any of these DBMS could be used for this project since all of them have similar ways of interaction and connection with an application or a software. However, there are several types of databases, such as relational, graph and document oriented. Thus, based on a personal preference and a need for a relational database, MySQL was chosen as a DBMS for this project.
DBMS by itself cannot access or manipulate information in the database. A Data Manipulation Language (DML) is required to do so. DLM adds new data, deletes and updates it and also retrieves it in the form of queries. Querying allows retrieval of data in response to a question about the data in the database. Structured Query Language (SQL) is the language that can provide that functionality and will be used in this project together with MySQL. To create a database in the application, a SQL script will written and executed.
3.1 Web application architecture and solution stack
To tackle the issues RGU marketing department has, the researcher is proposing to build a web application. A web application is a program where user interface and client-side logic is running in a web browser. Web applications provide flexible access which can allow employees to access the application from various locations as long as they have internet access. This is important as content creators often have to be on location to gather material for the content. In addition to that, web applications can be easily customised for the use on a range of different devices. Web applications also provide better security. Usually, they are deployed on servers that are monitored and maintained by experienced server administrators. Hence, any potential breaches can be noticed quicker.
Behind any web application there are three layers: presentation layer which provides user interface and handles interactions with the user; business logic layer which has rules for the information processing; and the data layer which manages information and stores data. Those layers can be combined in different ways, also called tiers.
One-tier architecture contains all layers on the same machine. In two-tier architecture, presentation and and business logic layers run on the client-side and data layer is stored on a separate server (Petersen, 2008). In the three-tier architecture all layers are developed and maintained as independent modules, often they can be on separate machines (Ramirez, 2000). The three-tier architecture allows easy maintenance of the base code by handling the presentation code and business logic layers separately. This means, that each layer can be updated without impacting other layers (Pepalis, 2017). Despite three-tier architecture being more scalable than one or two-tier architecture and separating the presentation, business logic and database layers, the business logic layer is still too broad. Nonetheless, three-tier architecture is suitable and sufficient for building simple web applications (Petersen, 2008) such as the proposed one.
Once the request is received a business logic layer will take its place. It will be developed with PHP as a server-side language. The proposed application will have two types of access: creator and requestor access. Depending on the type of a user different pages will be displayed. To differentiate between the users and provide login control, a PHP login script containing user verification, user authorisation will be used. The application will also provide file upload system for the extra files requestors might upload. Information about requests and requests progress status will be stored and retrieved in array JSON file with the help of a PHP script. To write and edit code for the web application, an Integrated Development Environment (IDE) PhpStorm will be used.
As for the data layer, a relational database will be created by writing an SQL script. All database functions will be handled by DBMS, MySQL in conjunction with phpMyAdmin as an administration tool.
3.4 Legal and ethical considerations
There are no legal or ethical implication that can arise from this projects. All gathered data will be stored locally at all times and does not include any personal data. However, during the project investigation phase, the researcher had to gather and provide information regarding RGU's marketing department structure. The information was obtained from the official RGU website which is public and thus, no permission to use the information was required. Proposed application will be implemented by using free software. In addition to that, PHPStorm will be used with an academic license.
Chapter 4. Project specifications
This chapter discusses specifications of the projects, provides its functional and non-functional requirements. It also describes the design of the system and how it will be implemented.
4.1 Proposed design and implementation
The proposed web application will be designed and implemented using PHPStorm IDE and PHP as a programming language. PHP side-server script with JSON will be created to store and retrieve both login system and request progress status information to and from the database. Nowadays, the combination of PHP as a server-side programming language and MySQL as an open source relational database management system is widely used. This is due to the ability to deliver highly unique solutions, its simplicity and the ease of use (Ullman, 2017).
All University employees have unique login details that are being handled by the University's IT department. Initially, the existing login details were planned to be used to provide the access to the system. However, getting access to the employees login details would be a very long process and due to the limited time, the researcher had to choose a different way of providing access to the system. Thus, a login system will be implemented.
Digital content creation request forms, along with the design of the rest of the system, will be implemented using Bootstrap4, HTM5L and CSS3
To provide a continuous service, system will be implemented using web technologies that could be accessed by the staff through the workstation computers or different kind of mobile devices.
4.2 Proposed GUI design
The proposed GUI design can be seen in figures 6, 7, 8, 9 and 10. The full GUI design can be seen in Appendix B. Figures 6 and 7 are illustrating digital content creators view. Figure 6 shows requests tabs. Those tabs give an overview of all pending and current requests. Figure 7 demonstrates a page which content creator will be taken to when one of the pending requests is selected. It provides more detailed information about the request and allows the user to accept or decline it.
Once request is accepted, it will move to the current requests tab. When one of the requests is selecter, the user can see detailed information about it, download additional files and create tasks that have to be completed in order to produce the content (Figure 8)
Figures 9 and 10 illustrate requestor's view. Figure 9 shows the list of request that have been made by the requestor and showing the progress of those requests. And figure 10 demonstrates the digital content request form.
4.3 Functional Requirements
The functional requirements of this project specify required functionality in order to build a system that would fulfil outlined aim and objectives. Optional functionalities are also listed however, due to limited time and resources those are not guaranteed to be implemented. If necessary, additional requirements may be introduced as the project progresses. When implemented the system should:
Have a login system
Have two types of users and access:
Requestors: These users can create a digital content request, provide relevant information and track the entire workflow of a request
Creators: These users can see the requests and request-related information
Have content request forms for various types of content on various platforms
Have request progress indicator
Have upload system
Optional functional requirement:
Have different content request forms for various types of content on Facebook and Instagram
Requests should be editable
4.4 Non-Functional Requirements
The system must be developed, implemented, tested and presented by August 30, 2018
GUI should be user-friendly and self-explanatory
The web application should provide a simple to use system that is intuitive and delivers all the necessary information to the user. Its layout should be attractive with a consistent design to ensure a positive user experience.
4.5 Development methodology
Several software development methodologies were researched in order to find a methodology that would work best for the implementation stage of the project.
4.4.1 Waterfall methodology
Waterfall methodology suggests a strict sequential approach where all deliverables are clearly defined. The project only proceeds onto the next phase when the previous phase is completed. (Douglas, 2009). It is easy to use and understand since it has clearly defined stages. However, waterfall methodology does not respond well to changes. This methodology would work best for project with the clear requirements that are not changeable.
4.4.2 Spiral model methodology
This is a risk-driven model that compares the likelihood of achieving most requirements in available time (Boehm, 1986). Because of that, it allows to see the early indicators of risks associated with the software. Unlike waterfall methodology, it is flexible and adaptable when it come to the changes in the requirements. This methodology is better suited for larger projects (Powel-Morse, 2016).
4.4.3 Incremental build model
In this method, software is designed, implemented and tested in increments. The software is considered completed when all the requirements are fulfilled (Ghahrai, 2017). The software is broken down into several components. Those components are designed and built separately. After the component is build, it is delivered to the user for feedback. Once the feedback is received, the component is being modified accordingly. Like in waterfall methodology, the next component cannot be built until the previous one is fully finished (Pressman, 2010). This model allows easier testing and debugging. This methodology would work best for this project as all primary requirements are established and can be decomposed into components. In addition to that, this methodology is flexible when it comes to changes.
Chapter 5. Conclusion
Throughout this project investigation it was concluded that currently there is no solution that would specifically track workflow of a digital content request and creation process. However, there are systems such as Issue Tracking Systems that provide needed functionality to some extend and it was used to develop the proposed solution along with the concept of FMS. The web application will be further developed in the second part of this project, implementation phase. Final application then will be proposed to the RGU Marketing department.
...(download the rest of the essay above)