3 ms·

> Whenever the user takes an action, you need to first update your UI to make things look fast, then send a request to the server to do that modification on the

> Whenever the user takes an action, you need to first update your UI to make things look fast, then send a request to the server to do that modification on the real database. Isn't this just lying to the user? What if the user acts on the update (e.g. closes the page, satisfied the file has been saved) and thereby loses data?

akhatri_aus 11y ago
On the other hand if something was shown to the user indicating changes were pending, yet allowed other tasks to be done simultaneously and still have everything come out in correct synchronous order, are people not better off with the 'lie'?
- millstone 11y ago
  What you describe is ideal and not a lie. Reporting progress ("Saving...") while allowing concurrent edits is great! But it's dangerous to claim the file has been saved before the save is complete, in the name of "make things look fast."
  - akhatri_aus 11y ago
    I think the author should have mentioned that latency compensation with meteor can be made optional. This is in contrast to a large proportion of existing patterns where the option to simultaneously pile on tasks and keep synchronicity is not available.
zan3 11y ago
When dealing with sensitive data it's still possible to show progress bars, spinners,... But in most cases it's best to lie to the user and it's what Meteor does by default.
virgil_disgr4ce 11y ago
Say you're asked to observe a video of a ball moving forward in a straight line, then the video is paused, and you're asked to predict where the ball goes. You say, "Straight ahead into the target." Then they play the video and instead of hitting the target, someone catches the ball. Oh no, you lied! You horrible, horrible liar!
- possibilistic 11y ago
  How does this address the problem of not saving user-submitted data after informing them you've done precisely that? This seems _very_ bad. I think we're debating the merits of different classes of update here. Some updates are not essential (UI preferences, etc.), but other requests by their very nature, are--billing, messaging, draft editing, etc.
  - hamburglar 11y ago
    It would be "very bad" for some types of applications and not for others. Clicking "Save" on some complex document is the type of thing where you probably want to report "saving..." and then "saved" only after confirmation back from the server, but for a lot of simple operations that you know should almost always succeed (especially if you're doing something with websockets and you are tracking connected state, so you have a pretty reasonable expectation that you're able to communicate with the server in the next 1s), the best approach is often to assume they're going to succeed, update the UI as if they've succeeded, then if they fail, make sure to call attention to that unexpected case and put the UI back in the right state.
  - syedatif 11y ago
    This is just one of the default mechanisms of Meteor. You can also construct regular calls to the server which do not have latency compensation (specifically, by having your update code exist on the server only).
baddox 11y ago
It's a common pattern to use window.onbeforeunload to prompt users before closing a tab if a request is still pending.
timestep 11y ago
Our team also runs into this issue. Dealing in real time means real time changes. Even if we have to wait on an return from the database to the api to the client. So we simulate the changes as the user makes the action, 'optimistic UI updating' and then wait for confirmation on the server to persist the data. During that waiting period, we tell the user that their changes are being saved, but they are free to do what ever they wish. It lets the user know things are happening, but might not persist because we are still in the mode of saving, yet allows the user to carry on with their tasks while we deal with the information they send us. If they close the page, during this time, they are well aware that the changes are happening. The request has been made, it just didn't return yet.
imslavko 11y ago
A common pattern is to indicate when the data is persisted on the server but still show a predictive update first. Take chat systems as an example: Whatsapp will show your message you just posted immediately but then it will indicate its persistence by showing you two checkmarks on your message. Meteor's architecture allows you to have slightly different models in the "predictive" mode and "persisted" mode.
quotedmycode 11y ago
Well, if you are designing such a system, you'd want to make sure that you hook into the close page function and give an alert saying 'If you close this page, the file will not finish saving' or something of the sort. Also, you'd probably want to design it such that the 'file save' operation is one of the first things you do rather than the last.

akhatri_aus 11y ago

On the other hand if something was shown to the user indicating changes were pending, yet allowed other tasks to be done simultaneously and still have everything come out in correct synchronous order, are people not better off with the 'lie'?

millstone 11y ago
What you describe is ideal and not a lie. Reporting progress ("Saving...") while allowing concurrent edits is great! But it's dangerous to claim the file has been saved before the save is complete, in the name of "make things look fast."
- akhatri_aus 11y ago
  I think the author should have mentioned that latency compensation with meteor can be made optional. This is in contrast to a large proportion of existing patterns where the option to simultaneously pile on tasks and keep synchronicity is not available.

zan3 11y ago

When dealing with sensitive data it's still possible to show progress bars, spinners,... But in most cases it's best to lie to the user and it's what Meteor does by default.

virgil_disgr4ce 11y ago

Say you're asked to observe a video of a ball moving forward in a straight line, then the video is paused, and you're asked to predict where the ball goes. You say, "Straight ahead into the target." Then they play the video and instead of hitting the target, someone catches the ball. Oh no, you lied! You horrible, horrible liar!

possibilistic 11y ago
How does this address the problem of not saving user-submitted data after informing them you've done precisely that? This seems _very_ bad. I think we're debating the merits of different classes of update here. Some updates are not essential (UI preferences, etc.), but other requests by their very nature, are--billing, messaging, draft editing, etc.
- hamburglar 11y ago
  It would be "very bad" for some types of applications and not for others. Clicking "Save" on some complex document is the type of thing where you probably want to report "saving..." and then "saved" only after confirmation back from the server, but for a lot of simple operations that you know should almost always succeed (especially if you're doing something with websockets and you are tracking connected state, so you have a pretty reasonable expectation that you're able to communicate with the server in the next 1s), the best approach is often to assume they're going to succeed, update the UI as if they've succeeded, then if they fail, make sure to call attention to that unexpected case and put the UI back in the right state.
- syedatif 11y ago
  This is just one of the default mechanisms of Meteor. You can also construct regular calls to the server which do not have latency compensation (specifically, by having your update code exist on the server only).

baddox 11y ago

It's a common pattern to use window.onbeforeunload to prompt users before closing a tab if a request is still pending.

timestep 11y ago

Our team also runs into this issue. Dealing in real time means real time changes. Even if we have to wait on an return from the database to the api to the client. So we simulate the changes as the user makes the action, 'optimistic UI updating' and then wait for confirmation on the server to persist the data. During that waiting period, we tell the user that their changes are being saved, but they are free to do what ever they wish. It lets the user know things are happening, but might not persist because we are still in the mode of saving, yet allows the user to carry on with their tasks while we deal with the information they send us. If they close the page, during this time, they are well aware that the changes are happening. The request has been made, it just didn't return yet.

imslavko 11y ago

A common pattern is to indicate when the data is persisted on the server but still show a predictive update first. Take chat systems as an example: Whatsapp will show your message you just posted immediately but then it will indicate its persistence by showing you two checkmarks on your message. Meteor's architecture allows you to have slightly different models in the "predictive" mode and "persisted" mode.

quotedmycode 11y ago

Well, if you are designing such a system, you'd want to make sure that you hook into the close page function and give an alert saying 'If you close this page, the file will not finish saving' or something of the sort. Also, you'd probably want to design it such that the 'file save' operation is one of the first things you do rather than the last.