2

Current behaviour: Most of the current systems are synchronous. This means you get a response immediately on sending a request. So the expectation is that the system will respond immediately and when it responds, all the users in the system will see the same state at a particular point in time.

Proposed behaviour: Our system is a bit different. Here the system may execute the request asynchronously(i.e at will) and therefore, the user may not get immediate response. Instead the state of the system will be changed automatically after some time.
Also, the state of the system at a particular point in time will be different for each user and therefore, inconsistent across the group.

With these constraints, how can we design a user experience that sets the expectation right?

For example, Person A creates an invoice in the system. A may not get an immediate response on whether the operation was successful or not. Even if A gets a successful response, person B in the same group with the same access may not see the invoice in his system immediately.

2

You are looking for an optimistic UI pattern. This has been done very well by meteor framework.

Example

So let's say person A creates an invoice, person A would make a query to the server (create invoice), while this query is being processed, person A will see in the UI the newly created invoice (which is not true, because the server is still processing it, but it is an assumption because you trust your server to process the request correctly)

Meanwhile, nothing happens for Person B.

When the query is processed by the server, the server updates the UI for all clients (person A and person B) in case of success In case of error, person A would see the result being changed and an error appearing. This is acceptable if your server responds quickly enough. (if you need 20 seconds to process, the pattern will result in poor UX)

Limitations

If you don't assume that it will return a success in most cases, you can also apply the same pattern but show a loading indicator while the query is being processed, and show the result only once the server has processed it.

Best way would be to opt-in or out Optimistic UI pattern according to your specific needs (does this query needs optimistic UI or not?)`

This is a specific way of thinking Human Computer Interfaces, which brings a lot of reactivity and is less static from what most users are accustomed to.

But a lot of real-time apps use it (Google docs, uber...)

  • Dont you think that the users experience will be affected if we include two different types of behaviour for different entities in the same application. – bin Apr 21 '17 at 14:13
  • Users expect reactivity in some use cases and don't expect reactivity in some others. For sure you have to identify the tradeoff to be done – Leths Apr 21 '17 at 15:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.