3 ms·

You shouldn't have to wait until you submit something to get feedback on it. It's poor UX. Frontend and backend validations are also different. Frontend is mor

You shouldn't have to wait until you submit something to get feedback on it. It's poor UX. Frontend and backend validations are also different. Frontend is more about shape and type. Backend is content and constraints.

emodendroket 3y ago
Right, you shouldn’t, but that means writing them twice. One of the selling points of backend JavaScript is the same validation code can run on both ends (obviously any validator that needs to check, e.g., uniqueness in a database won’t work).
- ZephyrBlu 3y ago
  Frontend and backend validation are usually not the same though. You won't be writing the same thing twice, you'll be writing different validations for each.
  - emodendroket 3y ago
    I think the frontend validations will, most of the time, be a subset of the backend ones, with many shared validation points.
    - iainmerrick 3y ago
      Yes, exactly! I’ve several times been in the position of writing a new UI for an existing API. You find yourself wanting to validate stuff before the user hits “submit”, because hiding errors until after submitting is terrible UX; and to do that, you find yourself digging into the server code to figure out the validation logic, and duplicating it. And then years or months later the code gets out of sync, and the client is enforcing all sorts of constraints that aren’t needed on the server any more! Not good.
petepete 3y ago
> It's poor UX. It's not as easy as that. Showing validation while people are editing can be even worse, especially for less-technically able users or people using assistive technology. Having an announcement tell you your password isn't sufficiently complex when you're typing in the second letter might not be bad for us, but how does that work for a screen reader?
- emodendroket 3y ago
  That seems like it’s resolved by waiting for a focus change event.
  - petepete 3y ago
    Not really. GOV.UK Design System team have done lots of research into this and their guidance says: > Generally speaking, avoid validating the information in a field before the user has finished entering it. This sort of validation can cause problems - especially for users who type more slowly https://design-system.service.gov.uk/patterns/validation/ https://design-system.service.gov.uk/patterns/validation/
    - emodendroket 3y ago
      Not seeing how that’s inconsistent with evaluating when the user goes to the next field.

emodendroket 3y ago

Right, you shouldn’t, but that means writing them twice. One of the selling points of backend JavaScript is the same validation code can run on both ends (obviously any validator that needs to check, e.g., uniqueness in a database won’t work).

ZephyrBlu 3y ago
Frontend and backend validation are usually not the same though. You won't be writing the same thing twice, you'll be writing different validations for each.
- emodendroket 3y ago
  I think the frontend validations will, most of the time, be a subset of the backend ones, with many shared validation points.
  - iainmerrick 3y ago
    Yes, exactly! I’ve several times been in the position of writing a new UI for an existing API. You find yourself wanting to validate stuff before the user hits “submit”, because hiding errors until after submitting is terrible UX; and to do that, you find yourself digging into the server code to figure out the validation logic, and duplicating it. And then years or months later the code gets out of sync, and the client is enforcing all sorts of constraints that aren’t needed on the server any more! Not good.

petepete 3y ago

> It's poor UX. It's not as easy as that. Showing validation while people are editing can be even worse, especially for less-technically able users or people using assistive technology. Having an announcement tell you your password isn't sufficiently complex when you're typing in the second letter might not be bad for us, but how does that work for a screen reader?

emodendroket 3y ago
That seems like it’s resolved by waiting for a focus change event.
- petepete 3y ago
  Not really. GOV.UK Design System team have done lots of research into this and their guidance says: > Generally speaking, avoid validating the information in a field before the user has finished entering it. This sort of validation can cause problems - especially for users who type more slowly https://design-system.service.gov.uk/patterns/validation/ https://design-system.service.gov.uk/patterns/validation/
  - emodendroket 3y ago
    Not seeing how that’s inconsistent with evaluating when the user goes to the next field.