Regarding #10, I have seen a lot of new folks get caught up on this. I think there’s definitely room for improvement in the initial goal settings. Instead of asking about extra safety days or however it’s phrased, it might need to ask ask both “Would you only ever enter integers as datapoints, or would you ever enter 0.3 units of progress?” combined with “What is the earliest day you want to be required to make progress on this goal?” and have it use those to set the initial settings.
Regarding #11… why?
Regarding #12, why are you getting so many emails? Are they “warn me x days ahead of time” (leadday) emails? Are they “you are going to derail today” (zeno) emails? Do you want the zenos bundled together? If so, do you only want the zenos with the same deadline bundled? Or do you just want the leadday ones bundled?
Regarding #13, you can enter times in HH:MM and it just works, assuming your goal is in hours. Once I found that out, I moved all my goals in minutes to hours and didn’t look back.
That sounds amazing, but I think the integer feature is a premium feature so you’d need a version for users who don’t have that level of control. I think I’d rather have the first question phrased “how many days” rather than “what is the earliest day.”
For one thing, there’s a limit of 150 data points through an IFTTT app, and this would prevent hitting that limit, as well as any other limits Beeminder may have.
For another thing, if I want to review the previous history of data points in tabular form, I have to go through and manually delete the extraneous entries.
And also, I just don’t like having 100 extraneous data points for each legit one, and multiplied over many users, it would reduce the amount of storage and bandwidth Beeminder needs.
For instance, I track my bedtime by using the last time my phone turns on or off, and the time I get to work and get home using GPS and wireless network connections, but each of these produces many many data points a day instead of just one. If I want to go back and review the times I got to work over the past month (I’m trying to average less than an hour late each day) it’s difficult to read the table without deleting the extraneous entries.
One for each goal within the leadday time (which includes most of my goals), all at 7:30 am - some are leadday and some are emergency day. Since they’re all set at 7:30 I’d like them all bundled.
As far as later zeno emails for emergency day goals, I would like those bundled together if sent at the same time also.
I had to change the goals that got automatic timer entry to hours, but I’m definitely looking back with regret and sorrow. They should really be in minutes. And any of my goals that don’t use automatic timer entry will definitely be in minutes - I really prefer that.
I would suggest that integery become first class, and probably default. The nitty gritty of the phrasing is probably best tested on people who haven’t used Beeminder before.
I have IFTTT goals with over 1000 datapoints, I think. I am not sure what the 150 limit is.
I would rather have a way to get the aggday-filtered list of datapoints for a goal, than have aggday be transformative and remove datapoints. If aggday deletes datapoints, what happens if you decide you want to change your aggday later, or mine your data in a different way than you thought originally?
I like that idea but I wouldn’t want to jeopardize Beeminder’s revenue.
Well, the goals are phrased as “per day,” “per week,” or “per month,” so I now think it should be in the form of “X days/weeks/months from now” for consistency’s sake.
This is the Beeminder email I got:
Well, I’m currently deleting the extraneous datapoints manually every day, so that’s not an option anyway.
But that’s not how I think of it. There is only one real data point - the others are just errors and not actual data that I want to record. Ideally I would set it up so they never get recorded in the first place but IFTTT runs each filter in isolation so I don’t think there’s a way to tell it “skip if you already ran this applet today.”
I have a weight goal, for example, and I usually weigh in multiple times per day. All of the datapoints are valid, but I need a single datapoint for the day. The last datapoint, maybe, or the average of the datapoints, or the lowest datapoint.
This is markedly different than your use case, where you’re submitting a lot of datapoints, and using aggday to determine which one is the “correct” one.
I think I have discovered one cause of this. Apparently the system derails you even when you’re not at your deadline if the previous day is in the red. One of my goals is always in the red during the day but goes back by my deadline. So if I derailed the previous day I will always derail the next day. Mid-day derailing when yesterday was red
At one point? I don’t think anything has reverted, has it?
In any case, almost all time-based goals should be in hours. People often think they want minutes but what they actually want is to be able to enter, e.g., “0:20” instead of “0.333333333” and they aren’t aware that they can in fact enter the former and have Beeminder understand it as the latter. Best of all worlds!
(As for the rare cases where minutes really is what makes most sense to plot on the y-axis instead of hours… First, I’m interested in use cases! But, second, we have to figure out how to make the colon shortcut more discoverable before we let people choose minutes when what they really want is just to be able to conveniently enter minutes.)
According to the link to your comment 5 years ago that I posted in my previous post, there used to be a “scalar-transform thing in advanced settings” which would allow you to multiply all your datapoints by a constant. This would allow the timer to work properly for me.
As far as I can tell that no longer exists.
If you really want to stay denominated in Minutes, let us know. If you’re not alone we also may want to just make this an option in Android app settings so you can choose how it submits the data
Well, I’m letting you know… I really want to stay denominated in minutes. Hell, I’d pay a monthly premium just to have that feature back. I definitely don’t agree that almost all time-based goals should be in hours.
The problem is not with entering the data - it’s with reviewing and correcting it.
The colon thing, aside from being very buggy, just isn’t what I want. For one thing, it doesn’t seem to work well for decimals of a minute; for another, when viewing entries, the display seems to randomly show some entries in minutes and some in decimals of an hour, with no way to switch; and finally, rounding is not handled in a sane way.
Except for some goals, minutes denomination is better. I am tracking the amount of time spent squatting. The data points are in the range 2-5 minutes. And its hour denomination is basically meaningless to my non-arithmetic mind The data points individually become quite meaningless and less motivating.
I wonder if it’s valuable for someone to go through the forum, look for discussions on timey-wimey goals, and see what the current state is. I know some of the most lowest hanging fruit options were implemented (i.e. hh:mm data entry) but there were some gold nuggets in there that I am not sure were captured.
The colon shortcut has always worked perfectly for me. Got a bug report?
You can do HH:MM:SS not just HH:MM, if that solves the fractional minutes problem.
Ah, that’s a good bug report! I’ve noticed that too. Now if we can pin down steps to reproduce it…
When you click through to the website from the Android app, you’re magically pre-logged-in and the site is now relatively mobile friendly, so duplicating functionality in the app (other than the 3 core features of the app – getting reminders, entering data, seeing your dashboard) is now, sadly, how to put it… not on the roadmap. Remember we’re a literal mom&pop business! It’s kind of amazing we have native Android and iOS apps at all. It’s really important to us to ruthlessly crush bugs though. Especially reversions – I’m super uptight about those. Those are mercifully quite rare, I think. There are pleeeenty of bugs though!
Yes, there’s no tracking in minutes and never has been. The rescale feature is so that you can convert to hours and track everything in hours, as God intended. (Scaling by 1/60 is what you want in that case – and it does understand fractions.)
In any case, definitely noted that there are actual use cases for wanting everything in minutes, but for now that’s not possible (except for totally manual goals of course). Eager to fix any bugs related to HH:MM format and such, that in theory should make it no big deal for everything to always be hours.
Can you clarify whether the intended interpretation of XX:YY:ZZ, as it shows up on the goal page or elsewhere in Beeminder, is XX days YY hours ZZ minutes, or XX hours YY minutes ZZ seconds? This was very confusing for me and there should be a consistent answer or notation for this somewhere.
I’m unclear - is the rescale feature a one-time thing that affects only existing data, or does it also transform new data when entered? I don’t quite understand how 1/60 scaling is supposed to be applied.
Gotcha - I’ll beehave and switch over to reporting colon problems.
PS: God’s intended time unit is clearly Planck time but there are 6 * 10^46 of those in an hour so it’s a bit impractical for us mere mortals!
12:34:56 is 12 hours 34 minutes 56 seconds. I don’t think it could ever make sense for the 12 to be days. The first number is just always hours. If you want, say, 3 minutes, that’s 00:03.
Exactly. It rescales existing data (and the yellow brick road) and then does nothing further. Rescaling should affect nothing about the graph except the numbers on the y-axis. A common use case is you started tracking a goal in minutes but now want to use the Android or iOS timer which reports hours. So you first rescale to hours and then you can use the timers (and hopefully also still enter minutes manually if you want, by using the colon syntax).
PS: Good point about Planck time! I should’ve said “how the Queen Bee intended” but she probably doesn’t want me dragging her into this…