-
Notifications
You must be signed in to change notification settings - Fork 51
Cloud Version
This page collects ideas for a planned cloud-based version of TagTime.
The ideas fall into a few categories: data entry, viewing history, and Beeminder integration.
- Straight on the website, of course.
- Android (and iOS?) apps.
- Native macOS app that works without an internet connection (Electron?)
One key point here is that pings and tags should sync ~instantly across all the platforms.
This has been the most significant weakness of the Android version in the past. You could scroll back, or export as a CSV file, but there were not good ways to track particular tags over time, and the data was not portable between phones.
With a cloud version the history should be unified and shared, naturally. In addition, it would be great to be able to view the density of particular (groups of) tags over time.
Integrations currently in the wild include:
- Stream a set of tags (eg,
work) to a Do More goal. - As above, but also with a "negative" set (eg,
distracted) that cost a penalty if TagTime catches you drifting off. - Arbitrary boolean combinations of tags (eg, all pings tagged
entertainmentthat aren't also taggedsocializingsent to a goal for less solitary tv-watching).
Also the Perl TagTime was very heavy-handed, forcing Beeminder's data to sync with the TagTime log no matter how far back in time you edited your TagTime data. @dreeves proposes a one-week statute of limitations for all autodata sources. Namely, if you edit data at the source (in this case TagTime) then you can count on that getting automatically reflected in Beeminder as well, but only for the past week. If you edit older data then you're on your own.
The real-time synchronization proposed here is a great fit for Firebase's real-time database. I (@shepheb) plan to build this first as a web app, and then add the Android client. I'll make this into my 20% project at Google.
Some problems and solutions.
Given the random nature of TagTime, we need a single source of truth for that randomness. Then all devices can ring simultaneously on a ping, rather than haphazardly.
If we want to handle devices which are offline (and we do), then we need a list of future pings that's synced across devices. 300 future pings is only 2.4KB, and covers more than 9 days.
Plan: Use a Firebase Function to maintain between 300 and 400 future pings for every user in the RTDB. Then devices should ring within a couple seconds of each other, when a ping fires.