PIQuqest data servlet

[baranan]

[If we have a backend repository, we could relocate this issue to that repository] This was from Elad: The PIQuest is ready for a proper backside. As far as I could understand from our discussion we decided to keep to the existing questionnaire tables. PIQuest POSTs pure json arrays. Each object within the array has the following properties:

name: (String) The question identifier (it is possible for names to not be unique - although it is discouraged) latency: (String) The time from page load to the last time this question was changed. pristineLatency: (String) The time from page load to the last[probably meant first] time this question was changed. response: (String/Array) The answer given by the user. Currently can be either a String/Number or an array of String/Number. startTime: (String) UNIX time for page load.

[baranan]

This was Andy: What, if any, of the PIQuest data should be saved to the session? Currently with other questionnaires all responses are saved. Do we want to continue with that?

[baranan]

I think that each unit described by Elad should be saved by the servlet. The most important row pertains to the actual response value: name to question_name, response to question_response

I assume you could infer question_number and questionnaire_name without getting the explicit information from PIQuest. @andrewdzik, is that correct?

For latency, I now see that it is a bit complicated and we need to make a few decisions. With the jsp questionnaires we had two additional rows for each question: One row had question_name = (name + 'rt') and question_response = latency from the time the question was shown to time the participant submitted the response (in PIQ's terms, this is the time from the loading of the page until its submission). Another row had question_name = (name + 'trt') and question_response = latency from the time the whole questionnaire started until the participant submitted the response.

I think that that these two values cannot be computed from what Elad planned to send. This could be fixed easily for questionnaires that do not allow going back: submitLatency: (String) The time from when the page was last loaded until the response was last submitted (i.e., when it was clicked away). questionnaireStartTime : (String) UNIX time for current questionnaire load.

I think that submitLatency will be identical to the 'rt' used today. So, the servlet will save these rows: question_name = (name + 'rt'), question_response = submitLatency. question_name = (name + 'trt'), question_response = submitLatency + (pageStartTime-questionnaireStart).

When we allow going back, it gets more complicated. Let's say I submit a response, but a minute later I go back and change it. What is the latency we want to save? And, if I submit a response, a minute later I go back and don't change the response. Perhaps we would like to know that in case it means that the participant took her time until deciding that her response is fine. As a researcher, I would say that this kind of information is too complicated for me to analyze, unless I have a very specific hypothesis about such cases. For all these, perhaps PIQ should also send: lastSeenTime: (String) UNIX time for the last time the participant saw her response. For now, the servlet will ignore that.

[andrewdzik]

Assuming that it makes sure that all data posts are finished before going on to the next task then things like task id don't need to be explicitly sent. Note that currently with the jsp questionnaire, every item in a question raises the number by 1, so if you have the response, the reaction time, and the time from start, the question number will go up by 3 for each question. Every item probably has to have a unique question number, so this will continue unless we change the DB.

Also, is the data just being submitted at the end, or pulsed? If people can change the answers to questions that have already been saved to the DB, that will make things a little bit more complicated.

On Sat, Aug 2, 2014 at 12:35 AM, baranan notifications@github.com wrote:

I think that each unit described by Elad should be saved by the servlet. The most important row pertains to the actual response value: name to question_name, response to question_response

I assume you could infer question_number and questionnaire_name without getting the explicit information from PIQuest. @andrewdzik https://github.com/andrewdzik, is that correct?

For latency, I now see that it is a bit complicated and we need to make a few decisions. With the jsp questionnaires we had two additional rows for each question: One row had question_name = (name + 'rt') and question_response = latency from the time the question was shown to time the participant submitted the response (in PIQ's terms, this is the time from the loading of the page until its submission). Another row had question_name = (name + 'trt') and question_response = latency from the time the whole questionnaire started until the participant submitted the response.

I think that that these two values cannot be computed from what Elad planned to send. This could be fixed easily for questionnaires that do not allow going back: submitLatency: (String) The time from when the page was last loaded until the response was last submitted (i.e., when it was clicked away). questionnaireStartTime : (String) UNIX time for current questionnaire load.

I think that submitLatency will be identical to the 'rt' used today. So, the servlet will save these rows: question_name = (name + 'rt'), question_response = submitLatency. question_name = (name + 'trt'), question_response = submitLatency + (pageStartTime-questionnaireStart).

When we allow going back, it gets more complicated. Let's say I submit a response, but a minute later I go back and change it. What is the latency we want to save? And, if I submit a response, a minute later I go back and don't change the response. Perhaps we would like to know that in case it means that the participant took her time until deciding that her response is fine. As a researcher, I would say that this kind of information is too complicated for me to analyze, unless I have a very specific hypothesis about such cases. For all these, perhaps PIQ should also send: lastSeenTime: (String) UNIX time for the last time the participant saw her response. For now, the servlet will ignore that.

— Reply to this email directly or view it on GitHub https://github.com/ProjectImplicit/Servlets/issues/1#issuecomment-50953744 .

[andrewdzik]

Any thoughts on this? I'd like to make sure I know exactly what to expect before I write the data servlet.

On Sun, Aug 3, 2014 at 12:43 PM, Andrew Dzik andy.dzik@gmail.com wrote:

Assuming that it makes sure that all data posts are finished before going on to the next task then things like task id don't need to be explicitly sent. Note that currently with the jsp questionnaire, every item in a question raises the number by 1, so if you have the response, the reaction time, and the time from start, the question number will go up by 3 for each question. Every item probably has to have a unique question number, so this will continue unless we change the DB.

Also, is the data just being submitted at the end, or pulsed? If people can change the answers to questions that have already been saved to the DB, that will make things a little bit more complicated.

On Sat, Aug 2, 2014 at 12:35 AM, baranan notifications@github.com wrote:

I think that each unit described by Elad should be saved by the servlet. The most important row pertains to the actual response value: name to question_name, response to question_response

I assume you could infer question_number and questionnaire_name without getting the explicit information from PIQuest. @andrewdzik https://github.com/andrewdzik, is that correct?

For latency, I now see that it is a bit complicated and we need to make a few decisions. With the jsp questionnaires we had two additional rows for each question: One row had question_name = (name + 'rt') and question_response = latency from the time the question was shown to time the participant submitted the response (in PIQ's terms, this is the time from the loading of the page until its submission). Another row had question_name = (name + 'trt') and question_response = latency from the time the whole questionnaire started until the participant submitted the response.

I think that that these two values cannot be computed from what Elad planned to send. This could be fixed easily for questionnaires that do not allow going back: submitLatency: (String) The time from when the page was last loaded until the response was last submitted (i.e., when it was clicked away). questionnaireStartTime : (String) UNIX time for current questionnaire load.

I think that submitLatency will be identical to the 'rt' used today. So, the servlet will save these rows: question_name = (name + 'rt'), question_response = submitLatency. question_name = (name + 'trt'), question_response = submitLatency + (pageStartTime-questionnaireStart).

When we allow going back, it gets more complicated. Let's say I submit a response, but a minute later I go back and change it. What is the latency we want to save? And, if I submit a response, a minute later I go back and don't change the response. Perhaps we would like to know that in case it means that the participant took her time until deciding that her response is fine. As a researcher, I would say that this kind of information is too complicated for me to analyze, unless I have a very specific hypothesis about such cases. For all these, perhaps PIQ should also send: lastSeenTime: (String) UNIX time for the last time the participant saw her response. For now, the servlet will ignore that.

— Reply to this email directly or view it on GitHub https://github.com/ProjectImplicit/Servlets/issues/1#issuecomment-50953744 .

[baranan]

After an email discussion about this issue with UVA Core, I think that this is what we agreed upon:

1. There will be two rows per question: Row1: will store the question_name in the field question_name and the response in the field question_response. Row2: will store the question_name+'rt' in the question_name field and the latency in the question_response field. The latency will the time from when the question was first presented, until the response was last submitted. Obviously, when the researcher allows going back in the questionnaire, she should probably not rely on the latency for anything.
2. Both rows will use the same question_number - @andrewdzik will make sure that it will be allowed in the explicit table.

Open questions:

• Which component will compute the question_number? @eladzlot, PIQ?
• We need to decide what happens if a response is sent and then the user goes back and changes the response.

[eladzlot]

Regarding the open questions:

• PIquest has a question number feature, it gives each question a unique number by the order of their appearance. The numbers are sequential and start at 0.
• The current behaviour, and I believe best practice, is that the question is not re-sent. We decided that it is best that by default question are only logged at the end of the task, and if users want them to be logged real time (so that we can pulse the responses), it will be their responsibility to make sure that a question cannot be "re-accessed" after being logged. It is possible to activate DEBUG mode that warns you if a question is re-accessed.