TickIn

Inspiration

The attendance problem at UC Berkeley has not received any attention. Firstly, students are easily able to fake their attendance by sending Google Form sign-in links and Top Hat codes to their friends who are skipping class. Although using TopHat and Google Forms are feasible options in very small classrooms so that professors can perform a quick head count to verify, larger classes make it impossible to verify student attendance.

College instructors of larger classes often wonder if students are attending class regularly and paying attention. Today, iClickers are used as a classroom response system in larger classes. The hardware consists of a remote keypad device called clicker, a receiving device connected to a computer, and Reef software. iClicker models have limitations on the maximum number of clickers that can be supported in one classroom, thus making iclickers unscalable beyond a certain number. For example, computer science classes at Berkeley, with around 1800 students, would not be able to use clickers for attendance.

Further, using TopHat and Google Forms requires students to manually type in a URL and access a webpage, where they enter all of their student information and a secret attendance code. This code can be sent to a friend who is not present in the classroom within a matter of seconds, and the attendance is therefore inaccurate.

Another factor to consider is cost. TopHat subscription for each student is around $25 per semester. The iClickers are deployed to students at a total of $40 each, and the Reef software that supports iClickers costs the university and students an additional subscription fee! Students are responsible for carrying around the iClicker remote whenever they go to class, or else they do not receive credit for attendance, and the iClicker is subject to running out of charge. Students, in addition to paying $40 for the iClicker, must also pay $4 for batteries and are also responsible for replacing a broken iClicker, which comes with a very limited warranty.

Our team is looking for a more cost-effective solution without the issue of fake attendance whereby friends try to send attendance URLs/codes or sneak in a friend’s iClicker. Hence, we thought of TickIn!

What it does

TickIn simply checks (“ticks”) you in. Using bluetooth and Arduino beacon technology, TickIn uses 3 simple steps to check students in.

Once the Arduino 101 beacon is turned on, it will emit low energy bluetooth waves.
Then, any bluetooth device that is within a close range of the arduino beacon will detect the signal. When the TickIn app is installed on the smartphone, the app will detect the bluetooth device specific to a course, and ask the student to log in using their college credentials.
Finally, the student will be able to press the send button if they are within the acceptable range of the arduino beacon, and the information will be sent to a web server. The server will collect, display, and analyze the data for the professor on a website using visual charts and graphics.

TickIn’s technology is scalable to a class of virtually any size. For example, classes as large as 2000 students can use TickIn’s technology to ensure that students are present in class, and TickIn’s built-in web analytics can analyze the data for the professor on the TickIn website.

How We Built TickIn

For the TickIn App: We used XML to design the architecture of the app and Java to design the back-end for the app via Android Studio. API’s involved with the application itself are the Android API and Java API.

For the Arduino(Beacon): We used the language C which directly approaches the hardware.

For retrieving data / website: We used HTML/CSS for the frontend of the website, JavaScript and Ruby which function as the bridge between the frontend and the backend, and Rails and SQL for the backend of the web as the database.

Challenges We Ran Into

We expected to have beacons at the venue, but there were none available. We instead treated Arduino 101 as a beacon because it features wireless bluetooth connectivity. Further, since none of our team members have programmed bluetooth devices and worked with MAC Addresses, a substantial amount of research was performed.

Accomplishments that We're Proud Of

Some student response systems that are currently in use are iClickers, Top Hat, and Google Forms. The current systems are coming at an unnecessary additional cost for the students.

We strongly believe this product is a cost effective and easy to use solution to the attendance problem at Berkeley, benefitting both students and the university.

We can extend the usage of TickIn to other universities and schools, and even outside classroom settings. For instance, large events like hackathons can use TickIn to avoid long queues for participant/attendee check-in.

Overall, TickIn is portable as it is a smartphone application, requiring only the professor to carry the beacon around to their classrooms. TickIn is cost effective as the application can be deployed for a very low cost to the large student population and an estimated $25 for the professor. TickIn is scalable to any number of students and generates visually appealing reports on the data collected from the mobile app. Also, the same beacons can be shared between different classes by configuring the same ID for different timings and locations to identify another class. Most importantly, students can no longer fake their attendance credit as the student has to be physically present to send their information to the server through the TickIn application.

What we learned

Connection between server and the app How to create GIFs, use various APIs. How to use arduinos as beacons (3D model for casing) How to integrate our team’s varied skill set to create an effective product Brainstorming and collaboration are key to success Process of creating a product through ideation, design, development, testing, and deployment. Object relationships are extremely important for data structure management

What's next for TickIn

We first want to make the TickIn application to be compatible with iOS as well, so that both Android and iOS users can have access to the application. Also, we are planning to upgrade this app so that it not only checks attendance but also facilitates quizzes and conducts polls.

iClickers allow only professors to ask questions to the students, which leads to a one-way interaction between the professors and the students. Therefore, we are planning to design TickIn in a way such that students can also ask questions via the application. While iClickers do not allow students to type in anything, TickIn will provide text boxes for students so that lengthier responses and questions can be conveyed to the professor.