Feeding U/X - entry intersection handling

[MisterPhilip]

Per @th0mcat in #800 (comment)_

Whenever I try to add a feeding in the past, it gives me the “ Another entry intersects the specified time period. ” error.

It looks like this is caused when there is another feeding that is between the start time and the time the bottle feeding is submitted. I suspect this is caused by the end time not being defined and thus defaulting to now, and validate_unique_period returns false.

[cdubz]

There has been enough issues and feedback around intersection that I think it's worth a harder look now.

Here are the issues that have been raised over time:

• Feature request: Allow / merge overlapping entries? #125
• Make error more helpful when entering conflicting/bad data #542
• Non-overlap of meals isn't always helpful #702
• Improve overlapping event validation #736

Plus various bugfixes that happened around the feature.

Some of those ask for a more complex "submit anyway" type of solution but I also wonder if the intersection check should just be scrapped?

The idea initially was just to help sleepy caregivers avoid data entry errors so I'd be curious to hear from users who do find this feature useful (if any happen to land here).

Otherwise I am feeling a bit more open to just dropping this feature. We'll need to figure what the impact would be on oyther aspects of the app (like graphing?) but it may be more minimal than I think.

[MisterPhilip]

The feature has saved me many times from forgetting to update one of the times, having the wrong date during the late night feeds, etc. To recap the various options, from easiest to hardest (assuming so, I'm not as familiar with Django):

1. Leave as-is, prevent users from adding overlapping entries
   Obviously the easiest solution, but we would need to figure out a way to allow for the bottle entry form (which is super helpful!) to set the default end time to the start time prior to validation.

2. Scrap the feature and allow users to have intersecting entries.
   This does happen in real life on occasion, e.g. started with a bottle, then moved to solids, then moved back to the bottle. I think the only report that would need to be updated is the feeding interval one? That one already is kinda messy when you have multiple food types in the same feed, so I personally would be OK with it being out of sync.

3. Continue to show the error but add a force submit option
   This might be the best compromise in my opinion. It still has the downside of the feeding interval graph being a little off but has the upside of providing a security net for the user to not make a mistake.

4. Show a warning as users are entering the times
   Similar to above, this would show a warning next to the time but wouldn't prevent them from submitting. It would require checks prior to submission as users update either of the time slots. One of the nicer UX options but I suspect it'll be way more work than it is worth.

5. Allow users to submit overlapping times, but also give the option to merge them
   I can see the use case for this, but I struggle to see how to handle that with multiple food types or delivery methods. Unless they exactly match, I don't think this is feasible (or desired as a user). Even if they did match, I'm not sure how often it would come up where you would want to merge. The time/date entry was likely a mistake.

From the UX side, allowing the user to continue after seeing a warning is best IMO (options 2,3, or 4). But for simplicity's sake, I totally understand if you preferred to scrap it!

As mentioned in #736, adding which type of event (feeding, sleep, etc.) would be nice. If you want to keep the feature, then I'd be happy to explore a PR to add that.

[Dinth]

Its not a big thing, but this feature prevented me from adding data incorrectly a few times in the past, but was also an annoyance a few times in the past (for example baby started eating the main meal, didnt want to eat anymore so got a fruit sachette, but after that started eating the main meal again).
I would opt for version 3, although im not sure how this would work with adding feeding via API

[cdubz]

3. Continue to show the error but add a force submit option
   This might be the best compromise in my opinion. It still has the downside of the feeding interval graph being a little off but has the upside of providing a security net for the user to not make a mistake.

I think this one is the best fit for what we have now. It will be a bit complicated but not crazy.

Happy to review a PR if you do get a chance to work on it, @MisterPhilip — thanks!

It looks like this is caused when there is another feeding that is between the start time and the time the bottle feeding is submitted. I suspect this is caused by the end time not being defined and thus defaulting to now, and validate_unique_period returns false.

Also just realized in the interim we could a small change to set the bottle feeding end time to the same as the start time. This would help with the current overlap issue after entering a bottle feeding late.

[cdubz]

I would opt for version 3, although im not sure how this would work with adding feeding via API

I think this would just be a UI-only change. If there is real need for an API option we could probably add like a skipIntersectionCheck boolean to the props or something.

[AstroPhotoJay]

The lack of an end time field in the bottle feeding form does make the UX inconsistent with other duration-based activities (which could create un-necessary confusion for us frazzled parents).

Perhaps it might be worth confirming if this is indeed a bug, and squashing it, so no further gymnastics for the validation rules are needed (hopefully*)

Per @th0mcat in #800 (comment)_
It looks like this is caused when there is another feeding that is between the start time and the time the bottle feeding is submitted. I suspect this is caused by the end time not being defined and thus defaulting to now, and validate_unique_period returns false.

Following on from, and building upon, my suggestion in #772 (comment) could we consider making the ux for the generic feeding and bottle feeding forms more consistent by:

• adding an end-time field to the bottle feeding form in the advanced section
• in the generic feeding entry form, move the end-time to the advanced section (the ux details of which would need to be more carefully thought through, though. )
• changing the functionality for both forms so that BB automatically uses the start time if the end time is left blank when entering a feed.

Other ideas...

• rename the "advanced" section to "Add more details" or something similar to make the purpose of this section clearer.

As for possible impacts on graphing...

We'll need to figure what the impact would be on oyther aspects of the app (like graphing?) but it may be more minimal than I think.
Would it be possible to exclude all zero-duration entries from graphs that rely on this info?

*I'm not a developer, so I have no idea how things work under the hood.