Improving Responsiveness of Data Validation Rules

Product Suggestions
, ,
1

Recently, @ta-aoki and I had a discusssion during Office Hours that I thought would be useful to raise here for feedback as a product suggestion. This topic revolves around data validation.

Consider the following scenario: I want to make an App that simply retrieves some contact information about a person from a Tulip Table (e.g. email address, phone, name) and allows me to edit this information. I make some text input widgets and tie their source directly to the Record Placeholder fields.

Perhaps I want to add some data validation - such as enforcing a proper email address format of “x@y.z”. However, two issues occur:

  1. I’m unable to actually affect change due to the validation rule running unless that change happens in a Trigger somewhere.
  2. Currently, data validation runs on every input to the text input widget, so the validation will kick on every intermediate keystroke before I have the full input.

Both of these issues lead me to believe that I instead need to make the text input widgets have an intermediate variable as their source, and then I need a button somewhere else that checks the validation status of the input before “committing” it to the table.
However, this has its own problems - now I need 2n Triggers for n inputs, as each input needs both a ‘pull from table record’ and a ‘push to table record’ trigger! My app is now becoming much more sluggish and hard to manage.

My suggestion: Data validation rules need to, in some cases (perhaps as an option), be able to:

  1. Only run when the data entry is completed - such as when the input field is de-focused. This will allow us to avoid the ‘false positives’ that throw when we’re in the middle of typing an entry.
  2. When triggered, revert or block the data entry. This will allow us to tie the Input Widget to the Table directly with the knowledge that the Table data is still ‘clean’ because of the validation rule.
    (Note - basically, what this is asking is for us (Tulip) to ‘in-house’ the have-an-intermediate-variable-holding-the-old-input-state process)

Have you ran into this issue? Would this be helpful for you? Have you seen it done a different way? Let us know!

2

I think the approach with checking for de focus is crucial.
This should also be an option for a trigger since the “enter key” is not a visible condition for the user and therefore must be additional to a button (redundant trigger).

The second suggestion seems to be a bit harder, but could also be relevant for variables (not only records). But when should data be applied immediately and when only after leaving focus?
Always when a validation is applied? Or is it an option on validation?

To apply both rules there is a conflict to solve by more complexity…
Or did I oversee something?

3

@thorsten.langner totally agreed. “Enter Key” triggers are also somewhat problematic for touchscreen interfaces like tablets/mobile, so I think de-focus is the better way to go.

Regarding blocking/modifying the result, I’m thinking that there are already pretty good solutions to this problem found in Excel and Google Sheets, respectively below:

image
image

In both these cases, the user can opt-in or out of having this destructive action. I like Excel’s one-step-further where you could still flash something like a warning without affecting the contents, because maybe sometimes you want to handle for weird corner cases (as someone with an email ending in @tulip.co, not @tulip.com, this issue rapidly becomes personal :sweat_smile: )

4

Who would have those kind of email address? :upside_down_face:

1 Like