We’re probably going overboard with it right now, but there are advantages. Like how in this other thread just now it was trivial to just add a new visual graph feature for marking when graphs were archived and try it out, without touching the database or any code except the graph generator itself. And it gives the user a ton of flexibility without any new UI or settings. We can experiment with zero impact on users who are blissfully unaware of the magic strings. (Unless an unsuspecting user stumbles on a magic string somehow – but it’s kind of part of the definition that the strings are chosen so that won’t happen.)
But now I’m defending it too hard. With better architecture, better UI organization, less tech debt, etc, I suspect you’d be right that more structured metadata for some of the things we’re using magic strings for (derails, restarts, and, just now, archives) would be better. Self-destructing datapoints and taring feel like they lend themselves to magic strings nicely. Anyway, we’re getting off-topic! (Totally happy to debate magic strings more in a new thread, or the comments of the recent blog posts – about magic strings for in-band signaling generally or the specific magic strings we’ve made official so far.)
Multiple very good points here about how difficult the transition to the bright red staircase will be. I do think each of the challenges you’ve identified are solvable. Quick reactions:
Retroactive data: I think a convention like noon or 12:01am or the current time but on the specified day can work. Metadata could record the fact that an exact timestamp wasn’t specified. The datapoint could even be shown with subtle horizontal error bars to indicate that all we know is that it happened in this particular 24-hour window. You’re right that the question of whether a retroactive datapoint happened before or after a critical stairstep is… critical. But maybe by choosing “yesterday” you’re implicitly vouching that it was early enough in that 24-hour window to have cleared the relevant stairstep. That’s what it means in the status quo and I think that generalizes to staircase world.
(Also, I think even in staircase world, you want a notion of a daily deadline, just that it’s a more flexible concept – like you can also set hourly deadlines, weekly deadlines, whatever. But that daily deadline, if you have one, can be used for the definition of “yesterday” so that everything works out, in the common case, like the status quo.)
Aggday: I think there’s always a logical translation to staircase world. Aggday=sum is just tracking a cumulative total, which works just as well if no datapoints are on top of each other. Aggday=last, same thing. Aggday=min for weight loss … is the translation here is that the red line wants to be a sawtooth shape that allows a higher weight in the morning or evening?
(Another approach is to say that aggdays apply the same as always, but specifically to points with the exact same timestamp. And then, in the weirder cases where this matters (not do-more or do-less or odometer goals, I don’t think), you can give all your datapoints that you want to be aggregated each day a timestamp of exactly noon today. Or mark subsequent datapoints as being in the same batch as some previous datapoint? I think there’s a way to have the best of all worlds. Or we bite the bullet on everything being continuous rather than discrete and accept some tradeoffs. I’m not at all sure which philosophy is best. I do like the Pareto Dominance Principle, but I also like worse-is-better.)
[shakes self out of reverie] Another fun digression! But we should return to the slightly more immediate question of whether to change “red yesterday”.
I think the answer to my original question is that checking for derailment is straightforward in staircase world: When we look at the graph at any time t, is there any point earlier than t [optionally: and more recently than a week ago, or whatever statute of limitations] at which the data crossed the red line? If so, the graph is derailed. Compute the most recent intersection of user data and the bright red line and insert the post-derail respite. (See also the sidebar in the uncle button post about post-derail respite in staircase world.)