QR Attendance - Final Report

---

Introduction

These days many students prefer using tablets, or even smartphones for note taking, while majority, if not every student have access to their own smartphone. Knowing that such portable devices are most popular among high school and college students, using built-in camera on a smartphone or a tablet can help with tracking students' attendance. Therefore, there needs to be some system that will simplify attendance tracking and will provide students with extra study material.

Design Problem

Attendance tracking system should be easy to use for both students and instructors. Our goal was to build a system that could be accessed from both web and mobile. Attendance tracking should be as simple as possible. If a student is using their mobile device, they will simply have to scan the presented QR code. If a student is using the web app, they will need to enter a unique lecture number. After QR code has been scanned/lecture number has been entered, the system will record that student as attending.

Some instructors do not release any notes in order to motivate students to come to lectures. This system can also help to those who attended lecture, but wanted to review the lecture notes/slides. An instructor will be able to share documents with all attending students, with ease. Our attendance system can enhance the educational process and it can verify student's identity to eliminate false registrations.

User Research and Findings

To gain better knowledge of how the system should behave, we have conducted two research methods: survey and secondary research. The combination of both methods gave us better understanding of what our end users want from the final system and how it should behave.

Survey

Our survey is designed primarily for students, because it is easier to ask a lot of students to fill out a survey and it helped us to gather necessary information for the project since they are major stakeholders of the project. We decided to conduct a survey, instead of interviewing students, because we realize we could gather a lot of data from many different students, rather than asking for opinions from just a handful students.

Secondary research

The system that we have designed has already been implemented in some different ways. Secondary research helped us to identify weak points in existing projects and to build up from previous experiences.

Design and Justification

Lo-fi prototype

Lo-fi prototype was an important step for implementing QR Attendance. It helped us to put all our first ideas into existence. Lo-fi prototyping also provided us with starting point for our final hi-fi prototype. Lo-fi prototype for our system can be found here: P2: Lo-fi prototype.

Hi-fi prototype

Hi-fi prototype was built using the best UI/UX practices we have learned throughout the semester. We based our final system design on lo-fi prototype. Both web app and mobile app were designed using material design principles. Since both web and mobile app form single system, it was important to keep the same design throughout both applications so that users do not have to re-learn UI from one app to another. Hi-fi prototype for our system can be found here: P3: Hi-fi prototype.

Heuristic Evaluation and Findings

The heuristic evaluation of our system pointed out errors and features we missed while designing the hi-fi prototype. One of the errors we had were that we assumed the user knew the whole process of resetting an email. So, instructions were not given in the mobile version as well as both versions had a kind of misleading button title that implied that the password would be reset on a click of a button. To fix this, we provided instructions on how to reset an email and changed the button title to ‘Send Email’ rather than ‘Reset’.

Other findings pointed out features that could have been implemented in the design to promote user control and error prevention, but were not in the initial design. These features included, unsaved changes alerting, removing uploaded files from a lecture, editing dates of a lecture, logging out on both platforms and allowing the teacher to manage the student list by adding or removing them. Not adding a logout function was a big error because it would create security issues for both the student and the teacher. The teacher also was not given much control or freedom over their classes and lectures so adding missed features such as removing uploaded files or managing class lists would give this control. Finally, the functionality to alert the teacher of unsaved changes to a lecture would help in preventing errors in the system.

The rest of the heuristic evaluation findings were either too tedious or impossible to implement in a prototype. This included the whole process of scanning a QR code as well as providing password requirements when creating an account. These features could only be partly implemented in a prototype, but not fully. Of course they will not be disregarded because they may help guide us to a better working system in future iterations.

Usability Testing

We have performed usability testing with 5 different users. Each user was given three different scenarios and they were asked to think aloud when was possible/or whenever they wanted. During testing, screen was recorded for future analysis, as well as evaluator was taking notes for each user. Scenarios, that each user was presented with, as follows:

• Scenario 1: "You are a new student who is trying to get access to the lecture material and to record your attendance using mobile app. How would you proceed?"

• Scenario 2: "You are a new instructor and want to start using the system. How would you create a new course, add lecture and present students with the QR code and lecture ID?"

• Scenario 3: "You are a new student who is trying to get access to the lecture using web app. How would you create an account and record your attendance using the web application?"

During the testing, we discovered some minor UI/UX issues with our application. It was discovered that users seemed to familiarize themselves with mobile application faster compare to web interface. That tells us that web application needs to be a bit more similar to its mobile companion. The screen recordings can be found here.

User #	Scenario 1	Scenario 2	Scenario 3
User 1	Thought onboarding camera highlight was clickable.	Thought logo was a button.	Took a bit to figure out access button. Thought logo was a button.
User 2	Always tried to click class list button when already in class list.	Tried to find generate QR through "create lecture" screen Bad “sign up” placement	Took a bit to figure out access button Thought logo was clickable
User 3	No complaints	No complaints	Thought logo was clickable Thought that after entering access code, they would be taken to the lecture screen
User 4	Thought onboarding highlights were clickable Wanted to see semester section, like it is in web application	No complaints	Wanted to have ‘download all as ZIP’ option
User 5	Thought onboarding highlights were clickable Clicked on class list when was already in class list	No complaints	Took a bit to figure out access button Thought logo was clickable

Mobile application issues

As it was mentioned before, users became familiar with mobile application quicker, so there wasn’t many complaints. People found it weird to have highlighted buttons as onboarding, because majority of users tried to click highlighted buttons. As well as lack of indication where user is currently located in the app was pointed out by users trying to click on class list button while already being on that page.

Web application issues

Users seemed to struggle when were presented with Scenario #3. There was a lot of complaints regarding finding the location of "access button". However, for both scenario #2 and scenario #3, users thought that logo was clickable and will bring them back home on click. After testing users also pointed out that web app needs some sort of onboarding/quick introduction guide just like in mobile app.

Interface updates

After usability testing, we fixed issues that occurred most frequently among users. These addition include:

• Clickable logo on Web

• More visible "Sign up" button

• After entering access code, user is redirected to the lecture

Recommendations for Next Iteration of Design

For future iterations, we plan to revamp colors of the mobile application, in other words, make it less bright and more easy on eyes, and add onboarding for web application, since there might be users who will need some guidance getting used to the application. Mobile application also will need "Pull to refresh" functionality to be able to update lecture content or lecture list. Web application needs “safety net” functionality, in order to help user to recover from possible mistakes.

Conclusion

Throughout the course, we went through the User-Centered Design cycle. At the Investigation step, we as a team researched the field that we were going to start designing for. It took us some time to find existing use cases and projects that others had tried before. However, it was much easier to identify our stakeholders. Building up from researched material, at the Ideation step we generated possible use-cases for our application, that are outside of academic/education world. That helped us to sketch initial outline of the system that we used to start prototyping. At the Prototype step, we started with Lo-fi prototype to get first UI of our system. We came up with two designs: a mobile application and a web application. At this step, we realized that both mobile and web components are interconnected and their interfaces should be similar. After lo-fi prototype was finished, we started implementing more concrete hi-fi prototype of our system. After having it done, we had it evaluated by other team and that helped us to see flaws in our design. After having these issues fixed, we conducted final usability testing, that gave us more insight on what actual users want to see in our system as well as potential improvements and issues.

With all of these steps, we were able to design a system that is ready to be developed and tested with actual devices in real world environment. User-Centered Design steps are important when you are designing a system that will be used by many different users.