publiclab / wherewebreathe Goto Github PK

For the specific symptoms questions*, can they be combined to flow something like in the following image?

• from the Google Survey: https://docs.google.com/forms/d/1BvjKvH5dUFNjhhDdA4NNtsTHiXgurjJN3-c72mcrvFM/viewform

https://publiclab.org/wiki/wherewebreathe-planning

using EJS

Hi guys,

I've posted where I am at with development as of this morning to our (development server)[http://dev.wherewebreathe.org:3000/]

Please consider the questionnaire half-done (questions that are asked conditionally depending on the answers to other questions arent incorporated yet)

That said, you wont hurt my feelings by getting nit picky, so please feel free to create new issues about anything you think needs addressing or can be improved, even if it is a 'to do later' thing.

@jywarren @shapironick @novakn

Jeff raised the issue that having multiple entries from different family members might be cumbersome.

But making sure that individual bodies are explored in relation to a single space is very important in terms of thinking non-normatively about biological responses to chemicals (ie their are varying sensitivities and metabolic abilities across bodies) and important to get our epi straight so i'll just leave this flagged here.

The current preliminary wireframes look like this: http://publiclab.org/wiki/indoor-air-quality

And the dashboard in particular has a lot of different content on it.

C: The consent possibilities seems too busy

N: Another point on the interface: we will probably end up having a pretty large number of questions, so minimizing the number of "clicks per question" will be important so we less risk of people losing attention/battery power/free time before they complete the questionnaire. Does this make sense?

N/NS: wonder if the interface leans a bit towards the complex side of things and it might be confusing to the average user. Should be pretty easy to make the site a little less busy or have ways to have the interface opt into a more complex interface (maybe a question on their web usage could be a "throw away" early question and also the interface could be catered to their answer?). My guess is that the average user of this site will make 30-40 k less than the average PL user and will be 30-40 years older.

Just a very first stab at less content on that page might look something like this:

[@jywarren asked why 2 databases are necessary, one for application data, the other for user data]

That may just be a convention (for better or worse) that I picked up somewhere.

Im not finding much documentation online detailing the argument for or against separating the users collection into a new Mongo db, so maybe it isnt a thing people do? I do know that an extra connection uses a bit more juice.

What do you think? I did manage to get through the problem of creating multiple connections, but it shouldn’t be a problem to rework the code to use stick users in the WhereWeBreathe db.

Do you think I've taken the modularity too far?

Moving from #38:

Jeff: @shapironick, do we want to be able to say either "you answered this question x days ago" and "has your answer changed?"

Jeff: Can people go back and change their answers or reanswer them, or delete old answers? Those are three separate approaches, to be precise.

@shapironick: It would definitely be great to have a "have your answers changed?" or more specifically "have your symptoms changed?" because with time symptoms will
probably get worse, and having that data on the sequence of symptoms onset
reported in near real time would be amazing!

@jywarren: To simplify this, we could invite people to run through a whole question block periodically. I'm going to add to the database design issue to ask if we can have a "repeatable" value on each question, so that we don't re-ask things that won't change. @novakn - how often would some questions need to be re-asked? Can we choose a standard interval to avoid having to record periodicity for each question?

Actual implementation of re-asking questions can probably wait, i just want to know so we can plan for it, possibly in phase 2.

as discussed in #7 Potentially phase II

A repost of @novakn 's comment in #4
I can see your point about the repetitive survey questions--I am a little worried that distributing them throughout the survey could be confusing or could prime people to respond differently based on the other questions surrounding them. Another option (and I'm sorry if this is annoying since you have already made these questions) would be to ask about a few symptoms at a time (If you look at the Google survey you can see how they were divided into categories of 3 to 6 symptoms each-- fatigue/cognitive, respiratory, skin, other). We could ask the Yes(often), Yes(sometimes), No questions for one set of symptoms at a time, and then have a follow-up page that asks about their attribution to home environment only for the symptoms for which they said "Yes". Would this be ok? This is actually returning slightly to the format of the symptom survey ours is based on--I attached a screenshot.

@shapironick - was thinking it'd be nice to display a short paragraph of "welcome" text to orient new people. It could be displayed above the questions if people have answered <5 questions. What do you think? What might it say?

Huge amount of literature here: http://www.iaqscience.lbl.gov/ that I need to go through. It looks like git hub has stripped my hyperlinks but here is a start for the knowledge base. Can move it over to the wiki for the second pass.

General information on Domestic Indoor Air Quality
The average formaldehyde level in manufactured homes ranges from 15.5 ppb (CDC, PDF) to 36.3 ppb (California’s Office of Environmental Health and Hazard Assessment, PDF)—about four times higher than those of conventional homes.

The EPA's website on the indoor air quality of homes (Link).
The EPA's Toxicological Review on Formaldehyde Inhalation (Link).
For more information call the EPA Toxic Substance Control Act (TSCA) Assistance Line (202) 554-1404.

Studies on the Air Quality of FEMA Trailers
Centers for Disease Control and Prevention's Studied on FEMA trailers (Link).
The Agency for Toxic Substances and Disease Registry tests from 2007 (Link).
A pilot study on the health effects of FEMA trailers on children is underway (Link).

FEMA Trailer Sales Certificates
The conditions of sale and liabilities of the various models of FEMA trailer can be viewed in the following document acquired by way of the Freedom of Information Act (PDF). * I have the document and can email to developer later*

Advocates
Safer Chemicals Healthier Families (Link).
Blog by the Director of the Sierra Club Formaldehyde Campaign (Link).

Wireframes have complexity without narrativizing their data--narratives could make it "make it personally valuable for people to contribute."

And focused on relationships rather than questions or data:

Answers are means of relating generally rather than specific nodes that people can cluster around "I'd much prefer to have some sort of mode of engagement that is relationship building (e.g. showing me how my responses relate to other peoples'), and have other ways for free discussion, but not directly attached to my response.

Hi guys,

I've updated http://dev.wherewebreathe.org:3000/

Changes since sneak peak 1

• I've 'finished' the logic for the questionnaire. Not all of the questions are asked yet, and that will be one of the things that I will be working on next. Follow up questions based on the answers to other questions now work, and users are also now able to go back and answer questions they have skipped once they reach the end of the survey. Answers are also validated both on client and server side of things.
• Knowledge base page's copy test is now there and links an pdfs are now hooked up.

(I am a pretty terrible speller and typer, so it would be useful if you keep an extra eye out for spelling errors!)

Questions

• Is it safe to assume that we will go ahead with a narratives page in some form so that I can start work on that next week? Its one of the last high priority tasks for phase I left for me to do, so I'd like to start it as soon as possible.
• For year of trailer manufacture, it it safe to assume that we wont be getting answers prior to 1900?
• I've left zip code's input validation flexible to allow for international users to participate and added a "What is the country of your housing-unit" question. Is that what is wanted?

@jywarren @shapironick @novakn

We need to introduce the project on the front page, and display some data. How much and what kind of data can we show? @shapironick - to what degree do we want to share aggregate graphs or narratives with the broader, non-signed-up public? @novakn - can we mitigate what effect this might have on answers from people who later sign up to contribute?

So far, I am thinking along the lines of this for the database:

Thoughts?
@jywarren

(its easier to look at in something like gedit...)

Housing Unit
{
  _id: String, //HUD/VIN ** there was a mention of the existence of formatting notes. could those be linked to?
  make: String,
  model: String,
  dmfg: Date, //date of manufacture
  desc: String, // Description - "Which of the following describes this housing unit?"
  location: Object{
            city: String,
            state: String,
            zip: String
            }           
}

User
// have yet to approach login component in-depth. This part (value types?) could likely change when I get there.
{
  _id: Objectid, //so exported data is less able to be tied to individuals
  n: String, //user handle (unique)
  d: Date, //date joined (do we care? dont need this if use Objectid.getTimestamp())
  p: String, //password
  hId: String //housing unit id
}

Answers
{
  qId: Objectid, //references quesiton id
  set: String, //E.g. "housing-unit". To make the db more poeple-friendly, export-friendly, however this is redundant, and can be queried from qID... probably waste of server resources...
  uId: Objectid, //references the user id of the survey-taker. Maybe this shoule be obscured for export?
  d: Date, //date answered
  a: Object // answer. Is Object to accomodate questions that have more info. E.g. about symptom onset and abatement, etc. 
}

Questions
{
  _id: Objectid,
  order: Number, //order to ask questions, (can be edited later and not break links) 
  type: String, //  type of question to direct which html object to use E.g. "mc-drop" to use a drop down select 
  set: String, // E.g. "health-issues".
  question: String, // E.g. "What make is your housing unit?" 
  label : String,// E.g. "Click the drop down list to choose a make"
  answers: Array, // depending on type of question (e.g. radio, dropdown), a list of possible answers will be supplied here. Potentially, if 'type' indicates that the question has further conditional questions the array will be of object like below, if not the array will be of strings (to save space? does this matter on less than 100 questions?) Perhaps the existence of the nextQ will be the indicator of further questions.        
        [{
          text: "cats",
          nextQ: Number //refers to number of next conditional question (probably start conditional question numbering in 1000s
        }]
  submit: String // potentially to differentiate database collection to save to. E.g. Answers vs. Housing. (could also use set value above
}

This requires some potentially time consuming regular expressions, so I am putting off until higher priority work is done

A possible solution "Maybe something like a clear dashboard that shows me what others can find about me, and lets me revise my publlic/private settings at any time."

@shapironick sez: In my experience people are likely to want to have everything private or everything public, so maybe we could just have a very clear pubic/private toggle next to the answer box so that they don't have to worry about the pub/priv decide every time they answer but they can change it if the content of their answer pushes them either way.

Suggestion for first version: choose just 3-5 questions. This may also help to build momentum for the site as the questions will likely have more respondents if there are fewer; can also help to focus on repeated answering over time.

Later, we can expand with a larger set.

Something like "you've answered 10 of 43 questions" above or below the questions themselves. I can take a pass at what this should look like in a mockup.

We should think about the kinds of activities site admins would regularly need to do, and what access such admins need to have. @shapironick -- thoughts?

This is where we might ask about VIN #, and be very clear about pseudonym and privacy issues (i.e. your answers will be public, or at least show a "privacy switch"?)

See #4 (comment) for VIN discussion.

Task list:

• figure out over-18 question
• use "manufactured housing" as vocab
• HUD & VIN or HUD || VIN?
• "how to find HUD & VIN" blurb & photos (modal?)
• use email as login mechanism, not username.
• indicate which parts of a VIN we may use? or none, if we'll ask it as part of the survey
• username generator: use animal names? or some ungendered naming convention: "BlueGiraffe34"

Junction looks great on headers but let's stick to helvetica on any small or body text <14px in size. It'll read better small. Thanks!

No email sent to me to allow me to access the privacy page or the survey.

two buttons need more spacing when vertically stacked

Noticed the buttons are on the other end of the page... just a lot of mouse movement. Could we put them on the left, or centered, even though it's not as strong a convention? Would it cause trouble?

Current state of graph design from #3:

I think the short survey list looks concise enough to move forward on -- thank you so much, Nicole.

https://docs.google.com/forms/d/1BvjKvH5dUFNjhhDdA4NNtsTHiXgurjJN3-c72mcrvFM/viewform?usp=send_form

A few questions:

• Are there any questions you'd consider "required"?
• Can we break this up into different pages or forms where each page has 1 question?
• Is order important? Can people "go back" and change their answers, or go back and forth in the questionnaire?
• The big grid may be a little intimidating -- would it be possible to break it into a 2-3 smaller forms?

Junction looks beautiful on most of the title and body text, but I think we should stick to the Bootstrap default (helvetica?) for the actual form inputs and help text, as the spacing works better. Thanks!

Hmm...

Maybe I'm off here but I think there may be some confusion about there being two switches in Jeff's diagram in issue #2. I thought that the two privacy switches in the mock up were actually representing the two options (on/off) of a single switch. I'm think they should be merged into a single switch as I don't think the second switch should exist, because what would even happen if they opted out of letting the research team see the data and opted out of data being public? The data would just disappear once they entered it?

I like Melissa’s urge on the site to use language other than “data” as it is a little vague and may be somewhat alien to our average user.

So maybe we could have the two toggles be:

a) Your questionnaire answers are currently shared only with the WhereWeBreathe research team and will not be visible publicly.
b) Your questionnaire answers can be seen by the research team and anyone on the internet. (Only your chosen username will be shown along with your answers).

Option A would be the preset.

Also, some users may not recognize the switch as something they can interact with, so maybe below the switch we can say for option a) you can slide this switch to the right to share publicly and b) you can slide this switch to the right to share exclusively with the research team. We could also have a little arrow like in jeff's diagram above.

After clicking update privacy settings it would be nice to be automatically sent to the questionnaire.

@mmmelissa @jywarren

I think we should look at redirect flows... Maybe in a map or flow chart. For example when you log in, or finish the privacy form, where are you redirected next...

I'll take a pass at this soon.

@shapironick, i'm catching up on this project today; could you give this a quick browse and see if I've forgotten anything big for the first version? I jotted it down quickly but can't immediately think of anything more:

http://pad.publiclab.org/p/wherewebreathe

Just to sync up on everything, here's an overview sitemap of what I know we have so far; does this look right, @shapironick ?

media queries cutoffs need tweaking (Login button creates new line in nav bar when screen a certain size)

Instead of having to submit the form to find out.

Notable changes since last time

• question button placement and questionnaire width
• form and info message fonts use Helvetica
• space in email field wont cause match error with email confirm field (but will trigger the default 'please enter valid email' error
• the all of the questions for the short survey are now asked
• an example of a stand-alone narratives page is up and running.
• your user account and answers are effectively deleted. Please sign up again.

(I wont ask questions here this time, but in the relevant issue threads. )

http://dev.wherewebreathe.org:3000/

just keeping this in mind:

possible anonymous aggregate database download formatting in both conventional csv/excel and custom plaintext for analysis in stata

Let's display these in a Bootstrap download popover on each graph page, and a total bulk download from footer and/or settings page

@shapironick - can you provide some example files for the stata format you're asking for? It's just text, right?

I'm currently getting it going but once it's up and login info is set, @mmmelissa could you install the node and application dependencies? Thank you! I'm using "mmmelissa" as your username at dev.wherewebreathe.org.

The full list from #4 -
https://docs.google.com/forms/d/1G7pi27dNkUHfYFbj94b4c5jLOiFHySG5_xqpl6bVDf8/edit#

Just want to create a place to discuss how the narratives/comments/graph page -- which I propose we start calling the "Forum" is shaping up. We've discussed possible changes to this that may be part of a future phase, but now that we're in implementation, just linking things back to the original design:

Just a design issue - can we have the graph bars be solid, as in the mockup? Thanks and looking great, Melissa!

From @jywarren :
do people read links as links? (consistent underlining) buttons as actionable? is it too cluttered or intimidating?

A place to collect issues related to the signup process, from design to UI/UX.

I noticed that there's no "call to action" once you've saved your privacy settings. Not sure what to do next!

(looking super duper, btw!)

I'm working on the IRB approval form now.

I'm not sure about this question, as I guess it depends on finance. Any quick sugestions?
"How long will the data be stored? And how will it be eventually destroyed?"

Also I'm wondering what terminology I should use about how we are ensuring security of our data.

Thanks!

Text for the About Page is drafted here: https://publiclab.org/wiki/wherewebreathe#About

@mmmelissa , when you get to coding this page later there is space for you to fill in your bio.

Just want to keep an issue open for checking if folks who don't use the web much, and/or don't know web UX idioms, can read/use the site. We should do some user testing.

makes a big difference on mobile, will probably zoom to actual question too....