5

Assume I have a modal dialog where I allow the user to change values of an encapsulated configuration through different UI components and I want to save the effort to implement a validation per component or restrict the component models to allow invalid values to be chosen/entered and rather validate the state of all values when the dialog is requested to be closed.

Natuarally I'd refuse the dialog to be closed if at least one value is invalid, inform the user about the invalid state in a separate dialog or a similar UI window/component and continue to do so until the values are valid.

If the dialog or its UI components respectively write their values directly on the configuration instance - because I also want to save the effort to implement a discard function for configuration changes in the dialog - this seems to be a good deal - if only I was sure it doesn't violate any programming/usability standards.

Kalle Richter
  • 222
  • 1
  • 7
  • Why do you have input controls that allow invalid input in the first place? –  Mar 13 '17 at 00:50
  • @Snowman: Your input controls are smart enough to know all cases (including business domain specific ranges)? – Robert Harvey Mar 13 '17 at 00:52
  • 7
    There are also some good question over at **[UX.SE](http://ux.stackexchange.com/search?q=dialog+validation+is%3Aquestion)** on the topic. –  Mar 13 '17 at 00:53
  • @RobertHarvey depending on the input control type it is trivial to have it self-validate, not allowing invalid input. For others, it is trivial to indicate in real-time whether input is valid or not, which is great for e.g. email addresses which allow free-form string input but the format is specific. –  Mar 13 '17 at 00:54
  • @Snowman Laziness. If I implement a validation routine in the configuration class, I don't have to implement different UI component contraints, but just call one validation function which returns a boolean or eventually raises an exception. I can reuse this validation routine after deserializing the configuration. The validation in the UI is unnecessary work from that perspective - no matter whether it's quite trivial. – Kalle Richter Mar 13 '17 at 01:17
  • The missing search term for this question is **"friction"**. In other words, even though the user will understand this software behavior to be well-meaning and somewhat necessary (depending on your design), the user will nevertheless experience a moment of displeasure, just because of being trapped, or because of sudden dimming or blurring of the screen. Hopefully you can find relevant answers on [**UX.SE**](http://ux.stackexchange.com/). – rwong Mar 13 '17 at 01:19
  • You don't want to write a discard function, you just want an immutable configuration instance. If the user can't give you a valid new value your "discard" is just "don't swap the configuration value" – Phoshi Mar 13 '17 at 12:51
  • It is a capital error to implement validation in only one place. It is also a capital error to *force* your users to do anything. – BobDalgleish Mar 13 '17 at 13:25
  • @BobDalgleish Please elaborate. Implementing things in only one place sounds like a valid approach to maximize maintainability of code. – Kalle Richter Mar 13 '17 at 19:36
  • If your system is small enough, implemented in a single language, never uses a database, never performs backups and restores, never has to upgrade from repository version to the next, never has to regress data, never has to communicate with another system, only ever applies data in a single ordering, or has only a very simple topology, you can get away with a single implementation for validation. Otherwise, not. – BobDalgleish Mar 13 '17 at 21:30
  • Reminds me of the application that had a box "are you sure you want to do this? yes no" and would show the same box again when you clicked "no" forever until you clicked "yes". Do you really want that? – jwenting Mar 16 '17 at 10:26

3 Answers3

12

It's a fine goal to want your validation logic exist in only one place. It's not fine to take that as an excuse to give the user a lousy experience.

You shouldn't "refuse the dialog to be closed". You should refuse to accept the submission. If the user wants to hit cancel let them.

Wherever you put your validation code just use it as the user fills out the form. Preferably, one field at a time.

Of course, if the controls limit input to valid input, even better.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
1

A general design goal is Don't Make Me Think. The interface should guide the user through the process as smoothly as possible.

This includes laying out the interface in a logical way, limiting the opportunity for entering incorrect data (e.g. dates and times), making valid assumptions where possible (e.g. deriving address data from postcode/zip) and not being too anal about the format of data presented if it can easily be taken care of (e.g. allowing lower case, upper case or mixed case for forename, surname etc).

A generic form error is likely to irritate the user if it isn't accompanied by clear information as to the fields they need to correct.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53
0

There are basically two situations I expect:

a: A change is immediate. In that case, every change I make will result in a valid change. The interface will be developed in such a way that I can't make up invalid inputs. There is no reason in this case to trap users because every input is valid by default.

b: A change or list of changes is only done when I press an OK or something like an apply button. In that case I totally expect there to be a cancel or back button. Please don't trap me somewhere I can't easily get out of.

Pieter B
  • 12,867
  • 1
  • 40
  • 65