Our team was entrusted with the task of migrating features from version 3.2 to 3.4 of MotionInput, along with implementing new features that would benefit developers and ultimately aid disabled individuals. This undertaking required an extensive process, which we dedicated ourselves to throughout the first term.

Preparation Phase

In addition to our four-member team, the migration effort was a joint collaboration primarily involving the Calibration Team, represented by Suhas Hariharan, and the AX-CS Frontend Team, represented by Vayk Mathrani. To effectively manage such a large group, we established a custom Notion page to allocate and track tasks.

In the initial month, we engaged in numerous discussions with our client, teaching assistants, and past contributors to MotionInput. These conversations provided us with valuable insights into the functionalities of versions 3.0 and 3.2, and the enhancements introduced in version 3.4. We then shared these insights with the broader migration team through comprehensive sessions, facilitating their understanding of the new repository. To aid in this transition, we developed a detailed migration manual, available here:

Planning Stage

After all members have familirized with the MotionInput codebase, we held a number of dicussions about features we should focus on and which are the most needed. As the number of these features is in the dozens, we needed to develop a framework to objectively assess their importance. As such, we utilized a ranking system, where we scored features based on their flexibility of use, migration difficulty, and future potential. In the end, we came to the following list of features and functionalities, which we have successfully implemented as well:

Migration Stage

Upon finalizing the selection of features, we embarked on the journey of integrating them into the new version of MotionInput. To ensure a smooth and efficient migration process, we adopted an agile methodology, organizing our efforts into weekly sprints. These sprints were kick-started during our lab sessions every Tuesday, where we delegated specific functionalities to team members. Despite this structured approach, we maintained frequent meetings throughout the week to foster communication and enhance our overall productivity. The following is video from one of such sessions:

For a streamlined development process, each feature was migrated in its own dedicated branch, created by the respective assignee. This strategy not only facilitated focused development and isolated testing but also simplified the review process. Once a feature was fully developed and rigorously tested, the assignee submitted a pull request. This request was then reviewed by another team member before being merged into the main project. Through this iterative and collaborative approach, we were able to monitor our progress effectively and continuously refine the newly added features.

Key Feature: Swipe Feature Migration

This case study outlines the migration process of a swipe gesture feature, which we have specifically focused on based on the feedback from our client. Additionally, as the client requested, we omit any specific code details. Instead, we'll focus on the structural approach taken to enhance the feature's modularity and maintainability.

In version MotionInput 3.2, the swipe gesture is encapsulated within a Python module, comprising several methods. The method _check_state is pivotal, as it monitors for gesture activation on a per-frame basis, subsequently invoking the update method when necessary. Complementing the Python logic, each gesture is defined in a JSON file, detailing the gesture's name and the associated actions it can trigger. These gestures are then grouped into a collection, forming a 'gesture' that users can select and interact with. Despite its functionality, the existing architecture presents a challenge due to its complexity and lack of modularity, with components dispersed across multiple files. Our migration strategy aims to address these issues, streamlining the feature for better flexibility and integration.

With the transition to MotionInput 3.4, the swipe gesture has undergone thoughtful refinement, which you can find below. It is now encapsulated within a Python class that introduces a more modular approach, incorporating methods for initialization and action handling.

A key feature of this update is the from_kwargs method. This addition enables the dynamic creation of gesture instances using keyword arguments, facilitating a more adaptable and responsive design. We need to compile a list of these keywords based on previously implemented features, and ensure our newly added feature is modular enough for future users and development.

To ensure clarity and maintain the system's integrity, the action and check methods have been introduced, evolving from the previous update and _check_state methods. We then define these methods to mimic the functionality we require, with additional auxiliary ones to help them proccess incoming frames.

Before fully integrating this refined gesture into MI 3.4, it undergoes a thorough testing phase. This involves adjusting the active game mode in the "config.json" file to assess the gesture's performance and ensure it meets our expectations. Following successful testing, we will conclude the gesture's integration by documenting each method. This documentation aims to clearly explain the functionality and purpose of the methods, ensuring a smooth transition and easy adoption for users.