At the end of our project, we gathered all of the MoSCoW requirements we had set at the start of our project and reflected on how much of our goals we had accomplished.
| No. | Description | Priority | Completed? | Contributors |
|---|---|---|---|---|
| 1 | Migrate Features from MotionInput V3.2 | MUST | Yes | Michal, De Xin, Shu Han, Seojeong |
| 2 | Design and Develop MotionInput SDK | MUST | Yes | Michal, De Xin, Shu Han, Seojeong |
| 3 | Ensure Windows Solution is natively compiled and not use the cloud | MUST | Yes | Michal, Shu Han |
| 4 | Incorporate MotionInput into a Python package | MUST | Yes | Michal, Shu Han |
| 5 | Examine build references for DLL and kiosk implementations | MUST | Yes | Michal, De Xin |
| 6 | Finetune MotionInput features at the Richard Cloudesley School | MUST | Yes | Michal, De Xin, Shu Han, Seojeong |
| 7 | Improving compilation processes with data security packaging and obfuscation | MUST | Yes | Michal, De Xin, Shu Han, Seojeong |
| 8 | Support other Migration groups | SHOULD | Yes | Michal, De Xin, Shu Han, Seojeong |
| 9 | Assist BBC shooting and other promotional activities | SHOULD | Yes | Michal, De Xin, Shu Han, Seojeong |
| 10 | Assist the Android build solution | SHOULD | Yes | De Xin, Seojeong |
| 11 | Prove efficiency gains in optimizing the codebase | SHOULD | Yes | De Xin, Shu Han, Seojeong |
| 12 | Assist Bluetooth Controller team on porting the codebase | COULD | Yes | Michal, De Xin, Shu Han, Seojeong |
Percentage of core functionality (MUST & SHOULD) implemented: 100%
Percentage of additional functionalities (COULD) implemented: 100%
We have thoroughly tested our code to ensure that there are no bugs in any of our MFC's or additions to the MotionInput repository. However, during development, we encountered a plethora of bugs that we had to fix. The table below documents some of those bugs:
| Bug Description | Priority |
|---|---|
| The API package lacks mechanisms to manage computational resources effectively, leading to instances where MotionInput consumes excessive amounts of RAM/VRAM. This excessive resource usage can result in performance degradation and lag in the primary application. | Medium |
| Certain functionalities within the codebase are hardcoded and not configurable through the json files. This limitation prevents developers from accessing and leveraging these features dynamically. | Medium |
| The files linked to the DLL are susceptible to unintended modifications by the user, which can disrupt its proper functioning and necessitate a reinitialization of the DLL to restore normal operation. | Low |
| The MotionInput Package is incompatible with Python versions 3.9 and lower, limiting its usability across different Python environments. | Low |
| Task | Michal Bravanský | Ho Shu Han | Fu Dexin | Hong SeoJeong |
|---|---|---|---|---|
| Client Liason | 25% | 25% | 25% | 25% |
| HCI | 25% | 25% | 25% | 25% |
| Requirement Analysis | 25% | 25% | 25% | 25% |
| Research | 20% | 25% | 35% | 20% |
| V3.2 Poses and Modes Migration | 25% | 25% | 25% | 25% |
| MotionInput SDK/DLL Development | 70% | 10% | 10% | 10% |
| Monthly Blogs and Videos | 1% | 10% | 10% | 70% |
| Project Website | 10% | 40% | 10% | 40% |
| Video Editing | 10% | 40% | 10% | 40% |
| Liason with other teams | 25% | 25% | 25% | 25% |
| Testing | 10% | 70% | 10% | 10% |
| Overall Contribution | 25% | 25% | 25% | 25% |
| Main Roles | Technical Lead, Client Liaison |
Developer, Tester, Researcher |
Developer, Tester, Researcher |
Developer, Blogger, Website Editor |
User experience has been enhanced as developers no longer need to delve into the entire code repository to run MotionInput software. They can simply execute the software from its compiled executable. For added flexibility, they can customize pre-defined poses by modifying the config.json or mode JSON files. This allows for flexible use of the software without requiring an in-depth understanding.
However, the limitation lies in developers' inability to access the actual code repository. If they discover a bug, they are unable to rectify it themselves and must instead reach out to the MotionInput team for a resolution.
Furthermore, their ability to introduce new features is limited. Therefore, it is imperative for the future MotionInput team to prioritize modularity, allowing developers to easily adapt and repurpose various functionalities to meet their specific requirements.
The developer experience has been improved by simplifying the repository structure. Specific gestures are no longer hardcoded into poses; instead, developers specify them in the JSON modes they create. The structure of individual pose classes has been streamlined as well; most of them no longer need an action() method, only the check() and from_kwargs() methods. While this greatly enhances flexibility, it depends on the developer's knowledge of keyboard/mouse methods names to define those in the JSON. Consequently, comprehensive documentation has been provided and will be crucial for future work.
Due to the above reasoning, we believe we did a Very Good job in creating a usable user interface.
MotionInput software has been made more functional, allowing developers to run it as a standalone application or import it into their own projects, rather than needing to execute it from the code repository. The functionalities have been further enhanced by the setup() file, which generates a .so file, enabling the local installation of the motioninput package for reuse.
However, a significant limitation is that some functionalities cannot be fully encapsulated within these new distributions. For example, installing additional computer packages is necessary to emulate an Xbox controller. We hope that in the future, all such external OS dependencies will be bundled with the application we distribute.
We have migrated all essential and usable features from the previous version to the new repository. This process involved introducing entirely new modules, such as the Head Module and the Sound Driver, and migrating dozens of classes. This effort allows future versions of MotionInput to build on the progress made by earlier versions.
A significant limitation of this approach is the lack of coherence in the previous version. Certain poses were in a state that did not allow for an easy transition, requiring their complete reimplementation. However, this was not compatible with our other requirements.
Due to the above reasoning, we believe that we did a Very Good job in ensuring code functionality.
The MotionInput SDK and DLL have demonstrated considerable stability across platforms, including both Windows and MacOS, after numerous rounds of thorough testing.
However, the API and DLL are not yet configured to fully support all versions of Windows, Mac, and Linux. We believe that additional efforts are needed to expand the coverage of these distributions.
All the poses migrated to MotionInput v3.4 underwent rigorous testing and quality assurance checks before deployment. We employed integration testing to ensure that our migrated poses work across platforms. User Acceptance Testing was also conducted to verify that users could effectively utilize the poses.
One limitation is that not all poses from v3.2 were migrated to v3.4 due to inherent time constraints. As a result, there are discrepancies between the versions in terms of functionalities, making it more complex to switch between different versions.
Due to the above reasoning, we believe that we did a Very Good job in ensuring code stability.
The performance of MotionInput remained stable, as evidenced by the performance testing we conducted across the code repository, Python package, and the DLL.
One limitation is the backend application's inability to specify its memory usage or select which GPU to use. This constraint could complicate the integration of the DLL into other applications, as developers might not have direct control over MotionInput's resource requirements.
Efficiency of poses did not decay at all, evident from the performance testing that we conducted on the code repository compared to v3.2.
Some of the optimization techniques from version 3.2 were not transferred. Had they been incorporated, the efficiency of version 3.4 could have been further improved. We encourage future teams to build upon our work and extend MotionInput to an even wider range of devices.
Due to the above reasoning, we believe that we did a Very Good job in ensuring code performance and efficiency.
Cross-platform compatibility has been ensured for the MotionInput SDK and DLL. Users can run MotionInput using a .pyd file on Windows and a .so file on MacOS.
The main limitation is the unaddressed gap in cross-language support for the package on non-Windows devices. The current method, which employs a .so file, still requires a Python interpreter, potentially adding extra overhead that developers may find undesirable.
Cross-platform compatibility for MotionInput v3.4 was rigorously ensured by testing all migrated poses across different platforms (macOS and Windows). The poses were tested using multiple simple online games. We also ensured cross-device compatibility by assisting other teams with their migration and development efforts, such as the Bluetooth team.
However, some features that are specific to Windows could not be transferred to Mac. Consequently, certain migrated modes are only available on Windows.
Due to the above reasoning, we believe that we did a Very Good job in ensuring code compatibility.
The MotionInput SDK and DLL can be easily updated to accommodate changes in the codebase by simply recompiling the code. This facilitates straightforward maintenance without the need for additional development.
However, different OS versions necessitate distinct compiled distributions. As of the time this blog was written, there is no automated process for generating these compiled binaries, hence they must be produced manually.
The software architecture has been made adaptive and modular due to the introduction of modified JSON modes. Gestures triggered are no longer hardcoded into specific poses but are instead specified in the JSON modes. This improvement enhances usability for future developers.
One potential limitation is that since the migration was performed manually, tracing different poses back to their original versions can be more challenging, necessitating additional effort to locate them.
Due to the above reasoning, we believe that we did a Very Good job in ensuring code maintainability.
Overall, the project has been managed very effectively, as we ensured equitable task distribution among group members. Communication was a top priority for our group. We held productive weekly internal meetings to update on progress. All members successfully completed their respective tasks by the deadlines outlined in the GANTT chart.
Our team leader, Michal, kept in constant contact and provided diligent updates to our client to ensure alignment with the desired goals. Our team utilized Notion for task management and Google Drive for the orderly compilation of documents throughout the project. Ultimately, we fulfilled all the prioritized requirements to our client's satisfaction.
Due to the above reasoning, we believe that we did a Very Good job in managing our project.
Even though we were able to exceed our own expectations when it comes to the number of requirements we were able to complete, there are a number of tasks that we wish we could have further accomplished within our limited timeframe. We hope the future MotionInput teams will be able to expand on our work and allow it to have an even larger impact than what we achieved during our two-term project.
While we have successfully completed the migration, we were unable to achieve the desired level of modularity for all poses due to time constraints. We hope future MotionInput teams will not only focus on making devices more accessible but also prioritize enhancing the usability of features for developers.
We believe that establishing a developer community around MotionInput would be more feasible if we distributed our solutions on community-centric platforms like PyPI. Although our current solution can be installed in Python, it requires a compiled code for the specific OS system along with the appropriate Python distribution. If future teams could automate the compilation process, possibly by leveraging cloud solutions, we could distribute various compiled versions of the codebase on PyPI, significantly simplifying the installation process of MotionInput.
To our knowledge, it is currently not feasible to eliminate the need to ship the Python Interpreter and the compiled binary of the codebase along with the DLL. However, we encourage subsequent teams to build upon our research and explore ways to reduce these additional files, which would decrease the overall size of the DLL package and enhance developer convenience and maintainability.