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
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.
|1||View all types of OER||Must||☑️||Patrick|
|2||Suggest relevant OERs and show them below the OER that is currently on display||Must||☑️||Patrick|
|3||Play or pause an OER video||Must||☑️||Patrick|
|4||View a specific OER and its details when users press it||Must||☑️||Patrick|
|5||Bookmark a specific OER||Must||☑️||Patrick|
|6||Add notes to the OER when they are on display||Must||☑️||Patrick / Felix|
|7||Show the person or organisation who uploads the OER material||Must||☑️||Patrick|
|8||Search X5GON OER collections for keywords||Must||☑️||Patrick|
|9||View their browsing history||Must||☑️||Patrick|
|10||Full screen (focus) mode to view OERs||Must||☑️||Patrick|
|11||Rate an OER by pressing the like and dislike button||Must||☑️||Patrick|
|12||Login and logout of their accounts.||Should||☑️||Patrick|
|13||Buffer users’ notes for a specific OER and send them to the backend of X5GON.||Should||☑️||Patrick|
|14||Preload the video shown on the lists for responsiveness.||Should||☑️||Patrick|
|15||Provide different main pages, including trending, subscribed contents.||Should||☑️||Patrick / Felix|
|16||Create a simulated backend to pre-develop certain features||Should||☑️||Patrick|
|17||Deploy this software on different platforms, e.g. iPhone, iPad||Could||☑️||Patrick|
|18||Allow users to report inappropriate content||Could||☑️||Patrick|
|19||Continuous Integration with Travis||Could||☑️||Patrick|
|20||Introduce unit testing to the Application||Could||☑️||Felix / Patrick|
|21||Have captions or translations for captions||Won’t|
|22||Allow users to upload OER from our app||Won’t|
|23||Allow users to collaborative edit notes||Won’t|
|24||Allow commenting on OER||Won’t|
|25||Show users’ note to other users||Won’t|
|26||Keep suggesting the same OER to same user||Won’t|
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.
|Part Of Project||Patrick Wu||Yinrui Hu|
|Main Roles||Lead Developer, Lead Researcher||Tester, UI Designer, Video Editor|
As a team lead, I am very delighted to see Yinrui made a solid
40% of contribution to the project.
We conduct thorough investigation of the work we have done, and evaluate them for continuous improvements in future projects.
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
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.
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
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.
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.
If 6 more months were given, we would be able to improve on below 4 aspects to make the application even better:
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.
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.
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.
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