[JENKINS-68952] Wrong location of email form validation on setup wizard

[Langer0416]

See JENKINS-68952.
Before

After

Proposed changelog entries

• Let error messages correspond to correct entry.

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO") if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content-Security-Policy directives (see documentation on jenkins.io).
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[NotMyFault]

Is there a specific reason why you dropped the exclamation mark next to the form validation?

Also, the validation looks weird, because the warnings aren't update if the input has changed.

[Langer0416]

Is there a specific reason why you dropped the exclamation mark next to the form validation?

I found that signup page do not use the exclamation mark, in my humble opinion, i think it's sufficient enough to use red for error message and red border for input field

Signup page

Also, the validation looks weird, because the warnings aren't update if the input has changed.

demo.mp4

In my test, I need to click the "store and continue" button so that the warnings will update

[daniel-beck]

The new version looks fairly similar to how the normal Jenkins UI does field validation, while at the same time being quite different (above the field vs. below, same line as the label vs. on a separate line, no icon vs. icon, not updating live). As a user I wonder why these (relatively minor) differences. The existing validation on the other hand is pretty clearly intentionally different. I might still wonder why, but at least it's so massively different that there's less surprise about the differences in behavior.

Additionally, combining error messages and form field labels seems to make it too easy for users to miss the messages. (Who has time to read more than one word of each label? It's just going to explain what a user name is or something equally irrelevant.) The lack of icons and other highlighting (bold text or similar) except for a slight text color change makes this worse.

I am confused by the Jira issue description as well. Is it wrong to have a single block of all validation errors on top of the form, as opposed to a design choice? If so, could you provide references to UI design guidelines saying so? Because as the screenshots here show, it's not like the email validation field is an outlier. It behaves consistently with the other field validations.

[NotMyFault]

As a user I wonder why these (relatively minor) differences. The existing validation on the other hand is pretty clearly intentionally different.

I agree.
The existing form validation is correct, syntax wise, the message is just placed in the wrong location, but I don't see a need to change the existing design to something that isn't proper form validation.

Is it wrong to have a single block of all validation errors on top of the form

It doesn't comply with the format form validation is supposed to be used. See https://weekly.ci.jenkins.io/design-library/Validation/ how it should be done, the validation is attached to the input it belongs to, not somewhere else on the page, which is what the issue is about.
The change proposed changes one wrong format to another.

[daniel-beck]

See https://weekly.ci.jenkins.io/design-library/Validation/ how it should be done

Ah, good point. That makes sense. Still, the differences with how form validation otherwise works are awkward.

[Langer0416]

demo.mp4

I have moved the error message below the input field, but i haven't make it updating live, if neccessary, I'll do it in my spare time, thanks.

[NotMyFault]

I have moved the error message below the input field

That looks much more promising, thanks!

but i haven't make it updating live

I wouldn't consider that as blocker for this PR, but would be nice to have if you are interested in a follow up PR to this one.

[basil]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process. Thanks!