Near realtime UI updates using notifications

[ramonsmits]

Change the system to push notifications to the UI to update the statistics near real-time.

I want to know why it needed to refresh every n seconds if it's a messaging product

Source: http://twitter.com/DamianM/statuses/741164116610584576

[adamralph]

One important thing to consider here is, when there is a change on the leaderboard (an entry moving up/down or a new entry), we want to show that using the green/red or yellow highlights for a few seconds before showing the next update, otherwise the movements will be too quick to follow when there is a series of closely timed tweets.

This means that, after a period of inactivity, a "real time" UI will only show the first change in near real time, pause the display for a few seconds, and refresh again after x seconds if there is an update during the pause, which then triggers another pause (x will probably be the same period as our current polling interval).

During a period of high activity there will be little difference between the "real time" UI and the current "refresh periodically" UI. This will result on a lot of redundant pushes from server to client, with the client only using the last update before refreshing.

During a period of low activity, the push model will be more efficient, since the redundant pulls will be eliminated, but we have a low number of clients so this is not really a problem.

Given the low number of clients, and the added complexity of having to pause the display and buffer only the last update during the showing of a change, I'm not convinced that it's worth implementing the push model. The only benefit it will provide is the elimination of a delay of (on average) half the polling interval in showing a change after a period of inactivity.

[leggetter]

we want to show that using the green/red or yellow highlights for a few seconds before showing the next update, otherwise the movements will be too quick to follow when there is a series of closely timed tweets.

Definitely an important UX consideration. 100ms is likely the fastest a human will notice change. 250ms is a better aim. But for this type of data an update every couple of seconds may be a better solution. The best bet would be to do some user testing.

During a period of high activity there will be little difference between the "real time" UI and the current "refresh periodically" UI. This will result on a lot of redundant pushes from server to client, with the client only using the last update before refreshing.

The update frequency should really be controlled by the server and not the client - there's simply no point in pushing through updates that won't be processed. Although the client can help inform the server of a required update rate e.g. if it's struggling with processing the data. Although in this case we know an update rate of one per couple of seconds is probably the correct rate.

Given the low number of clients, and the added complexity of having to pause the display and buffer only the last update during the showing of a change, I'm not convinced that it's worth implementing the push model.

The low number of clients can impact a decision. As things scale, it is worth considering moving to push. I covered the basics of this in my real-time .NET talk at NDC 2016 using this app as an example (I was nice).

As per the point above, IMO the server should control the update rate and should only push data through when it should be displayed.

The only benefit it will provide is the elimination of a delay of (on average) half the polling interval in showing a change after a period of inactivity.

If there is value to the data being instantly displayed then the delay matters. In this case I tend to agree that a slight delay doesn't break the UX. That said, I do think more frequent UI updates would increase the engagement of the UI and add a bigger gamification element to the app.

I'd love to see a move to an intelligent push mechanism and some testing around the UI update frequency to determine the pros/cons.

All this said, it's been a good addition to the NDC Oslo experience. Good work!

p.s. I covered some general tools, trips and tricks for developing real-time apps in the past: slides & video.

[adamralph]

@leggetter thanks very much for chiming in! Everything you say is true.

As things scale, it is worth considering moving to push.

Currently there is no plan to scale the number of clients in our use cases, but this is worth remembering if that changes.

If there is value to the data being instantly displayed then the delay matters. In this case I tend to agree that a slight delay doesn't break the UX. That said, I do think more frequent UI updates would increase the engagement of the UI and add a bigger gamification element to the app.

It certainly would be nice to see a near-instant update after a tweet is sent. It's something worth considering for next time round.

We're glad you enjoyed the leaderboard! Thanks for links, I'll be sure to check out your tips and tricks.

[adamralph]

I've been having some thoughts about this. I think we should implement this like so:

• leave the current "every n seconds" updates in place
• add a notification of an update to clients, which invokes an immediate update, but scheduling the next update for n seconds afterwards, otherwise a series of rapid updates does not allow eyeballing of the change. Updates made in the meantime will be reflected in the next n seconds update.

The benefit this brings is, when the board is currently showing no updates, the effect of a new tweet should be visible on the board in near real time. This could have a considerable wow-effect.