Task triggers
simeons says:
RTM is awesome but, like any successful system, it's being pushed past its breaking point by its most advanced users. Developer APIs help developers but others feel a bit stuck.
I've seen a lot of requests of various types on the forums over the years about special-purpose advanced capabilities such as subtasks which won't be used by too many people and may complicate the UI significantly.
RTM argues that smart lists, which are a horizontal capability that's broadly usable by lots of people, obviate the need for many of these feature requests and I agree to an extent. The missing piece is another simple horizontal capability which is specifying actions that can be taken automatically when a task's state changes.
So the basic idea is Triggering Event -> Action.
Actions can become a new tab for tasks after Notes in order to keep the UI very clean. The Task, Notes and main results UI won't change one bit.
I'd start with "task completed" as the only available trigger. It keeps things very clear and simple. More can be added if it makes sense down the road.
There are lots of actions that could be taken but the one that would complement smart lists very nicely is to modify the tags of some tasks. A number of advanced features can be implemented using this by motivated users w/o disrupting the UE for mainstream users. The much-requested subtasks is one of them.
Task Completed -> For tasks identified by Selector { remove tags RT, add tags AT}
RT and AT are easy to specify, just as in a multi-edit field: a list of tags to add/remove. this takes two edit fields.
Specifying a tag selector is a bit harder.
For minimal changes, the selection should just be a search query--another edit field in the Action tab. Unfortunately, this may lead to advanced users having to use lots of "behind-the-scenes" tags. For example, If I wanted to select 7 specific tasks, I'd first come up with a special tag to apply to them and then specify tag:special-tag.
Something which requires more UI changes would be to have a "selector mode" in the UI where the user can select any number of tasks in the *current view only* (including the tasks whose action is being specified) and then say "done" to finish the selector, which could be written out as a long search expression to keep things simple. In other words, there would be no new selection UI--just a new mode to select several tasks the same way people are used to doing this for multi-edit.
For those into GTD and sub-tasks, here how to get the equivalent using this. Say you have master task MT and sub tasks ST1-ST5. The idea would be to modify the tags of ST1-ST5 such that when MT completes--but not before--they are identified as ready-to-go.
The way I use GTD with RTM is to tag ready-to-go tasks with na for "next action". My MT rule would be to add the na tag to ST1-ST5 when MT completes. Done. For the crazy ones out there, note that this allows for infinite nesting of sub-tasks, not that this is a good idea.
Hope this helps.
I've seen a lot of requests of various types on the forums over the years about special-purpose advanced capabilities such as subtasks which won't be used by too many people and may complicate the UI significantly.
RTM argues that smart lists, which are a horizontal capability that's broadly usable by lots of people, obviate the need for many of these feature requests and I agree to an extent. The missing piece is another simple horizontal capability which is specifying actions that can be taken automatically when a task's state changes.
So the basic idea is Triggering Event -> Action.
Actions can become a new tab for tasks after Notes in order to keep the UI very clean. The Task, Notes and main results UI won't change one bit.
I'd start with "task completed" as the only available trigger. It keeps things very clear and simple. More can be added if it makes sense down the road.
There are lots of actions that could be taken but the one that would complement smart lists very nicely is to modify the tags of some tasks. A number of advanced features can be implemented using this by motivated users w/o disrupting the UE for mainstream users. The much-requested subtasks is one of them.
Task Completed -> For tasks identified by Selector { remove tags RT, add tags AT}
RT and AT are easy to specify, just as in a multi-edit field: a list of tags to add/remove. this takes two edit fields.
Specifying a tag selector is a bit harder.
For minimal changes, the selection should just be a search query--another edit field in the Action tab. Unfortunately, this may lead to advanced users having to use lots of "behind-the-scenes" tags. For example, If I wanted to select 7 specific tasks, I'd first come up with a special tag to apply to them and then specify tag:special-tag.
Something which requires more UI changes would be to have a "selector mode" in the UI where the user can select any number of tasks in the *current view only* (including the tasks whose action is being specified) and then say "done" to finish the selector, which could be written out as a long search expression to keep things simple. In other words, there would be no new selection UI--just a new mode to select several tasks the same way people are used to doing this for multi-edit.
For those into GTD and sub-tasks, here how to get the equivalent using this. Say you have master task MT and sub tasks ST1-ST5. The idea would be to modify the tags of ST1-ST5 such that when MT completes--but not before--they are identified as ready-to-go.
The way I use GTD with RTM is to tag ready-to-go tasks with na for "next action". My MT rule would be to add the na tag to ST1-ST5 when MT completes. Done. For the crazy ones out there, note that this allows for infinite nesting of sub-tasks, not that this is a good idea.
Hope this helps.
fboosman says:
+1
Implementing triggering events and starting with just one, task completion, sounds right to me. That seems like a fairly straightforward UI extension that could be done in an uncomplicated manner.
Implementing triggering events and starting with just one, task completion, sounds right to me. That seems like a fairly straightforward UI extension that could be done in an uncomplicated manner.
+1, with a suggested simplification:
I expect that the "Sub-tasks please" requests are sustained is because those users do not particularly like the hacky alternatives that RTM currently provides and that other users recommend. Simeon's suggestion would provide a better solution (and it's been suggested elsewhere), but I worry that the tag-dependent suggested implementation might not be entirely satisfactory for the same reasons.
The best bit of Simeon's version of triggers is that it is the simplest version of task triggers that I've seen so far, recommended as a temporary "see what happens, and then build from there" plan. So, I would like to suggest a further such simplification:
Give developers a way to implement push notification through the API (please), or, if it is is already possible, please point an amateur programmer (Hello!) in the right direction.
I have been trying to work out a way to add event triggers to my RTM greasemonkey script for a long while, and would be happy to put more free time into this project if I could just figure out how to get the script to recognize when a task is completed.
I expect that the "Sub-tasks please" requests are sustained is because those users do not particularly like the hacky alternatives that RTM currently provides and that other users recommend. Simeon's suggestion would provide a better solution (and it's been suggested elsewhere), but I worry that the tag-dependent suggested implementation might not be entirely satisfactory for the same reasons.
The best bit of Simeon's version of triggers is that it is the simplest version of task triggers that I've seen so far, recommended as a temporary "see what happens, and then build from there" plan. So, I would like to suggest a further such simplification:
Give developers a way to implement push notification through the API (please), or, if it is is already possible, please point an amateur programmer (Hello!) in the right direction.
I have been trying to work out a way to add event triggers to my RTM greasemonkey script for a long while, and would be happy to put more free time into this project if I could just figure out how to get the script to recognize when a task is completed.
Log in
to post a reply.