Contexts vs Tags

A major difference found between task management systems is between contexts and tags. My own preference is for contexts, at least for the reasons I outline below. Meanwhile, I wonder if others make tags work in ways I have not considered and welcome any thoughts in the comments.

One and Many

The difference between contexts and tags may be more subtle than at first recognized. In general:

Tasks may be assigned only one context

Tasks may be assigned any number of tags

While it may seem that tags have an advantage based upon this initial impression, I feel there is actually an advantage to the restriction placed on contexts. It’s not quite a “less is more” idea, so much as it is more similar to a restriction of a flow that ultimately produces a sound.

An Example with Tags

Take, for example, a task such as adding a list of ingredients on an iPad/laptop list for later use. It needs to be done at home, in the kitchen, and either on the laptop or iPad.

Using the tag system, one may write:

Copy list onto iPad or laptop – #home #kitchen #laptop and #iPad.

A major point of the GTD system is being able to look at a context list based upon one’s location and/or available tool and readily be able to choose a task without having to consider whether or not it can be done. Where or with what a task can be done is written up front, either at the time of task entry or while processing an inbox.

In this scenario, were I at home in the kitchen and I selected #home, the task “Copy list onto iPad or laptop” would appear. However, if I did not have either my iPad or laptop there, the task could not be done, and the task list “#home” would be compromised. Confidence would lost that the task list accurately reflected what could actually done at the moment. One would recognize the need to re-think through each task. As forethought is the name of the game, the system is defeated.

One could theoretically add the functionality of an AND/OR system similar to the iTunes smart play lists. However, one then runs into the problem of needing to tag everything with all possibilities of tools, people, and places. You may see a task in the #kitchen, realize you need your laptop, and then recognize that the task has not been tagged with the #laptop. You would then need to create the smart list to reflect the present situation and add the tags as needed.

This latter method could be functional and may even become a part of a workflow, but it is additional work.

An Example with Contexts

Consider, however, the functionality that is created by contexts. Because only one context is allowed per task, one then needs to carefully consider which parts of the task require which tools. The singular action of Context lends nicely to working with the phrase “a person, place, or tool without which the task cannot be done”. The task may even be realized as several tasks:

Task 1 Get laptop or iPad @bedroom,

Task 2 Get cookbook @kitchen

Task 3 Write list @computers (encapsulating both iPad and laptop)

While this is a simple project, the concept holds for larger projects as well, where the gathering step may not be immediately apparent. Other examples surely exist. The assignment of a single context, in this case, fostered the conditions for actually doing something about not having the proper conditions for work, as well as helped break down the project into smaller components.

While I explain elsewhere an implementation of tags in creating categories for projects and tasks, it is not something I use much. I imagine tags have their uses in task management system that I have simply not considered and welcome your thoughts.

21 Comments

Prior to OF I organize my tasks with Things – and learned to use tagging.

Yes it seems more flexible to assign multiple tags – but on the other hand it leads to a huge amount of tags and the feeling of ‘I need more tags to handle this or that!’

Even outside task management I get often trapped in this manner.

3 months ago I gave OF a try and the hardest part was to understand the approach with contexts. I have to admit that I was struggling at the beginning and I have searched the web for help – so I found you and your excellent book.

What should I say? Well, I will never again miss the context-driven approach and so OF! Yes, you have to sit down first and make yourself clear, what are the contexts of your life – and then everything works fine and easy: I just have to think of, with what, where or with who I have to do the job – that simple!

This is my ‘episode’ of the ‘Context vs Tags’ blockbuster 😉

But as almost always: there is not one way, there is your way – so if you like tags, keep on tagging 😉

Actually you can use tags like contexts. Just assign only one tag per task, voilà. But tags are more flexible. It’s not often but sometimes I wished I had more than one context available. Especially in combination with people-contexts. For example there are tasks I can only do at a special location when a specific person is available. Or I can do tasks at more than one place but not “anywhere”. In my case this is often the case when I know that a book is available in two libraries (my university has a dozen specific libraries and some books are available in several). It’s not a general generic errand but one which would be active when I am close to or in one or the other library.
OmniFocus is a very very flexible tool and if you want you can probably emulate every other ToDo-tool out there with OF. The only place where it is not flexible are contexts because you can only assign one and cannot “tag”.

Contexts have worked well for me. My experience of GTD stretches back to the OF pre-cursor with Ethan Schoonover.

I use tags, and the issue I have is to remember to use those already used, rather than some slight variation, for example. Tags grow to clouds very easily, and it is not so easy to rationalise them once they have been created.

An example is in using MailTags. Now having Projects available linked into OF for MailTags means I should replace most of my historical messages (many thousands), with the OF project task names. but instead I live with both.

Where I want one tag as an addition to a context is when I need to have a person context AND another context (such as a place) for the same task. It is though I need a different dimension to be added for such a thing. Tags would be a ‘simple’ solution, if carefully implemented and managed. An addition, not a replacement.

An example? I have a context called ‘waiting for’ – though the task could say ‘FRED’, actually it will state what the task is, which might not say call FRED, but I know I have to have his input which I have already asked for in a previous task.
I would not be able to quickly call up all the tasks waiting for ‘FRED’ without breaking open the system by remembering to add ‘FRED’ to each task note (which might no longer be needed once I have the response from ‘FRED’). That means I will also need to delete ‘FRED’ from the note once sorted, or it will keep on appearing in filtering even when the context might change to something else.
Hope this makes sense.

The use that I would have seen for tags is to put things on to an agenda with a person that belong in another context or for which the work required to move contexts does not make sense.

The place in other apps that I’ve used it is to put things into a list to talk with my boss about. For example, I have a weekly meeting with my boss. There are actions that I specifically put into the agenda: boss context. These are actions where the action is dependent on our meeting. But on Monday I ask her for some information that I need to advance a project. I put that into a waiting context.

On Thursday morning in anticipation of our meeting I tag the waiting for actions so that I can remind her of them. I may also put on actions that I only need to report to her. The reporting isn’t a true next action because I’m reporting the status as of the beginning of the meeting. It is entirely possible that a couple of actions will occur on that project just before our meeting so trying to figure out where in the scheme of things the action of reporting should occur is a lot of effort for new gain.

I see tags as a way to create a system that I can trust to remind me of things we should discuss but which are not actions required to advance the project. If my boss is unavailable one week we skip the reporting and the report of the status at that time never occurs.

If I stick the reporting in to the flow then when it comes up as the next action and the meeting won’t happen for 2 days then that next action becomes a block to being able to advance the project. Do I wait for two days until I can complete the meeting? Do I have to go back into my project every time that meeting item comes up and move another action ahead of it so I can keep advancing the project before the meeting? Then will I remember to report if a different action is ahead of the report in the next action list?

I have to admit – the only thing holding OmniFocus back from being a 10 out of 10 is the lack of Tags. For me, it’s not a ‘Contexts vs Tags’ thing – I would love them both! I use Contexts similar to the way you do. But I would use Tags more like a user definable Flag that can be sorted on.

In OmniFocus, Flags are a simple boolean On/Off, with no basic definition of what the Flag means. It’s great for creating a single on-the-fly list (ie, I find myself unexpectedly forced to run out for an important errand, so I check my Errands Context, and realize I don’t have time for the 15 other things on there, so I quickly Flag 4 or 5 of them to do while I’m out) But since there is only one Flag per item, I can only create one such list. I’d often like to have more. For example, a Things I’d Like To Get Done Before Going on Vacation list; that is a list of things that don’t necessarily have an urgent or specific due date, but just gives me an additional method of focus to tackle things. It is a list that would exist for only a couple of weeks, but if implemented using Flags, it would tie up the Flagging method for that entire time.

Another example of a use for Tags is assigning user-definable priorities. Some Tasks I would like to Tag as more urgent than others – I could create something like a 3 or 4 level priority for Tags and assign them ad hoc at will. Some Tasks I don’t really care to have a priority, and wouldn’t Tag them with a priority Tag at all.

I guess I see Tags as more flexible way to organize. It can bridge the gap of rigidity (Tags that are always available like a priority level system) and flexibility (Tags I can create ad hoc, use for the length of time that I need them, and then throw them away)

From a higher perspective, when I consider the whole GTD paradigm, Projects are a way of grouping related Tasks together that are necessary to lead to a common goal; great for organizing and planning. My ‘Build Deck’ Project combines all the Tasks needed to build the deck in my backyard. Contexts are a way of grouping related Tasks together by the state or method of getting them done; great for actually accomplishing all the Tasks I have set for myself. While I’m at the hardware store, I can pick up all the things on my ‘Errands – Hardware Store’ Context, and end up getting all the things I need from there for my ‘Build Deck’ Project, but also anything else from unrelated Projects.

I see Tags as another way (actually, multiple user definable ways) of grouping Tasks in whatever groupings I want. Sometimes I want to view Tasks by Project, and sometimes by Context, but sometimes I want to view them in a different grouping, and the flexibility of Tags allows me to do this in whatever way I choose.

I guess for me, dividing the planning and organizing (Projects) from the actual doing of Tasks (Contexts) isn’t always the way things work. I’m not always going to be thinking “okay, I’m on the phone, what phone calls do I need to make”. Although this is one of the primary purposes of GTD, to give you focus on what you can do and eliminate focusing on what you can’t at any given time, I’d still like the option of pulling my head up from the Phone Context and taking a look at the bigger picture sometimes to see if maybe there might be a better way to spend my time right now. Maybe getting out of the Phone Context and into a different Context would allow me to work better at a given time. And I can see ways that Tagging Tasks might allow me to find that middle ground of flexibility between rigid adherence to a Context focused execution.

To me this seems like a bit of a false dichotomy. I don’t see it as necessarily a tags XOR contexts question, as you seem to here. There’s no doubt about the utility and accessibility of locationally-/situationally-defined context, and Omnifocus’ opinionated stance here provides a productive constraint. I do wish OF would allow multiple contexts for a given action. To take a canonical GTD example, I could have a “Brain Dead” context. Now, there are times when I’m not actually in the brain dead state, but I am in the correct physical context to do that task next. Similarly, there are actions that could be done on an iPad *or* on a web-connected Macbook.

Multiple contexts would be great, but adding arbitrary tags would also give an additional potential dimension to actions. These could provide context-like metadata, or something else entirely, allowing one to define quick views of related actions across difference projects that are not necessarily related by context.

Multiple contexts per action would cover most of what people want from tags; tagging would itself add an additional dimension.

If something could be found at either 1 or 2, then select Group A as your context?

Clive, I have a similar complaint with tags in that they do tend to grow into clouds.

If I understand the situation with Fred and Waiting for correctly, one thing I tend to do is separate the call/emailing action from the agenda items.

In other words, I can have a Waiting for Fred to return my call @ Waiting for, but in the note field I have a context link to Agenda : Fred.

Ted, for the Agenda : Boss item that needs to wait until Monday, I would still consider it an Agenda : Boss item, but I’d put a start date on it for Monday morning. If there are agenda items to discuss, I’ll just leave them in the Agenda : Boss context until they can be addressed. If I’d rather not see them until the future, they’ll get a start date or be conditionally set with sequential tasks that define their conditions.

I see that if the Agenda item becomes a next action while that person is not around, it no longer works as a next action. In that case, it truly is not a next action and the project’s plan needs to be re-worked to meet reality.

Jonathan, I could see the tagging system you describe as another means towards creating priorities. Just as you describe, I believe it could work very well for some, but for myself, I know I’d get thrown off. If I have more tiers than flag vs unflagged vs on hold, I know I’ll get confused.

Your last two paragraphs are very on point and I think one of the reasons I like OmniFocus – that Planning and Doing are nicely distinct, but in practice they need to be done to some extent simultaneously. Working from context view, one needs to be able to snap back to planning and back again quickly. Option-Command-r is one of my favorite key commands for this reason.

Anaxaman, I wonder if you could use Perspectives for these situations. Command select the projects you want, then focus on them, switch to context view and Save it as a perspective. Would that work similarly?

There may be a false dichotomy set up as you describe.

All in all, I think that tagging can certainly add a particular dimension to some workflows. I just worry if it would detract, at least myself, in some ways that I cannot readily foresee. Sometimes, a “feature” could become a detractor. A lot about the use of a task management system is balance or even a homeostasis. There is a risk anytime something is added to a relatively stable fishtank – it could enhance or it could wipe out half the tank. Of course, I speak for my own particular usage. Were tags introduced, I would adapt as would anyone else.

You misunderstood me. If you have tags, you can create tags that resemble contexts. Create a tag “home”, a tag “computer” and so on. And then you use them like contexts. You do not have to give a task more than one tag, that is optional. So, if you want to use contexts, then just give a task only one tag.
Nested tags are possible as well (as seen in Things, even so it’s not implemented well).
The advantage of tags is that you can give more than one to a task.
I see contexts as a subgroup of tags, just with the limitation that I can add only one context to the task. Alternatively you could see tags as a way to give multiple contexts to a task. And depending on your personal system add other metadata.

Coming back to OmniFocus. I could already use now tags. Just add them in the Notes-field and then I can search for them. But this has two disadvantages:
1) I do not have auto-completion. Would tags be first-class-citizens in OmniFocus there could be auto-completion like with contexts. That omits also the problem of diversifying tags too much – the “biggest” problem of tags. But this gets solved with auto-completion imho.

2) I cannot create perspectives based on tags. I.e. someone has a system where he wants to have priorities. Right now there are 3 prioririties: flagged, due, overdue. But I can’t add “important”, “very important” etc. in OmniFocus. If there would be tags, you could create a perspective that shows you only your “very important” tasks. This is just an example. I could also create a perspective based on the tags “home” and “computer” or whatever.

I see tags as in adding flexible meta-data which you can use the way you want it: contexts, priorities whatever.

With tags the field: Estimate, Context, Flag would suddenly become obsolete (maybe not the flag because it is very easy to add a flag). All those could be easily re-created using tags. *And* I would have the option to extend it as far as I want. Nobody forces you add 20 tags to each item or create tons of tags. It’s just adding flexibility.

Btw. The Hitlist has a very nice implementation of tags (the one of Things has imho too many problems which made me not to use them)

Tags are a strict superset of contexts. Everything done with contexts—including making them hierarchical, as OmniFocus does (with your @computers context containing @ipad and @laptop)—can be done with tags. But many things which can be done with tags cannot be done with contexts.

The great virtue of tags is that you can then use them to create other cross-cutting views of your tasks and projects, aside from the primary context view. You can implement flags, Things’s (wonderfully simple and powerful) notion of “today” list (or your own “tomorrow” or “next week” lists), highlight things you want to review, or virtually anything else.

The power of contexts is not that there is only one of them, or that they can be hierarchical. The power is that they create a second, cross-cutting view of your data. In a sense, canonical GTD (including OmniFocus) is a system with two (and only two) classes of tags on items: projects and contexts. As I said, you can also think of OmniFocus’s Flags as one more special tag. And indeed, having a streamlined UI built around a conventional set of schemata is great. But with real, user-defined tags, a huge space of user-customizable workflows also become possible—both more complex, and also *simpler* than the canonical GTD flow currently baked into OmniFocus.

User-defined tags are extremely well matched to OmniFocus’s Perspectives: Perspectives could easily allow the user to define their own views much like Projects and Contexts, but sorting, grouping, and filtering on entirely different classes of tags.

Based on how the article has been written, I would say that GTD has this right with the use horizons of focus and contexts. I don’t feel the need to tag items because I instinctively know which area of focus I’m looking in for a particular action, and so pull up a context-based perspective for that area of focus to find the task. When I’m processing and need to find an action in another project, I open a new window, show a perspective called Show All Projects and search it, then I can update it or link to it.

I’ve put a lot of thought into my contexts and I don’t feel the need for tags in my particular setup. When I first read an OF feature request for tags I thought they would be really handy but I don’t now. If, as an earlier poster wrote about tagging actions to do before a holiday, I would have a single project for it, focus on it and then work in Context Mode.

If you had asked if contexts and tags can work together, then I’d say that it gives us more options although I wouldn’t necessarily use them just because they’re there. I use tags extensively in DevonThink Pro Office where I have support databases for projects and for areas of work and personal life. These databases are far less structured than how I have OmniFocus set up and the tags are used for searching for items rather than having rigid folder structures. I use as many tags as possible when adding documents to the database as I find that it’s very mood-dependent how tags are added and I haven’t always found something in the future.

It’s all very interesting and I’m sure if OmniFocus 2.0 turns up with tags we’ll see some innovative uses of them.

Damon, I think I share your feelings on tags. Using them for prioritization may confound a rather robust system that already exists with contexts. I would similarly create a project for the pre-vacation work. Alternatively, one could focus on several projects and create a perspective based on those projects to do before vacation.

To each their own, of course. It is clear that some readers find benefit with tags and using them towards prioritization. I’m glad to have stirred up some discussion over the matter, and I appreciate all of the well thought comments.

One of the difficulties of your solution to my “Things To Do Before Going on Vacation” list is that the Actions I want to put on the list may already be parts of another Project, or multiple Projects. I don’t want to take them out of those other Projects, because then I lose all the workflow aspects of having them in those Projects to begin with (ie, being a part of my regular Review schedule, holding a place in a sequential Project workflow, etc)

For example, let’s say I am going away on vacation on Friday. On Monday morning I do a regular Review of most of my active Projects. During this Review, I start to notice Actions here and there that I’d like to get done before leaving on Friday. Maybe two of those Actions come from my “Build a Backyard Deck” Project, one comes from my “Install New Kitchen Faucet” Project, three from my “Complete Income Tax Return” Project, 2 more from my “Plan Steven’s Surprise 40th Birthday Party” Project, and five of them from various Single Action Lists I have set up.

Now, if I create a specific Project for my “Things To Do Before Going on Vacation” list, then I have to pull all those Actions out of the Projects that they are currently placed in. This causes me to lose some of the effective workflow management aspects of those individual Projects. For example, if I pull the “Buy Invitations” Action out of the “Plan Steven’s Surprise 40th Birthday Party” Project, which is a sequential Project, then all of a sudden, the next Action in that Project starts showing as available, and now I’m looking at a prompt to “Address and Mail Invitations”, when I haven’t actually bought them yet. This effectively goes against one of the whole points of GTD.

To me this seems like poor organization. Doing things this way defeats some of the purpose of organizing Actions into Projects in the first place. (This doesn’t even take into account what happens if I don’t actually complete that Action before going on vacation, which may be likely, and then I have to reintegrate the Actions back into their individual Projects, possibly readjusting the workflow of each Project to account for this!)

I agree with the previous posters who have stated that Projects and Contexts are just subgroups of Tags, that have specific attributes, functionality and workflow concepts attached to the groups themselves. Basically, all we have are a huge set of Actions. We try to group them in various ways in which they are related, to make it easier to work with them: to make it easier to organize them (Projects help do this); to make it easier to perform them (Contexts help do this); to make it easier to Review them, etc. But in the end, all we are doing is grouping Actions together in various ways.

Creating and using Projects allows us to group Actions together in a specific way – Actions that string together to complete a larger common task. The concept of Projects allows us to work with those groupings in various specific methods and to track specific things about the group as a whole (ie, defining a Project as sequential or parallel) But in doing so, we’re just creating a set of “Project” Tags that each Action gets, and then tracking another set of data for all Actions that have a given Project Tag.

Similarly, creating and using Contexts allows us to group Actions together in a different way – Actions that require a like situation or circumstance to accomplish them. Again, we are then able to track specific things about this group as a whole (for example, specific location data related to the place we need to be to perform these Actions) But again, in doing this, we are effectively just creating a set of “Context” Tags that each Action gets, and then tracking another set of data for all Actions that have a given Context Tag.

Using Flags is the same thing, but much more basic, given their simple On/Off state. It’s just another way of grouping Actions.

So in the OmniFocus world, we are limited to only 3 ways of grouping Actions: Projects, Contexts, and Flags. And although this is great for most applications of GTD, there are instances where I would like to group Actions together in different ways. And Tags would greatly open up the flexibility to do this. Now I could create not just my own groupings of Actions, but my own methodologies of grouping Actions as well. I’ve already mentioned 2 ways I could see implementing this: the one I’ve just discussed of throwing together an ad hoc list of Actions I’d like to accomplish by a certain date (even though that may not be a specific hard due date for each Action on the list); or user definable prioritization coding. Another hypothetical way I could see this being useful is if I manage a group of people as well as managing many of the tasks they perform. I can create of set of Tags to assign the Actions to specific individuals. This wouldn’t necessarily fit well into Contexts, because each individual may look at the tasks assigned to them and then decide for themselves which Context they should be in. But it would allow me to track who is doing what, it would allow the people involved to focus on their own tasks and no one else’s, and it would allow me to still organize the overall workflow into various sub-projects, etc. Maybe there would be a good way to implement something like this using only Projects and Contexts, but given that this idea just came to me while typing this response, my first impression is that it would need more.

A Tagging system would just seem to open up flexibility so much. True, you could accomplish most of what I am talking about here just by including specific keywords in the Notes field, and searching/filtering based on that. But a solid and robust Tagging system would be so much easier to work with.

Like I have said previously – a well Implemented Tagging system integrated into OmniFocus would take it from really great to absolutely fantastic! 🙂

Jonathan, a well-reasoned argument for the use of tags. Thanks for helping me see another perspective.

Based on the holiday situation, I would still work with a holiday project and add a recurring action to work on actions due before holiday. I would add a link to a “Due” perspective and add due dates to actions in all the projects you mentioned. I would then see those actions on the dates I want to work on them. I know you mentioned that some of these actions wouldn’t have hard due dates so this method isn’t exactly what you’re looking for and I understand how tags would work for you in this situation.

As for assigning tasks to staff, I would add an action to delegate the task to a staff member using their agenda context. Once delegated, I would put that action into a “waiting for” context and add a start date for when I’d chase that person up if the task hasn’t been completed. Horses for courses.

I mentioned DevonThink Pro Office earlier. I used to add tags to a comments field and search that before tags were implemented. Tags with auto-complete and a tags section where you select the tag and see everything in the database with that tag is highly-productive. I don’t worry about creating a rigid, hierarchical folder structure in the database. A good set of tags allows the database to be loose and free-form, in itself a trusted system where I know I’ll find what I’m looking for.

I’m not yet sold on the idea of using tags in OmniFocus because, in my system, it’s adding another layer of complexity. I’m happy with my system right now. I was also happy with my system before reading Kourosh’s book and I made some big changes based on some methods that made sense to me and I’m a lot more productive because of them. I hope OmniGroup implement tags in v2 so your system can be improved. I may find myself using them upon learning more techniques on their use.

I agree that is a nice description of where tags would come in handy. As with Damon, I would use due dates to gather them, but understandably, that method has its limitations.

One feature I’d like to see implemented that could work well for such an issue is an alias task. One could have a task that, when checked, is checked off in multiple places. This way, one could create a project dedicated to stuff to do before vacation entirely composed of alias tasks. When they are checked off, they are also checked off in the original projects.

This would also lend to further adjustments in various hierarchies. As an example, I could have several tasks in various projects waiting for a single task to complete. Rather than write a Waiting for … task in each of them, I could create a series of aliases that when one of them were completed, then all of the projects would then move forward.

Your idea of alias tasks sounds a lot like clones in an outliner application. Clones have been requested for OmniOutliner for a long time. Maybe the Omni developers could develop this in tandem for both applications.

As I have been reading this discussion and thinking about why I might like tags, I think the utility of tags is to give additional ways to categorize actions, which would then allow for fine tuning of them.
I’ve recently seen several comments that some of the “traditional” contexts that David Allen laid out in his books are not of much use to those who essentially carry their office with them in their cell phones and computers. So they have looked at creating contexts relative to their energy level or emotional state. I can understand that one would like when in a low energy level state to not take on a task requiring high attention and be able to work a task requiring less energy, but at the same time, I don’t want to have a Brain Dead, low energy task that I have to do at home appearing on my list when I’m at my office. It creates clutter. On the other hand, it might be nice to identify tasks requiring low energy within a context to allow for selection of tasks appropriate not only to the context one is in, but also the time, energy and priority of the task.
I am using the iPad and iPhone versions of OF and don’t have a Mac. I know that OF for the Mac does have an estimated time. So for the Mac, presuming the flag gets one of the GTD four criteria, 3 of the 4 criteria are covered, but on the iphone and ipad, only 2 are.

Great post! For me, tagging is best for independent variables and I agree that contexts are mutually exclusive (ignoring the fact that they can be nested of course).

I think that tagging works best when you assign attributes to research; say chapter and character if you’re writing a book. To use this analogy, lots of characters could appear in a single chapter, but lots of characters could be referenced by a single piece of research. This parallelism could be the main difference between a research system and a task system, where context is essentially serial.

That’s an interesting thought – that tags function better for reference and context for action. I’m still in a process of thinking tags through.

I wonder if the use of tags depends even more on habit than does general task management. A consistency in how one tags, like your example using characters in a particular piece of research, could be very useful.

I think the ablity to apply Tags would be helpful in the following situation. Let’s say I’ve set up a number of tasks, on which I’m dealing with “Bill”, and I’ve added a “phone” context to one of these. When I phone Bill to deal with that particular task, if Ihad applied a ‘Bill” tag to all other tasks involving him, I could use the phone call to discuss all these other tasks also, perhaps completing many them.

That could work. The problem, however, might come in that there are many items with the “Bill” tag that might not be actionable. The tag may have been set more as a way of showing a relationship to that object. I prefer to separate agendas and call items.

Recent Posts

OmniFocus is a registered trademark and is used under license by the Omni Group. For more information on The Omni Group products the user may visit their website at the Omni Group. For OmniFocus, please visit the OmniFocus homepage.

This product uses or is based on Getting Things Done® or GTD® Principles. It is not affiliated with, approved or endorsed by David Allen or the David Allen Company, which is the creator of the Getting Things Done® system for personal productivity. GTD® and Getting Things Done® are registered trademarks of the David Allen Company For more information on the David Allen Company's products the user may visit their website at www.davidco.com.

Apple, Mac, Mac OS, iPad, Multi-Touch and iPhone are trademarks of Apple Inc. Other company and product names may be trademarks of their respective owners