Role Frontend Lead + UIUX Design — sole frontend developer in a 2-person team Stack React 19 · Vite · Leaflet · Vercel Timeline April – June 2026 (10 weeks) Course TUM Practical Lab — Recommendation Systems · SS 2026 Status Week 5 of 10 · four core features shipped · paper deliverable in progress

Live demo · GitHub


Summary

WayBack is a tourism re-finding application that surfaces previously-saved places at the moment they become relevant. It implements three recommendation algorithms from Sappelli et al. (2017) — Case-Based Reasoning (CBR), Just-In-Time Information Retrieval (JITIR), and Contextual Item Activation with Grossberg spreading activation (CIA) — and translates the paper's four evaluation criteria (context relevance, document relevance, action prediction, diversity) into user-facing UI surfaces.

The frontend work covers four product surfaces: a map with saved-place pins and category filters, a detail panel with paper-faithful explanation breakdown, a proactive notification system driven by a composite signal gate, and a method comparison view that exposes the paper's central three-method comparison as a live product surface rather than an offline evaluation.

This case study documents the five decisions that shaped the frontend, the design philosophy that emerged across them, and what shipped against the 10-week timeline.


1. Problem framing

The product problem

Travelers save dozens of places — restaurants, museums, viewpoints, transit nodes — and forget what they saved by day three of a trip. The Sappelli et al. (2017) framework calls this re-finding: the user's challenge isn't discovering new places, it's surfacing saved ones at the right moment based on context.

Re-finding succeeds when three conditions hold: (1) the surfaced item is contextually relevant, (2) the user understands why it was surfaced, and (3) the user trusts the surfacing enough to act on it. Existing recommendation products optimize for (1). They fail at (2) and (3).

The trust gap

A user will not act on a recommendation they don't understand. "Why is this place showing up now?" gates the entire product. If the UI cannot answer that question in plain language, the underlying ranking algorithm is irrelevant.

Project goal

Build a working prototype in 10 weeks that

(a) implements the paper's three ranking methods

(b) surfaces why each recommendation appears through paper-faithful explanations

(c) proactively brings up relevant saved places without requiring an explicit user query.

Constraints that shaped the work