OccupEye
A Web of Things concept and prototype for showing available individual study spaces on campus — using sensors, a backend API and a digital interface.
← Back to projects
A Web of Things concept and prototype for showing available individual study spaces on campus — using sensors, a backend API and a digital interface.
← Back to projects
OccupEye developed a strong visual identity alongside the technical concept. The eye and chair symbol became the core of the project's visual language, backed by an abstract pattern system used across materials.
The problem statement for the project was:
The problem was based on a practical campus situation. Students need study spaces, but it is difficult to know where free individual seats are without walking around and checking manually.
OccupEye explored how sensors and a digital interface could solve this. The challenge was not only to show whether a seat was free or occupied — the project also needed to consider how sensor data could be collected, structured and presented in a way that is actually useful for students.
My role was mainly as a developer. I worked with both frontend and backend parts of the project and contributed to the technical planning of the solution.
My contributions included: researching sensors, boards and suitable technologies, helping decide parts of the system architecture, working on database structure, working on API development, doing frontend development, helping determine sensor types for the solution, giving feedback on frontend design, and joining meetings, planning and presentations.
Ideation, sensor research, group coordination and iterative development.
The project started with ideation and brainstorming. I took part in the early discussions where we explored different possible project ideas. I also suggested another idea at the start, but after discussing the options as a group, we agreed that OccupEye was the strongest concept for the course.
After choosing the idea, I researched different sensors, boards and technologies to understand what would be realistic to build within the time available. This was important because the project depended on hardware, and hardware choices affect what kind of data can be collected and how the system can be implemented.
The group split the work between designers and developers. This made it easier to focus, while still keeping the project connected through meetings and shared discussions. I was on the developer side, but I also gave feedback on the frontend design and helped connect the interface to the technical concept.
The technical idea behind OccupEye was to connect physical seat availability to a digital overview. A sensor would detect whether a seat was available or occupied. That data would then need to be sent, stored and displayed through a web interface.
My work focused on the parts needed to make that system possible from a development perspective — thinking through the architecture, helping with the database structure, working on API development and contributing to frontend implementation.
That connection is the main reason this project is valuable in my portfolio. It shows that I can think beyond a static website and work with systems where physical input and digital presentation need to work together.
The goal of the prototype was to make the OccupEye concept concrete enough to show how it could work in practice. The interface needed to communicate seat availability clearly, while the technical structure needed to support data from sensors.
Because the project involved hardware, the implementation process had to be flexible. Some things were not possible to test exactly as planned because of delays with sensors. Instead, the project used mocked or expected data for parts of the testing and development. This made it possible to continue working on the system even when the hardware was not fully available.
Testing was more limited than originally planned because we had issues getting the sensors on time. Ideally, we wanted to test the system with real sensor data, but because of the hardware delay, we had to test parts of the solution with mocked or expected data.
Even though this was a limitation, it taught me something important about project planning. Hardware dependencies should be handled early, and testing should not depend on everything arriving perfectly on time.
The result was a more concrete Web of Things concept and prototype for showing available individual study spaces on campus. The project moved from an early idea to a planned system with sensor research, technical structure, frontend work, backend/API thinking and database planning.
For my portfolio, OccupEye shows that I can work with early-stage concepts, technical research, prototyping and interdisciplinary teamwork. It also shows that I can handle uncertainty when a project does not go exactly as planned.
OccupEye was valuable because it taught me how to think through a Web of Things solution from idea to prototype. I learned more about sensors, system architecture, frontend/backend connections and how physical input can become useful digital information.
I also learned more about working in a group with both designers and developers. Communication was important because technical choices affected the design, and design choices affected what needed to be implemented. The group dynamic was good, and the project helped me understand how important it is to explain technical ideas clearly.
If I continued this project, I would focus on testing with real sensor data, improving the connection between hardware and interface, and planning hardware dependencies earlier. I would also use a more test-driven approach so problems could be caught earlier in the process.
OccupEye shows that I can work from an early idea toward a concrete prototype while balancing technical possibilities, user needs and group collaboration. In a Web of Things project, the connection between hardware and software is always the real challenge — and that is exactly what this project taught me to think about.