Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time Conductor Fixed Time inputs are using "punish early" validation #7873

Closed
2 of 7 tasks
charlesh88 opened this issue Oct 8, 2024 · 0 comments · Fixed by #7886
Closed
2 of 7 tasks

Time Conductor Fixed Time inputs are using "punish early" validation #7873

charlesh88 opened this issue Oct 8, 2024 · 0 comments · Fixed by #7886
Assignees
Labels
severity:critical type:bug verified Tested or intentionally closed

Comments

@charlesh88
Copy link
Contributor

charlesh88 commented Oct 8, 2024

Manually editing Start and End times in the Time Conductor popup now fire validation on keystroke, rather than field blur. This has two bad UX results:

Time Field

Editing the time immediately shows an 'invalid date' error in the date input as the user deletes a character in the time inputs, and worst of all, jumps the input cursor into the date input, which is actually well-formed. The user will almost always type a bad number into the date field as a result, making it harder to correct the situation.

Initial state
Screenshot 2024-10-08 at 11 50 50 AM

Delete the '5' intending to change it to a '0' Note that the validation message points to the wrong input.
Screenshot 2024-10-08 at 11 51 01 AM

Input cursor has jumped into the date input. User's finger in slow-motion types a '0'
Screenshot 2024-10-08 at 12 07 55 PM

Date Field

Editing the date immediately shows an 'invalid date' error as the user deletes a character prior to typing a new one.
Delete the '8' intending to change it.
Screenshot 2024-10-08 at 11 54 45 AM

Expected vs Current Behavior

This has become the "punish early" UI model of form validation, which is bad.

  • We should only be validating inputs when the user blurs out of an input in the popup, and we definitely should not be jumping the user's input cursor into a different field than the one they were working in.
  • The 'Invalid' message should point to the actual bad input.

Steps to Reproduce

Follow steps above.

Environment

  • Open MCT Version: 4.1.0-next / RC10
  • Deployment Type: localhost, server
  • OS: any
  • Browser: both Chrome and Firefox tested.

Impact Check List

  • Data loss or misrepresented data?
  • Regression? Did this used to work or has it always been broken?
  • Is there a workaround available?
  • Does this impact a critical component?
  • Is this just a visual bug with no functional impact?
  • Does this block the execution of e2e tests?
  • Does this have an impact on Performance?
@charlesh88 charlesh88 added this to the Build 9 RC11 milestone Oct 8, 2024
@akhenry akhenry assigned davetsay and unassigned akhenry Oct 8, 2024
@akhenry akhenry added the verified Tested or intentionally closed label Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severity:critical type:bug verified Tested or intentionally closed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants