jolygod
My feedback
5 results found
-
9 votes
AdminSergio (co-founder, GTD Next) responded
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.
An error occurred while saving the comment An error occurred while saving the comment 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.
jolygod
shared this idea
·
-
35 votesjolygod
supported this idea
·
-
13 votesjolygod
supported this idea
·
-
35 votesjolygod
supported this idea
·
-
2 votesjolygod
shared this idea
·
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.