Inspiration
As we were both private tutors before, we have a lot of frustration in finding students efficiently and effectively. Especially when it comes to students with whom our personalities and teaching/learning styles match very well. This is an often overlooked but extremely important part of education. Hence, we though how nice it would be to have an app that can help people find their best holistic match for a tutor/tutee with the click of a button.
From our market research survey and competitive analysis, we have found a huge market for an app like such, and a lack of a large dominating market player in the Asian Pacific region.
What it does
Studiy is different from any other tutoring apps. We don’t just focus on academic aptitude, we value the teaching/learning styles and MBTI personalities of our users just as much. From our market analysis survey, we have found personality and learning styles to be a close 3rd and 4th most valued traits when looking for a tutor/tutee, right after aptitude and school.
How we built it
Backend: I referred to Google Jetpack for their guidelines on how to organise an app. This application follows the Model-view viewmodel architectural pattern, where a ViewModel object acts as a wrapper to parse Models into Views, and vice-versa. Each component is only linked to the components above and below it to increase encapsulation. I split the app into 4 main flows, with each flow representing an action a user can take, e.g. logging in or signing up. This gives the app natural transitions between actions and continuity while performing the same action. Each flow comprises an activity, its fragments, as well as the necessary viewmodels for managing the data. All transitions between fragments are managed within the activity class while layout changes are managed by each fragment, which separates the fragment design from the app transition logic. One problem I ran into is that Recycler Adapters couldn't access the viewmodel properly so I had to use a singleton pattern for the viewmodel (I'm not sure if this is the best approach though).
User Interface: The overall UI was done in Figma. As we chose to design for the Android environment, I used the Google Pixel 2 template for my mockup. The fonts of choice are EB Garamond and Roboto, Roboto as the default Android font matches well with EB Garamond, a serif font conveying the professionalism we want to portray through this app. I chose to adopt the 8pt grid system with 16 columns on XL/L breakpoints and 8 as the browser sizes down. This allowed us to create more interesting layouts whilst introducing consistency and rhythm across products. The primary colour scheme is limited to two main colour groups of blue and red, conveying efficiency with a touch of brightness.
Challenges we ran into
SQLite: The schema was not planned out in full, so the fields and attributes kept changing; Integration of the SQLite into Android also posed a problem and we took a while to find the SQLDroid solution Android Studio: Implementing UI elements from Figma fast was a real challenge. Many animations that we wanted on Figma was not trivial to do in Android Studio.
Accomplishments that we're proud of
We are proud of having built a working AI matching algorithm, and integrating it with the front end and UI with a time crunch.
What we learned
Programming and working with Mobile App development Integrating databases with other code Process of software development, from deciding on problem statements to making use cases to narrowing down on the important features How to import UIs from figma into Android studio Learnt what a hackathon is about and how to collaborate with a team on a project on a tight deadline
What's next for Studiy
We are planning to implement a referral system where people can refer good tutors and tutees based on the most popular current way of acquiring students, word-of-mouth. We are hoping to eventually launch it after combining the back end, front end and user interface design more seamlessly. We would have had the ML model calculate compatibility scores locally, on each person's phone. This is because every time a user adds new information (e.g. more test scores), we need to recalculate scores, and it makes sense to distribute the computation instead of having centralised computation on a server.
Log in or sign up for Devpost to join the conversation.