13.1d RelativeDateItem allows invalid selection

[Blama]

Hi Isomorphic

please see this sample (SNAPSHOT_v13.1d_2024-07-22, not happening in 13.0p).
Anything that isn't two dates selected from the calendar (so "Today", "n weeks from now", ...) allows invalid combinations where start > end.

Best regards
Blama

[Isomorphic]

It's usually better UE to allow the end user to transiently enter an empty range, since they may simply choose to update the dates in a particular order that is more convenient.

Similar to a DateItem that may require a specific date range, where you don't want to force the user to change the month before they change the day, etc.

If you are concerned about end users not realizing that they have entered a date range that won't match anything, we'd suggest adding a server validator that prevents the criteria from actually being run if it's invalid in this way.

[Blama]

Hi Isomorphic,

but then the behaviour is inconsistent with selecting dates from the calendar (where this is not allowed) and it's not clear to the user why one invalid selection works and the other does not. I think I prefer the client side validator, as I don't see a good reason for this to go through to the server.
Also, how would one build a server validator here? RelativeDateItem and MiniDateRangeItem are about filtering, not data entry.

The validation happens on OK click, so one can select dates in whatever order.

Best regards
Blama

[Blama]

Hi Isomorphic,

actually, there is even a setting controlling this, MiniDateRangeItem.autoValidate.

Best regards
Blama

[Blama]

Hi Isomorphic,

testing a bit here I also noticed that calling dateForm.validate() in the sample via the Developer Console Evaluate JS Expression Section,
it shows these two validation errors. I'm not sure this is intended either.

12.1p and 13.0p only show the error for the DateRangeItem, not the RelativeDateItem, but even here I'm not sure this is intended.

Best regards
Blama

[Isomorphic]

What do you mean by "inconsistent with selecting dates from the calendar" - what is "calendar" here? Are you talking about the Calendar control, or maybe the DateChooser?

Which two controls seem inconsistent with each other?

Note that we have settings for more aggressive date validation. Sometimes, UE principles imply that you should immediately flag invalid input. Other times, it's best to wait.

Note also that we have seen designers making very very bad mistakes in this area recently. We've seen things like zip code or credit card fields that immediately tell you your input is invalid when you type the first digit. That's clearly wrong from a UE perspective - it's noise, not useful information, and it's distracting.

As a general UE principal, you tell the user about mistakes in their input at the moment that it is going to cause a problem, or the moment where it is crystal clear that they've made a mistake that they will need to correct.

Entering a date range that is transiently invalid satisfies neither threshold.

[Blama]

Hi Isomorphic,

answering from phone. Please see the screenshots in #1 and #3. Both are MiniDateRangeItem.
Using DateChooser in #3 (that is what I meant by Calendar) you get a validation error immediately.
This does not happen when selecting the date as in #1.
As there is even a property for this that defaults to true, dates should be validated like in #3 IMHO.

Best regards
Blama