Thinking about abusing the jQuery Validate plugin...
-
So I have a page that uses jQuery Validate For All Your Validation Needs™, but now we're thinking of doing something that may theoretically be possible, but introduces quite a bit of
sludge to the mix.Background: This is a questionnaire system that users submit data to. Later on in the process, if the answers aren't "satisfactory", a "remediation team" goes in, fixes the problem that generated the unsatisfactory answer, and marks it as such in a "remediation page". Now, the consumers want to be able to "pre-remediate" the initial submission, i.e., they know this is a bad answer, but want to click the "I fixed this" box right there in the form as they're filling it out (yes I know this is a terrible idea, no I haven't yet gotten them to budge on it).
Anyways, so I'm thinking of how to do this, and it seems easiest to dynamically add in a checkbox element (or whatever) to the form next to the input whenever that particular answer gets an "unsatisfactory" value in it, so they can check it and move on.
The problem is that I don't want to try implementing my own version of jQuery Validation, and I'm not sure how to separate actual "Validation failed" statuses with "Well, validation failed so the plugin would generate an error element which we re-wrote to actually slice in a new Input element and friends, so it failed once but now all the sudden it's not a fail".Am I off my rocker, is this even possible?
The end goal is to have one set of validation rules to do the actual validation and marking-errors bit, and one set of rules to appear/disappear the "we know this is bad, but we fixed it" input element.
-
So, right now:
The answer is bad, user gets a validation error and is stuck until corrected.You want:
The answer is bad, user gets validation error, but also a checkbox. If checkbox is checked, error disappears and user can move on as if the answer is correct.Right?
-
Right?
Basically. Although, slight modification: if it's bad, and they don't check the box, it still gets submitted (i.e. form is "valid") and gets handled the normal way (the "remediation group" uses their version of the form to mark it fixed).
-
I don't understand.
Sounds like the form is submitted whether the answer is good or bad. And whatever processing you do afterwards (including these remediation groups) has nothint to do with jquerry validation.
-
Am I reading this right, you want
- Good, submits ok
- Bad but box ticked, submits ok and fixed by an internal team
- Bad but box unticked, submits ok and fixed by an internal team?
It seems like you want to remove the client side validation, and just have server side logic that sets a flag for your internal team to check it?
-
Sounds like the form is submitted whether the answer is good or bad. And whatever processing you do afterwards (including these remediation groups) has nothint to do with jquerry validation
Kinda. Yes, the form gets submitted, but essentially I'm adding part of the functionality of another form (the marking "this is fixed" part) to the this one.Am I reading this right, you want
- Good, submits ok
- Bad but box ticked, submits ok and fixed by an internal team
- Bad but box unticked, submits ok and fixed by an internal team?
It seems like you want to remove the client side validation, and just have server side logic that sets a flag for your internal team to check it?
#2 is more like "Bad, but box appears and gets ticked, no interaction by remediation team"
#3 is like "Bad, but box appears and doesn't get ticked, interaction needed by remediation team business as usual"The apparent idea is to give the first answers the chance to be remediated before needing remediation by the remediation team. Essentially, it skips the bucket if they tick the box here.
-
What happens if the user enters bad information and ticks the box avoiding the remediation team? How will later systems cope with being fed garbage data? This sounds like a recipe for disaster...
-
The more I evaluate this, the more it sounds like hacking a really ugly bodge into the Validation plugin.
Current plan goes as follows:
- For those questions that have a remediation condition (aka bad value rule), add a validation rule that checks the condition, and also checks if there's an extra sub-element containing the "this is fixed" box. If it passes, or the box is there, validation is good. Additionally, set a custom message that's an encoded string for the next part.
- In the errorPlacement handler, check if the error message is in the previously mentioned format, and if so:
- Drop the Validation Plugin's version of the error element, and build up a custom one (being careful to avoid giving it an ID of
[name]-error). - re-trigger validation, but only for that particular field.
- Figure out if doing this will ostracise the new element from the Validation Plugin's handling (because we want the new element to disappear/become erased if the value is replaced with something not a "bad value), and if so, attach an event handler to the source element
What happens if the user enters bad information and ticks the box avoiding the remediation team? How will later systems cope with being fed garbage data? This sounds like a recipe for disaster...
For the moment, it's "I don't care" from the customer. I'm still working on getting them to see reason, after all. ;)
Apparently, they'd rather have users intentionally entering bad data and claiming it's been fixed, than having another set of eyes actually verifying it's been fixed.
-
So your current form uses jquery validate to notify users of answers that don't match the rule, but doesn't prevent them from submitting, and you want to change it to notify users of answers that don't match the rule and add an extra input element to let them indicate whether the question will need to be revisited and still not prevent them from submitting? I don't see any problems there.
-
So your current form uses jquery validate to notify users of answers that don't match the rule, but doesn't prevent them from submitting,
Not quite, we prevent submission if the "normal" validations fail, but not if the "needs remediation" rules fail. In other words, multiple validation.and you want to change it to notify users of answers that don't match the rule and add an extra input element to let them indicate whether the question will need to be revisited and still not prevent them from submitting?
Not quite. The idea is that they can check a box that indicates that they fixed the issue that caused the "needs remediation" rule to fail.As an example, say I have a question, and it's a free-form text box asking for a number. If the number is above a given value (say, 50), it's still a valid entry, but requires remediation. Therefore, there will be two rules:
- Is the input given a number? (If no, fail validation, prevent submission)
- Is the input given > 50? (If no, don't do anything, if yes, show a checkbox, submission can succeed so long as #1 is good)
So, if they put in 51 as the answer, it's Ok to submit, but they have the opportunity and option to check the box that says "I fixed this", which allows things further down the line to be skipped.
If they put some gibberish, they couldn't submit it, and rule #2 wouldn't apply at all because #1 failed.
-
Ok, I'm not sure I'd call that multiple validation then. I'd say that part 1 is a validation step, and part 2 is changing the form based on the value of already validated data.
I'm not front end, but the way I would expect this to be done is to have the checkboxes always present on the form, but hidden, with a data element relating them to the question, then put a hook on validation success that unhides them as appropriate.
-
have the checkboxes always present on the form, but hidden, with a data element relating them to the question, then put a hook on validation success that unhides them as appropriate.
This was one of the ideas, but then I would be writing my own rules engine.
It sounds like that's probably going to be the way to go, since I'm not really liking the way I would need to abuse the Validation Plugin...
-
I think you're using what should be basic validation (did they enter anything, did they put letters in a number field) to do business logic, which it's not designed for.
-
-
If I've learned one thing from the project I'm on right now, it's that you definitely need to clearly separate basic validation from business rules.
But don't do it the way we're doing it, our business rules handling is pants-on-head stupid. You want a single, concise location for your business rules.
-
You want a single, concise location for your business rules.
In this case, I have two tables total, validation and remediation, of which a given question can have one of each. So, at least there's that...
-
My current thinking is I would use the jquery-dependent-questions plugin, just extend it to allow properties of the form
data-depends-on="functionName(inputName), where functionName is looked up in a dictionary somewhere, likefunctionTable[name](value).
-
You want:The answer is bad, user gets validation error, but also a checkbox. If checkbox is checked, error disappears and user can move on as if the answer is correct.
Right?
It seems like you can just uninstall the validation if the checkbox is checked. I'm not sure how to uninstall the validation in that library, but... isn't it as easy as that?
-
The quoted assumption is wrong, I think. From what I can tell, if its like what we're doing, it's not that you want the user to be prevented from moving on, but instead, you want to take different actions on the backend depending on if their answers met certain rules. It's just confusing because one set of rules defines a 'bad' answer, which needs to go into the 'bad answer' flow.
"Bad, but box appears and doesn't get ticked, interaction needed by remediation team business as usual"
isn't the usual "pop up a red box and make the user fix their error" flow that you'd want for things like, they typed "banana" into the "phone number" field.
-
Yeah I answered too early. I don't really get this in a couple ways.
Why is the front-end and not the back-end the determinator of what constitutes a "bad" answer? Does the back-end just trust the front-end's opinion? Or...? Front-end validation is supposed to be a convenience to save the user time, not the authoritative source of validation.
And like you said, what we're doing here is really almost entirely unrelated to validation. (It's kind of the opposite of validation, really.) So. It's not surprising that a validation library doesn't support it.
It seems to me that the "correct" way of doing this would be to do the normal validation on the back end, and then the back end redirects to a page saying something like, "your data is bad because X, Y, Z, are you sure this is correct?" with a yes/no button.
Think about how when you enter an incomplete address to, say, Amazon, and they come back with, "is this the ZIP+4 you intended?"
But anyway, the real problem here is a user problem. The person entering the data is always going to say they did it right, and therefore there's no point in the remediation process existing anymore. Assuming there was a reason the remediation process existed in the first place, you're almost certainly throwing some babies out with that bath water.
-
I figure there are cases where the business just needs to have a human acknowledge that they recognize that the numbers are outside the usual parameters — presumably so they know who to point at if something goes wrong — and only want to get remediation involved if there's something they could do to actually change those figures, like if the real numbers weren't known at the time of filling out the form, or whatever.
-
isn't the usual "pop up a red box and make the user fix their error" flow that you'd want for things like, they typed "banana" into the "phone number" field.
Yes, this is the validation part, and it works fine.
Why is the front-end and not the back-end the determinator of what constitutes a "bad" answer? Does the back-end just trust the front-end's opinion? Or...? Front-end validation is supposed to be a convenience to save the user time, not the authoritative source of validation.
It's not, the Front End is just supposed to provide the opportunity to mark the bad value as "fixed" before it gets marked "needs to be fixed" by the back end.But anyway, the real problem here is a user problem. The person entering the data is always going to say they did it right, and therefore there's no point in the remediation process existing anymore. Assuming there was a reason the remediation process existed in the first place, you're almost certainly throwing some babies out with that bath water.
Wholeheartedly agree, which is why I didn't design it that way. But, I'm not the one defining the requirements
.
I figure there are cases where the business just needs to have a human acknowledge that they recognize that the numbers are outside the usual parameters — presumably so they know who to point at if something goes wrong — and only want to get remediation involved if there's something they could do to actually change those figures, like if the real numbers weren't known at the time of filling out the form, or whatever.
Something like this. Presumably, the questionnaires are supposed to be filled out after the fact, so by the time they fill the answer, it might have already been corrected somehow, and thus no further attention is necessary.
For example, some agent failed to complete a task within a given time frame, so an escalation occurred and blah stuff happened. In this case, the issue is already fixed by the time the questionnaire happened, so there's no need to involve another agent to mediate it.
One thing I think we're mixing up is a "bad value" versus an "invalid value". There's still validation happening on the front end, that's not going away (it is also double-checked in the back-end too), and now we're adding remediation checking for "bad values", which already happens in the Back End, but now they want it to happen in the Front End so they can pre-fix things.
-
If the user enters a value which is "bad" - why are they checking another box to say they fixed it rather than just filling in a "fixed" answer?
-
As I read it, I think of an issue I had several years ago when I just moved into my apartment with the water meter.
Each year I have to go to an online form and fill in the current value of my water meter. This is a 5-digit number of cubic meters of drinking water used. The validation here is simply 'did the user enter a 5-digit number, including leading zeroes'. The business check is 'is the water usage sane for this type of household'. If I mistype one of the early digits, this might result in an unreasonably high bill which requires effort for all parties to resolve. But it's also possible I had a water leak (so I just have to pay the bill), or that the recorded value of the last year was actually incorrect (and that may have to get fixed by the provider).
The water company actually implements such a flow, but if I recall correctly it's a multi-page process, which is OK since it's only the one entry box which has such a rule. If a similar condition occurs in a longer form, it is more user-friendly to attend the user to this discrepancy immediately, rather than having the user come back to a problematic figure after the fact.
-
which already happens in the Back End, but now they want it to happen in the Front End
I think you need to expose the rules as a service and fire an AJAX at them before submission, then.
-
Or make a second page, like Blakeyrat recommended.
-
If the user enters a value which is "bad" - why are they checking another box to say they fixed it rather than just filling in a "fixed" answer?
The idea is that a team of QA people are grading actions of other agents (Quality Assurance), so it is expected that some answers are "bad".
This is a sketch of the workflow:
The first part is done by agents doing their normal thing, the second and third parts are two pages handled by the QA team, which has agents doing the initial check and agents doing remediation.
The idea here is that the initial-check agents might know that despite a particular item failing (i.e. has a "bad" value), they might know that it has already been fixed by the time they got to filling the questionnaire, and so can immediately mark it as fixed in the second part, instead of waiting for the remediation agents to go back and confirm it.
In other words, allow the questionnaires that would normally go to remediation agents to skip that.
The goal is to acknowledge there is a problem (hence, entering in the bad values), while also showing that it gets fixed (marked as fixed).Or make a second page, like Blakeyrat recommended.
It's already made. They just want the opportunity to skip it. :P
-
Well when you phrase it like that, make it a button.
"Clear Form", "Submit", "Submit Skipping Remediation".
And might I just add: you're really bad at explaining shit in plain English. It's taken like 2 days for the general populace here to figure out what the hell you're talking about.
-
you're really bad at explaining shit in plain English
You're right, having details is a
to understanding, but apparently using words was too complicated, so I put those words into colored boxes and all the sudden it makes sense.Well when you phrase it like that, make it a button.
Ah! But there's the kicker: They don't want a button that ignores remediation totally, they want the part 2 agent to individually acknowledge each failed question as fixed, not just blanket-check the whole thing (though you can bet that's what's going to happen anyway, but the theory is that there would be more culpability or something)."Clear Form", "Submit", "Submit Skipping Remediation".
This whole thing doesn't make sense from most viewpoints, and that's more likely the reason nobody can understand it well without pages and days of explanation and re-explanation.
-
so I put those words into colored boxes and all the sudden it makes sense.
I'm sure there's a step in the picture which wasn't in the words, but I don't care enough to go back and check the words.
-
This whole thing doesn't make sense from most viewpoints
That too. Just tell them to stop being idiots.
-
Ah! But there's the kicker: They don't want a button that ignores remediation totally, they want the part 2 agent to individually acknowledge each failed question as fixed,
Pretty sure this is the first time in the thread that we've learned this little detail. (That the problem applies to individual fields, not just the form in general.)
This whole thing doesn't make sense from most viewpoints, and that's more likely the reason nobody can understand it well without pages and days of explanation and re-explanation.
I don't get why you don't call up the client and suggest just removing remediation entirely. It seems like that's what they want (or: the thing that they want will inevitably turn into that as soon as the users figure out that you put the change in.)
-
I don't get why you don't call up the client and suggest just removing remediation entirely
Can't, on vacation.
. I'm sure once I get a demo working they'll turn around, but for now there's nothing I can do but try and get it done.Pretty sure this is the first time in the thread that we've learned this little detail. (That the problem applies to individual fields, not just the form in general.)
I guess my vague terminology is to blame. Here's a few quotes that should have clued in that this is individual fields we're talking about:Not quite. The idea is that they can check a box that indicates that they fixed the issue that caused the "needs remediation" rule to fail.
As an example, say I have a question, and it's a free-form text box asking for a number. If the number is above a given value (say, 50), it's still a valid entry, but requires remediation. Therefore, there will be two rules:
- Is the input given a number? (If no, fail validation, prevent submission)
- Is the input given > 50? (If no, don't do anything, if yes, show a checkbox, submission can succeed so long as #1 is good)
So, if they put in 51 as the answer, it's Ok to submit, but they have the opportunity and option to check the box that says "I fixed this", which allows things further down the line to be skipped.If they put some gibberish, they couldn't submit it, and rule #2 wouldn't apply at all because #1 failed.
The apparent idea is to give the first answers the chance to be remediated before needing remediation by the remediation team. Essentially, it skips the bucket if they tick the box here.
it seems easiest to dynamically add in a checkbox element (or whatever) to the form next to the input whenever that particular answer gets an "unsatisfactory" value in it, so they can check it and move on.
I know it's stupid to expect a chronological reading, but that last one was in the OP (which wasn't all that long, and was the clincher sentence).Anyways, I'm dragging my feet on this particular aspect anyways, since it entails more work for a nearly worthless feature that will inevitably be abused.
-
Can't, on vacation.
.They are, or you are?
I'm sure once I get a demo working they'll turn around, but for now there's nothing I can do but try and get it done.
If you're SURE then just do a half-assed mockup.
-
They are, or you are?
They are
.If you're SURE then just do a half-assed mockup.
Would this count? (Not done by me, but censored by me)
They also wanted Yes/No answers to be changed to Pass/Fail, but I'm also almost sure they will back out on that as well.
-
I don't get why you don't call up the client and suggest just removing remediation entirely. It seems like that's what they want (or: the thing that they want will inevitably turn into that as soon as the users figure out that you put the change in.)
Sure, that's what everybody wants. Not every mess needs to go through to the department in charge of wiping asses. I don't get why everybody here is so against this.
But according to the picture above, this form is being filled out by the team in the middle column about the performance of the team in the left column, so I dont see what their incentive is not to pass the buck on to the team in the right column any time there's any doubt.
