Reimagined Radio in Augmented Reality
OnGen is a real-time geolocational platform for AR users.
In the AR era, AI already reads our surroundings and summarizes them for us, acting as an assistant that interprets the world on our behalf. But what if the AR experience could go beyond that assistant role? What if space itself were mapped into the user's own world, and reshaped to match each person's interests? OnGen began as a thesis project exploring that question.
At GradEX 111, the graduate exhibition hosted by OCAD University, OnGen drew 408 sessions from 147 test users (121 guests and 26 registered), with a median interaction time of 35.6 seconds. These real numbers let me validate whether the service could hold up in real-world use.
OnGen AR is a geolocation intelligence that reconstructs the city you might miss, or the one you care about, and brings it closer.
AR devices already exist, but AR interaction is still an extension of the smartphone. So what new modes of interaction could maximize immersion in a user's augmented reality environment?
OnGen AR maps social media and local information onto real buildings, raising immersion and making space itself both content and context. Through the AR display, the project focuses on the user as a spectator and uses that role as an effective mode of interaction.
The AR display market is growing quickly, and it points to strong potential demand, yet today's AR glasses still sit as an accessory to the phone. To move past that limit, I set the project's research direction toward maximizing the user's AR experience.
Seven boards, in the order the work actually ran: map the service, map the journeys, decide what to test, then go and test it.
I mapped the service before designing any of it, so the team could argue about one picture instead of four descriptions. Solid lines carry data, dashed lines carry consent and feedback, and the whole thing resolves to one sentence: every User podcast becomes audio in a regional playlist. Drawing it is what surfaced the open questions I could not answer yet, including what happens to a context snapshot once consent is revoked.
Two journeys run in parallel: the User who publishes and the regional listener who tunes in. Laying them on one timeline is what showed me the loop closes at reactions, not at publishing, and that what regional users react to decides what plays next. Each step carries the interview, hypothesis or metric attached to it, so the research had somewhere to land before it started.
I mapped the user journey and the possibilities a user might experience, and built a strategy to optimize that experience. Five peers and two supervising faculty, Alexander Manu and Bernard Dietz, critiqued the work, and I used their feedback to design the actual survey, shaping it in line with TCPS 2. Each step of the journey gets one number to test, so a result could move the design rather than just describe it.
The survey is ordered the way the product is: consent is tested first, since that is where people are most likely to drop off. Writing the risks and assumptions beside it kept me honest about what a small beta can actually show, which is direction rather than proof.
Building on the points confirmed in the earlier stage, I ran the hypothesis validation through a Google Form survey with 22 respondents. To ground their answers, I published an MVP prototype that supported basic interaction and provided it as context. Every average sits within half a point of neutral and only 4 of 22 score high on both comfort and interest, which reads as open to it, but not excited yet.
The numbers said neutral, so the free text is where the signal was. Sorting 13 responses on each side gave the same split every time: people want useful local information in one place, and they worry about how much is being listened to. That tension is what the consent copy had to answer.
At GradEX 111 the concept met people who had not agreed to be research subjects, which is a harder test. 147 users ran 408 sessions, but nearly half left within 30 seconds and one heavy user accounted for 58% of total app time. Registered users spent 20 times longer than guests. The gap between a curious look and real use is the number I took into the build.
The full working set behind the project, from the ecosystem map through to the personas. Hover any board to bring it forward; on a phone, tap one to open it.
I ran a digital showcase of what OnGen AR does, so people could respond to something concrete instead of a description. Each person went through the interaction first and answered the survey afterward. Thirteen of the 22 respondents interacted with the working app directly.
After the pre-pilot and the survey, I confirmed the direction. OnGen curates nearby local information and each user's interests, and for the interaction itself it uses the camera to map that content onto the real terrain, so the space around the user becomes the experience.
These three fixed the design synthesis and the interaction scope, and I planned the build against them.
The prototype was built from computer-science components. Because the service runs on AI, I set up an environment that connects to AI APIs and runs a local AI, and carried out the experiments there.
Built entirely in VS Code, the prototype runs as a small full-stack app.
I built the OnGen interface as a design system in Figma, a web-based resource that gathers the dashboard, components, type ramp, and the downtown map in one place. It cannot run inside an actual AR device, but it let me design the whole interface as a single coherent concept and use it as the visual reference for the build. Along the way, I took critique at Gate 5 and Gate 6, which let me refine the finer interaction details.
Before I published to Firebase, I showed this build as a mid-point check at Gate 5, around February, during the faculty and peer critique. The showcase made clear that the interaction still fell short of the AR premise in many places, and I used that feedback to reset the project's direction.
Through Firebase, I captured user interaction data in detail, from micro-interactions to retention and how users responded, and set the project up to update itself recursively from that data. I designed it to parse and extract the data as well, so the interactions could be analyzed directly.
blender/libmv
This breaks the overlay into its steps. I start from the raw scene, scan the site into a rough 3D model, build the digital layer against that model, and composite it back into the viewpoint, so the content lines up with the real buildings.
The feed lives in space rather than in a list. Each post is pinned to where it happened, carrying its bearing, distance, and how many people are listening nearby, so the city itself becomes the timeline.
OnGen AR on show at GradEX 111, OCAD University.
Building spatial intelligence was the core of the OnGen project. It is a product meant to widen the practical use of AR hardware, and a project that connects the digital and the physical. As AR glasses are expected to gain more capability, it holds real room to grow.
SDK access to AR display hardware during the project period.
At the time of this project, Meta had not opened the Ray-Ban Display SDK to developers, so I could not build OnGen onto the device it was designed for. This was the main constraint on the project and the one dependency I could not design around. I therefore ran the showcase on a web app I built myself with HTML and Python, which means what visitors experienced may not have matched the intended AR interaction exactly. Once the SDK is released to developers, OnGen can run on the actual hardware and the project moves into full development.
The OS providers OnGen AR could realistically run on.
Meta, Rokid, and Apple's upcoming glasses are potential service providers, and a basic precondition for scaling OnGen AR. The field is still experimental, and since most experiences today rely on mobile and laptop interaction models, I found that AR itself is not yet effective. This pointed to the need for interaction built on the growing adoption of AR devices.
