Our main goal with OpenBook was to address some of the flaws we found when trying to get and give homework help online. We’ve tried a fair amount of other softwares that have had their advantages and shortcomings, so we wanted to try our hand at making one. Some of the places we were coming from when designing OpenBook were using class-based group chats, Google Classroom, and annotation software. The most successful solution we saw was nb.mit.edu, which allowed teachers to upload readings and homework and let students annotate the documents directly for all their peers to see. However, some of us found their implementation of this lacking and a bit outdated. We decided to take this idea of having “open source” insights on shared resources and create a web app that could make this easy for students to use.
What it does
When creating OpenBook, we focused the functionality around letting students share, be it questions or insights. Sharing is the main point in collaboration, and so all main features center around it. We took inspiration from nb’s annotating system and built upon it to allow users to highlight a part of a document and either share a comment or ask a question. Either of those would be visible to anyone viewing the document, so someone could get a helpful explanation of a confusing textbook passage or give a hint on a problem someone was stuck on in the homework. We also implemented a feed system that allows users to see recent activity and active questions.
How we built it
We first went to Figma for some quick prototyping and making sure we all had the same final product in mind. After that prototyping, we used glitch.com, a free collaborative online web development platform to enable us to work together. We could all edit the code at the same time and test it quickly, though some of us at times would do other tasks besides coding. We also used firebase for a quick and easy database backend.
Challenges we ran into
A problem we faced early on was the choice of database/backend. Due to some miscommunication, we started off with a backend that no-one was particularly experienced in and so we had lots of trouble in the beginning. Once we figured that problem out, our main hurdle was keeping the ever increasing codebase readable between all four members. This problem was compounded once one of the more experienced coders in our team had to leave early due to a headache. A final problem we had when adding the last pieces of functionality was that the way we set up the database required lots of asynchronous calls, which were tedious to get correct. None of our solutions were entirely perfect, but we were able to get it good enough to carry on.
Accomplishments that we're proud of
I’d say that everyone in the team is proud of how much we’ve accomplished in just a single day. Since half of us have never done a hackathon before, we’re mainly proud at how effectively we were able to work together. We identified a problem that we all were familiar with and that could help our community, we designed a potential solution, and we made lots of progress on the prototype of it. We worked pretty hard all day, and we’re happy with what’s come out.
What we learned
What's next for Open Book
Our prototype does not have full functionality, so a good next step would be reaching MVP status. From there, we would touch up the UI a bit to make navigation simple, and then just get it into the classroom and in the hands of students! These would be our peers and teachers, who would be more than happy to give feedback on it.