I now have a working GTD system based on Ryan Holcomb’s template and I learned a lot about actions, etc., in the process.
One thing I would like to do if anyone has any suggestions. I have agents that collect actions from contexts that have “next actions (OF/GTD term)” and actions that are due or approaching start dates. There are a dozen agents performing this. I would like to pull all those collected into a single view, so I can have a single dashboard view to check off things to do for the day.
Any suggestions how I might do that? For now, and it really isn’t that onerous, I can select the ones I want to work on make alias and then drag the alias to the single view.
Slightly tangential but if you haven’t already seen it, I’d view the “Actions and Dashboards” resource in the Tinderbox Help menu, specifically the Dashboards aspect.
One dead simple approach would be to create an agent with the query
inside("name of agent1") | inside ("name of agent 2") | ...
This would work, but is somewhat fragile.
You could also create an $IsNextAction attribute that you set with your querying agents. You can then create an agent that simply queries for $IsNextAction, or perhaps $IsNextAction and !$Checked or something similar.
inside(“name of agent1”) | inside (“name of agent 2”) | …
This isn’t really fragile. For example, my weblog does on the main page, and has done it for more than a decade. We want the 20 most recent articles, from this month if there are 20 articles, or all of this month’s articles plus sufficient articles from last month to make up the difference:
If the query has a typo, it will not fail cleanly — it will just produce wrong results, which could lay undetected for quite a while. Given that @mbrownri will be querying a dozen other agents, the query will be long and laborious to test, and thus relatively likely to contain a typo.
If he adds, removes, or renames the task agents, he will have to update this global task agent’s query as well.
So in my view there’s plenty of room to get things slightly wrong with this approach. Do you agree?
From my reading, this query could match as many of 40 articles — I presume you pull off the first 20 children of recent articles somewhere later in the process?
And furthermore, even this simple query is feels somewhat fragile to me, in that it requires that you update it correctly by hand every time the month changes. @eastgate, have you found this to not be an issue in practice?
If the query has a typo, it will not fail cleanly…
This is the nature of computing. If you would prefer a tool that uses a different query language, Apple makes a nice tool called Xcode…
Manually updating agent queries
As I said, the example I reached for comes from a project that’s more than ten years old. When that query was written, Macintoshes were roughly 64 times slower than they are today, and agent updates interrupted user work. A simpler query would look for the 20 newest items in the archives; that’s O(n log n) in the number of articles. This would be fine today — especially if we used an edict. It wasn’t ideal in 2001.
The manual agent updates have seldom caused even a brief fumble — I’m a very sloppy typist, and so I’ve had to fix a typo in the query two or three times over the years. That was a good tradeoff for a more responsive system, back in the day. You might not need the optimization, but it’s there if you do.
Typos causing failure is the nature of computing. Failing cleanly or not is a question of design. Tinderbox, in the tradition of many dynamic programming languages, tends to fail silently, which puts a larger burden of testing on the user. I’m not arguing for or against that design. I’m just pointing out that given Tinderbox’s design, a long query that hardcodes the names of a dozen other notes is fragile compared to one that doesn’t.