Project Description

This project is meant to be the culmination of all my accumulated experience gained while working through my degree at UBCO. As a Capstone Project, it is different in structure compared to the other projects I've worked on. In this project, our task as a group is to design a backend attachment that can take text from a user, and output a video. In this video, users should be able to hear the audio that represents their text, and should be able to see an avatar "speaking" and gesturing in relation to the audio. One could compare this project to existing applications like the famous Talking Tom app. Additionally, our project is meant to teach us how to work as a team, learn how to structure development, and improve our understanding of the software development process.

Roles & Responsibilities

Group Contribution

As the Project Manager, planning out the project was one of my more important tasks. As this project is something that the group was unfamiliar with, and rather open ended, we needed a plan that was solid enough to give us direction, while at the same time allowing us to make changes as needed during development. During our research phase, we found a potential solution to our problem, but it would be a large development process, that had a potential of failure. I proposed to have 3 members of the team focus their efforts on that, while I developed a backup alternative system that we would use in case the main system failed. Over our winter break I discovered that fully developing the alternate system would result in a product that wouldn't meet our standards, so I decided to scrap the system, and moved on to hooking up a Front End + Back End to the headless main system.

Aside from planning, I delegated development tasks in accordance with each members' strengths, other course load, project responsibilites and weaknesses taken into account. Naturally, I applied these factors when proposing the plan mentioned above as well. My non-development work load as a Project Manager was lower than that of my teammates, so it made more sense to me that I alone would work on the backup system, and ask for help if absolutely needed.

During meetings with our professor, I was usually the one responsible for communicating our progress and concerns as a team. Usually, we held our group meetings every Monday or Friday, which was when we discussed any issues or concerns about the project. During these meetings, it was my duty to ensure that all concerns needing attention from our professor be addressed when meeting with the professor.

Solo Work

As I briefly mentioned, I was developing the backup system (now deprecated) for this project. You may wonder why it was necessary, and the answer to that can be found in our choice of language for this project. The client we were assigned to for this project has a TypeScript backend, so we wanted to develop a system that would be easy for them to integrate with little effort. Naturally, we decided that TypeScript would be the best language for this. However, this made the actual task of the project much harder, since many existing programs that have the capabilities that we wanted were always written in different languages. Since we didn't want to compromise the ease of integration, we decided to stick with TypeScript and split development into two sides. One side would work to rewrite a forced alignment system that was originally written in Python, completely in TypeScript. The other side, which is what I have worked on, would work to develop a novel solution completely in TypeScript. This meant that I would have to design a system that would process user input, process audio, and generate a video as the end result. This is why I opted to call it, the "Manual System."

As mentioned in the "Group Contribution" section, I decided to deprecate and scrap my Manual System. After putting in multiple hours of work, I hit a wall when trying to increase the accuracy of the system, but due to my inexperience and our system limitations, it became very apparent that this system would not be able to accomplish our goals in full.

My work on our project's FE and BE included writing client side scripts, and server side endpoints that would allow a user to use a fully interactive site that would take text from the user and a selection of the voice, avatar and aligner which would eventually send back a video for the user to view. Making this wasn't a requirement from our client, as the meat of our requirements was the BE video generation engine, but we felt that it would make integration for our client a lot easier. With this FE, we had a fully integrated and working example of how the client may want to implement our BE system to their site, which made our technical documentation easier to digest and understand. Functionality was definitely a priority here, so visually it isn't a very pretty FE. Additionally, testing our system was much easier because of the FE, which lead to us finding a few bugs that I fixed. One nasty bug (with a simple fix) caused our animation engine to crash due to poor data handling. We also were able to test many kinds of inputs extremely quickly, and were able to give our client a more complete list of issues and capabilities of our system.