Lately I've been developing applications with Meteorjs and I notice that most developers/designers don't pass the idea to the user that you don't need to refresh the browser.
In Meteor, it's completely useless to refresh the browser, the data changes are directly pushed to client.
What UI/UX Design practice match this kind of application behaviour?
I thought about adding a refresh button in the UI, in the hope that the user doesn't refresh the browser, but this is bad design, it's not an honest design. With this approach I'm lying to the user.
I've been dealing with this lately and there are a few different ways I've handled it, depending on the scenario.
Sometimes it doesn't really matter that much for UX that the user refreshes. Generally, for data that changes often, you can use methods like those described in this link about designing for realtime (provided by larsbuur's answer) to make your user understand that they don't need to refresh. The general idea is to use unobtrusive but visible and clear cues that the data has changed.
If there is not much UI state that can't be recovered from the route, refreshing the browser should work pretty much how the user expects. Generally, you don't want to try to make browser features work in unexpected ways. If you want to persist UI state across refreshes, you can try something like the Meteor package u2622:persistent-session.
You could also remind the user that they don't need to refresh after they do. For example, using the web storage API:
Meteor.startup(function() {
var reload = !!sessionStorage.getItem('reload');
var manualReload = reload && !Session.get('hotReload');
if (manualReload) {
// Tell the user they don't need to manually reload the browser
}
sessionStorage.setItem('reload', true);
Session.set('hotReload', true);
});
In certain cases, it is more important that the user understands they shouldn't refresh. For example, in online games you often have a pre-match lobby system where game settings can be adjusted, and the lobby leader is the player who has been in the lobby the longest. If the lobby leader refreshes, they will lose their position.
It is possible to make this work by having a reconnect time window where the user can reclaim their position, or the user will lose their spot in the lobby after the timeout. The mizzao:user-status is helpful with this. This is, in my opinion, the most friendly UX option, and you can even display a spinner icon next to the username to indicate to other users that the user may be reconnecting. However, my attempts at implementing this have proven to be a bit buggy and unpredictable when it comes to data integrity/server reliability.
For now, I've chosen to simply use the beforeunload event like StackOverflow does when you are typing. It's not very customizable and not as friendly as transparent reload/reconnect, but sometimes it's the best compromise when you simply want to warn the user why they might not want to refresh right now.