Q-rious

Satisfy your Q-riosity.

Comment

Inspiration

You've got 20 minutes to get a coffee. Café A is 2 minutes away but has a 10-minute queue. Café B is a 5-minute walk but only a 3-minute queue. The closer café is the slower one, and we usually choose it because we can't see the queue until we're standing in it. Surveys suggest people lose around a day a year to queues, and most say they'd walk away from a long one. Our hackathon theme was Time, so we built something to give it back.

What it does

Q-rious is a phone-first web app that shows how long the queue is at nearby venues, predicts how long it will be by the time you arrive, and sends you somewhere quicker.

  • Live map of Oxford venues, with each pin labelled with its queue and wait, plus your own location.
  • Prediction: the queue you'll find on arrival, a wait range, whether it's rising or dropping, and a best-time-to-go chart.
  • Report a queue in two taps: short, medium or long.
  • Find another: choose how far you'll walk (5, 10 or 15 minutes) and see only places that sell what you want, ranked by total time: \( T_{total} = T_{walk} + T_{queue} \)
  • Ask Q-rious: a chatbot you can ask in plain English, such as "where can I get a coconut milk latte quickly?". Tapping its recommendation jumps the map to that venue.
  • Voice in and out for hands-free use.
  • Accessibility: larger text, high contrast and the dyslexia-friendly Lexend font, in a navy and white scheme chosen to work for colour-blind users.
  • Log in or continue as a guest.

How we built it

Stack: a phone-first Flask (Python) web app with an HTML, CSS and JavaScript front end, Google Maps for the map, and the five sponsor technologies below.

HRT: data to prediction to decision

  • Data: a time-stamped queue reading for each venue goes into a database every couple of minutes.
  • Prediction: we predict the queue at the hour you'll arrive, not just the queue now, because you walk first: \( \hat{q} = 0.5\,q_{now} + 0.5\,\bar{q}_{hour} \). Wait time is the predicted queue multiplied by the average time per person, shown as a range. We also show whether the queue is rising or dropping, and a best-time-to-go chart for the day.
  • Decision: the prediction drives a recommendation. For every venue that sells what you want and is within your walking limit (5, 10 or 15 minutes), we add walk time and predicted wait, and recommend the lowest total: \( T_{total} = T_{walk} + T_{queue} \).
  • See it in the demo: tap a café to see the forecast and chart, report a long queue, then tap "Too long? Find another".
  • Honest limits: the demo queue data is simulated and labelled in the app, so the forecast's accuracy isn't yet tested against real queues. That's our next step.

Tiger Data: the time-series core

  • Timescale Postgres stores the venues, the queue readings over time, and user logins with hashed passwords.
  • The time-series design lets us query the usual queue at each hour of the day, which is the basis of the HRT forecast.
  • A feed script writes new readings continuously, and the app reads them live, so every pin, forecast and chart on screen comes from the database.
  • See it in the demo: the pin labels on the map, the best-time-to-go chart, and logging in.

Gemini API: a chatbot that can't invent data

  • Every question goes to Gemini together with our venue data (walk time, queue now, expected queue on arrival, trend, and what each place sells).
  • It's instructed to use only that data, compare walk plus wait, explain its pick in a few sentences, not present figures as real-time unless the data is live, and refuse unrelated questions.
  • It's built to fail safely: a 12-second timeout, a keyword-based backup if Gemini fails, the model's "less thinking" option for speed, and one Gemini call per search.
  • Tapping a recommendation opens that venue on the map.
  • See it in the demo: ask "where can I get a coconut milk latte quickly?".

ElevenLabs: voice in and out

  • Speech-to-text lets people ask questions by speaking, and text-to-speech reads the answer back in a natural voice.
  • This makes the app usable hands-free while walking, and easier for anyone who finds typing difficult.
  • If ElevenLabs fails, the browser's own voice takes over, so the app never goes silent.

Vultr: prepared, but unavailable this weekend

  • Vultr was not working for any participants this weekend, so we couldn't complete a live deployment. The demo runs locally instead.
  • We prepared the full deployment: the Flask app running as a service on a Vultr server, served over HTTPS, and connected to our Tiger Data database.
  • API keys are held in environment variables, not in the code or on GitHub, so the same setup works on a Vultr server.
  • Our step-by-step deployment guide covers the server setup, HTTPS and environment variables, so the integration can be completed if access is restored.

Google Maps

  • It draws the map, shows your location and gives walking directions.

Challenges we ran into

  • No real queue data. We had no real queue history to work with, so we built a simulated feed that writes realistic readings into Tiger Data, and we label it clearly in the app. This lets us demonstrate the whole pipeline while real sensors are the next step.
  • Four people, one codebase. Joining the map, chatbot, database and front end meant adapting our code to each other's data structures. We merged each part through GitHub and adapted our data layer to the database's real table structure.
  • Gemini model availability and speed. Our first choice of model wasn't available to new users because of demand, so we switched to a replacement. That model was slow to start (around 105 seconds), so searches timed out and an early version of the chatbot froze. We fixed it with a 12-second timeout, so the app gives up instead of waiting, a keyword-based backup that answers if Gemini fails, the model's "low thinking" option to cut response time, and one Gemini call per search instead of two.

Accomplishments that we're proud of

  • A complete flow, end to end. Report a long queue, find a quicker café that sells your item, and get a plain-English recommendation, with a spoken answer if you want one.
  • A prediction that drives a decision. The app predicts the queue you'll find when you arrive, shows a wait range, a verdict and a best-time-to-go chart, then ranks alternatives by total time (walk plus wait) and shows how many minutes you save.
  • A chatbot that can't invent data. It answers only from our venue and queue data, and a timeout and a keyword-based backup keep the app working if Gemini is slow or fails.
  • Live updates from users. A queue report takes two taps and immediately changes the queue and the prediction.
  • Accessibility built in from the start. Larger text, high contrast, a dyslexia-friendly font option, voice in and out, and a navy and white scheme.
  • Honest by design. Every simulated figure carries a "Simulated feed" label in the app.
  • Built for everyone, not just students. Anyone with limited time, or for whom a long wait is a real burden, can use it.
  • Real accounts. Sign-up and log-in with hashed passwords stored in Tiger Data, plus a guest option and a personalised greeting.

What we learned

  • Constraining an AI to your own data makes it far more trustworthy.
  • Working as a team across a shared codebase, and building fast, taught us a lot about GitHub and about deploying a real app.

What's next for Q-rious

  • Real data: a camera that counts people on the device (keeping only the number, never images), cross-checked by a CO2 sensor, plus user reports, starting with a few partner venues.
  • Testing the forecast against real queue history, then improving it.
  • A business model: free for users, with venues subscribing for busy-time insights, and recommendations never ranked by who pays.

Built With

Share this project:

Updates

Submission history