Bug List

Our team utilises GitHub issue tracker to keep track of bugs and fixing progress. We did not use JIRA issue tracker as its isolated from the code base on Github.

Upon completion, we are proud to say we have fixed all known bugs and there is none left in our issue tracker.

On the right, we provide a snapshot of issue list on 5 Apr, 2020. All 3 of them being documentation related issues.


Achievements - MosCow List Status

1View all types of OERMust☑️Patrick
2Suggest relevant OERs and show them below the OER that is currently on displayMust☑️Patrick
3Play or pause an OER videoMust☑️Patrick
4View a specific OER and its details when users press itMust☑️Patrick
5Bookmark a specific OERMust☑️Patrick
6Add notes to the OER when they are on displayMust☑️Patrick / Felix
7Show the person or organisation who uploads the OER materialMust☑️Patrick
8Search X5GON OER collections for keywordsMust☑️Patrick
9View their browsing historyMust☑️Patrick
10Full screen (focus) mode to view OERsMust☑️Patrick
11Rate an OER by pressing the like and dislike buttonMust☑️Patrick
12Login and logout of their accounts.Should☑️Patrick
13Buffer users’ notes for a specific OER and send them to the backend of X5GON.Should☑️Patrick
14Preload the video shown on the lists for responsiveness.Should☑️Patrick
15Provide different main pages, including trending, subscribed contents.Should☑️Patrick / Felix
16Create a simulated backend to pre-develop certain featuresShould☑️Patrick
17Deploy this software on different platforms, e.g. iPhone, iPadCould☑️Patrick
18Allow users to report inappropriate contentCould☑️Patrick
19Continuous Integration with TravisCould☑️Patrick
20Introduce unit testing to the ApplicationCould☑️Felix / Patrick
21Have captions or translations for captionsWon’t
22Allow users to upload OER from our appWon’t
23Allow users to collaborative edit notesWon’t
24Allow commenting on OERWon’t
25Show users’ note to other usersWon’t
26Keep suggesting the same OER to same userWon’t
Key Functionalities:100 %
Optional Functionalities:100 %

*Certain modifications are made to the MoSCoW list upon mutual agreement with the client during the project.

We are happy to present our product with 100% completed MosCoW requirement. We recognise the hard work and dedication our team has made throughout the development process.

Achievements - Individual Contributions

Part Of ProjectPatrick WuYinrui Hu
Client Liaison80%20%
Requirement Analysis60%40%
UI Design50%50%
Bi-Weekly Reports70%30%
Project Website80%20%
Poster Design80%20%
Video Editing80%20%
Overall Contribution60%40%
Main Roles
Lead Developer, Lead ResearcherTester, UI Designer, Video Editor

As a team lead, I am very delighted to see Yinrui made a solid 40% of contribution to the project.

Critical Evaluation of the project

We conduct thorough investigation of the work we have done, and evaluate them for continuous improvements in future projects.

User Interface and Experience

We adopted a similar feed based UI from other video service providers instead of education providers. This yields better results from our perspective, as this hides tedious information from users and presents key information in a feed way. It was generally praised that this type of UI gives user much familiarity to what they have used before, and they are getting used to using it really quick. However, some does point out there should probably be bits of innovation which differentiate our app to the biggest video provider. We put a lot of work into making UI responsive, and user-friendly with custom animations and effects in our application. For more information, checkout User Acceptance Testing.

In all, We give ourselves Good for our UI work.


With our backend in active development, we made our best attempt to mock up APIs and write our own backend to develop features that were intended to have in the MoSCoW requirement list. The application we are delivering covers 100% of all MoSCoW requirements and with extendable and easy-to-develop backend API support modules. Within our team, we have hand tested and presented every functionality in the technical video to make sure they are working as intended.

We give ourselves Very Good for our functionality completion.


Our team followed rigorous and extensive testing procedure throughout our development cycle. We are happy to archive 90%+ code coverage including all UI components and 85%+ documentation coverage as a client-based application. Not to mention, we also have CI/CD, automated document generation, formatter and linter on Git hook setup to ensure the stability of our application. With such measures, we are able to deliver to good confidence on the stability of our product.

We evaluate ourselves to be Very Good from a Stability perspective.


Performance and efficiency has been a key part of our concerns throughout the project cycle. This is a major reason why we adopted Swift as our main development language. Throughout our development process, we used Instrument, a profiler made for iOS applications to keep track of the network and CPU load of our application. When there is an improvement can be made, as stated in the Multi-Threading and Task Queueing section, we made our best effort to utilise technologies we have to make it faster. We also adopted predictive pre-fetching and pre-loading techniques to flatten the network curve. All these measures are worthwhile as we present you our performance testing results, which is 100% faster than similar applications, taking half its time to perform most actions.

We think we have done a good job and give ourselves Very Good for these optimisations done due to efficiency concerns.


As this project started with Swift 5, we considered certain aspects of backwards compatibility to make sure we can run our application on relatively older devices. For newer features, we used #available tag provided in Swift to optionally activate some of them when they are supported. However, due to design, implementation and time frame concerns, we were not able to rewrite some parts of our application to make it backwards compatible to iOS 11.0-. We conducted testing with past 3 OS images on our CI platform, Travis. However, it slows down our deployment process significant if we conduct tests on all platforms. Therefore, we can only limit it to 3. There are definitely work can be done to enhance support for much older devices, e.g. iPhone 6, iPod Touch 6 and iPad 4. Given the fact we don't have these devices and the simulator doesn't support older OSes, we would have to limit our support devices to those compatible with iOS 12.0+ and ideal ones to iOS 13.0+.

There are definitely rooms for improvement on this aspect and we give ourselves Good for backwards compatibility.


The code base overall is well-documented and can be extended easily as long as it conforms to our interface. We utilised multiple Design Patterns to make sure our code is highly cohesive and loosely coupled. Each module is thoroughly unit-tested and guaranteed to work on its own. Our client has been well informed of the code base from a technical perspective and fully understands how each module work together as an application.

Given the code being well-maintained, we recognise our work as Very Good from a maintainability point of view.

Project Management

We only have 2 members in the team. This has both its advantage and disadvantages. Although we have one less person to work with, our teams saves a lot of communication and synchronising effort. We were able to communicate easily and quickly without having schedule a specific time to meet up. As mentioned earlier, we utilised GitHub's issue tracker for this type of basic project management and archived good result. Every team member is clear when it comes up what to do and what are the next steps. Eventually, we are able to finish ahead of our schedule and put some extra effort into optimisations, as well as licensing issues. Retrospectively, we could have used Jira which makes the management process clearer yet more complicated. We are not sure if Jira would make the process better overall.

Our team had a well managed project and we give ourselves Very Good for project management.

Future Work

If 6 more months were given, we would be able to improve on below 4 aspects to make the application even better:

Captions Support

As a cross-language learning platform, captions support for videos would be ideal to help more users understand contents not in their mother tongue. To archive this, we would need to alter the built-in AVPlayerController and make custom floating UIExtensions to support caption injections.

Caching on Search Results

The backend, as stated earlier, would take more than 10 seconds to return full search results. We are looking into caching this data and present to users when they search for the same content in a limited time frame. This can greatly reduce the loading time on search and provide much better user experience.

Integrate ML algorithms locally in App

Currently, all ML algorithms are running on the cloud providing customised learning path. We would love to mitigate the network pressure and allow users to customise their learning process offline. This requires training a mini ML model and putting it into the application, potentially with TensorFlow on Swift.

Better layout for iPad

Although all UI elements are working correctly on iPad, we would take some time to draw up a different UI layout for iPad providing its slightly varied usage scenarios compared to an iPhone. This should possibly include a two-column ContentView and larger PlayerView, with more interactive WikiChunk Information.