Add checkboxes for various conditions/circumstances for children & families, in child & demographic surveys. about lookit-api HOT 12 CLOSED

May not reach while Kim on mat leave but if so: can start by implementing just collection/storage of info, rather than using it for eligibility.

from lookit-api.

@kimberscott Do you think you could post an initial list here? Once that's ready, I can get started on this pretty easily. I've also settled on what I think is a good approach for the analytics view (#134) so I'm happy to get started on that too!

from lookit-api.

Draft per-child list (running by researchers - feel free to comment here!)

• Autism Spectrum Disorder
• Asperger's Syndrome
• Down Syndrome
• Williams Syndrome
• Stroke
• Blind
• Visual Impairment
• Deaf
• Hearing Impairment
• Dyslexia
• Attention Deficit/Hyperactivity Disorder
• Learning Disability
• Generalized Anxiety Disorder
• Obsessive-Compulsive Disorder
• Panic Disorder
• Post-Traumatic Stress Disorder
• Social Phobia/Social Anxiety Disorder
• Depression
• Other Mood Disorder
• Allergies
• Fetal Alcohol Syndrome
• Epilepsy
• Diabetes
• Other Chronic Medical Condition
• Other Genetic Condition
• Gifted/advanced learning needs
• Adopted
• Multiple birth (twin, triplet, higher order)
• Has older sibling(s)
• Has younger sibling(s)

We also already ask:

• Birthdate (used for age-based inclusion criteria)
• Gestational age at birth in weeks (<=24 grouped together, >=40 grouped together, NA/not sure option)
• Sex (male, female, other, prefer not to answer - advice on inclusivity without being invasive here is also welcome, keeping in mind parents are answering for young children)
• Freeform notes about "anything else we should know"

Draft per-family list:

• Languages spoken in the home, from list of 64 most commonly spoken languages
• Number of children in the home and birthdates
• Number of parents/guardians in the home
• Country (+ state if US)
• Urban/rural/suburban
• Answering parent's approximate age + gender
• Educational attainment for parent + spouse/partner (if applicable)
• Approximate yearly family income
• Categories family identifies as, w/ checkboxes for White, Hispanic/Latino/Spanish origin, Black/African American, Asian, American Indian/Alaska Native, Middle Eastern/North African, Native Hawaiian/Other Pacific Islander, Another race/ethnicity/origin. (Taken from US census proposal after our earlier freeform question was hard to process)
• Approximate # of children's books in the home

from lookit-api.

So, three things:

1. I'm not sure where we'd want to put the per-family data. Should that be in the demographics section? Or should we make a new section called "family"?

2. I think we need to work first on distinguishing which of these proposed fields are binary (checkbox) vs. multiple choice (radio button/select) vs. quantifiable (number entry) fields. That will help me either select or create a new appropriate Field Type.

3. Do we have a clear rubric or set of decision criteria for how we are organizing child vs. family data? A child is part of a family, and yet we ask family questions that are replicated in the child update/create sections.

from lookit-api.

1/3. As discussed - we will hold off on family info (beyond what's already in the demographic form), and plan to eventually model that separately.

2. Almost all the new proposed fields are binary (discussed that multiple birth could be binary as we're just getting rough eligibility here & details would be up to researchers, also given rarity of triplets+)

from lookit-api.

Some thoughts on researcher interface: Effectively we want to let researchers select, for each characteristic, an answer or range of answers that are "ok" (meet inclusion criteria), with a default of allowing all answers. This will cover the vast majority of use cases, and the rest would be covered by eventually allowing unions of such participant group definitions. Here's a quick mockup of what the interface could look like. (Not sure if tri-state checkboxes are actually a good idea, but could have "all/yes/no" instead and do something similar.)

This is sort of like how Facebook ad audiences work:

Alternately, we could let people add criteria one at a time, selecting the thing they want to condition on, IS/IS NOT/IS ONE OF/etc., and a value(s), like this (BBEdit):

Let's just avoid something like this where it's impossible to parse what the actual search will be (Cambridge public library search interface):

from lookit-api.

For deployment at this point: let's just stick to a few where likelihood of using in the near future is relatively high, and wait for input from researchers/families before updating to a list intended to be more complete. Proposal:

• Autism spectrum disorder
• Deaf or hearing impairment
• Dyslexia
• Multiple birth (twin, triplet, etc.)

from lookit-api.

This looks beautiful! There's quite a bit of engineering here that's going to make future work easier, too. The view is very easy to find; I like the new distinction between "edit study" and "edit eligibility." A bunch of comments here most of which are just requests to add/change words rather than functionality :)

1. Questions/considerations:

• a) The new eligibility criteria don't seem to be monitored fields, i.e. once a study is approved the eligibility criteria can change. Is this the intended behavior? I think this is probably fine, and might be useful for when people are finishing up data collection and want to e.g. tighten the age range. We'll still have a chance to review initially (e.g. to point out that no, you probably don't want to require all languages / exclude on mild prematurity for a study with 5-year-olds / etc.)
• b) The slider is a bit hard to use to define an age range--in general this is something that will be done once and precisely, based on a researcher knowing exactly what age they want to specify, not something they might play around with. (E.g., try to specify exactly 1 year to 1 year 2 months. 1 year 0 months 0 days isn't something you can get to on the slider, and with a narrow age range the labels overlap.) But it's up top, so at least my interaction with this section was to try to specify using the slider, then give up and use the text entry fields (which are straightforward!) I recognize that the slider represents a bunch of work so that everything syncs up, and it is indeed very pretty :) But it might be easier to use this section (and maybe maintain the code?) with just the text entry fields. Thoughts?

2. To address, minor:

• a) On study eligibility view: Gestational Age -> Gestational Age at Birth
• b) Deaf or hearing impairment should be one checkbox (primarily because we don't have a way to have the eligibility criteria include an "or" yet, and the one study planning to use this would include both)
• c) Let's move over the help text for the min/max age fields in the study edit view to the age specification here, so it's clear to researchers that they are actually specifying an age range in days (correct?) with years/months conveniently representing 365 / 30 days respectively.
• d) On the participant-facing "add a child" form, minor wording changes: add help text under "Languages spoken" to say "Please check all languages this child is exposed to at home, school, or with another caregiver"; "Existing Conditions" -> "Characteristics and conditions" (we'll probably want help text later but not now indicating whether to check things that only applied in the past, that the parent suspects but has not gotten official confirmation of, etc.)
• e) Also on the child add/edit form, could we put the languages in alphabetical order? It's hard to find a given language without searching. (Also maybe put both forms of Arabic under "Arabic (...)")
• f) While we're editing the child add/edit form (scope creep sorry, but tiny!) could we add help-text for gestational age that says "Round down to the nearest whole number of weeks"
• g) If there's space in the language bitfield, could we add checkboxes for "another spoken language," ASL, and "another sign language"? Also can you remind me where the list of languages is from? Could we add Swahili, which has relatively few native speakers but many total? (It all looks reasonable; the only languages we've had reported organically that aren't on there are Armenian, Czech, & Azerbaijani, which are spoken by relatively few people: https://en.wikipedia.org/wiki/List_of_languages_by_total_number_of_speakers)

3. To address, possibly more involved:

• a) We should probably now use the actual eligibility criteria to warn participants about eligibility when they go to participate from the (participant-facing) study detail view. Right now just the min/max age are used to display a warning if appropriate.
• b) We should probably now display the actual eligibility criteria to participants on the study detail page in a format similar to the way it's shown in the summary at the top of the eligibility view, rather than leaving it up to researchers to provide a string that sums up the criteria. I would just omit any sections that don't have criteria - e.g., if there's nothing about gender, leave it out rather than saying doesn't matter. (Don't worry about optimizing display though; this will eventually be better addressed by #121) In the study overview page, with the grid of available studies, this could be pared down to an age range, probably just showing the first nonzero fields of the min & max ages - so e.g. 5 - 7 years, 8 - 10 months, 6 months - 3 years, 21 days - 3 months
• c) Min/max age are still defined separately on the study model; these are edited in the study edit view & displayed on the (researcher-facing) study detail view. The new values in the eligibility criteria should take precedence instead and these should be removed.

from lookit-api.

1a: It's undefined behavior :) now I'm wondering if we should add some language somewhere to warn researchers about this?

1b: The idea is to use the slider to get to a general idea of what you want, and then tweak with the direct input fields. The slider should also serve as a sanity check (no negative ranges, gives a meaningful representation of years vs months, etc.). In any case if you didn't spend more than a couple of seconds struggling with it I'm inclined to keep it. One option would be to disable the handles, so that only the input fields can change the slider length.

Minor changes incoming

from lookit-api.

1a: Hmm, that might be helpful. E.g. near "submit proposed changes" say "If your study has already been approved, changes to the eligibility criteria do not require review. Changes take effect immediately."

1b: Hmm, I just think that since people will in fact have an exact age range already determined, this is simpler as one step (rather than first getting the "rough" idea and then tweaking - esp. in case someone runs into one of the edge cases like not being able to select exactly 1 year as a start point). Disabling the handles sounds good since then it's clear where to enter info but the helpful visual is still there.

from lookit-api.

As for 2E, Maddie actually asked for English to be put first, and the rest is organized by # of speakers worldwide. TBH I think using the browser to search for a language is fine, that's what ⌘F is for.

Switching gears from that, I think we should revisit 2[B|G|F] and all of section 3 with a staged second phase of changes to the UX:
I. Deprecate the min/max age etc. fields in the Study model, do a data migration over to relevant EligibleParticipantQueryModel fields, and drop all references to the old fields elsewhere in the code.
II. Actually implement "soft" child validation (for studies) now; i.e. do the validation but merely provide a UI warning for ineligible children as we do now with min/max age on the Study model.

I am also investigating the feasibility of enabling filtering with Boolean Algebra, which would allow us to have complex criteria setting. TBD on that.

from lookit-api.

Just realized an empty criteria expression isn't allowed. That should be okay and should just be equivalent to 'true' - i.e. only use the age fields for eligibility, everyone 'passes' the empty criteria expression

from lookit-api.