@Compton
Hi,

Thank you for your feedback!

This feature is similar to the feature called Area which has been in our developing plan. We will consider your suggestion though it is not in our developing plan.

Shall you need any help or have additional questions, please do not hesitate to contact me back.

Thank you for your support!

Best regards,
Doit.im Team
—————————————
Facebook: http://www.facebook.com/imdoit
Twitter: https://twitter.com/doitim
Help Center: http://help.doit.im/
Blog: http://enblog.doit.im/
Group: http://help.doit.im/group/

@wendy_only

I think the Area feature is actually more similar to the feature Goal, that you already have. It would not be good to have to specify yet another property for each new task. Instead, all projects belong to an Area/Goal, and this is a permanent relationship that should be maintained automatically when a task is move into a project. The only problem today is that you can declare a goal, sure, and assign projects to it, but then you cannot really do anything meaningful with it at all (except access it from the left menu). To make the current Goals/Areas feature more useful and better integrated with the other features you would need to make the Goals available for filtering, grouping etc and to have a task view for the whole Goal. And some people (not me, though) would also like to be able to have a permanent switch for switching on/off certain goals, e.g. a Home position and an Office position.

But back to the request made by @Compton above - nested contexts: This request basically aims at solving the same shortcomings that others have aimed to solve with other requests earlier.

Doit currently has both Contexts and Tags, two different features in Doit that very much represent the same kinds of things, namely contextual requirements for being able to do a certain task:

- people contexts: you need to be with John or Mary to be able to do this task
- tool contexts: you need a computer or pneumatic drill to be able to do this task
- location contexts: you need to be at home or at sea to be able to do this task
- timing contexts: this task can only be done early in the morning or during weekends
- duration contexts: you need only a short time or a very long time to do this task
- mood/energy contexts: you need to very alert to be able to do this task, or can be half-unconscious

Currently, we (users) have to decide for each such "thing" whether to encode it as a Doit Context or as a Doit Tag, and afterwards there is no relationship or synergic use between them. They should be better integrated, since they essentially all carry contextual requirement information. They both have their pros and cons:

Contexts are mutually exclusive; a task can only have one. This is perfect for list grouping purposes and for neat availability in the left menu (if you do not have too many of them). I have defined just five Contexts so that my lists will be neatly grouped and the left menu not too cluttered.

Tags you can have as many as you want. This is perfect for good realism and precision, because in reality a task may require both a particular location and a particular person and a particular tool and a particular mood and a particular weather and a particular time of day etc etc etc, so of course we should be able to "tag" the task for all such requirements in order to be able to find them reliably through filtering at a later time.

The problem is that Contexts and Tags do not work together in Doit. For example, why aren't Contexts available in the the quick tag filer? And why, if I change my mind about which contexts to have represented as Contexts (for grouping purposes) and Tags (for all other the contextual details) do I have to redo the whole tag and context definitions and change all tasks? And why can I not be allowed to apply more than one Context?

I think a good-enough solution is very simple:

Tags and Contexts should all be seen as Tags. In our preference settings (tag management) we define which of these tags are going to be used as PRIMARY tags (i.e. "Context") for list grouping and for the left menu, and we also define a "priority" order between these primary tags such that if a task has more than one of those particular tags then Doit will use the "highest" tag as the primary tag. (Alternatively, the manually arranged order in the left menu of the primary tags aka Contexts could be used as a "context priority" - Doit will simply show the task in the first/highest context.).

With such a simple measure, users would not have to make a "strategic" decision up front whether to encode a certain contextual requirement as a Context or a Tag; we could just enter it as a tag to begin with, We could have tags for Sunshine, Night, Lunctime, Energetic, Braindead, Peter, Paul, Sarah, Home, Office, Town, Phone and so on and so on without any worries and we could use them all for quick filtering (narrowing) of our Next list etc. And whenever we want to introduce (or modify) which of these contextual requirements we want to use for list grouping and left menu headings we just edit our preference settings without having to edit a single task.

@wendy_only - or even more elegantly, perhaps: Each new contextual requirement always gets defined as a Tag, as suggested above, because Contexts are now a subset of Tags, but when at some stage we decide to use a certain Tag for grouping purposes etc (i.e as a "primary tag" or "Context") we would not need to go to our preference settings. We could still use almost exactly the same "Context" management as today with the only major difference that when we define a Context we primarily get to choose between all the existing Tags instead of defining a new one.

I agree that these are important issues and are the main reason I have stuck with Doit long term. The workflow friction can be quite high. I return to Doit regularly to see if these types of important features are refined ...