Creating standardized reading goals

Tech
1

I’ve been experimenting recently with just creating a new odometer goal for every book I read (or, at least the ones that require more effortful reading). Now that I’ve done it a few times, I’ve landed on what I think is the standard that has been working for me:

  1. Odometer with 1 page / day commitment
  2. Goal Value = 2x number of pages (one pass to read, one pass to extract notes)
  3. Max Safe Days = 3
  4. tagged with reading, because I tend to read several books in parallel and want to be able to look at just those goals together

1&2 are easy, but it’s not clear to me that you can do either 3 or 4 via the API. Does any else know a way way to set tags or max safe days via the API? Am I missing something obvious in the API docs, somehow?

2 Likes
2

I’m pretty sure that neither 3 nor 4 can be done via the API.

I’ve requested before the ability to interact with tags via the API. But as things stand, it is not possible to query tags or set tags via the API, at all.

I’m fairly confident that the maximum number of safe days is also not accessible via the API. Not only do the API docs not mention the existence of a field containing the maximum number of safe days, a look through the JSON returned by the API for one of my goals does not show any field with a value that’s the same as the number of safe days on that goal, confirming that it isn’t just contained in an undocumented field.

Not receiving this value when querying the API strongly implies that it can’t be set through the API either, though I guess you never know. But as far as I can tell, this is indeed lacking.

1 Like
3

It’s dirty laundry day at Beeminder so I shall now answer with the unedited dialog between me and Adam about this:

@dreev: good call on replying to Creating standardized reading goals – except i don’t know what to say. it doesn’t seem like the highest priority to get autoratchet and tags (especially not tags, i guess, since that opens the can of worms of what the heck the GUI should be doing with them, but maybe it’s easy in the API and we can keep punting on the GUI?) in the API…

@dreev: i guess i could say exactly that. transparency?

@adamwolf: I think the reason why autoratchet is not in the API may be because we don’t have a good paywall on api features, but I guess we could

@adamwolf: Maybe a good answer is that, and end with “What would a good tag API look like?”

So, um, what would a good tag API look like?

1 Like
4

For the tag API, how about the following:

  1. Add a tags request parameter to /user/USER/goals.json to filter by tag.
  2. Add a list-valued tags attribute to Goal attributes across all API methods

Number 2 covers my use case and 1 seems like a logical place to use tags.

Can’t blame you for your priorities. They seem fair, although possibly inconsistent — doesn’t the API give you the controls to make custom goals, which are themselves a paywalled feature?

1 Like
5

If actually feels weird to be able to use the api for pay walled features at all, but I guess at this point one has to live with the inconsistency or risk breaking existing tools, and last I checked beeminder isn’t big on breaking stuff for users… messy problem to deal with :frowning:

1 Like