## Inspiration

 Looking around our team, we see a common trait that hinders us in the classroom: Shyness. It's hard to ask questions during class, especially in front of large audiences. We want to combat this issue by giving the large population of students like us an opportunity to engage actively in classroom participation with confidence.

Additionally, we tackled another problem. When questions are asked during class, many students have difficulty hearing what was asked as well as reviewing that material, as it may not always be in the lecture material. With our product, important questions along with the teacher's answers will be recorded and sent out via email post-lesson. This way, key supplemental information will be provided to students to further enhance their learning experience.

## What it does

To address this lack of confidence during class, we provide an anonymous question portal that allows any student to ask a question through voice or text. This is disguised as a word processor, further allowing anonymity for students who feel too shy to ask questions. These questions will be sent to the teacher portal in real-time, where the teacher can select questions to answer. Once the class has concluded, Q/A pairs will be sent out to the class through email.

## How we built it

We implemented our idea with a variety of frameworks. Using MongoDB, we first started the development of the database to store the questions being asked. This database served as our main backend tool to store and send the data collected from student and teacher responses. We utilized Twilio's SendGrid to email the data. Our front-end application displayed this information using React JS. To control our microphone, we used an interface between javascript and the Google Cloud API for converting speech to text.

## Challenges we ran into

 One of our main challenges was formulating the idea. Because we wanted to create a product that was meaningful to both us and our peers, we spent many nights brainstorming a project that resonated with us. Thus, Qloak was born. During Qloak's development, we also ran into many technical problems, such as making sure button clicks were working properly with incoming data, correctly timing that data, and sharing it between users. We worked together by breaking up and assigning tasks that would capitalize on each of our individual strengths. As a team, we were able to successfully coordinate with each other and ultimately integrate our code together.

## Accomplishments that we are proud of

 Our team is proud that we brought to life an idea that will meaningfully impact and help our fellow peers. Additionally, during this process, each of us had to tackle programs and concepts that we had never worked with before.

## What we learned

 We learned the importance of teamwork. At the end of our hack, we reflected on our accomplishments and realized how we were able to combine our talents together and efficiently finish our task. Working together allowed us to bounce ideas off each other to polish and strengthen. Also, we became stronger developers after this project, as the product required a wide variety of parts and provided us with full exposure to software such as React, mongoDB, and Twilio.

## What's next for Qloak

Our next step is to deploy our product to a larger scale so that we can increase visibility to a wider userbase. We would also like to work on a more intuitive user interface with additional functionalities to allow for smoother flows and interactions.
## Inspiration

The transition to remote learning has been very rushed, and communication between students and professors is a challenge, especially during lecture. Livestream chats are used for questions, but its simplicity means that it can be overwhelmed with off-topic information and many repeated questions, leading to professors missing important questions from students. Online forums solve this issue, but are not in real-time, meaning students have to wait for their questions to be answered, sometimes more than a day. Because of these challenges, we wanted to design an application that creates a specific place for professors to answer questions during lecture.

## What it does

AskQ aims to improve the student-professor communication, creating a specific space for questions to be asked and stored. The professors can view the questions, and answer them when they see fit.

## How we built it

Our backend relies on Node.js for the server-client communication and Google Firebase Firestore to store the messages in a NoSQL database. We did this in order to be able to use a more complicated data structure for our messages, consisting of a hashed id, message content and rating system. Although only the content is used in our MVP, the other two parts of data will be used to implement a real-time rating system, as it allows us to reference specific messages and change their values in the database. Our user interface consists of html pages and some javascript to dynamically manipulate the DOM’s.

## Challenges we ran into

Originally we planned on using python-flask to establish the server-client relationship and run the application. However, we ran into complications with getting the client to connect with the server, and had to switch to Node.js. This proved to be extremely problematic for us, as 3 of our members had no prior javascript experience, and essentially learned the language on the fly.

## Accomplishments that we're proud of

Because of our group’s lack of javascript experience, we are proud of our MVP. It may not have all the features we initially planned, but to restart halfway through and make our MVP using frameworks and languages that we had little to no experience with is something we are proud of.

## What we learned

This was the first hackathon for three of our group members, and they definitely learned how to manage the craziness of a 24 hour deadline, and how to quickly learn the basics of new frameworks and languages on the fly. The team also learned how to stay positive, especially in times of frustration.

## What's next for AskQ

Next for AskQ, we want to implement a rating system for the questions. We want students to be able rate up questions that they think are good, or questions that they may also have. We want to dynamically sort the list, keeping the highest rated questions at the top, for the professors to answer first. We also want to implement containers for questions, so a question could get tagged with a specific topic, and go there.
## Inspiration

I've always been fascinated by the complexities of UX design, and this project was an opportunity to explore an interesting mode of interaction. I drew inspiration from the futuristic UIs that movies have to offer, such as Minority Report's gesture-based OS or Iron Man's heads-up display, Jarvis.

## What it does

Each window in your desktop is rendered on a separate piece of paper, creating a tangible version of your everyday computer. It is fully featured desktop, with specific shortcuts for window management.

## How I built it

The hardware is combination of a projector and a webcam. The camera tracks the position of the sheets of paper, on which the projector renders the corresponding window. An OpenCV backend does the heavy lifting, calculating the appropriate translation and warping to apply.

## Challenges I ran into

The projector was initially difficulty to setup, since it has a fairly long focusing distance. Also, the engine that tracks the pieces of paper was incredibly unreliable under certain lighting conditions, which made it difficult to calibrate the device.

## Accomplishments that I'm proud of

I'm glad to have been able to produce a functional product, that could possibly be developed into a commercial one. Furthermore, I believe I've managed to put an innovative spin to one of the oldest concepts in the history of computers: the desktop.

## What I learned

I learned lots about computer vision, and especially on how to do on-the-fly image manipulation.