De-couple Areas from Contexts.
An area of responsibility is not the same as a context. For instance: for my job, I am responsible for staff development (area), financial (area), process and procedures (area), etc. A context is a tool or someone I could need at any given time to do this: @calls (context), @intranet (context), @boss (context). Unless I am missing something, GTDNext is devoid of the ability to assign contexts unless I use tags to do so, which in my opinion, is not an elegant way to do so, rather more of a work-around. Thanks for your consideration.
We use the more broad term of “Tags” for context. We could have called this feature “context”, as the feature provides the exact same function as what tags provides. However, we choose to call it tags, so it could also be used for other purposes as well, if users so wish.
At this time we are not considering a “context” field that would be separate from “tags”. We never, say never, so if there is enough demand we would look at this again, but at this time we feel that tags does a great job for context.
-
Barry commented
This is a pity. Your program is actually called GTDnext. It is meant to help you to practice GTD. Therefore, use GTD language. Call tags CONTEXTS. It isn't consistent for you to put this kind of effort into a project, put such an elegant package together that is ostensibly meant to help you practice GTD, and then forsake one of the most basic terms in anyone's list management system: CONTEXTS. Don't you want to attract Omnifocus users? Then use the same basic GTD termology! Don't hide your contexts behind the term "tags." :-) Love what you are doing and I would like to get behind it, but for me this has to change. Best wishes.
-
Gustavo Carnevali commented
Folke,
My suggestion would be to start simple and implement mutually exclusive, but personally like multiple especially where @errands is concerned given that I could buy a hammer @target; @home depot; @ace; etc. Usually what I end up doing when I can't multiple tag is to go generic with @errands : hardware. But then I have to remember to check the different generic errands listings.
-
Folke commented
Gustavo,
Your description of areas vs contexts is correct, but I do not quite understand what it is you would like to change.
I have seen contexts implemented in a different ways in different apps, for example mutually exclusive rather than multiple; or hierarchically rather than linear; or with extensive defaults.
How would you like to see contexts implemented?