ENGINEERING / FRONTEND
WayBack
A context-aware re-finding web app for tourists — surfacing the places you saved at the moment they become relevant, by translating a 2017 research paper's evaluation framework into UI signals users can actually read.
Role
Sole Frontend Developer, 2-person team
Timeline
10 weeks · April – June 2026
Context
TUM Practical Lab · Recommendation Systems
Stack
React 19 · Vite · Tailwind · Leaflet · TypeScript
Status
● Live · prototype phase
The premise.
Travelers save dozens of places — restaurants, museums, viewpoints — but forget what they saved by day three. The challenge isn't discovering new places. It's re-finding saved ones at the right moment, based on context (location, time, recent activity).
The deeper problem isn't memory — it's trust. Users won't act on a recommendation they don't understand. The 2017 paper we're adapting (Sappelli et al.) defines four evaluation criteria for recommendation quality, but only measures them offline. My job: make those four criteria visible inside the live product, without academic jargon.
Four decisions that shaped the build.
Decision 01 — Paper criteria as UI signals
Built an Explanation Breakdown component that surfaces the paper's four §4 evaluation criteria as plain-English signals on every recommendation: Right here (context relevance, §4.3), Good time of day (document relevance, §4.4), Likely your next stop (action prediction, §4.5), Worth revisiting(diversity, §4.6). A methodology modal — opened via “How we picked these signals” — explicitly cites paper sections and acknowledges where my client-side proxies extend the paper's framework.
Decision 02 — Composite signal gate for proactive notifications
The W4 brief requires proactive recommendations — surfacing items without explicit user query. Naive single-threshold approaches either spam in dense areas or stay silent. I built a composite-signal evaluator: CIA score must clear a minimum bar and at least one of {proximity, time-of-day fit, under-surfaced}must fire. The gate mirrors the paper's “no single criterion captures quality” argument from §4.
Decision 03 — The paper's comparison, made interactive
The paper's core contribution is comparing three methods (CBR / JITIR / CIA) under shared context. The original UI only let users switch one at a time — the comparison was invisible. I shipped a Method Comparison view: three columns side-by-side, three context presets (Morning at Marienplatz, Afternoon at Englischer Garten, Evening at Hauptbahnhof). Switching context rearranges all three rankings visibly. The paper's central comparison becomes a live, interactive surface.
Decision 04 — Independent components as ownership architecture
Mid-project, working rhythms across the team diverged. Rather than escalate or mirror the pattern, I redesigned my contribution surface: every new paper-faithful feature ships as a self-contained component under frontend/src/components/ — one author per file, paper-section-cited commit messages, explicit ownership boundaries documented in writing. The architecture itself became the coordination mechanism. Ownership stayed legible regardless of working rhythm.
What I'm taking from it.
Translating research into product isn't about implementing the algorithm — it's about making the evaluation frameworklegible. The four signals, the composite gate, the side-by-side comparison: each is a UI artifact that lets a non-technical user (or a recruiter, or a compliance reviewer) read what the system is actually optimizing for. Same pattern works for any AI surface that needs to be legible to people who don't read the source paper.
The second lesson was structural: architectural decisions can substitute for difficult conversations. When file ownership is self-evident from the codebase, coordination becomes lower-stakes. I'd treat that as a Week 1 design choice on the next project, not a Week 5 response.
“Did you talk to five users?” is the question I want to ask of every product I touch from now on.
FULL CASE STUDY
The 10-week version — with screenshots, code, and the decision trail.
Four decisions in detail. Code snippets from the composite signal gate. Real screenshots from the working prototype. Reflection on what I'd do differently.
Read the full case study on Notion →