2

In my app, I have a settings page with a number of options that all need to be saved on our backend. The call to the backend may fail for connectivity reasons and I'm not sure what's the best way to tackle it. Here are the options I thought about, maybe I missed some:

  1. Optimistic individual change

    • Every time a setting changes, call the backend and visually reflect the change. If the backend call fails, show a toast and revert the change.

    • Advantages: seamless, user knows when there's an issue asap

    • Drawbacks: more backend calls, state management can be a pain

  2. Pessimistic individual change

    • Every time a setting changes, call the backend with a progress dialog disabling interaction until the call is done

    • Advantages: user knows when there's an issue, easier to manage state

    • Drawbacks: more backend calls, lots of friction

  3. Optimistic global change

    • Only call the backend when leaving the settings activity and visually reflect changes. If the backend call fails, show a toast and revert changes

    • Advantages: seamless, one single call

    • Drawbacks: user doesn't know about issues before leaving, has to come back and redo everything

  4. Pessimistic global change

    • Only call the backend when leaving the settings activity with a progress dialog disabling interaction until the call is done

    • Advantages: one single call, easiest to manage

    • Drawbacks: user doesn't know about issues before leaving, has to come back and redo everything (I don't want to lock the user in the page if the save fails)

Note that the issues will be related to connectivity most of the time as the app prevents from sending invalid input, so no error messages to display on particular fields.

What would the best practice for this, in particular on Android? I've tried to get inspiration from existing apps with good UX but I can't seem to find a common pattern.

  • do not revert the change.... just indicate "failed retry" – Tomer W Apr 5 '17 at 10:24
1

From the user's perspective think about the ideal workflow first. That should be your target. As a user, I need to know the time required for you to save the change in my settings. I do not know that you have a backend processing or not. What are the lag and network response time? That way you establish your target.

Usually, that ideal scenario is an instant reflection of every setting just as when the user does it. That is the best practice. That is our target. That is the approach where the user is agnostic of your implementation. All others are workarounds due to limitations of some or the other kind.

Then we start analyzing the technical feasibilities and reducing the degree of freedom you have in the implementation of that target feature.

There is rarely a magic bullet. If you have servers and responsiveness like Instagram, you can go for the optimistic approach of instantly reflecting every change. For that, the settings should be fairly independent. On the other hand, if you have an enterprise application and your changes in one setting have some cascading impact on other settings, you will need some sort of evaluation time to make sure there are no faults.

Your practical implementation will have both the technical and business constraints. Even though the first one is the best approach, it is not always practicable.

  • 1
    Thanks for the answer, it makes sense overall. The settings are completely independent from each other, and our save settings call is rather responsive, so I guess I'll give a try at the first implementation. – Jukurrpa Apr 17 '17 at 18:38

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.