Beeminder Forum

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

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

2 Likes