rubyforgood / flaredown Goto Github PK

• forgot password
• update password

Currently, on days when the user does not rate a trackable, the graph returns to a midpoint. What it should do is interpolate between the points directly:

The message stays there because autosave isn't triggered on the first screen. I need to investigate about why the Ember record is dirty at that point, but anyways I don't think we need such message at all on this screen. @lmerriam Do you agree?

For simplicity, the first version of the history showed all trackables by default. That means it's tough for users to compare the specific trackables they're interested in (for example, if I want to see the effects of a particular treatment on a symptom, and they are not both visible on the screen). To fix this, let's give users control over the visible trackables.

• Button in the history navbar that lists the number of visible trackables, which you can tap on to open the trackable selector modal.
• Dropdown in the modal to select different trackable types. As we are adding new types of trackables, we should try to make sure that new ones in the future show up in this list.
• List trackables of the currently selected type, with a switch to turn them on/off in the history

1. A new trackable should only become visible in the autosuggest if 5 people independently add it, to make sure that we don't end up with a bunch of variations of the same thing. DONE

1. We should show the number of users like the existing app does:
   

The line graphs are currently low when the user has indicated MORE active ratings in the check-in, and high when the user has indicated that a condition/symptom is less active (which is backwards). See here:

More pips selected by user should = higher line graph

Same way we had it in the original app [will add screenshot soon]

This is what's causing the following:
https://flaredown.airbrake.io/projects/121837/groups/1653854108580241014/notices/1653854106619961672

Here's the params:

{
  "action": "index",
  "controller": "api/v1/treatments",
  "format": "json",
  "ids": {
    "0": "4544",
    "1": "9213"
  }
}

ids should be an array, it is an object instead because the query string is ?ids[0]=4544&ids[1]=9213

@safeforge Any idea?

Example: I record a rating for the Abdominal Pain symptom on Wednesday, I don't record one on Thursday, and I do record one on Friday.

Right now the line graph does not draw a line between Wednesday and Friday because Thursday had no value. We should connect the line graph across days, and add dots to show which days were explicitly rated. Quick example:

The most recent dose used for a treatment has to be saved for each user, in order to allow him to quickly select it during checkin

When adding a new Condition, Symptom or Treatment from the Checkin Summary screen, it appears twice immediately after autosave. Refreshing the page shows it once as expected.
@lmerriam adding this to Launch milestone, feel free to change if disagree.

Developer note: this happens because the onCheckinSaved() method from trackables-step component needs to be invoked, rather than the generic one coming from the CheckinAutosave mixin, so that the deleteAddedTrackeds() method is invoked, which removes 'ghost' records

We need to provide some visual feedback to users:

• when there are unsaved changes
• while saving
• when all changes are saved

@lmerriam Hints welcome on UI!

This feature is present in the old app, so I'm adding it to Launch milestone.
@lmerriam Feel free to change if you disagree.

Two issues I can reproduce:

• Clicking on a date on the graph takes me to the prior day in the check-in
• Clicking the arrow to move to the previous day in the check-in moves me back two days, clicking the arrow to move to the next day in the check-in does not do anything

Right now I see this at mobile sizes:

Let's choose and implement a service to monitor exceptions in the production app

Our existing app creates an account for our users on our discourse and logs them into it, let's get that working in flaredownember-2

This method is causing Rack::Timeout::RequestTimeoutException

I need to find a better implementation

@safeforge found a case when trackable color differs from chart to checkin.
Not sure if this is an edge case, @lmerriam might help understanding this.

1. User adds a trackable to a past day's checkin; system assigns it a random color and saves it into checkin record. As per req., it won't be tracked on future days, and it won't appear in the chart either.
2. User adds the same trackable to today's checkin. As per req., it will be tracked on future days, so system assigns it a random color which gets saved in the tracking record.

Now that trackable appears on chart, but on that past day's checkin from step 1 it continues to appear with its original color, because at that date no tracking record exists for that trackable.

Getting this deprecation when entering Checkin's 2nd screen (Conditions)

There seems to be an issue when including more than 2 beforeModel hooks in the same route.
After implementing beforeModel hook in index route, the same hook in OnboardedRoute mixin stopped getting called for some reason.

Most popular doses for the selected treatment should be suggested to users

Users report seeing the loading dots endlessly

Seeing lots of timeouts on the heroku dashboard:

The gray color of a trackable item is too close to the default color and could be mistaken for the items not being clickable/working. I actually thought something was wrong with the Back Pain trackable and it wasn't clickable when I first noticed it. See screen shot.

http://prntscr.com/amthgn

Consider either darkening the gray or not using a color so close to the default color.

Give the user a way to change the email address they log in with and receive emails from Flaredown at

If the user is just navigating through days by clicking the back arrow, we don't want to create an entry for each one (and thus turn them into empty summaries) until they actually enter data to be saved.

Send the same information as the existing app:

• Demographic and profile data
• Check-in event
• Onboarded event

Create a new "app" on intercom so stats are kept separate from the old app.

We should throw in a spinner when the graph is loading up, otherwise it's just a blank page for several seconds

Add a link to "Check-in" before the "Graph" link in the navigation, that goes to today's check-in

• Upcoming
• Discussion
• Terms of Service
• Privacy Policy
• Contact

A place for the user to leave a freeform note about their day: https://paper.dropbox.com/doc/Design-Doc-Check-in-JXiQVK4KzNL9p4R9zBFro#:h=Summary

Airbrake error: #3994
Airbrake project: Flaredown

Error type: Mongoid::Errors::Validations
Error message: message: Validation of Checkin failed. summary: The following errors were found: Date is already taken resolution: Try persisting the document with valid data or remove the validations.
Where: checkins#create
Occurred at: Apr 01, 2016 12:42:42 UTC
First seen at: Mar 26, 2016 01:22:44 UTC
Occurrences: 177 (0 since last deploy on <no information>)

URL: https://flaredown-api.herokuapp.com/api/checkins
File: /gems/mongoid-5.0.2/lib/mongoid/persistable.rb

Backtrace:

/gems/mongoid-5.0.2/lib/mongoid/persistable.rb:78:in fail_due_to_validation!
/gems/mongoid-5.0.2/lib/mongoid/persistable/updatable.rb:73:in update!
/app/app/services/checkin_creator.rb:28:in create!
/app/app/controllers/api/v1/checkins_controller.rb:13:in create

Right now, if the user leaves the history to navigate to another section of the app, then returns to the history, they have to load the history again. If possible, it would be ideal to cache the currently visible history when the graph loads, so that the user can quickly switch between sections of the app.

Navigating the chart on touch devices is particularly tough, because scrolling up and down to see different trackables conflicts with the left/right dragging gesture to navigate the chart viewport. The goal is to improve navigation patterns.

• Navigation buttons that move the chart backwards and forwards in time
• Calendar button that opens a datepicker (mockup uses a screenshot of the PickADate.js plugin). On selecting a date the chart viewport should be centered on that date.
• Tap anywhere on the charts to show the scrubber, along with a button displaying the date. Tap on the scrubber again to hide it. Tap the button to navigate to the check-in for that date. (extracted to #162)

After some experimenting, it looks like a good date range for mobile portrait is around 10 days. Maybe we can check the user's window width when the page is loaded up and adjust the amount of days in the view such that they are spaced ~32 pixels apart.

See here:

That means when the taken field is true

May be a regression from fixing the line graph recently?

If you leave a summary screen open for a few minutes, it can get into a state where the first hover over a pip locks the rating in. Even clicking and changing the rating will not reset it.

If you refresh the page, it functions fine and you will see that any rating changes you made did register.

Video: https://www.dropbox.com/s/ff47v1ulcqteinx/pipBug.mov?dl=0

On today's checkin, when typing a new condition not present in select box, I get the following failure:

POST http://localhost:4300/api/trackings 422

That's because trackable_id and trackable_type params are sent as null values.

If the user has already checked-in today, default route when they open the app should be the charts
If the user has no entry today, default route should be today's check-in

Given URL is not allowed by the Application configuration: One or more of the given URLs is not allowed by the App's settings. It must match the Website URL or Canvas URL, or the domain must be a subdomain of one of the App's domains.

Seems to be universal for me, I don't have to do anything to reproduce. Several users reporting same issue. Video: https://www.dropbox.com/s/brctlgw0nhvjz8z/cantAddTrackables.mov?dl=0