We need a creative solution for this because it only affects Citronade.

If I remove the input-error class, then in Citronade, no validation messages will ever appear. Try the ls2_validation_tests.lss survey (in /docs/demosurveys) to see the normal behavior in the default template. Citronade is the only packaged template that includes input-error. Can it's css be adjusted to not show red if there is no embedded content?

Alternatively, input-error may be obsolete at the div level. The dynamic validations set the font color for errors to red (or green if it is OK). We could consider having a class that specifies the color of the <span> the contains the validation messages. Currently, the validation messages are put into a <span class="questionhelp"> block.

It affect all survey who use input-error, and it's a misconception : if the input aren't in error, then it don't have input-eror class ( maybe an input-ok if you want).

If you remove input-error class, it's a regression, i see survey with input-error put the border red for question block.

For validation block red/green : it's a very bad idea ti put inline style. It's best to use a class="error" class="ok"

I think best is to add a class to question block and the helptext.

A quick modification: LimeExpressionManager line 4869 and next
$jsParts[] = "\n if(" . $validationJS . "){\n";
$jsParts[] = " $('#" . $_veq['subqValidSelector'] . "').removeClass('error');\n";
$jsParts[] = " }\n else {\n";
$jsParts[] = " $('#" . $_veq['subqValidSelector'] . "').addClass('error');\n";
$jsParts[] = " }\n";
For example.

ANd in LimeExpression manager, we have the question id, the we can put:
$jsParts[] = " $('#question" . $arg['qid']."').removeClass('input-error');\n";
$jsParts[] = " $('#question" . $arg['qid']."').addClass('input-error');\n";
etc , according for what you want.

For another example: line 4899:
case 'U':
$jsParts[] = " $('#question" . $arg['qid'] . "').addClass('input-error');\n";

Then the user can choose to put input in background:red, or another alert system.

I think it's very important.

I can make a patch for LimeExpressionManager to remove all inline style and put it in class, after it's the template who choose

Shnoulle - in my haste, I didn't see the addClass/removeClass options - that makes it easy. I'm doing some other fixes, so I can patch and test this. Thanks for the offer, though.

No prob Tom,

I use jquery a lot !

A good think too is : .closest

For example: i work on a empty class:
$('input.text').blur(function(){
if ($(this).val()==""){$(this).closest('.question').addClass('empty);}
else{$(this).closest('.question').removeClass('empty);}
}

I have to put .question on all question class AND on subquestion. ( and a lot more).

See: http://bugs.limesurvey.org/view.php?id=4984

I think we can remove a lot of line and complexification on LSExpression_manager.js.

What do you think of put function in em_javascript.js, and in LimeExpressionManager.php : only call the em_javascript function ( with question id ).

I think we can remove too the : onclick="cancelBubbleThis(event);limitmaxansw_xxx(this);noop_checkconditions(this.value, this.name, this.type)"

And put in external js file.

$('input.cbox,input.radio').click(function(){
if (test on class){

}
noop_checkconditions($(this).val(), $(this).('attr','name'), $(this).('attr','type'))"
}

But there are a lot of thing to verify ...

Denis
( with jquery : you can do all with class and id)

onclick="cancelBubbleThis(event);limitmaxansw_xxx(this);noop_checkconditions(this.value, this.name, this.type)

That is already gone, or should be. The only thing that still does some of that in-line JavaScript in qanda is the Ranking question type. All the rest use EM to manage validation.

All of the noop_checkconditions vs. checkconditions stuff doesn't apply anymore - EM is called with every onchange event.

So, I'm not sure which sort of complexity within em_javascript.js you feel needs to be refactored (or are you referring to refactoring qanda.php further)?

Sorry,

Not em_javascript.js , just remove some inline javascript, put function call and not direct call LimeExpressionManager.php.

for a quick example:
case 'U':
callTextError($arg['qid'],true) // To put an input error class
And
callTextError($arg['qid'],false) // To remove an input error class

Then refactoring all Text error javascript is easy (and can be made in template.js too ;))

I think there are a possible way:
callError($qid,$sqid,$type,...)

( and please : remove that < br /> and < b >, for br : put a display block on span, and b: < strong > )

Denis

Denis

Denis-

I'm still not following completely. Are you suggesting removing in-line jQuery calls from LimeExpressionManager and instead having it call functions?

Perhaps if you created a small patch file showing what you recommend for one question type?

I like the idea of using styles, but I think we need to increase the granularity of our styles. I'm feeling very limited by just .input-error

So, how about something like this?

(1) Index:
(a) #index .has_missing_mandatory // at least one mandatory not answered
(b) #index .has_unanswered_question // at least one question not answered
(c) #index .has_incompletely_answered_question // partially answered array
(d) #index .has_invalid_answer // fails any validation test

(2) Question Validation
Should we have separate styles for each type of validation?
(a) .missing_mandatory // mandatory, but not answered
(b) .incompletely_answered // not mandatory, but some array options not answered
(c) .wrong_num_answers // too many or too few
(d) .wrong_value_range // single cell value too high or low
(e) .wrong_sum_range // sum of values too high or low
(f) .wrong_regex_validation // wrong syntax based upon regex validation
(g) .wrong_q_fn_validation // fails em_validation_q equation
(h) .wrong_sq_fn_validation // fails em_validation_sq equation

Those classes could apply to the whole question. That would give authors the ability to selectively format the different types of validation messages

(3) Question Tips
Also, we'd probably want different styles for the different types of tips:
(a) .mandatory_tip // like "please answer this question", or "answer all parts"
(b) .num_answers_tip // for min/max number of answers
(c) .value_range_tip // for min/max values for each cell
(d) .sum_range_tip // for min/max/equals sum
(e) .regex_validation_tip // for the preg validation
(f) .q_fn_validation_tip // for em_validation_q_tip
(g) .sq_fn_validation_tip // for em_validation_sq_tip

We've had some people say they don't want to see the regular expression validation messages - this might be a way to give them more control over that.

We could use the .good and .problem or .error (I'm not clear on how problem and error differ) to color code the question tips.

However, at present, EM just ANDS together all of the validation equations. So it can validate the whole question, but not selectively report on which parts of the validation pass/fail. If we want/need to do that, we'd need to refactor EM a bit. That wouldn't be too hard, but might take a couple of days.

Like you:
"but I think we need to increase the granularity of our styles." !!
And you're right : input-error aren't a great choice, maybe .question-error or answers-error ? (because there are already error class but only for tips, to be more compatible with personnal template)

I think double/triple class is the best:
There are only IE5.5 on MacOS9 who don't find double class, and i think IE5.5 on mac are dead .... ( maybe some IE4 or Netscape3 too).

I use hyphen on css class name : look at http://stackoverflow.com/questions/1686337/hyphens-or-underscores-in-css-and-html-identifiers for some reason
( javascript better accessibility && _ : not in php && already in pseudo-class )
Example:

(1) Index:
(a) #index .index-error .has-missing-mandatory
(b) #index .has-unanswered-question
(c) #index .has_incompletely-answered-question
(d) #index .index-error .has-invalid-answer
(e) #index .all-answered-question

(2) Question Validation:
(a) .answers-error .validation-error .missing-mandatory
(b) .answers-error .validation-error .incompletely-answered
(c) .answers-error .validation-error .wrong_num-answers
(d) .answers-error .validation-error .wrong_value_range
(e) .answers-error .validation-error .wrong_sum_range
(f) .answers-error .validation-error .wrong_regex_validation
(g) .answers-error .validation-error .wrong_q_fn_validation
(h) .answers-error .validation-error .wrong_sq_fn_validation

(3) Question Tips
.tip .error .adapted-class-for-error

I look to put a patch but, i go to see my mother this week end , then not until monday.
I think we can't remove jquery inline completely, but yes, put maximum script in external js file ( there are 2 reason : easiest to change the code, and speed up the load of the page: js file are put in navigator cache ( see best practice : http://developer.yahoo.com/performance/rules.html#external )

Denis :)

Oups, something more: i look to put
.question-block on each subquestion block and mon-question block.

Although, personally I prefer camel case for visibility, ease of typing and cutting/pasting (just a double-click in most tools), I guess hyphens would be more consistent with the current styles.

TMSWhite, when the final decisions are made on the classes, if you give a list of all of the new classes with their current inline styles, I would be happy to add the rules for the new classes to the shipped templates.

There was related discussion on the listseve about this. I'm copying them as notes below for easier tracking.

[[From Menno Dekker]]

Didn't dive in deep, but I would prefer something like
<div class="errormessages>
<div class="mandatory-msg">Please answer</div>
<div class="wrong-sum-range-msg">Sum must be xx</div>
</div>

This way it is easy to use one style for all error messages and style the ones you want different. I don't see why people would want to hide a validation message but it can be done this way.

So when there are errors, display all the messages in one container and have each message get it's own class, much like the question type classes. The question should get one class to show it is in error or not. The message should tell what kind of error. Ofcourse as much backward compatible as possible to help people who created custom templates.

[[From Shnoulle]]

Hello, then maybe something like that:
For a mandatory question ansered but wher wrong sum range:

<div class="answers-error">
<span class="validation-ok mandatory-msg">You must answer</span>
<span class="validation-error sum-range-msg sum-range-msg-error">Sum must be xx</span>
</div>

The best semantic way can be:
<ul class="validation-message">
<li class="validation-ok mandatory-msg">Please answer</li>
<li class="validation-error sum-range-msg sum-range-msg-error">Sum must be xx</li>
</ul>
Because it's a list of validation message, but we don't have allway a list of message ;) and have only one.

[[From TMSWhite]]

I neglected to communicate a critical piece of this discussion. Unlike in 1.91, in 1.92, there is only one copy of each message. They are meant to serve as tips and/or validation. In 1.91, tips and validation messages were separate (so different wording) and managed separately.

I don't want to have tips that say one thing, and then repeat the same messages if the validations fail. I'd rather give people the ability to show/hide the tips, and color-code (or otherwise stylize) the validation messages if they are a problem.

So, if although we could put all of the messages in a <div class="tip">, we should not encapsulate them all in a <div class="answers-error"> or <div class="errormessages">, otherwise the tips might never be shown.

Furthermore, if we were to encapsulate them all in a <div class="tip">, we need to override the "hide-tip" behavior. I'd like to give users the ability to initially hide the tips, but force them to be visible if the validation messages fail.

Given this, how would you suggest supporting both the tip and validation aspects of these messages?

[[From tpartner]]

But, aren’t the tips and error/validation messages really two different animals? And therefore should be handled differently?

In my mind, the tips should be to simply offer help on how to complete the question and be shown at all times unless explicitly disabled by the admin.

Error/validation messages should only appear when the question is answered inappropriately and the admin should really only have control over their appearance via the template files.

Can you use .append() and .remove() to add or remove the error/validation messages in a container div depending on how the question is answered?

[[From TMSWhite]]

Tony (and other developers)-

I agree that it should be possible to manage them separately, but isn't the text always the same?

Here are some sample messages (but putting the question attribute in curly braces for readability):

(1) num_answers: "Please answer between {min_answers} and {max_answers} questions."
(2) num_value_range: "Please enter values between {min_num_value_n} and {max_num_value_n}."
(3) sum_value_range: "The sum of the answers must be between {min_num_value} and {max_num_value}."

You could have exactly the same text in the following locations:
(1) Tip - to optionally show the user the validation rules before they try answering the question.
(2) Validation - to always show the rules if they fail the validation criteria; and optionally color code the text to indicate whether they pass (e.g. green) or fail (e.g. red) the validation (similar to what is done in 1.91 with min/max_value for sums
(3) Printable Survey - this would be the message on the printed page saying how to answer the question (is this the same as Tip?)
(4) Data Entry - to optionally show the validation rules when people are doing data entry - since eventually (not at the moment), data entry should be validated the same as everything else so that errors can be identified and fixed.
(5) Edit submitted responses.

So, my questions are:
(1) Do you agree that we can use the same text in all 5 of those locations? If not, why not (and what would you recommend instead)?
(2) Do you agree with my strategy of completely eliminating pop-up validation messages? Personally, they drive me crazy and it is hard to figure out which question on a long page needs to be fixed. I'd rather do real-time validation (which is now being done) and somehow show the users that the question is valid or invalid (e.g. the way I do in the 1.92 RC demos - via changing the text of the validation messages to green or red - but classes could certainly be used instead).
(3) Regardless of whether you agree that the validation and tip messages should be the same, would we really ever want to show both an always-visible tip and the (potentially identical) validation messages on the same question? Wouldn't it make more sense to use classes to stylize the validation criteria when needed?

Thoughts?

[[From tpartner]]

Yeah, or maybe use divs so they would be displayed block by default (as list items are) and could be given padding, etc.

<div class="answer-errors">
<div class="validation-ok mandatory-msg">You must answer</div>
<div class="validation-error sum-range-msg sum-range-msg-error">Sum must be xx</div>
</div>

[[From Menno Dekker]]

I think there are two categories: validation error and tip. The tip would be for options 1, 3, 4 and 5 as they tell you what to do. The could be disabled on screen or data entry as validation should enforce it, but in print it is the only thing you have.

I think the validation error is a different message. Example:
tip: upload between 2 and 5 files
validation: upload 1 more file

It all depends on the validator and type of validation what the exact error message is. So I would show them both. I agree on the popups, but I am not sure that it is clear enough when you hit next and get returned to the same page that it is because there is an error. You would have to be pointed to the right question then that could be off the visible part of the screen for large surveys / groups. So I would say only 1 popup on next that says there are errors bot no more than one popup. Nice would be if that dialog could tell all questions and the error message, but that would be optional for me if they can be properly highlighted.

[[From tpartner]]
I agree with Menno. I think the tips and errors should have distinct wording:

· Tips

o (1) "Please answer between {min_answers} and {max_answers} questions."

o (2) "Please enter values between {min_num_value_n} and {max_num_value_n}."

o (3) "Please enter values so the sum of the answers is be between {min_num_value} and {max_num_value}."

· Errors

o (1) "You must answer between {min_answers} and {max_answers} questions."

o (2) "The values must be between {min_num_value_n} and {max_num_value_n}."

o (3) "The sum of the answers must be between {min_num_value} and {max_num_value}."

I also agree with both of you that alerts can be just plain nasty but perhaps Menno’s idea of one alert to indicate a problem is valid.

I don’t really see a problem with showing tips and error messages together. Presumably the error message is bold/red/in-your-face where the tip should blend with the question more.

[[From Holger]]

It would be great, if popups could be optional. I really don't like those Javascript-Popups. I'd rather prefer the error message on the page, just below the question, as a reload will bring you there anyway.

[[From Shnoulle]]

javascript alert function can be replaced with your own function easily.

For confirm function it's more difficult, need to put directly own
confirm function.

For alert:
put this in your template file:

// Replace common alert with jquery-ui dialog
// Uncomment this part to test this function
function alert(text) {
var $dialog = $('<div></div>')
.html(text)
.dialog({
title: 'Alert',
buttons: { "Ok": function() { $(this).dialog("close"); } },
modal: false
});

$dialog.dialog('open');
}

It's the speedy way :). There are problem with title and OK for non
english langage, replace it with own langage, but onky for mono-langage
survey.

[[Transcript of discussion on 1/27/2011]]

[18:34] <TMSWhite> main question is whether this needs to be fixed before releasing 1.92stable
[18:34] <TMSWhite> secondary question is how you want the community to weigh-in on such changes in style options
[18:38] <c_schmitz> something is still weired
[18:38] <c_schmitz> I am using _dev
[18:38] <c_schmitz> and imported the LS2 Validation Samples survey
[18:39] <c_schmitz> I activate it, start it and submit the first question page without filling anything
[18:40] <c_schmitz> on the second page the 'Multi-Flex 1-10' question is marked red
[18:41] <c_schmitz> because I did not fill anything, which is weird because I see the page for the first time and the question is not mandatory anyway
[18:41] <c_schmitz> It also says 'Please select between and answer(s)
[18:41] <c_schmitz> Each answer must be between 0 and 0'
[18:41] <c_schmitz> weird
[18:42] <TMSWhite> if you look at the logic file, you'll see that the min/max answers and min/max values are set on the first page
[18:42] <c_schmitz> yeah, but why showing this in red eventhough I have not submitted the page yet
[18:43] <TMSWhite> That's related to another issue discussed on bug 5698 - EM validates everything with every onchange event
[18:43] <TMSWhite> ideally, it should only validate questions after you have visited them (so when the focus is on a later question)
[18:44] <TMSWhite> That sounds like a good idea, but would require some augmentations to the logic to only change the validation colors if focus is after the current question
[18:45] <TMSWhite> well - really, any time focus has passed the current question - validation should not disappear just because focus changes to an earlier question
[18:45] <c_schmitz> I don't think that is a good idea, maybe it is just a matter of presentation/CSS - I would not expect anything to be red that is not mandatory, just because it is not mandatory
[18:45] <TMSWhite> but ultimately, the issue is whether that should be handled by changes to EM logic, CSS, or both
[18:46] <TMSWhite> ah - the red there shows that the entry fails the validation tests, not that it is mandatory
[18:46] <TMSWhite> thus, perhaps pink would be better
[18:46] <TMSWhite> or a CSS class that would let people style it as they see fit
[18:47] <TMSWhite> try some of the validation tests on the next page - like entering bad email addresses or phone numbers - that changes the background color of the cell
[18:47] <c_schmitz> definately something with a CSS class
[18:47] <c_schmitz> adding color:red directly is like hardcoding
[18:48] <TMSWhite> I know, thus the discussion about classes
[18:48] <c_schmitz> yeah
[18:48] <TMSWhite> so, should we put this on the agenda for Tuesday vs. create a wiki of style ideas and vote vs. other?
[18:49] <TMSWhite> Also, do you want the community to weigh in on this (e.g. via Forum) or keep this among the developers for now?
[18:49] <TMSWhite> From our discussion so far, sounds like this is a show-stopper that must be fixed before stable release.
[18:50] <c_schmitz> validating everyhing on onchange is fine, I guess
[18:50] <c_schmitz> no, keep this among devs
[18:51] <TMSWhite> (the benefit of validating on change is that it ensures that cascading validation works properly)
[18:51] <c_schmitz> yes
[18:51] <TMSWhite> But, keeping the style changes related to validation from annoying users would be nice.
[18:55] <c_schmitz> I think we need to make a difference between 'on the fly validation' and 'submit error'
[18:55] <c_schmitz> the on the fly validation should be more subtle
[18:55] <TMSWhite> I presume that could be done via CSS classes?
[18:55] <c_schmitz> but if on submit responses are no properly filled out the hint should get bright
[18:56] <c_schmitz> yes
[18:56] <TMSWhite> good segue ... should we have same text for tip and validation messages?
[18:57] <TMSWhite> like this: http://bugs.limesurvey.org/view.php?id=5698#c17027
[18:57] <TMSWhite> or like that
[18:58] <c_schmitz> Looks good, but I think only one of them should be shown at a time. Tips during validation while filling out. Errors after page submit
[18:59] <c_schmitz> the 'tip' form is just more polite
[18:59] <TMSWhite> sounds like you're suggesting to keep the hint and validation messages the same, but the hint "should get bright" if it fails validation after submit
[18:59] <c_schmitz> yeah, or we are just being always polite, just insisting ,)
[18:59] <c_schmitz> less work for the translators
[19:00] <TMSWhite> yes, thought might make translators happier.
[19:00] <TMSWhite> what do you mean by "one at a time"?
[19:00] <TMSWhite> or do you mean don't show both tip and validation if they are essentially the same text?
[19:00] <c_schmitz> yes, the latter
[19:00] <TMSWhite> OK
[19:00] <c_schmitz> I think we should use the same text
[19:01] <c_schmitz> just different appearance
[19:01] <TMSWhite> So, what do you think for the more subtle way of on-the-fly validation errors?
[19:01] <c_schmitz> Keep the text and background in almost the same colors
[19:01] <TMSWhite> Also, I don't want a regression - in 1.91, you do use green and red to show the min/max sum value conditions are met
[19:01] <TMSWhite> for multiple-numeric questions
[19:01] <c_schmitz> but only for the sum
[19:02] <c_schmitz> let me check
[19:02] <TMSWhite> true - it just seemed like such a nice solution I tried to extend it.
[19:02] <c_schmitz> I think it was only for the sum value
[19:02] <c_schmitz> in general I think it is a great idea, will enhance usability
[19:03] <c_schmitz> I just felt like I did already something wrong when I saw the page for the first time ;)
[19:03] <c_schmitz> with all the red stuff ;)
[19:03] <TMSWhite> very good point
[19:03] <TMSWhite> I should at least put default values on the first page
[19:05] <TMSWhite> Since I can add a qseq attribute to questions, it should be possible to only conditionally change the validation class if the current focus has passed the gseq of the question being validated.
[19:05] <TMSWhite> that would avoid having things look invalid before you get to the question
[19:05] <c_schmitz> Yes, it is the usually not seen/not touched/not answered
[19:05] <c_schmitz> problem
[19:06] <TMSWhite> last question on this topic
[19:07] <TMSWhite> if you select hide_tip, and the question becomes invalid on-the-fly, should the tip be shown, or wait until submit and then show that the validation failed
[19:07] <TMSWhite> ... presumably we can also use a subtle styling to show it was invalid even if the tip was not shown
[19:08] <TMSWhite> personally, i'd get annoyed if I knew I hadn't passed the validation criteria, but didn't have more information on how to pass it (e.g. a tip)
[19:08] <c_schmitz> I guess the easier solution is only to show when validation failed, isn't it?
[19:08] <TMSWhite> which is why the default behavior is to have the tip appear if you fail validation critiera
[19:09] <c_schmitz> question is why people are using hide_tip in the first place
[19:09] <TMSWhite> right now it is easy to show the tip if the validation fails on-the-fly. I haven't tried to re-hide the tip if the validation passes
[19:09] <TMSWhite> I have some examples in the ls2_validation
[19:09] <TMSWhite> Such as age - the tip doesn't show initially, but if you enter a number < 0 or > 115, then it shows
[19:09] <TMSWhite> figure most people know to enter valid ages without being prompted
[19:10] <c_schmitz> Afaik most people use hide_tip because the questions are (all mandatory or all not mandatory) and simple
[19:10] <c_schmitz> so they don't want the same text repeated over and over
[19:10] <c_schmitz> I would only show it on submit error
[19:11] <TMSWhite> e.g. they don't want to see "Please answer this question" ad nauseum
[19:11] <TMSWhite> ?
[19:11] <c_schmitz> yeah
[19:12] <TMSWhite> hmm. Well, the new validation tips are always more detailed than just "please ansswer this question"
[19:12] <TMSWhite> do we really even need "please answer this question" anymore?
[19:14] <c_schmitz> Was it really 'Please answer this question?' - I think it was originally invented to make the participant aware that with certain question types he can select more than one answer option, like multiple choice question
[19:14] <TMSWhite> true, for multiple choice, it was "Please answer all parts of this question"
[19:14] <TMSWhite> array
[19:15] <c_schmitz> Tips for multiple choice questions seems to be missing
[19:15] <TMSWhite> and for multiple choice, it was "Please select as many answers as apply" or something like that
[19:15] <c_schmitz> The question '[M] All the other questions will filter on this one' does not show any tip
[19:15] <c_schmitz> eventhough it is multiple choice
[19:16] <TMSWhite> that might be an oversight on my part
[19:17] <c_schmitz> with single choice it is 'Please select one of the following answer options' or similar

[quote="Fred" post=73165]
I installed RC3 and the validation messages are appearing now. Thanks.

One minor thing is that the messages are using different CSS class ids. Using the example of the multi-numeric question where the amounts must not exceed 100:

When I run the question in 1.93 it shows both messages, but using different styles

<span class="questionhelp" id="442_vmsg">The sum must equal 100</span>
<div class="survey-question-answer"><p class="tip">Only numbers may be entered in these fields

In v. 1.91 both messages use the survey-question-answer style
[/quote]

For Fred,

I look to put
<div class="help-wrapper">
{QUESTION_MAN_MESSAGE}{QUESTION_VALID_MESSAGE}
<div class="tip help">{QUESTION_HELP}</div>
</div>

In question.pstpl and remove the border ... form template.css,

But i have a lot of problem with inline-style ;)

Fixed in revision 12285

1.92RC4 released