Beeminder Forum

Writing a mini-beeminder, what limitations annoy you the most?

#1

A very broad question: I’m curious what limitations / awkward corners people have run into with beeminder that you wish would go away?

The issues I’m interested in are about the “model” of how beeminder works rather than about things like bugs or missing integrations. For example, I’m very interested in this kind of thing:

  1. the fact it uses a “road” instead of a “half-plane”
  2. the fact that “retroratchet” changes history (actually, I don’t know whether it does or not – but it if it did, that would fit in this thread)
  3. any consequences of the fact that if you want to track how often you do a task, that’s represented as a new goal based on aggregation of daily numbers (I think?)
  4. any consequences of the fact that “do less” goals add “pessimistic presumptive report” data if you don’t add real data
  5. the fact that it totally misses out on the whole area of functionality that whatever.com provides, which would go well together with beeminder because <…>

And not so interested in this kind of problem:

  1. there’s no integration with fizzbuzz.com (that’s a made-up service, as far as I know)
  2. whenever you click on a Thursday after adding a new goal, IFTTT integration stops working (a made-up bug, as far as I know)

– I am interested in bugs that are the consequence of some design decision, though.

I’ve been reading a lot of old forum posts for a while now and making some notes, so I’ve picked up a few things, but I’m sure I’ve missed a lot or just forgotten.

Here’s one question in my mind right now that prompted me to post this:

  • Do you ever have any reason to look at an old point on your road, and think “why is that point there?”

Why am I asking?

I’m writing a little beeminder-workalike system (dreev was typically welcoming and optimistic about it when I asked him about it, following his “love your competitors” philosophy). I say “workalike” and “competitor”: the truth is, it will only be beeminder in miniature, it won’t be any sort of replacement for beeminder in most respects so I’m sure it will only ever have a very small audience beyond me. For example:

  1. It won’t be a service, just code running locally on a desktop computer
  2. There will be no “auto-data” to speak of (I know, I know, auto-data is crucial, you tell me – still, I think I’ll get by without it)
  3. There won’t be any fully-automated financial commitment device (maybe partly-automated, eventually).
  4. It will be pretty much maximally geeky (perhaps beeminder is a little geeky. not this geeky. I’m using emacs org-mode as the UI – the rest is not tied to that, but I doubt it’ll ever support anything else.).
  5. I’ve never used beeminder! So I’m sure there will be lots of minor and not-so-minor differences.

Otherwise, it will be very heavily influenced by beeminder’s ideas. It does exist already in barely-workable, not yet published form. I’m in the long process of making it useable long-term for me, and later I hope for other people (open source code of course).

So I’d love to know what people think the most important limitations are in beeminder – maybe I can lift some of those limitations in my design. Maybe I’ll find something out that will be useful to beeminder in the process, even if it’s only “well, that didn’t work”?

It does already have a half-plane, of course :slight_smile:

Thanks in advance for any help with this

4 Likes
#2

Very curious how this is going!

1 Like
#3

Thanks for asking! I’m still using it every day, I mention it in my posts, sometimes indirectly (whenever I’m talking about beeminding, I’m secretly talking about that :wink: ).

Certainly don’t hold your breath to see a release though: I’m still committed to developing and releasing it – and I’m beeminding that! (I guess I need to come up with another verb…) – but I’m not spending a lot of time on it right now. I spent a LOT of time on it in earlier months and expect to do some more concentrated development later in the year. There are still a small handful of significant basic features I want to add / changes to make before I consider it releaseable – less because I want the features in the release, more because I want to push the “domain model” a bit to see how stable it is. Release early/often is great because building the wrong thing is a huge problem, but I need this to 1. fit my own purposes well (and continue to in the future) and therefore 2. be maintainable if it ever gets more than a handful of other users but me: changing fundamentals at the same time as keeping things working can be a lot of work.

Some things I want to change: fix my “derail plummet” implementation (see a recent post), which is a hack right now; generalise goal composition a bit; implement cutoff times; implement breaks based on day of week; maybe auto-catchup (“max safe days” I think beeminder calls it?).

I also have some ideas about visualisation I’m keen to experiment with.

It still doesn’t have a “proper” database (just an org mode text file), which I think was a good decision: changes are probably easier that way. It is built in “DDD” style to be minimally disruptive to add a database though, and in fact, since I ordered a linux smartphone (librem 5), I do fancy having a play sometime with maybe a vue.js web front end and making a PWA webapp – who knows when I’ll get around to that though!

2 Likes
#4

I just noticed that I am still irritated by an inflexible derail penalties, especially on the lower end.

It probably applies especially to people that are extremely loss averse (me!). Some on top of that are from poorer countries (me!). For reference Poland has an average wage around $1000/month*, $500/month minimum wage, rents start from $100/month for a room, president of the country has $5000/month salary.

*official one is a bit higher but there are multiple tricks there, like excluding small companies that are typically offering lower salaries

#5

Well on that score, an open source implementation has both big pluses and minuses, notably:

+ It can be 0 dollars every time (that’s how I’m doing it). Still seems valuable to me, so far. In fact the thing I worry about most with it at the moment is not that I don’t stick to the goals, but rather that it might make me too rigid about what I’m doing.

- Right now there is no way to even record a penalty, let alone take your money by default.

The aspirational README file that was the first thing I wrote does say that it supports writing penalties to a https://www.ledger-cli.org/ file, though :slight_smile: But as I say, right now I don’t feel any need to implement even that at all, because that part of it seems to be working for me already.

#6

By the way, I love that six people have visited whatever.com. I don’t know what’s there, but I hope they’re grateful for the traffic.

1 Like
#7

Hey, if you want to implement it, it’s probably a 1-10 liner (depending on whether you want to use oauth or are fine with the developer auth token, and what kind of oauth library you use and stuff like that). http://api.beeminder.com/#charge

You know. If you just want to give beeminder an arbitrary amount of money, they have an API call for that. Just saying. :smiley:

2 Likes
#8

Ha that didn’t occur to me! Presumably beeminder, towering faceless corporate entity that it is :wink: wouldn’t be like hey how dare you send us money, but I don’t imagine they’d be so eager to accept the resulting customer support for somebody else’s system, nor the legal complications that tend to come with taking money :wink:

1 Like
#9

I just went to both whatever.com and fizzbuzz.com just for fun.

I’m not sure I understand your last comment - there are quite a few other programs that make use of beeminder’s payment system to motivate, like complice and BaaS.

What do you mean about the legal complications or accepting customer support for someone else’s system? It’s all done through people’s beeminder accounts.

1 Like
#10

Oh, interesting, I had no idea, I don’t use any of these things :slight_smile:

1 Like
#11

Still don’t understand what you meant - I mean, that’s the whole point of having an API, so other apps can use it, right?

#12

I’m happy to admit that I don’t know what beeminder’s policy is on this, nor how people use the API in this way.

1 Like
#13

I can confirm that you’re totally welcome to hit Beeminder’s /charge API endpoint! :slight_smile: And @zedmango is correct – it works only if someone has a Beeminder account already so we’re happy to consider them customers and accept any support burden entailed, even though the charge was initiated by a 3rd-party tool. The user gets an email and can contest the charge and we believe them if they do, but we insist they talk to us in a non-automatable way if they do. (We don’t have weaselproofing for API-initiated charges – holler if you think we should!)

2 Likes
#14

That seems like an extremely bad idea to me.

#15

What seems like a bad idea to you? Having weaselproofing for API charges? Or not having it?

#16

Having the possibility of weasel-proofing API charges seems like a bad idea to me. I just can feel the headaches it could generate, having support have to deal with users using third party app weaselproofing, especially badly written or designed third party apps.

1 Like
#17

Yeah, there are territorial issues there. Like figuring out whose fault the derailing was. Seems like a difficult thing for beeminder to determine. I don’t think weaselproofing an API-initiated charge makes sense.