Opened 12 years ago

Closed 11 years ago

#4437 closed enhancement (fixed)

Validation warnings during input inpolite

Reported by: dante Owned by: Douglas Hays
Priority: high Milestone: 1.2
Component: Dijit - LnF Version: 0.9
Keywords: ibm Cc: bill
Blocked By: Blocking:

Description

wrt to, though extends #4427 - when you are entering data into an input (in this case, the first time you focus the input to enter text) it warns you "the value you have entered it not valid" ... seems like an intuitive UI decision would be to wait until blur to warn with icon (eg: LOOK HERE, this input has invalid data) and to give the user the benefit of the doubt while the input has focus(), or simply have a more subtle warning while invalid data is being typed. Perhaps you could incorporate this behavior into whatever decision is made regarding a fix for #4427 ...

Attachments (3)

4437.patch (1.3 KB) - added by Douglas Hays 11 years ago.
new validation logic to match partial values
4437.2.patch (3.1 KB) - added by Douglas Hays 11 years ago.
incomplete errors on focus show up as white box with error msg until the error is fixed - rangetextboxes no longer check the range until the 1st blur
4437.3.patch (3.7 KB) - added by Douglas Hays 11 years ago.
added more sophisticated range checking

Download all attachments as: .zip

Change History (11)

comment:1 Changed 12 years ago by bill

Milestone: 1.02.0
Owner: changed from bill to Douglas Hays

This is by design, to notify users the instant they type an invalid character, so they know which character is invalid. I don't know, we could have yet another CSS class, or modify the invalid CSS to be more subtle while the field is focused. But it's not just CSS, there's also a tooltip.

I think perhaps what you are really asking for is to differentiate between error values (like "450-326-12x4" for a phone number) vs. incomplete values (like "450-" for a phone number), but that's harder to do.

comment:2 in reply to:  1 Changed 12 years ago by guest

To solve this issue for incomplete values, I can suggest two alternatives:

  1. The easier one: have a boolean setting like showErrorMessageOnLostFocus. If this is set to true, the tooltip for invalid value should only be shown once the user leaves the input field and not while the focus is on the field.
  1. The slightly trickier one: have a setting for timeDelay. The value in this property will be used to set a time delay before the actual comparision between the value entered and the regular expression takes place. This delay will give time to the user to finish typing the value.

Replying to bill:

This is by design, to notify users the instant they type an invalid character, so they know which character is invalid. I don't know, we could have yet another CSS class, or modify the invalid CSS to be more subtle while the field is focused. But it's not just CSS, there's also a tooltip.

I think perhaps what you are really asking for is to differentiate between error values (like "450-326-12x4" for a phone number) vs. incomplete values (like "450-" for a phone number), but that's harder to do.

comment:3 Changed 11 years ago by alex

Milestone: 2.01.3

Milestone 2.0 deleted

comment:4 Changed 11 years ago by bill

Component: DijitDijit - LnF

Notes from http://spreadsheets0.google.com/ccc?key=p3oic4WD9C-x4pXrTGo7dBA :

We think it's wise to minimize disturbing the users with error messages before they've finished typing or an error is apparent. A valid case for presenting an error while the user is typing is when you know that the user has typed something that will never be correct (eg an apha is typed in a zip code field). However, if a field calls for 5 characters and user is simply typing the first character no error should be displayed until onBlur or the 6th character is typed.

comment:5 Changed 11 years ago by bill

Keywords: ibm added

Changed 11 years ago by Douglas Hays

Attachment: 4437.patch added

new validation logic to match partial values

comment:6 Changed 11 years ago by Douglas Hays

Cc: bill added
Milestone: 1.31.2
Status: newassigned

I'd like to get the function provided by this patch reviewed in time for the 1.2 beta. The new function will match partial values and not flag them as errors until the field has been blurred for the first time.

comment:7 Changed 11 years ago by bill

Thanks for working on this. The partial value matching is great. The thing that confused me (when I tried it) was how partial matching stops after the first blur. For example, let's say a user types in a value (like 123.45), and then later goes back to the same field to type a completely different value (after erasing the old value)... he no longer gets the benefit of the doubt... the field turns yellow instantly.

ISTM that if a user starts to modify a field (even if the field was previously blurred) the widget should revert to the more lenient partial matching (until another blur).

I also noticed three bugs (in the sense that incomplete values are flagged as errors):

  • In test_validate.html, for the elevation field, as soon as you type "-" it goes yellow. Then when you type a digit (so the field becomes "-2") it goes white again.
  • In test_DateTextBox.html, for the "American Date" field, if you erase the current value and start to type "12/30/2006", it goes yellow after you type "20" (from the year). Apparently it's "jumping to the conclusion" that the user is typing a two-digit year even though the typing hasn't finished yet.
  • In test_TimeTextBox.html, for the "Time using local conventions" (which is american on my machine), as soon as I type "3:" (planning to type "3:00 pm") it goes yellow. Typing "3" by itself is fine, even though that is also an incomplete value.

So basically, the change is good but we are still being too eager to turn a field yellow.

Changed 11 years ago by Douglas Hays

Attachment: 4437.2.patch added

incomplete errors on focus show up as white box with error msg until the error is fixed - rangetextboxes no longer check the range until the 1st blur

Changed 11 years ago by Douglas Hays

Attachment: 4437.3.patch added

added more sophisticated range checking

comment:8 Changed 11 years ago by Douglas Hays

Resolution: fixed
Status: assignedclosed

(In [14142]) Fixes #4437. Creates a parsing regexp for ValidationTextBox? widgets that matches valid subsets in order to mask validation errors during data entry that are only due to partial input.

Note: See TracTickets for help on using tickets.