Aesthetihawk and Bathroom Pass Write Up

🧠 Déjà Vu

The planning and writeup process below might sound familiar. That’s because this process is what is actively used at Qualcomm!

As described by product manager job listings, a scrum master would need to:

1. Execute project plans with scheduling, resource forecasting, and stakeholder identification.
2. Scope and prioritization of deliverables
3. Ensure project objectives are met, present the vision to management, and gain stakeholder buy-in
4. Identify team skills, create project teams, and schedule task assignments.
5. Communicate with stakeholders to establish needs and goals.
6. Manage project performance (timeliness, quality, scope, complexity)
7. Secure project compliance
8. Facilitate collaboration

What I wrote was no coincidence! I looked on LinkedIn for posts and job offerings related to a Qualcomm product manager and formatted my write-up just like how you would in a real job!

🤔 What is covered?

I worked on two projects/features: bathroom pass and Aesthetihawk. Bathroom pass was more in the first ⅔ of the trimester with Aesthetihawk taking the focus in the last ⅓.

🎫 Bathroom Pass

This writeup will focus on how to handle authentication using the scanner and the interplay between hardware and software, something commonly seen in the real world (ex: Qualcomm or Apple).

📖 Contextualization

When developing a product, you need to ask some key questions first:

1. Who is this product for?
   1. You cannot develop a product without knowing who it’s for. Almost every product you see was developed for a specific purpose and audience. In our case, our product is for students AND teachers.
2. What is the product’s purpose?
   1. The goal of our product is to let students use a digital bathroom pass. For teachers, they should be able to manage their students and see if someone is using the bathroom for a suspiciously large amount of time.
3. Why should you care about our product?
   1. Physical bathroom passes suck. They waste resources and are often tampered with. They may be lost, destroyed, or can get dirty (trust me; you don’t want to shine a blacklight on one of those things). Digital bathroom passes solve this. Furthermore, they are tamper proof. You can’t abuse the pass as easily, and your usage is tracked so you can’t cheat the system or lie to your teacher.
4. What would our audience want?
   1. Teachers hate when students bring their phones to the bathroom. A digital bathroom pass may seem like the antithesis of that. However, we want to implement a system that lets students scan their school-issued IDs to authenticate without having to take their phone with them.
   2. Students won’t use the pass if it’s hard to use. Most products that fail are due to friction. We cannot have any friction between the user and the product. It has to be easy to use, quick to deploy, and intuitive. In fact, the same principle applies for teachers who want something easy to manage and not something that they have to worry about.
5. What does our product need?
   1. We need a way to scan a student’s ID to track who is leaving. We need to have these changes synced to the cloud so a teacher can view who is going where. We might also want other quality of life features, like a bathroom queue or a way to report issues with bathrooms.

🖥️ Understanding how the Technology Works

1. Barcode scanning
   1. The barcode scanner is going to be our “window” to the outside world, letting the Raspberry PI (a microcontroller) “see” the student IDs
   2. The scanner shines a light at an ID, capturing the reflected light back. Reflections are strong in white areas and weak in black ones. The analog signal received is converted into a digital one via an A/D converter.
2. Interface
   1. The scanner interfaces with the RPI using the Universal Serial Bus protocol. A synchronization packet is first sent to sync the clocks on each hardware device. The binary data is then relayed to the controller.
3. Raspberry PI
   1. This microcontroller reads the data and decodes it with a library. Most scanners use a standard decoding method, so off-the-shelf libraries work well. Some might not though, so keep this in mind.
   2. The decoded data is the student ID.
4. Backend API connection
   1. The data needs to be sent to the backend where the backend will verify the student and mark them for check-in/check-out. Everything is synced in the cloud.

➡️ Flowchart

🎨 Aesthetihawk

This writeup will focus on Aesthetihawk. Aesthetihawk is visual and function overhaul that aims to bring visual cohesion to the Java profile system and student toolkit and to improve user intractability and experience. The goal is to bring a sleek look to the profile page. Apart from looks, important key features will be more easily accessible and easier to control. This will bring a beautiful, seamless, and unified experience to nighthawk-coders.

📖 Contextualization

When developing a product, you need to ask some key questions first:

1. Who is this product for?
   1. My audience is students because they will have access to their profiles and the student toolkit. Teachers will have access to the teacher toolkit, but the main focus will be for current and future students.
2. What is the product’s purpose?
   1. The goal of my product is to make two extremely important tools, profile and toolkit, easy to use and just look better. Students should be able to understand the system with little to no prior instructions. This makes it easier for the teacher since they don’t have to explain much. It also makes it easy for students because it eliminates confusion and redundancy.
3. Why should we care about my product?
   1. Students access these important tools all the time. For a student, anything to improve this experience will make their class life much easier and can improve overall happiness and efficiency. For a teacher, you won’t have to worry about students being confused with the old system. It’s my way of creating something you can “set and forget,” and something that will impact future generations/students.
4. What would my audience want?
   1. My audience will want a frictionless experience. Many older folks joke that kids these days go “too fast,” or don’t have enough attention. While we can’t really change how students act, we can change the technologies they interface with to adapt to these needs. My audience wants something that is easy to you. It needs to work in a snap. It must be quick, visually appealing, and logical. This applies to both the UI and UX.
5. What does my product need?
   1. My product doesn’t need specific hardware unlike the Bathroom Pass. Instead, it will need to be able to communicate with critical backend endpoints pertaining to user data. It should also ease the load on the backend. Let’s be honest here: most student-written backend code is a spaghetti mess. It’s a lot easier for me to create well-made code in JavaScript than it is to make a new API and contribute to noodle-code. For those reasons, all the data processing and validation is handled in JavaScript. The only thing that the backend receives is a neat little package of data. All the hard work is taken care of by Aesthetihawk which lessens the needs on the backend. After all, real products need balance, right?

🖥️ Understanding how the Technology Works

1. Liquid
   1. Liquid, which most students don’t use, is the greatest thing invented for web development. I don’t like to repeat my code and nor does the next developer who will see it. Liquid lets me create modules and templates which I can drop in anywhere. For example, the student toolkit and the profile page have a navigation pane on the left-hand side. They share the same pane and the same code logic there. Without Liquid, I would have to write the code twice and any changes made on one page need to be pasted over. In fact, I had this problem which took several hours. That problem was the reason I switched to Liquid. There were others too, but that was the main one. Man-hours are important, and we shouldn’t waste them as laborers.
2. Backend API connection
   1. Once again, most logic is handled with JavaScript. I needed to analyze how the API endpoints work. I also had to fix some of them like the profile picture endpoint, requiring changes in the backend and the frontend. Most importantly, I refactored and redid most of the JavaScript codebase because there were redundant functions and code which didn’t follow DRY principles.

➡️ Flowchart