New calendar picker format prone to user issues

[cusackjm]

The calendar picker in COV3 and COV27 looks different and I think this will be prone to user error. Previously looked like:

Now looks like:

I am able to click on the dashes and type in a month (although difficult for months that start with same letter) and year, but the way the question is worded and response is shown, one may not assume we are asking the month in the second dash section. For example, I typed in "M" and the "2" which brought me to March Year 2. A red error message range check popped up. When I clicked on the "2" it opened to year 2 and then I would have to scroll all the way to 2,023 to get to year 2023. Participants could select "clear" or "today", or type over "2", but I am not confident that all participants would be aware to do so.

Can we go back to the previous format, where the range check was not red font, and instead the range check involved greying out the date we didn't want participants to select, and they greyed out date was unable to be selected? This would prevent people from having to figure out how to scroll through the years.

[joshid-ims]

@cusackjm By previous format, you mean Month and Year?

This question may be for @danielruss if we need to keep the |month| function ("SRVCOV_COV3_MY_V2R0#prev","2020-03") and make changes in how it appears to resolve this.

[cusackjm]

@joshid-ims the previous calendar picker had the range check built into what could be selected, and did not allow you to type in a response. this calendar picker has a range check that occurs in red text after you can select an erroneous date, and allows you to type in the response

[joshid-ims]

@danielruss, can we do anything about this for the function we are using? For e.g. "SRVCOV_COV3_MY_V2R0#prev","2020-03"

[danielruss]

@cusackjm There are two date formats:

• <input type="month">, which picks a month and year, and
• <input type="date"> which selects a month, day, and year.

They will look slightly different in different browsers. In the example you showed, you said that you received your COVID vaccine in March 2CE (around the time of the Romans). This is before the COVID vaccine, so there is a validation error. You did not select March 2nd.

The menstrual question asks for a specific date. So you need the month, day, and year. Yes, they look different that is a browser issue.

[cusackjm]

haha yes I understand, but is there any way to prevent the participant from entering March 2 CE? My concern is that this population may not be intuitive enough to just re-type the date and instead try scrolling from year 2 to 2,023.

When we had the date formatted as a numeric text entry, we received feedback from multiple participants who stated that they couldnt finish the survey because they couldn't enter a response (they were attempting to type the month in characters, like January, rather than "1"). Based on that, I anticipate that people will manage to get stuck in early years.

[danielruss]

Can you specifically ask for the month and year of the covid shot (e.g. 1/2022)?

Of course you will want to say "your" instead of you. On chrome, if you type 1 in the month, you will get January.

I see the problem. Chrome and Firefox don't support the Month picker. They need to input the data as: 2022-01

[joshid-ims]

Just FYI - the function being used currently is like:

|month|id=SRVCOV_COV3_MY_V2R0 min=valueOrDefault("SRVCOV_COV3_MY_V2R0#prev","2020-03") max=#currentYear-#currentMonth|

[joshid-ims]

From what I remember vaguely, the change was made as it was not possible to enforce some restrictions on month and year for COVID. They should be after certain dates and same for vaccination. That is why we changed from MONTH and Year variables/functions to the function I mentioned above.

[cusackjm]

@danielruss It's fine to input the data instead as year-month.

@joshid-ims The calendar picker was in the previous covid survey for COV27, but not COV3. We changed to calendar because this allowed us to save the date as one response (and therefor include an error message), whereas the numeric text entry saved the response in 2 parts, month and year separately, so we couldnt include range check.

Is it possible to use the previous version of COV27 calendar? This had the month/year calendar and had the range check incorporated into the date selection, not as an error message

[joshid-ims]

This will be a change in Data dictionary as well, I guess. We will be adding new variables. Can we make this change in the text document please?

[cusackjm]

@woodruffr my understanding was that this was already changed in the DD and qx document?

[woodruffr]

The DD uses the Month Function. The Questionnaire asks for a Month and a Year in the same line but does not specify how it is to be coded.

If I understand this correctly, our options are to use a Date picker or the Month function. The third option of using individual text boxes didn't allow for the min/max values to be applied to dates. I'm a little confused when we talk of how it was handled. Are we comparing the current Month function to when it was done as two separate text boxes or something else?

[cusackjm]

@danielruss I met with Deepti, Rose, and Peter just now and confirmed that the markup code for COV3 and COV27 is formatted the same as COV27 in the Blood/Urine and Blood/Urine/Mtw surveys. Was there any QUEST code pushed that would change the way this question type would appear in the PWA?

When I had tested COV27 in the Blood/Urine and Blood/Urine/Mtw surveys (pre-removal of COVID questions), the range check was incorporated into the "month picker" (NOTE: I previously was referring to the month picker as calendar picker, and know now that they are different), i.e., Any month/year before March 2020 was greyed out and the participant was unable to select a month/year before that. Currently, the range check is outside of the month picker, so someone is able to select a date before March 2020 and a red error message tells the participant to select a month/year after March 2020. I expect this to be problematic for some participants, and am concerned they will get frustrated and stop the survey. Is it possible to use QUESt code to force the range check to be incorporated into the month picker?

[joshid-ims]

Both COV 3 and COV 27 had Month and Year functions. From version delivered on 09/29/2022 of Blood Urine Mouthwash survey:

[SRVBLU_COV3_V1R0!,displayif=greaterThanOrEqual(SRVBLU_COV2_V1R0,#loop)] When was the <b>{##}</b> time that you had COVID-19? If you are not sure, please make your best guess.

Month |__|__|id=SRVBLU_COV3_MONTH_V1R0 required=true min=1 max=12|
Year |__|__|__|__|id=SRVBLU_COV3_YEAR_V1R0 required=true min=2020 max=#currentYear|

[SRVBLU_COV27_V1R0?,displayif=greaterThanOrEqual(SRVBLU_COV26_V1R0,#loop)] When did you get vaccinated with your {##} shot? 

Month |__|__|id=SRVBLU_COV27_MONTH_V1R0 min=1 max=12|
Year |__|__|__|__|id=SRVBLU_COV27_YEAR_V1R0 min=2020 max=#currentYear|

Both have |month| function in current version.

[danielruss]

@cusackjm The issue we had with the example that @joshid-ims provided is that we (currently) cannot validate the month AND year data at the same time (e.g. if a person puts in 1/2020 as the date of first vaccination. We have to allow January, and we have to allow 2020, but not Jan 2020)

[cusackjm]

@joshid-ims what is the status of this?

[joshid-ims]

If I am not mistaken this change was done in Quest. So I do not think any code change is required at this time as the new version that will be delivered will have |month| function used for both COV3 and 27.

From: Julie Cusack @.> Sent: Monday, July 10, 2023 9:48 AM To: episphere/questionnaire @.> Cc: Joshi, Deepti (IMS) @.>; Mention @.> Subject: Re: [episphere/questionnaire] New calendar picker format prone to user issues (Issue #233)

@joshid-imshttps://github.com/joshid-ims what is the status of this?

— Reply to this email directly, view it on GitHubhttps://github.com/episphere/questionnaire/issues/233#issuecomment-1629006706, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APPZ4465I5YMXNYRIO5O5HLXPQBZRANCNFSM6AAAAAAZNY5EA4. You are receiving this because you were mentioned.Message ID: @.***>

---

Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.

[cusackjm]

confirmed fixed in dev testing 7/24/2023