Integrated Life Management (by alaric)
I used to keep a todo list in OmniOutliner, with the help of an AppleScript that sucked up completed tasks into monthly archives, so I could easily tally the Time Spent column to generate invoices/timesheets for hourly-rate work.
However, then one client set up their own task management and timesheeting app, so suddenly I had to juggle their system for that client's tasks, and my own system for tasks relating to other clients, my internal projects, and personal tasks. Without one integrated list, it was then hard to produce a single prioritised list of what I should do next.
However, there was trouble even before then; lots of little requests to do work come in by email. I either do them there and then, reply with a reason why not (such as asking for more details), forward the message to delegate it - or flag it as a todo and come back to it later. However, those flagged todos tend to get lost amongst the drifts of spam and old emails. I really wanted a button in my mail client to turn an email message into a todo item. Most ideally, I'd want a RT instance, to manage correspondance relating to a task. But again, that would not be integrated with my todo system.
Now, somewhat uncharacteristically, I'm not about to set out a design for a task management app. After all, there are various different valid models for different workflows - my own stuff, managed entirely by me, naturally fits into a hierarchy of clients and projects and tasks. Email requests are best handled by an issue tracker like RT. Tools like Bugzilla are optimised for tracking bugs. Workflow systems best handle formalised processes. And so on.
All I'm suggesting here is that all of these systems, which all at some level present a prioritised list of tasks for one or more users, should export per-user todo lists in some common file format, so that a single personal aggregrator can merge them all - using some overall prioritisation system to merge different priority schemes, lest pushy clients that mark every minor change as SUPER URGENT in their database cause problems.
There's two ways it could be done. One is to follow the RSS model, and mandate that each such app should provide, at a given URL, a file listing all the specified user's tasks, with appropriate metadata (context, deadline, status, priority, description, etc). The other is to have a push model; when a task is assigned to somebody, they are sent an email (or some other form of message) with a description of the task. Subsequent changes to the task are also sent as email notifications.
The upsides of the push model are bandwidth efficiency - a list of all tasks does not need downloading just to find that nothing, or maybe just a single task, has changed - and that it actually frees the project managing software from needing to keep a database of tasks; very lightweight clients might only ever create tasks, which upon receipt get added to the user's local database and tracked purely locally. Systems that detect system failures could use this protocol to tell a systadmin to fix things, for example, without the overhead of an inbuilt issue tracker. Also, the protocol could be used to submit tasks into a standard shared task database application, which would then create a task in its database and send out an email to the lucky duty sysadmin to notify them of the existance of the task.
However, the push model does require a more complex per-user aggregrator, which really has to be a full-fledged task management app in itself.
For ARGON, I'd like to go for the push model; the IODINE object send protocol would be a perfect way of sending objects of type Task or TaskUpdate, both to people (whose user agents would file them in their task database) or to 'role' UAs that accept tasks and store them in a queue where they can be assigned to members of the role, either automatically (with a load balancing system, or a duty roster), or manually (with appointed managers able to assign work, or tasks being tentatively assigned to all members of the group until one 'claims' the task, making their assignment firm and cancelling all the other's assignments of that task).
When a task is completed, there ought to be some sort of protocol for submitting a report back to the sender documenting the costs incurred, such as time and expenses. For employees, these can be used to track effort spent for management purposes; for freelancers such as myself, these can constitute my timesheet and expense claims, from which my actual pay is calculated each month.
I suspect that it'd be awfully hard to convince the developers of existing task-management apps - which often aren't very imaginatively written to begin with - to support such a thing, however. Certainly outside of open source circles. So I may remain frustrated... apart from the fact we have the source code for the task tracker my client is using, so may write a small script that extracts my tasks from the database, purely for my own aggregration 😉
Thu 24th Aug 2006 12:57 am 
Subscribe
By andyjpb, Thu 24th Aug 2006 @ 9:24 am
This is something that has bugged me for a long time. I use bugzilla to track issues both in stoic and at work. I also have my own todo list: my PIM has been Lotus Organiser 97 for a long time. However, I stopped using the Palm because text files became quicker for me to mess around with. Anyway, I've been looking into Calendaring and Scheduling for a while, with the intent to write my own "one day", and I think the technology you are after already exists. ical (the standard, not the app) can represent the data you want and iMIP, iTIP and CAP (or the newer XML alternatives: CAP never really "worked") act as the transports.
http://www.ietf.org/html.charters/OLD/calsch-charter.html http://www.imc.org/pdi/ http://www.ietf.org/rfc/rfc3283.txt
By Alex B, Sat 26th Aug 2006 @ 10:01 am
The push model permits semantically more operations than the pull model, such as assigning tasks to users, because intelligent components can intercept the data before it's user-visible. An RSS aggregator that just pulls task lists is pretty simple-minded in comparison.
But, bandwidth INefficiency is not something to criticise the pull model for. RSS is just the format; the pull interface is REST. (Indeed, you'd want to use Atom, not RSS, in order for tasks to carry modification times.) So http://tasks.org.uk/alaric/created/thisweek, /alaric/due/thisweek, /alaric/highpri - no requirement to receive a monolithic listing of all tasks, unless you ask for it.