- 1. Inspiration
- 2. What it does
- 3. How we built it
- 4. Challenges we ran into
- 5. What we learned
- 6. What’s next for Adopt a Student
The spread of Covid-19 has forced schools to shut down and move classes online until further notice. There are many challenges students across the globe are facing in virtual learning, such as poor internet connectivity, lack of school budget, and unequipped teaching staff.
2. What it does
Adopt a Student is an app that connects students and teachers around the world. It matches students to teachers and vice versa based on subjects, topics, education level, and location. Students would then be able to ask questions and receive one-to-one tutoring via video call or chat message, which does not require high-speed internet. The app would have a section that caters to the students and another to the teachers.
This platform opens up a teacher's responsibility to the general public by making it easy for anyone with academic knowledge to teach students.
Adopt a Student does not substitute physical or virtual classes organized by the school. The app acts as a supporting learning platform for students to ask more questions outside the formal classroom. It enables students to receive one-to-one interaction with tutors, which is crucial for learning development. The idea is to give students the extra morale to learn online by giving them access to a big pool of educators who can help them to understand their subjects better. Schools without the virtual learning facility would also use this platform to connect with their students.
3. How we built it
Alexandro Acha suggested developing a platform to manage volunteers who wish to help students who are not attending physical classes. Information is gathered from students to help identify and match with teaching volunteers.
We realized that we had to create a minimal viable product (MVP) in a short timeframe for submission to the hackathon from the onset. The project was dubbed as a ‘Tinder-like’ app that matches students and teachers for learning purposes. The MVP was then decided to be a simple process that will allow students to signup, key in information, primarily learning subjects and topics, and then view a list of matching teachers.
3.1. Chin Wei’s role
My role in this project was primarily as a UI UX designer. I approached the project with a standard progression starting from the discovery and strategy phase, followed by developing the information architecture and designing the UI and visual mockup.
For the discovery and strategy phase, I researched the challenges of virtual learning and looked into existing online platforms for ‘what has been done and ‘what could be improved’.
I created an affinity map for my research which would then be used for developing user personas, one for students and another for teachers. The user personas helped gain a better understanding of their needs and pain points which would then inform our information architecture.
In the information architecture phase, I wrote down all the necessary functions and content to address our user personas' needs and pain points.
The functions and content were then card-sorted and organized to develop our sitemap. I would place myself in the shoes of our user personas to figure out how they would actually journey through the app. Regrettably, real users were not used for validation due to time constraints.
As I was creating the sitemap, it soon became obvious that the user flows needed to diverge into two from the very beginning of the app. It would require the users to choose either the students' or the teachers' path, with each taking them on a separate journey while sharing some similarity. The student’s journey would focus on helping them to find and successfully engage with matching teachers to acquire the needed knowledge. Meanwhile, the teachers' path would create an appealing environment for the teaching volunteers to share their knowledge easily, intuitively, and hassle-free.
The wireframes were then designed based on the sitemap using simple black and white shapes to avoid making aesthetic decisions tackled in the visual mockup phase. Some revisions were made concerning the sitemap; for example, the buttons ‘Ask a question and ‘Lesson request’ were added to the student’s path to streamline communication between students and teachers.
For UI and visual mockups, I did simple research. I created a template mood board for reference, a colour palette, and a logo design before starting the UI and visual mockups.
For mood board research, I looked at education sites, illustrations, and good UI designs. The UI style that I went for was simple and clean, with a little curve on the edges.
As for the colour, it was decided that green would be the main colour of the app and the brand identity. Green is associated with the colour of the chalkboard and also symbolizes learning growth akin to a sprout.
I created several iterations of the Adopt a Student logo in green and arrived at a design with a mortarboard iconography.
As for the usage of green in the UI, I used green shades of teal and turquoise as the primary colours, such as for the header; lime green as an accent colour, particularly for the buttons; and white and dark-desaturated blue as the neutral colours.
I picked Open Sans sans-serif typeface for its clean and readable quality. I tried several choices and was quick to eliminate serif fonts because they resonate with ‘institution’, and I wanted the app to be less formal and approachable. But at the same time, it has to be clean and modern to give confidence to the teaching professionals. Opens sans fulfils all the criteria, and as a font for a learning platform, it has great legibility, especially for reading.
I designed three slides titled ‘Connect’, ‘Learn’ and ‘Explore’ for the onboarding process to explain what this app is about.
My final deliverable is a clickable visual mockup consists of 61 screens following students’ path from signup to submitting lesson requests to a matching teacher. The sitemap, wireframe, UI, and visual mockup were all created in Figma.
3.2. Elias Mangoro’s role
My role in this project was to design and implement the data model, data controller/API, and a web application for users. I approached these various tasks in the order described below, based on how they depended on each other, which was defining the data model, then defining and implementing the API which managed interface to the data model, then developing a web app that uses the API to interface with the data model.
I decided to use Firebase for this project. It included all the technology required for the MVP, i.e. a built-in authentication system, Firestore database for the data model, cloud functions for the API, and hosting for the web app. I am new to Firebase; however, it is a platform I have been interested in exploring for some time, and it seemed like a good fit for this project.
3.2.1. Data Model
For the data model, the structure of this would define what functionality could be implemented on the final product that users would interact with, so it had to accommodate any currently known target functionality but also be easily extensible for any possible updates/changes such as adding fields to the information that can be assigned to different aspects.
I based the core structure around collections of entities: Students, Teachers, Subjects, and Subject Categories. All the models and their details were defined as Typescript interfaces. For this MVP, the functionality I focused on accommodating is described as following.
126.96.36.199. Internationalization (i18n)
The project's core idea is to connect students and teachers across the world, so consumers should personalize content based on user locations and different languages.
The result is that the subject entities were split into multiple representations based on their language and country, so Maths in Canada in French would be a different subject to Maths in Canada in English. The subject categories, did not require separate entities, as they represented a universally recognized grouping of entities. In this case, only the information of the subject category was internationalized, e.g. the name would be different based on the user’s language.
188.8.131.52. Entity relationships
Another core idea of the project is “connecting” users, so a relationship system between user entities was required. Relationships were also required between other entities such as users relating to subjects, subjects relating to each other for users to discover related content, subjects relating to different categories, etc.
For this to work with the required structure for i18n of multiple subject representations per locale, it was assumed that relationships were independent to locale/country independent, e.g. the fact that physics is related to mathematics is true in any language or country. This meant that the relationships of subjects to other subjects, students, teachers, and subject categories had to be contained in a generic subject entity which represented all the locale/country representations of the same subject, this would allow better consistency as any relationships added by users in any language/country would be visible to all other users, i.e. no synchronization to other languages would be required.
Some relationships also required data to be associated with them, e.g. the relationship between a subject and a student or teacher could have information such as how confident the student/teacher is in that subject.
The methods available from the API were determined based on requirements by reviewing the wireframes and mockups produced by Chin to understand what data might be required on different screens, which described the queries required, and then also understanding the different actions a user would be able to do, which described the mutation queries required.
A list of required API methods was produced and implemented from the process above, with the following considerations.
The API was made to only allow authenticated users to make requests, and some methods also include logic to prevent users from editing, viewing, or editing other user’s data.
The API would be used by the web app and mobile app, where another team member, Moh, was developing the mobile app, so I knew documentation would be required for usability. I used tsoa to generate an OpenAPI specification from the Typescript definitions of the methods and then used redoc to represent the specification as a web page. See the resulting documentation here.
3.2.3. Web App
This was an attempt to implement the UI design work from Chin as closely as possible. It uses Gatsby and interfaces with the API. This section of the project was underdeveloped due to time constraints; however, it shows some basic functionality, such as the sign-up process for students and showing a filtered list of teachers based on a student's preferences.
Note: The Firestore database was populated with fake data to show the MVP.
3.2.4. Team Productivity
I also took it upon myself to help the team be more organized and created a project plan comprised of 3 sprints with deadlines during the project, with the various target features to aim for at each stage. This allowed me and other team members to understand what we were aiming for and the priorities. This project plan was done as a Kanban board in Trello.
3.3. Moh Smad's Role
Je suis moh Smad mon role dans adopt student était de faire l’application avec flutter, ce fut ma première fois de faire un hackathon en ligne. Jai utilisé la technologie de google pour faire l’application j’ai fais le get started et je devais me servir de L’API que Eli a créé dans mon apps flutter.
4. Challenges we ran into
The biggest challenge we ran into was the limited time we had to create what we had in mind. This was compounded by the fact all team members were from different time zones across four continents.
The time constraint also meant that we had to create an MVP within an MVP and forgo participation from real students and teachers in the research and usability testing to validate our product.
5. What we learned
5.1. Chin Wei
This is my first hackathon and team collaboration as a self-learning UI UX designer, so I definitely learned a lot about teamwork and the coding side.
5.2. Elias Mangoro
This is my first hackathon, where I have used a few different technologies and techniques for the first time to solve a real problem. I have learned a lot about the benefits and implementation details of the MVC design pattern. I have also learned more about topics such as:
- Firebase, i.e. Firebase cloud functions, Firestore
- OpenApi/Swagger for API documentation
- NoSQL database design
As an aspiring full-stack developer, this project has highlighted some areas I can improve and develop for my further development.
5.3. Marko Peric
I've learned many interesting things in the sphere of data design and tools design for the software with firebase cloud functions. I would like to calibrate this model further on, with the possibility of pivoting toward lucrative areas of interest. s a fully scalable solution, our app can also offer an option to host online summer schools for young adults while giving them an option to renew the knowledge or finish a course that they couldn't get in the past. We offer a calibration model of knowledge sharing while connecting the dots in academia and business.
This app is an initial step in creating talent pools for the top UNI and industrial employers. With the current transmission channel, we can offer an innovative way of scholarship - "buyback scholarship" to redeem scholarship between industry/academic and a professional scholar before the end of the contract. Conversely, it can be a starting point where scholars are consulting UNI and industrial employers on creating the best possible place for an internship, rotation programmes, and online modules done under the supervision of professional academic and/or industry professionals. Also, it could be an excellent opportunity to create a "buddy programme", which could render an opportunity to help each other out of the scope of current activities related mostly to education.
5.4. Rohit Singh
I quickly learned the fundamentals and contributed to the coding of data models and presenting insights.
6. What’s next for Adopt, a Student
6.1. Chin Wei
If this project continues in any shape or form, I would like to see the completion of other functions aside from what was developed in the MVP.
The app has the potential to connect a big pool of untapped educators to poor students who have no internet accessibility or the appropriate learning devices such as a computer. It can, for example, work closely with teachers, parents, and NGOs to organize classes in poor communities. It could also adopt messaging technology such as FireChat to allow students and teachers to communicate without an internet connection.
Chin Wei, UI UX designer
6.2. Elias Mangoro
I think the idea and goal of the project have the potential to have a positive effect on some people’s lives, so I will try to develop it further to become a usable product.
Elias Mangoro, aspiring Fullstack Developer https://github.com/eliasm307
6.3. Moh Smad
Ce fut ma première fois de faire un hackathon en ligne et j’ai vraiment aimé. Je suis moh Smad dev backend my GitHub https://github.com/smad20
6.4. Marko Peric
The idea connects dots between tangible and intangible processes where final customers get an added value of the service. While implementing the in-app, we get a broader picture of more lucrative market niches.
Marko Peric - Data Consultant with a demonstrated history of working in the venture capital and private equity industry. Skilled in Negotiation, Start-ups, Business Development, Marketing Strategy, and Management Consulting. Strong finance professional with a Doctor of Business Administration (DBA) Candidacy focused in Management Sciences and Quantitative Methods from Sheffield Hallam University. MBA in Quantitative Finance
More info: https://www.linkedin.com/in/markoperich/
6.5. Rohit Singh
Connect for more innovative solutions! https://www.linkedin.com/in/rohit-singh-717b50118/