Additional potential usability change - double tapping zooms by default on Safari iOS. I’ve read this can be disabled? It makes tapping to input data points clunky, as the screen zooms in when you tap twice to input data, and you have to zoom out to resume inputting data.
Here’s a video of this in action.
Wow, that’s crazy. It failed to load the bullseye image (and so forth) from a data: url? That’s seriously broken, especially if it then didn’t even fire an error event for the failure. (Could it be that the length of the data URL exceeded some sort of URL-length limit? I know that can be a problem with data: urls in some browsers, such as Opera. But even so—the bullseye image isn’t that large. Even base64 encoded, it should easily fit in under that limit.)
Apparently, this can be prevented by adding a touch-action: manipulation CSS rule. I’ve added it, let’s see if this works.
Bah. Apparently, instead of taking the icon from the webmanifest like it should, Safari demands that a separate apple-touch-icon be given. Very well then, done.
Both issues fixed!
I’ve been using this since you first posted and really like it. Thanks! I just have a UI request.
When you click the graph from the main page you get a zoomed in graph, but there is no way to get from that to the data entry page, could there be?
I find I click on the graph intending to click through to enter data, forgetting everytime that I need to click elsewhere on the goal box to do that, and there is no way to get to the data entry page without going backwards.
Good idea—I’ve now added such a link.
Hello,
Not really a bug but an aesthetic thing - iOS turns the background of PNG logos to black, which would be fine if it couldn’t decide between the two while app switching, video shown below. Perhaps having the iOS icon be solid white would solve those two aesthetic issues? (iOS not liking transparencies/ defaulting to black background looking a bit naff?)
Thanks.
Yeah, it looks like Apple is very much not in favor of transparencies in app icons. I’ve done as you’ve asked, and made a sold-white-background version of the icon, just for Apple.
You may need to remove the Altbee icon and re-add it (or something like that) to see the new white-backgrounded iOS icon, but it should be there.
(It rubs me a bit the wrong way to do things specially just for Apple (as opposed to building things according to web standards, and leaving the browsers to render things accordingly.) But I guess this isn’t so bad, all things considered.)
Oh, and by the way: thanks for the suggestions and comments on Altbee. It helps a lot, and it’s always gratifying to see other people using and enjoying the thing I built.
Not sure if this is an iOS specific problem, but I can’t seem to input decimals in the data field for a goal.
Sorry about that, fixed.
Turns out that iOS doesn’t have a decimal point on the inputmode="numeric" keyboard. I’ve changed it to inputmode="decimal", which should work properly on both Android and iOS.
Altbee now supports filtering by tag—yes, really. Check it out: go to the Beeminder tags page, add tags according to whatever categorization schema or taxonomy you feel is best, then you’ll be able to filter your Altbee dashboard according to these tags.
A few related threads: [1], [2] (discussed in more detail later in that thread), and also various threads about organizing goals: e.g. [3], [4], [5].
In the past, I said a few times [1], [2], [3] that I needed API support for tags before I could implement this feature—but it turned out to not be that hard to do the impossible and fetch tags even without such support. I still really would like formal tag support to be added to the API, if only so that I can remove the somewhat dumb and hacky workaround which I’m currently using behind the scenes.
Not that for now at least, Altbee can filter by your tags, but not add them. So to add or edit your tags, you’ll still need to visit the official Beeminder tags page, which isn’t particularly easy to find. So I suggest bookmarking it or the like, or simply remembering the URL (not actually that hard!)
This sounds like a great idea, but how do I know it’s secure?
Would you be willing to open source it?
The original post speaks to that: Anyway: go check it out and see what you think of it. (And/or go read the source code : it’s completely open source.)
Oops. Reading comprehension. Thanks! I will.
How did you filter by tags when it’s not part of the API?
Aha! I was waiting for someone to ask that!
The answer is this API endpoint, the fact that the goals’ tags are included in data- attributes on the Beeminder home page, and some HTML parsing with Floki.
Here’s the code that makes all this happen, if you want to take a look.
A new feature—if you’ve added tags to your goals, you can now use them to group up your goals on Altbee.
Instead of having one big grid of goals, you can now use tags to divide up your goals. It’s not quite one section per tag, though you could do it that way too if you really want to—you can group goals with one of several tags together, and so forth.
You can define any number of goal categories, and for each you choose one or more tags, and each goal with one or more of those tags is included in that category’s section of the main page. (A goal can fall into two (or more) such sections, if its tags match for both.) There is also a main, catch-all section, with all the goals that don’t fall into any of the groups you define (plus all the red goals, so as to ensure that you keep them top-of-mind.)
This is all entirely optional, though it actually seems to work really well. The result is a UI that scales to many more goals than before, solving such problems as for instance described here.
Try it out, but first you’ll need to add tags to your goals. It’s probably a good idea to add tags anyway, if you’re using Altbee—using the filter box to filter by tag is quite a useful feature in its own right.
Super!
Currently matching tags works in Altbee as “match any”.
Feature request: support also “match all” (where one can filter on more than one tag and a goal much have each tag to be matched)
Rather than forcing the default (catch all + red), perhaps that could be an initial filter which one can then deactivate in Settings / Goal categories.
I do intend to make a lot of this more customizable in the future.
That’s a good feature to have—I’ll probably add it at some point soon.
There has to be a catchall section, because goals that don’t fall into any category need to be shown somewhere, lest a user lose track and accidentally derail on a goal that was hidden because it didn’t fall into any category.
But one thing I intend to do in the future is have a checkbox on the settings page to control if red goals are included there. I like it the way it is, but I’m not averse to having this be a configurable option if others would prefer to not have the red goals up at top.
OK. Understood. How about listing the catch-all after all the custom goal categories?
Do you particularly want that? If you arrange that all your goals fall into one or more of the categories, and if you disable the inclusion of red goals in the catch-all section, you’ll end up with a catchall section that is always empty, and thus is never shown.
If I understand you correctly, this is more or less what you’re aiming for, right?