Survey Aesthetics

[cassidysymons]

1. On new_participant.jinja2, there are two groups of changes:
   1a) Not all fields that are required were actually shown as required to the user - I standardized that
   1b) The asterisk for required fields was breaking onto a new line - I formatted it to be red and show up on the same line with cleaned-up visuals

2. On survey.jinja2:
   2a) I paginated the form by field group
   2b) Added buttons for Previous & Next Section
   2c) Added a progress bar to the top of the screen
   2d) Add a one-time confirm on submit since responses can't be edited
   2e) Made some font weight and size changes to decrease the wall-of-text effect

(note, depends on biocore/microsetta-private-api#315)

[wasade]

Thanks, @cassidysymons! Two general requests, can variables be declared for use relative to their scoping needs? And second, would it be possible to use strict equality (===) on conditionals?

[wasade]

From interactive review:

The confirm window unexpectedly shows only once. I selected "Submit survey", then clicked "cancel", and then reclicked "submit survey". The second "submit survey" click proceeded without the confirmation window.

Would it be possible to default the selection as Unspecified on the radio buttons and if easy, to do so for the dropdowns?

Any particular reason the alcohol levels have a pulldown but the other selections don't (see attached screenshot)?

[cassidysymons]

The confirm window unexpectedly shows only once. I selected "Submit survey", then clicked "cancel", and then reclicked "submit survey". The second "submit survey" click proceeded without the confirmation window.

That was an intentional decision to make it fairly unobtrusive - essentially, just a one-time "Hey, you can't edit this, do you want to go back and check it?" If you think it will be confusing to users, I can change it to continue showing up until the users hits OK.

Would it be possible to default the selection as Unspecified on the radio buttons and if easy, to do so for the dropdowns?

For some reason, the createDefaultObject function in VFG doesn't seem to actually populate default values. I see two options here:

1. Add a custom JavaScript function after the form is generated to walk through the form and choose the "Unspecified" option for any radio button and dropdown. My main concern is that if people see a question already answered, they might be less likely to change it, as there's a behavioral bias towards leaving default answers in place.
2. Eliminate the "Unspecified" option altogether since people have the implicit option to just not answer any given question. However, I'm unsure if this would be something that would require approval and/or introduce any sort of statistical issues in new surveys vs old surveys?

Any particular reason the alcohol levels have a pulldown but the other selections don't (see attached screenshot)?

That question has seven possible answers, so it falls just outside of the criteria for changing to a radio button. We can move that limit around however we want, choosing six was fairly arbitrary in that it seemed like a manageable number of options.

[wasade]

Thanks! For the confirmation window, that makes total sense, do you think it would be nice to note in the window this message will only appear once?

For Unspecified, I like option 2 except for the situation where a person selects a response and then decides they don't want to answer the question anymore. Is there a non terrible way to allow someone to unselect a radio button while also eliminating unspecified?

I agree with the behavior bias concern on 1.

Ah I see where the limit occurs now, thanks. Would it be possible to bump it +1? I think that gets the alcohol question and one other. It does wrap around on small form factor devices, but that's true at six too

[dhakim87]

Looks like a bunch of the spans use class="red right required-field", I'm guessing class red just sets color: red. Should we bundle the definition of right into here also, then we can just set class="required-field" everywhere and drop the red and right classes from all the spans?

[cassidysymons]

The "red" and "right" classes were already in the code but didn't appear to be doing anything. I added the required-field class to handle the aesthetic changes I was making, but left red and right in place in case there was some legacy reason for them that I was unaware of.

If there's no reason to keep them, I'd be happy to clean them all out and just keep required-field.

[dhakim87]

Ahh, so spans are required-field, divs are red right required-field? I think my question is can we drop the red class from the divs (assuming the right class does something else we want that isn't covered)?

[cassidysymons]

As far as I can tell, both the red and right classes can be dropped from the divs. Neither class is defined anywhere in the CSS and I don't see any JavaScript that uses them. If neither you nor @wasade know of any reasons to keep them, I can drop both and just leave required-field in place.

[dhakim87]

I'd say drop them then, if nothing shifts around or changes color, we're in the clear

[cassidysymons]

I just dropped all of the references to the red and right classes and standardized all of the asterisks to . I double-checked after the change and nothing was altered visually, either in color or positioning.

[wasade]

No preference on this

…

On Tue, Apr 27, 2021, 11:35 cassidysymons ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In microsetta_interface/templates/new_participant.jinja2 <#124 (comment)> : > @@ -118,6 +118,11 @@ width: 80%; margin: 0 auto; } + +.required-field { As far as I can tell, both the red and right classes can be dropped from the divs. Neither class is defined anywhere in the CSS and I don't see any JavaScript that uses them. If neither you nor @wasade <https://github.com/wasade> know of any reasons to keep them, I can drop both and just leave required-field in place. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#124 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADTZMRV6A23G5DJ5JGDZVDTK37XLANCNFSM43VHC7KQ> .

[dhakim87]

This is a great change, the pagination code is very clear and the css changes on the vue elements look good as well.

[dhakim87]

My understanding is that this catches labels in groups of radio buttons, should similar style be set for groups of checkboxes?

(See Do you eat a specialized diet ? (select all that apply), Step 2 of 7 in the Microsetta Participant Survey)

Rough guess on the css selector is:
.vue-form-generator .field-checklist .dropList .list-row label

Could be a separate change entirely though.

[cassidysymons]

Are you thinking you'd want to have the checkbox options span the entire width of the screen (similar to radio buttons), rather than in a one-per-line dropdown?

[wasade]

@dhakim87 is this a blocking item or can this be sorted out later?

[cassidysymons]

I updated the variable scoping and switched to strict equality conditionals - let me know if I missed anything on either of those fronts.

I also added a line to the confirmation box saying that it will only appear once.

As far as the Unspecified side of things, there's really no simple way to deselect a radio button once the user has selected it. It's possible to do via JavaScript, so we could theoretically add a button to each field to clear selections, but that's neither cleaner for the user, nor from the standpoint of code maintinability.

I can definitely see the issue in users not having a way to deselect a field after answering, whether due to erroneously clicking or deciding they prefer not to answer. Let me think about this topic a bit and circle back to it later, I feel like there's some sort of middle ground in making the "Unspecified" option both more useful and more graceful but I'm not seeing it at the moment.

[wasade]

Thanks, @cassidysymons!! Sounds good on the unspecified item -- let's table it for now. I'll re-review this evening

[wasade]

I'm +1, will merge after hearing on the open comment with @dhakim87