9
3 Comments

Supporting live updates

Didn't update yesterday because of April fools but today we're clear.

One of the things that become very clear to me, as I was using Station View, was being able to support live updates, as and when trains depart, or lets be honest the more likely scenario when a train is delayed.

This wasn't to hard to achieve but tweaking the logic to get the right time to refresh was a little tricky, and also setting up a subtle animation was also a must have so you can tell somethings changed.

I've got a few more updates that I'd like to make as well as featuring the new mascot a little more prominently.

posted toAvatar for product StationView
StationView
  1. 2

    Live updates are one of those features users don't notice when they work — but scream about when they don't.

    Getting the refresh timing right is tricky. Too frequent = battery drain, server load. Too slow = users miss real delays. Sounds like you found a balance.

    Quick questions from someone who's built similar real-time features:

    1. Are you using polling or websockets for the live updates?
    2. How do you handle the 'delay' scenario — does the animation change based on severity?
    3. Any plans for push notifications for major delays? That's where the real value is.

    The subtle animation is a smart touch. Users need to know something changed without being annoyed by it.

    Keep building in public. This is the kind of progress that builds trust

    1. 1

      Yeah you're absolutely right, as something people are likely going to be checking from their mobile phones refreshing too often kills battery. I think I'm happy with the current interval but I will continue to tweak it.

      1. Currently it's a simple poll, only because the overhead in setting up a websocket connection is more than reloading the data currently based on usage. The general usage is people check the departures and then close the web app.

      2. Yeah I'm going to look in to how I might be able to better show there's a significant change such as a delay, I've got a working branch at the moment where it highlights the significant status changes but it needs a few tweaks.

      3. Absolutely there are plans for notifications. I want to be very careful with this however and ensure I've earned the trust of people who use it and ensure that it will never be abused with essentially advertising notifications, because lets be real they're kinda annoying :D

      Thanks for the questions and I will continue to build in public as much as possible.

      1. 1

        Appreciate the detailed breakdown — polling vs websockets is one of those trade-offs most users never see, but it directly impacts their experience Smart move keeping it simple while usage is low. Premature optimization kills momentum.

        On notifications: respect the cautious approach. Nothing kills trust faster than spammy alerts. Maybe start with an opt-in for 'significant delays only' (e.g., 15+ min delay) — that feels valuable, not annoying.

        Quick question: have you considered a visual indicator (like a color-coded timeline) so users can glance and see delays without even reading the time?

        Keep building in public. This is the kind of transparency that builds real trust.