[eatmytag]

I have solved my single task problem by creating a _project group_ called "Single Tasks". I then use projects as single tasks. This way, They are ready to accept sub-tasks if the need arises and are unordered - all projects are next actions.

Alternatively, they could be sorted into one of my project folders. Folders are great! Project grouping without sub-projecting! It took a while for me to figure out the correct difference between contexts and project groups. Here is how I use contexts and project groups:

Context: the _place_ where the task can be done. I work at three different offices, but some of my tasks, I can do anywhere. At first had created @office1, @office2, and @office3 and put all @officeX related tasks in their related context. I found that my mistake was that I should have put some tasks in e.g. @mac or even @email since they were unrelated to the physical office.

Project groups: the _topic_ or _area_ which the task belongs to. I realized my context mistake when I found myself naming my project groups using the same names as I had used for my contexts. "This can't be right" I thought.

So now I have contexts such as @mac and @mac:internet, @officeX, @email/im/phone and @home. My project groups are called things like "OfficeX: Documentation", "People to contact" etc.

Hope this helps somebody.

[brab]

I just tried using projects as single tasks, but the problem is that they do not show up in the context view. Do you still do it this way?

[Ken Case]

Originally Posted by brab

I just tried using projects as single tasks, but the problem is that they do not show up in the context view. Do you still do it this way?

Single tasks can now be assigned directly to a context, without having to assign them to a project (or turn them into a project).

[eatmytag]

No, right now I have put my single tasks into a "single tasks" project for two reasons:

1. Projects not showing up in context view
2. Projects not being assignable a context.

It's a bit tricky though. For single tasks as projects I would like to assign projects a context, but when using projects as containers (sub-projects as containers as well), I do not assign sub-projects contexts as I do not want the containers to show up in the context view.

My current solution is to view context view showing all available tasks giving me an overview of my workspace.

[brab]

I now use the "official" approach to single tasks: tasks without a project. It works pretty well except that tasks whose start date is not due yet are shown.

[johnrover]

Originally Posted by brab

I now use the "official" approach to single tasks: tasks without a project. It works pretty well except that tasks whose start date is not due yet are shown.

Yes, I'm having the same issues. I have a lot of "projects" that are simple. They involve only 1 task, but might involve more later. I would like the "project" to also be a task, if the "project" has no sub-tasks assigned

Right now in order to get one of these simple project/task things to appear properly in the context view, I need to create a "project" with one "task" inside it and assign a context to the task. And, just in case more sub-tasks spring up, I should really assign a default context to the project.


This is a lot of extra keystrokes when all I need is a reminder to "call Karina and remind her to bring my jacket to the party".

I don't want to have a "shopping" project to contain my "pickup milk" task (context = errands –> grocery store, due date = today) and "pickup batteries" task (context = errands –>radio shack, due date = next week).

Extra projects clutter up my "project" view and over complicate the organization and make the experience cumbersome. I recognize, and need, the ability to use project heigherarchy to organize complex projects. But I want my little reminders in the same program without the added complexity.

Does anyone have a good workflow to address this? Am I missing something?

[johnrover]

Furthermore - In some of my bigger projects, Tasks have subtasks that have sub tasks. And some of them require that the actions be done in order and some don't.

I don't really see the need to differentiate between "projects" and "tasks". Wouldn't it be easier, simpler, and more flexible to have every "task" be a "sub-project" and every subtask be a "sub-sub-project" with all of the same options and metadata, including an "actions must be performed in order" true/false?

Why the disctinction? it seems to complicate things. What am I missing?