Hierarchical Areas
I use areas to categorize my actions and projects by area of responsibility e.g. Health, Work, Social, Recreational...
A better presentation of my areas, however, would be hierarchical. I have social commitments to my family and friends, I might want to see them separately or together. Same goes regarding work commitments relating to my clients vs my accountant; my different hobbies etc.
It would be convenient to:
- be able to organize my areas in a hierarchical way.
- associate actions/projects to any (one or more) area in the hierarchy (different scopes). A drag and drop of multiple actions/project to be added/moved to areas would be nice too.
- to be able to see this hierarchy (when reviewing) in the top area selection boxes (where it is today or on the left panel), in a configurable order and be able to select (multiple) scopes / areas (similar to the way it works today).
Thanks
Interesting. We have thought about making Tags Hierarchical, but had not thought about it for Areas. We will think about it.
One thing I don’t think I agree with is having “Bills” be an Area as Jolygod gives as an example. That seems more like tag to me.
Areas are intended to be Areas of Focus in your life. So examples would be Work, Family, Side Business, Personal, Spiritual, etc.
-
Greg May commented
For those of us who work with clients, hierarchical areas would be great (eg, under WORK, have areas CLIENT 1, CLIENT 2, etc.) It would make it really easy to process the inbox by client (something I accomplish now by assigning client tags when collecting)
-
jolygod commented
Hi James,
Thanks for the reply.*tasks* and *projects* are entities with well defined outcome, i.e. the conditions for them to be finished.
I think that a node in the hierarchy grouping child tasks/projects becomes a scope and not a project, as this node is not "born" with well defined outcomes.
An area of responsibility could be a scope node in the hierarchy instead of maintained in a separate data structure.
I think that this is what I will do in the meanwhile to model a hierarchy of scopes/areas of responsibilities (I would use the info mode but it doesn't allow project child nodes).In fact, if you'd allow multiple parents in the hierarchy, context and tags could also be nodes in the same structure. i.e. assigning @home context to a task could be modeled as an @home parent node.
Looks like the whole task management system could be implemented in a single poset data structure.
Add a minimum 0 node to be a root and a maximum 1 node.
Define [a,b] (the interval) to be set of nodes between a and b in the poset (inclusive).
Without much explanation, I think the following examples explain the idea:{next actions} = [next-action,1] \intersect [task,1]
{scopesof:project1} = [0,project1] \intersect [scope,1]
examples intersecting with tags and context are similar.
Parallel and sequential orders between tasks and projects are also naturally modeled in the poset.
I think a single poset data structure gives quite a bit of flexibility and reduces redundancies when organizing each separately.
-
jolygod commented
A minor note about hierarchical vs tree;
Ideally, I would like to "un-clutter" my areas by organizing them hierarchically and not a tree (today it is a list).
Example, I might create an area called "bills" that is a child of both my "Home" and "Financial" areas of responsibility (the only restriction on a hierarchical order being there are no directed cycles in it) i.e. "bills" would show in both the parent scopes.
That been said, a tree would be a huge improvement over today's, statically ordered by creation date, list.