Be careful with abstraction

Recently, I accidentally added a 3:49 am sleep log for the day before, instead of the actual day, in my Meimei app. Because it was added to yesterday’s timeline, I didn’t realize my mistake until my wife noticed that the sleep duration was showing 29+ hours.

For context, the new log modal uses the current date of the timeline, which could be today or any past date, and doesn’t show the date. Arguably, I could just add a date in this modal but most people don’t actually read everything in an interface anyway and make assumptions based on their mental model of the app.

Because the erroneous 3:49 am sleep log didn’t have an end time, the sleep duration became so long. A quick fix was to calculate the sleep duration only if a sleep is the most recent log, since anything logged afterwards means the baby is no longer in that sleep session.

But this fix doesn’t help highlight any erroneous sleep logs, like the one I made. Claude Code smartly suggested this improvement:

1. If the user creates a sleep log without an end time, anchor the sleep log to today, because it’s most likely an ongoing sleep.
2. If the user creates a sleep log with both the start and end times, keep the selected date because it’s most likely an intentional backfill.

Anyway, Claude Code’s suggestion felt smart until I realized that such hidden abstractions can be harmful because they are invisible and users might not always have this mental model of the app. It is fine for a personal software that I use myself but not for a public app.

For a public app, I might want to raise a flag such as “you are about to add an open-ended sleep log to the past” or show a banner like “ongoing sleep since X”. But I’m also afraid of the slippery slope of adding too many banners and modals into the app.

The alternative I landed one is to always add new logs to today since that’s the main purpose of the app. If the user wants to backfill a missing log, he has to go through more steps (change the date, tap on “Add entry” at the bottom of the activity timeline, and select the log type) which is fine because backfilling should be rare or in fact better because it makes the act of backfilling more intentional and obvious.

(As an additional guard, an end time must be set when adding a sleep log to the past.)

In fact, it might even be okay to only fix the sleep duration calculation and not highlight the erroneous logs because the mistakes don’t really cause any issues and are obvious when spotted. Unless users complain about it, it’s probably worth seeing if there are higher value work.