I agree, and in actual fact Doit already has this to some embryonic extent. The Goals feature essentially is a project folder - projects belong to goals - but unfortunately all the realred features are missing: For example, there is no grouping or filtering by goal, nor is there a consolidated task view for the whole goal (listing all the tasks in the goal's projects).
Project folders
It is used to group tasks or projects, and other nested project folders.
As project grow larger, it makes sense to break them down into sub-projects.
-
12/14/2014 10:16#1PRO
-
12/14/2014 15:16#2PRO
@zmfile04
Hi,
Please use Goal to manage your projects.
@Folke
We will improve the feature with Goal.
Thank you for your support.
Best regards,
Doit.im Team
-
12/15/2014 16:12#3PRO
@Wendy + Folke:
Goal is a nice idea to have while organizing tasks, though it's in many way not as elegant as simply as a design that project as a container simply can be nested. Here's why
- GTD is already quite complex a concept and each extra dimension will involve some cognitive burden. If the users are thinking in terms of projects to categorize things, they will feel easier to apply the same concept when things get complex and it's a smoother path.
- Goal is against the intuition in such scenario. When things go complex, you want to BREAK DOWN. You are very likely want to create sub-projects not parent project like goals (that is when you want to make the scope larger).
- Goals are less well-supported as a feature. It's only recent that we have that on all platforms (to some extent) and you don't consistently have access to that info on all UI. Furthermore, you can't assign goals using smart keyword while doing quick entry, which is the way 95% of my tasks are created.
- Goal will give you ONE extra level that's it. It's not an ultimate solution.
Admittedly, at current stage nested project is a far stretch for the dev team if it's not on the drawing board when designing it initially. It involves rewrite a significant amount of client code and back-end code.
-
12/15/2014 16:42#4PRO
Just to define more clearly what the can do with parent project folders.
Functional wise, as a user, I can:
- Assign tasks to a sub-project, and they are also associated with the parent project
- See the total number of tasks (on the project badge) at the upper level
- Drag tasks from a sub-project to another project, and also a parent project
UI design aspect:
- Under the project list view, I can see both normal tasks and sub-project folders.
- The sub-projects are listed above the normal tasks
- The sub-project can be created just like a normal project
- If the project is created under the top level Projects view, it's a top-level project
- If the project is created under a specific project, the new project created will be a sub-project, and the current project the user is viewing will be assigned as a parent project.
-
12/15/2014 19:10#5PRO
@zmfile04
I think you forgot a few things, like e.g. filter and group by this "top level container", whatever it is called.
I think we are on the same page. Whether the top level is called "Folder", "Goal", "Super-Project", "Area" or something else is not my main concern, but the full functionality needs to be there. And I'd advise against having more than one top level ;-)
I think "Goal" is a a good word, because in GTD it means a concrete medium-term "objective" (like a "super-project"). The projects can then belong to these goals. The word Folder has the main advantage that people recognize it from computers. The term "Area" is also pretty good, because GTD has something called Areas of Responsibility (usually one or two dozen, also often seen as roles), and most people use the Area feature in those apps that have one in the sense of "Groups of AoRs", such as Private AoRs, Work AoRs etc. I personally use Goals both as Groups of AoRs and as "Super-projects" (concrete medium-term objectives).