1

Case: enterprise web-client solution for sales orders, the User needs to select lots of items to perform one operation in bulk and not all the items are applicable for this operation (due to hidden parameters, status, etc.).

Please advise, which practice is better to follow:

  • A) Allow the user to select anything/all and let the backend validate the selection and if any not suitable item is found - rollback the operation dropping the message listing the items caused the rollback.
  • B) Validate the selection on UI on click of the button allowing to send to backend only the 100% valid set of items, so backend will not fail.

So far we can choose only from these options because of the performance issues.

Improve this question
1
  • To take a good decision, more information on the context of use would be very helpful. Is it important that the user understands why the operation is not possible on certain items? Can they fix that situation and do they have an interest in doing so? Are the items isolated from each other, or are there relationships between them. In other words, does the transaction make sense if only applied to part of the selection?
    – Andy
    Jun 20, 2022 at 12:37

2 Answers 2

Reset to default
0

A - This is the preferred option. That said, the content has to be crystal clear, both before and after the selections are made as this ensures that the user is informed and doesn't leave the process thinking that they were successful in getting everything they selected.

The user first needs to be informed that there is no guarantee that every selection they choose will be available before they make their selection. Once the system has determined their fate, there should be distinctive UIs for the happy path (100% of the selections are available) as well as the not-so-happy-path (<100% of their selections are available). The error handling should look very different than the happy-path so that the user is clearly informed that one or more of their selections were not available. It should be very easy to tell which selection(s) were available and which selection(s) weren't.

Improve this answer
1
  • Thank you for response, but it's still not clear. Either set of selected items is checked for validness before start of the operation (i.e. the user clicked on the button, but system rejects it), or the system does it in the backend and responses to the User which items aborted the operation? Or if the set of selected items isn't applicable for the 'action intended to be performed', than the system must disable the button completely (with a helpful tooltip on hover, for example)?
    – elisarea
    Feb 6, 2020 at 13:03
0

You say, for your second option:

allowing to send to backend only the 100% valid set of items, so backend will not fail

You are aware that frontend validation is not secure, right? If you have frontend validation, you must also have the same validation in the backend -- both because the user may have avoided the validation, and (in your case particularly) because the state of the selected entities had become invalid between the user picking them and submitting the form.

The option of letting the user submit an invalid form and then telling them why their input didn't work is bad, because then the user will have to input the form again, or navigate back to it.

What I'd do is, when the user presses the submit button, an API request to perform the change is sent. If the response is successful, navigate to the result page. If it is unsuccessful, the response will contain the items that were invalid, and then they are highlighted on the form, and the window scrolls up to reveal them with a message saying that the operation could not be performed on this item and that it hasn't been on any of the others.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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