Thomas Mckeown's Team Project Individual Journal

16^th – 25^st April

Sprint

With this being our last sprint we all worked on adding the last improvements and bug fixes to the project before its finished.  This required doing any bug fixes to any calls on the server as well as any bug fixes to the layout of the app as some pages had buttons cut off on smaller screens.  We also worked on making some updates to the calls on the database to make sure the right details were being returned such as returning only players belonging to the current team a user has selected even if thy have multiple teams. The update game call was also updated as it was returning some wrong values, nulls instead of 0 when no details need updating. Over the course of this sprint expiry an expiry time was added to the token, meaning even if a valued user is using this token after it expires they will no longer be allows to make calls and will have to create a new token. Ove the course of this sprint the command parser was improved. This required people talking into the app and any mistaken translations made are added to the command parser so if these mistaken translations happen again the app server will be able to correct them.

Overview

For this sprint I worked on making small improvements to the server by adding the user id to certain call that needed it such as the create team. I added a check to see if the user has a team already, as well as a check to make sure players can’t have the same jersey number. I updated the player call to get all players belonging to a certain team and user. I worked on updating the update game call to now include both user and game id and updating the authentication to include an expiry time.

Token extraction

Over this sprint I updated some calls to include the user id. To do this I had to request the token and then decode it to get the users id. From here the user id is then added to the create game and team as well as the update game call. This was done so when creating a game or team the server knows which user this game or team is for. Below is an example of this for the create team call.

Team and player checks

While working on this sprint I added checks for the team and player calls. The team check was to check if the user has a team when they login. If they don’t, they will be redirected to the create team page. A check was added to the player calls to make sure there aren’t duplicate jersey numbers assigned to players. Below is the team check. It checks the database to see if a team exists with the users id. If one, does it will send back the teams’ details to be used in the app. If one doesn’t exist, the message in the response will let the app know to redirect the user to the create team page.

All players

During this sprint I worked on creating a call that will send back all the players belonging to a team and user. This was done so when the user views the manage team page all the players belonging to the team, they have currently selected will appear while players that belong to that user but to a different team won’t appear. Below is the code used to achieve this. It takes in the user id from the token and requests the team id from the app so the server can know which team the user wants the players for. It then checks id players exist for this team. If the any do all they will be returned in an array. If no players exist for the users team an appropriate message is returned.

Token Expiration

I worked on adding an expiration time to the token. To do this I added ‘exipresIn’ to the token and set it to 24 hours. This time was chosen as analysts would be commentating over the full length of a match, using the app over half time, and after full time. This may last a few hours, so I didn’t want the user to be unable to make calls to the server while recording a match or showing statistics details to a coach or player. After the match is over the analyst would still be using the app to record and statistics missed during the game by watching recordings of the match. This may take a few hours, so I didn’t want the user to be unable to finish collecting statistics while doing this. 24 hours would accommodate this.

2^nd – 14^th April

API calls

During this sprint I worked on updating some of the API calls and creating API calls that have been missed. I created a call to retrieve all player details from the database so a user can see all the players in their team and make any necessary changes to those players. Below is another call I made during this sprint, the delete team call. It checks if the team the user is trying to delete first exists, and if so, it will allow it to be deleted.

Authentication

I also made some changes to the authentication, now there is only one token created when the user logs in. This token will contain their id and will be used when a call is made to make sure the user is allowed to make that call. I then went through the calls that had authentication added to it and tested to make sure it was working as expected. Below is some of the calls I have added and updated the authentication for. These calls will be taking the users id to make sure it is a valid user making the call and they are allowed to make the call. 

I also worked on adding authentication to the app. It will take the token created when the user logs in and will send the token back when a call is made so the server can authenticate that the user is allowed to make the call they are requesting to make. The token will be stored in the header of the call when it is made. Unfortunately, I was unable to fully implement this and not all calls that should have authentication currently have it. The below image is of the token in the header of a call getting a users details. This will be sent to the server where the header will be requested and the token in it will be authenticated.

Tutorial used to help with adding authentication to the app: (App Authentication )

Responses

During this sprint I updated all the responses the server sends to the app. Before this the error code was only sent in the message response but it was still considered a 200 ok call even if it failed. I changed this so now the status of the call changes to match the problem that was encountered. I also updated the response messages to make it clearer what the error was. Below is the response code. if it is a valid call the status is sent to 200 and a message is displayed. If it is invalid the status is set to 400 and a different message is displayed.

The below images show a successful login. The status is set to 200 and the message saying it was successful is displayed.

Below is the response when the call is unsuccessful. The status is set to 400 and the message telling the user the login was unsuccessful is displayed.

Validation

During this sprint I adding in some new validation for the create team call to make sure the data entered is in the correct format. Below is some of the validation used when the user tries to create a team. Regex is used to make sure the correct format for the fields is entered, along with a min and max for the fields, followed by an appropriate error message for when one of the criteria's is not met.

Scrum

The goal of this sprint was to work towards finishing the app by working on any parts that need improvements, fixes, or changes. This was done trying to complete the following objectives:

Add Authentication to the app + update server side authentication 
Display all necessary details e.g.  players details, all relevant statistics at half/full time
Improve app layout - some details at half/full time were off the screen/ not formatted correctly 
Fix app bugs - sometimes crashing when logging in, moving slowly between pages
loading - add in loading screen/icon when the user is moving between pages/ logging in so they know the app checking if it is a valid user
command parser accuracy - increasing how accurately the command parser can pick up incorrectly translated words.

Overall I think this sprint was a success as most of the objectives were completed, e.g. loading, app bugs,  and the ones that weren't are nearly finished e.g. app authentication is not fully implemented for every call but is working for the calls it has been added in for. 

12^th March – 24^th March

Testing

For user testing I was able to get two people to help out. One who played Gaelic football and one who didn’t. Before the testing took place, I explained the vocabulary they will be using and the structure to use, e.g., when someone scores a point they would say, (shot) (outcome) (player number) for this the structure and the vocabulary would be shot point 14. After this they watched an example video showing how to use this vocabulary and structure in a match. Once this was done, I got them to do a short quiz. The person that played Gaelic football scored 9/10 and the person who didn’t scored 8/10.

After this the person that didn’t play Gaelic football was able to do a short 5-minute test where they had to commentate over a match while using the vocabulary, and trying to stick to the structure as close as possible. While they were doing this, I was taking notes on any mistakes they were making and if they were sticking to the structure. From this test I noticed they were saying kick instead of kick pass throughout the test, they said “number X” instead of just the number e.g., "number 14" instead of just "14". They said possession for most events even if the ball didn’t change possession e.g., "hand pass blue possession" even when it was already a blue ball.  They also tried to use the optional statistic for position when they could, e.g., "kick out short left". I noticed at the start they were hesitating when calling an event as they had to think of the correct word to use but over the course of the test they hesitated less as time went on.

After the 5-minute test they gave some feedback saying they felt the key words used were concise and easy to pick up.

Over this sprint I also did a noise test. This consisted of me playing a video of a crowed and reading out a script, increasing the volume and reading the same script again. I tried to keep the phone the same distance from me and speak at the same volume for each test. The results can be seen below.

I was expecting it to get less accurate the more the volume went up, but I was very surprised to see after 80 it got more accurate again. I was also surprised how accurate it was at all volumes when numbers were said, as only a few mistakes were made with the numbers.

 Authentication

In the last sprint I created the authentication. This sprint I was adding it to calls. For an example below is authentication working with the create_player call.

Below is the call that will be used to verify the authentication. It takes the users id and the team id that the player will be part of. This is to make sure the user is allowed to create players and the team exists.

The below code in the index page is using verify.TeamVerify. This is verifying the create_player call by using the above code.

Using postman I can test the call. With the authentication inactive in the headers I get Access Denied as a response.

With the authentication active in the header the player is created.

Validation

The validation, like the API calls has been moved into their own page. To make it work with the API calls it had been slightly reformatted. The first two lines are the one lines that allows it to work with calls in different pages.

To call the validation it first needs to be exported by doing the following.

To call it, you now go into the call the validation is for and add in the first two lines shown below. This verifies the input or returns an error message if the input is incorrect. 

The bottom two lines have been added to check for duplication emails as this is not allowed.

Create Team

Over the course of this sprint, I created the create team call. This will be used when create player and a match as a player needs to be part of a team and a match needs to have a team involved in it. In the below code the call is first checking if the team that is being created already exists. If it does it wont be created. If it is a new team the name and colour of the team is added and a json web token is created which will be used for authentication when a match is being created.

Kevin Mc Guigan

During this sprint we had a meeting with Kevin Mc Guigan, a performance analyst with Down GAA. Throughout this meeting he gave some extremely useful insight into the job of an analyst and what our app could do, for example he mentioned it would be useful to have statistics like points returned per 10 possessions, or a feature that would allow the analyst to add their own key words. He also mentioned that the vocabulary used is good but could be improved such as adding the pitch position to other events such as turnover and heatmaps would be extremely useful to add as it gives a quick breakdown of where events are happening at a glance. He mentioned it would be good to have recent events pop up on the screen in case they need to be edited or deleted. They could be marked when they pop up on the app, so it is easy to change them when the analyst has time. After this he mentioned how the systems, he currently uses works with video analyst software. This would be done by timestamping the events and then exporting them to an xml file which the video analyst software uses. He mentioned that while the user may get tired while using the app, he believed it would be less then the current system which requires the user to be constantly looking at the match, then looking at the computer to type then back up. He said this type of app would cut that out.

Kevin Mc Guigan mentioned how noise would be a major problem as the stadium would be very loud and while some have rooms the analyst can sit in to mitigate the noise not all pitches have this.

Sprint 11

Over the course of this sprint our main goal was to focus on user testing. To do this we came up with several tests. We created a short quiz of 10 questions to see how easy the vocabulary was to understand. There was a 5-minute test where the user would commentate over a match using the vocabulary and structure. This was done to understand how easy the vocabulary was to pick up and any changes that may need to be made. There was a 30 – 35-minute test which has been done to test how fatigue could affect a user’s ability to use the correct structure and how useful they felt the vocabulary was for the events occurring in the match. We also performed a background noise test to see how much background noise affected the apps’ ability to understand the user. Lastly there was an accent test. This was done to see how the accurate the app was when people with different accents used it.

During this sprint we also worked on adding authentication, completing the manage team page functionality, getting updated statistics to appear during recording and in the statistics screens, black box testing throughout the app.

26^th February – 10^th March

Authentication

This sprint my main objective was to work on adding authentication to the calls on the node server. This is an important part of the server as it makes sure only relevant details from the calls are given to each user. To achieve this a JSON Web Token (jwt) is created when the user logs in or register. This token is then sent in the header of the calls they make to verify it is them and so only details relevant to them are sent back e.g., they only see their own player details, not another user’s player details.

The below code shows the jwt being created in the login call. It takes the users id as well as a secret word. Both of these are added to the token making sure it is unique for each user. The token is then added to the header which will be used by the node server to verify the user.

The following code is called when the user makes a call. It first requires the header as that’s where the jwt is being sent. If there is no token, then the user is denied. After this it checks if the token sent is a valid one. If it is the call is allowed and the details will be sent to the app. If it isn’t a valid token the user is told ‘Invalid token’.

Link to tutorial used for authentication: https://www.youtube.com/watch?v=2jqok-WgelI  

Sprint 10

The main goal of this sprint was to finish the main functionality of the app. The main functionality that still needed to be completed was the call to update the statistics during a match so that the correct score can be displayed while the analyst is recording. This call would also be used to display the most up-to-date statistics at half time and full time on the statistics page.

For this sprint we also had a set of objectives, with the most important being to get up to date statistics displaying on the statistics page. Some of the other objectives were based on other work will wanted to get done during the sprint such as adding authentication to the project as shown above, adding in the functionality for the manage team page on the front end as after talking to Mark Copeland he stated how important it is to have the events linked to a player.

Meeting with Mark Copeland

At the start of this sprint, we had a meeting with Mark Copeland, a lecturer at the Southern Regional Collage, Newry and he has worked with Down GAA. During this call we demonstrated our app, discussed how statistics are currently collected, what statistics he collects, and any problems he sees with the app.

One of the main benefits he mentioned for this app was it meant the analyst didn’t have to keep looking down to record an even and potential miss another event. He liked the vocabulary used as it is common GAA terms, but he felt they could be more detailed e.g., when an event happens player numbers should be included (12 handpass). He also told us about the details he wanted displayed on the statistics screen – turnover and kick out won and loses percentages. During this meeting he mentioned a feature that is very important, flagging events. This would flag up certain events if they happened repeatedly such as losing 3 kick outs in a row so quick changes could be made during a match instead of waiting until half time or full time to get a detailed breakdown of the match events.

12^th February – 24^th February

Presentation

Over this sprint I prepared for our T-CA2 presentation. For the presentation I talked about our release 1 goals and our new release 2 goals. I also went over how the project works, explaining that the user talks into the app, every 15 seconds there recording is sent to the google cloud where it is converted to a text file. It is then sent to our server where it is converted into a JSON file. From here it is stored in the mongoDB and can be called by the phone using node to either store data or display data on the app.  

Validation

During this sprint I added more of the same type of validation that I added in the last sprint. I also added different validation to some calls. Whereas the validation added last sprint checked if the layout and types of data entered was correct the extra validation also checked whether the actual data added or called is correct data. An example is in the login call. The first type of validation checked that the data entered is of the correct type, e.g., certain length, password has numbers etc. The second type checked that the data entered match the data in the database. The below code shows an example of this. The password entered is verified with the password stored in the database. If it matches the user can login, if not an error message is sent telling them they entered incorrect details.

During this sprint I added more validation to the node api calls. Once of the calls was the create match call. Before this we were running into problems with this call. The create match function would send the data to the games collection before all fields are filled in but would run into a timeout error when also putting the necessary data in the active_games call. Adding validation solved this problem.  

Password Hashing

During this sprint I worked on adding password hashing to the login and register. For this password hashing node-password-hashed was used. In the registration call the password the user enters is hashed and then the hashed password is put into newUserObject. This is then sent to the users collection in the mongoDB.

To login the hashed password is compared to the password the user entered. If it matches then they are allowed to login.

(Link to password hashing : https://www.npmjs.com/package/password-hash)

Sprint Goal

The goal of this sprint was to work towards finishing app development. This was going to be achieved by completing several objectives: updating and fixing any api calls we have been having problems with e.g., create match, improve the command parser so words are more accurately converted, improve app flow for the statistics to recording page and display statistics accurately. Unfortunately, while most of the objectives were achieved not all where, as there were problems with the counting of the statistics which meant they were not displaying when it came to doing the T-CA2 presentation.