ForumsTips & TricksA bit of simplification
A bit of simplification
As I worked on my lists, recently I decided to simplify a bit:
-I've merged contexts and locations. Everything is a "location" now. The reason is because locations, unlike contexts, can have a physical location. IMO making the two separate is unnecessarily complex, and a system needs to be as simple as possible to be effective.
-I've gotten rid of priorities. Prioritization is implicit when I sort my lists, and if something really needs extra importance, I can always star it.
This message was edited Jul 16, 2011.
I have made similar efforts to gradually simplify the way I do things. I take advantage of many of the data fields in Toodledo. Most of these I use for exceptional things and fine-tuning. I try to keep the "mandatory" ones to a bare minimum:
Status: This is my main "mandatory" field
I use Next Action, Active, Planning, Hold, Waiting, Delegated and Someday for the scheduling/pipelining of tasks (pretty much in accordance to GTD).
(I have "hijacked" the statuses Postponed, Canceled and Reference for more unorthodox purposes related to filtering etc.)
Due date and Time: Only for externally timed tasks
I never use due date for scheduling my own time - I rely on Status reviews for that, and I try to minimize the use of due dates.
I use Due date only for tasks that have a "real" external deadline or decency requirement, or which at least have some other "real" external dependancy. For example, if I am waiting for some necessary input from somebody I usually set a due date (reminder) for when I need to take action in case nothing has arrived.
Folder (or one Tag): Necessary to keep me sane
This is the basis for how I break things into manageable portions at the most fundamental level. My tasks are separated into more than a dozen different buckets which represent different time-limited projects as well as permanent areas, such as Family-Admin, Family-ProjectZ, Job-Marketing, Job-Admin, Job-ProjectX etc, etc.
Contexts: For special conditions
I have no need for @computer, @phone etc. My standard environments are such that I have all these kinds of things available all the time. This means I do not need to specify a context in most cases, which saves time. I still use contexts, though, but not quite according to the book. One such context is "Away" (= out and about=@errands), which I find useful for seeing and selecting things that can be done at the same time while out and about somewhere.
I have not found any use for it yet. I know it is very common (most systems have it), but this is not for me, it seems.
Priorities: I use them, but do not depend heavily on them
I use them as an indicator of the impact or potential the task might have. This measurement provides additional fine-tuning of the pipeline. For example, in the Someday category, the ones with a higher such "potential" are more likely to be detected and selected (by me, when I manually review the tasks) for a promotion along the pipeline (to, say, a Hold or Active status).
Star: Yes, intuitively
The way I usually keep my lists sorted (by Status, with Star as a second Sort order), the Star gives me a versatile means to further fine-tune the pipeline, for example to highlight the most urgent of the Next Actions, or by pre-marking some of the tasks in Active, Hold or Someday as the most likely to be next in turn for a promotion along the pipeline.
I used subtasks and subfolders a lot when I was using Todoist a few years ago. I decided this is not the way I want to get things done.
I generally try, as far as possible, to keep projects as a one-task item. In many cases this is good enough, because I often know the steps intuitively or by heart - I just need to have it on my list so that I do not forget chipping away at it every day. If I need more info on file, I prefer to just use Task Notes. For slightly larger projects, where I need to use separate tasks, I sometimes create a new folder to keep them in, or, especially if it is a "matrix project" (tasks in different folders but somehow related) I may define a common short-term Goal for them (to be able to filter them in or out in Saved Searches etc).
Task names: Yes, heuristically systematic
I have found it to be good practice - even if there are alll kinds of sophisticated mechanisms for filtering and sorting - to also use very clear and a bit "systematic" (almost military style) task names. For example, instead of writing "Repair attic door lock" I might write "Attic Door Lock Repair". There might be other tasks named, say, "Attic Door Hinge Grease" and "Attic Floor Vacuum clean" etc. This "backward" naming tends to be particularly useful when the list is sorted alphabetically. In addition, it is generally easier to read task names if they all have a similar syntax.
This message was edited Aug 03, 2011.
"Status: This is my main 'mandatory' field"
I actually hijacked Contexts for that, since I wasn't using them anymore. Wasn't totally satisfied with Toodledo's statuses, and they can't be edited.
"Due date and Time: Only for externally timed tasks"
Pretty much agreed - I haven't really used them that much except for when I really need to hold to a certain time.
I did use them a lot more in college, because homework was always on a strict schedule. Right now, however, my current job isn't so scheduled.
You cannot reply yet
U Back to topic home
R Post a reply
To participate in these forums, you must be signed in.