Improve the UX around input validation

[jotaen4tinypilot]

Upfront disclaimer: this is a broader topic, so consider this issue to be an “epic”. If we wanted to do some, all, or more of the things which are suggested here, we could scope and refine the task once we pick it up.

It should also be part of the task to document the outcome(s) in the styleguide.

---

Specificity of error messages

Some of our error message in the frontend are quite comprehensive, e.g. in the hostname dialog:

That’s not super user-friendly, because it’s up to the user to figure out which of all the various rules they have violated specifically.

The error messages should be as specific as possible, though, because that allows the user to fix the problem quickly. Btw., since we have refactored our request parsers, the backend is already capable of that without none or much additional refactoring, see e.g. the hostname parser.

Inline help

The only downside with specific error messages would be that it’s harder for the user to get a complete overview of all applicable rules. I’d argue, though, that an error message is not the right solution for that anyway. If it was important for us that users can learn about all the rules, we could introduce a separate UI element for that, as demonstrated below.

One potential idea would be to introduce a ? icon-button next to the input field (or to whatever there is something to learn about), and when hovering or clicking it, it would reveal an info box with a more detailed explanation.

Note, this is only one of many ways to do this, so it’s just a quick&dirty mockup to get the idea across.

Consistent phrasing

It would also be good to define some phrasing rules for the inline error messages. E.g.

• Which way around do we phrase them, e.g.
  • “the hostname is too long” (making a statement about what is wrong)
  • “hostnames cannot be more than 63 characters” (making a statement about what the rule is)
  • “this hostname is too long. Hostnames cannot be more than 63 characaters” (both)
• Are messages capitalized? (We are not consistent with that.)
• Since we only show one error at a time, what is the priority of them? (E.g. for the “add user” dialog, if there are validation errors in multiple fields, should it show the username-related errors first, or the password-related ones?)

“Dynamic” validation in the frontend

Currently, all input validation is done in the backend. (For security reasons, it has to be that way.) The downside is, that the user has to submit their input before the validation can be carried out.

It’s probably not a good idea to duplicate all logic in the frontend only for improving the UX. However, there are still some cheap and light-weight mechanisms, such as:

• Disabling the submit button unless all text fields contain a value. (That’s strictly speaking a duplication of the validation logic.)
• Using built-in HTML attributes like maxlength, required, or pattern.

Some of them we use currently, some not, so we should make a decision here.