Auto-submit

[thorwhalen]

Think of a general rule of thumb to determine whether to auto-submit (or "submit on event" — where event is usually a change in a GUI element).

When does it make sense to auto-submit?
When are cases to definitely avoid auto-submit?
When is "undoing submit" possible? (When it's possible, the vote towards auto-submit increases.)

We would like this analysis, and creation of some kind of rules/guidelines for making choices when we design a GUI, but of course, even more importantly, we want to be able to (as much as possible) implement those rules directly in the convention, so better UX choices are done automatically.

[charlie-dufort]

Here's what came to my mind after giving it some thought.

There seems to be a tendency indeed to remove the Save, Apply, Submit or whatever other buttons that are used to force the user to confirm changes they have just made on an interface. I've found a very good example on Windows:

• Here's the 'legacy' dialog for changing the power options, accessible from the traditional Control Panel (still available on Win10)
  

• And here's the more recent interface for doing exactly the same thing, through the new, casual-user-oriented, Windows Settings interface
  

The Save and Cancel buttons have disappeared.

The traditional Control Panel and the new Windows Settings interfaces are used for the same thing: configure Windows' general parameters. Why keep both then? A quick answer would be:

• The former is the legacy interface, which traditional users are used to, and offers more extended configuration possibilities.
• The latter looks more modern, is more intuitive to navigate through, and gives access to most parameters that average users might typically want to configure.

So I would say the use or not of the confirmation buttons follows the same pattern: they are present in traditional interfaces, or in interfaces for which the level of configuration is advanced, and tend not to appear on more modern interfaces, or on interfaces which offer a more basic level of configuration.

But there are certainly cases where there will always be confirmation buttons: for instance for all that is related to personal data and security (e.g. when it comes to modifying credentials, passwords, personal information etc.)

So, what should we choose?
On the one hand, we develop software and systems for use by industry professionals, to monitor machines and production operations. In this regard, it is important the behavior of our system cannot be changed accidentally.
On the other hand, as players in the domains of Data Science, Industry 4.0, etc. we want our user interfaces to look and "feel" modern when being used.

I would say we could follow the following rules:

• Allow "auto-submit" for all selections and modifications that can be directly and immediately seen on the interface, and that can be reversed. Typically, all that is related to UI customization (background color, time zone, etc.), but also when tagging data for instance, provided you can immediately see the newly created annotation on the preselected piece of data.
• Not allow "auto-submit" for any parameter that will change the behavior of the system (data acquisition, DPP, data upload, etc.) Even better would be to display information messages on the potential consequences of these types of actions.
• Definitely not allow "auto-submit" for any action considered "dangerous", like deleting, or largely and significantly modifying data, especially if the action cannot be undone for some reason. In those cases it's necessary to display a confirmation window with a call-to-action.

Another rule I will add, which seems obvious but it's because it's something I have seen many times in our previous interfaces: avoid any possibility for the user to close a dialog window without having them click on a button that explicitly says if the actions made on it will be saved or canceled.

[thorwhalen]

Excellent. Thanks @charlie-dufort.

Yes, something that emerges here that I'd like to emphasize by reiteration: We have a spectrum of choices. A few points along it are (from safer and annoying to less safe and less annoying):

• Need to submit, and then confirm with an extra "are you sure dialogue" that might tell you about consequences. The confirmation can also be made to take more effort when more safety is needed -- in one instance I had users have to type the name of the dataset they were deleting, backwards (to avoid copy/paste).
• Simple submit
• Auto-submit, with more evidence that it's being done, and possibly what is being done (consequences). We can consider subtle color changes to distinguish an unsubmitted state from a submitted state.
• Completely silent auto-submit

We can add to that spectrum. And lets consider the "undo" possibilities to, and how it effects our auto-submit choices.

My motto: Make everything easy and quick. Make frequent tasks even easier and quicker. But make dangerous difficult and slow.