What are the best practices for designing a UI when the system state might also be changed by a secondary client?

Question

I'm designing the frontend for a system (lots of text boxes for numeric entry, a couple of on/off switches). This isn't proving too tough, but I'm encountering some difficulty because there's also a command line interface to the same system. If someone changes a value there, it will take precedence, but should the text boxes at the frontend have their value change? I feel that might be a bit odd for users who see them primarily as an input space to have them change, especially given the CLI usage will be somewhat less common than Frontend.

I've laid out some potential options, including having a separate label for the "current true value" of the system.

What considerations would lead me towards one of these options?

Are there better options?

What is this topic/situation called - I feel like it must be a very common problem but I'm having trouble researching it.

Thank you kindly.

Answer 1

You have taken the right first step towards designing for a distributed environment. I would take your solution a step further and argue in favor of the other facets supporting the other heuristic paradigms:

1. Visibility of System Status

You have partially catered to this by presenting the change in the field's value, but you can go one step further here.

While a user updates a value from the CLI, show a warning hint text presenting the status of that field as locked on the GUI to prevent a race condition on the update and vice versa.

2. Match between the System and the Real World

In the real world, depending on the context, you might be required to reflect the updated value immediately or notify the user of an available update while leaving the choice to pull and merge at their discretion.

For example, an immediate update is imperative for an application catering to financial and other critical transactions. On the other hand, you can leave it to the developers' discretion to track and merge code changes done on the same repository.

3. Flexibility and Efficiency of Use

To take the approach even further, you can also afford advanced features such as auto-update and one-click merge controls for your power users.

Answer 2

The current value is probably always the most important value for the user. When I think about other systems where different user can change values, there often is no record of previous inputs. They just show the current value.

Assuming that you have to show the previous value, your current approach isn't right. The element you use (Inputfield + helpertext) is known by the user, but with a different use. To avoid confusion with the user, I would use a different approach.

Try maybe showing the current value in the inputfield and maybe as the helpertext you can give metadata to the current value. Such as "Changed 5min ago" The user would probably know, whether they changed it. The Inputfield would be still correctly used and the helpertext would put out metadata.