I'm designing an app that controls a connected object.

In one of the screens of the app, the user can activate or disable a nightlight and set the hours of lightning (e.g. 8pm - 7am).

In the first version, the app developers coded the screen so that the data is sent to the server only when the user has leaved the screen. Thus, if the user wants to switch on the nightlight immediately, he will have to leave the screen to see the nightlight switching on.

enter image description here

In my opinion, the user might think that the object is not correctly connected and that the parameters have not been saved.

What are the best practices for that type of usage? These are the options I was thinking of:

  1. Option currently coded: Saving data when user leaves the screen
  2. Option developers don't like for server consumption considerations: Saving data each time the user change a parameter in the screen (e.g. disable or change the hours)
  3. Adding a button to save the data

2 Answers 2


I think the approach here is slightly wrong. Saving and applying changes shouldn't be clubbed together.

Like you mentioned, the user wouldn't understand why a certain setting isn't being applied as soon as they set the value.

I would recommend applying the setting locally as soon as the values are changed by the user[1].

As far as saving the value onto the server is concerned, I would suggest using some sort of a push method. Sending it on exit of the screen may lead to other issues like, what happens if the user closes the app rather than going back or what if the user turns off data services and then closes the app. But that is outside of the scope of this question so I won't dive any deeper into it.

[1] - Unless the command comes from the server in which case, I recommend changing that behavior as it isn't user friendly and has many other drawbacks as well.

  • The command comes from the server. So we need to update the server so that the changes are reflected on the object. In this case, what is your advice?
    – Aliz
    Apr 4, 2019 at 13:05
  • Is there a reason why the command has to come from the server? If the screenshot is accurate, the command is to turn on blue-light filter. This action is something that needs to be handled on the device-end. I can't think of a reason why such an action would require access to the server Apr 5, 2019 at 6:55

It not the right approach to justity any design desicion based on "In my opinion". Have any tests shown that this problem exists? perhaps you are solving a non-existent issue (just food for thought)

Regarding the 3 options you've presented id go with the first one (with a caveat): "Saving data when the user leaves the screen" this is a commonly used pattern. It still, however, requires some form of user feedback. "Were my changes saved? Was there a server error which prevented my changes being saved? Perhaps the user didn't have any internet connection and the changes could not be applied?" in any case, presenting a toast or a notification would be preferable to accommodate for all possible scenarios and to assure the user.

"Saving data each time the user changes a parameter in the screen" is another commonly used pattern. saving data locally then pushing it to the server at will as is a way to mitigate any performance issues BUT it can create a discrepancy between the in-app settings, and the settings that are applied to your actual device (changes are updated locally but not yet pushed to the server or perhaps could not be updated on the server). In your case (controlling an external device) I would avoid it due to the sync issues mentioned above but it should be preferred. In your case, however, I do not think it is needed.

"Adding a button to save the data" goes against the principle of "automation of unwanted workload" I would avoid it as it requires additional interaction which is unnessercary.

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.