Does OmniFocus really only allow one Context(/tag) per task?

[Ship69]

Hello

Can it really be true that OmniFocus - the GTD application that everyone says is wonderful - only allows one Context (i.e. tag) per task?

If so surely this is a pretty crippling limitation, no?

I can't experiment myself as I only run Windows but a friend has installed it and he isn't happy!

J

 

[greeno]

Yes, it is true that you can only have one context per task, but I don't see that a limitation, let alone a crippling one.

Contexts can be nested, so I have Home -> Phone for example. This means I can look at my "Home" context and will see all of the tasks nested under child contexts.

You can also use perspectives to gather different types of dashboards or saved searches to be quickly available to you.

I've been using OmniFocus since it was Kinkless GTD and I struggle to see where multiple contexts would be useful. It does require you to put thought into the structure of your contexts though!

If your friend does see this as a problem, it's great that there are so many other products out there that might meet their requirements.

 

[jenkins]

Hello

Can it really be true that OmniFocus - the GTD application that everyone says is wonderful - only allows one Context (i.e. tag) per task?

If so surely this is a pretty crippling limitation, no?

I can't experiment myself as I only run Windows but a friend has installed it and he isn't happy!

J

Yes, you can only have one context per task. You can, however, add meta data to a task such as flagged/unflagged, due date, and estimated time to complete. So you could create a custom perspective to "Show me tasks I can complete on my computer in 5 minutes or less sorted by due date."

Out of curiosity, what do you see as the ideal use scenario for multiple tags?

 

[Gardener]

If so surely this is a pretty crippling limitation, no?

Not really. I'm not saying that I wouldn't like it once in a while, but I've found that I very, very rarely care. And when I consider what it would involve in complexity of interface...eh. I think it was the right call.

 

[Oogiem]

Can it really be true that OmniFocus - the GTD application that everyone says is wonderful - only allows one Context (i.e. tag) per task?

If so surely this is a pretty crippling limitation, no?

Yes correct, only one context per action.

Not at all crippling, instead it's a benefit. IMO the best, properly crafted contexts are mutually exclusive so there is no need for multiple contexts. There are a few unavoidable duplications, I have a context that is either local town or the town just down the road but that is more to avoid having more contexts. The number of items in that list is small enough that I can tell by the action which town I need to do the action in. Some can be done in either, go to the post office can happen whichever town I find myself in.

At one time I thought that I needed to have multiple contexts for actions. But then I learned just how expensive in time and attention it is to switch contexts and that the myth of everything is avail. everywhere is just that, a myth. Really crafting contexts to be specific means it's a lot easier to actually get stuff done.Now I see needing multiple contexts for an action as a sign that the contexts need to be defined better and that they haven't been thought out well.

 

[TesTeq]

In the Things application contexts are just tags. You can assign to a Project many contexts, many Areas of Focus, and many people. POWERFUL. And contrary to the following statement Things developers did a good job (maybe they are less "omni" :-D ):

And when I consider what it would involve in complexity of interface...eh. I think it was the right call.

 

[Oogiem]

One note: There seem to be people who think better with lots of tags and those who do not. I can't remember the details but it's been studied in the context of how you group and associate items and how you prefer to see large sets of information presented to you for review and action. I'm paraphrasing but in general those that like tags, also like mind maps, are often extroverts, do not work as well in strict linear structures. They also tend to clump rather than sort collections. Again, very broadly, those that don't like tags tend to be very verbal or written, not graphically oriented, don't typically like to see random presentations of things but tend to prefer linear, more structured presentations. They are often introverts and typically are engineers or programmers. So to the first type lack of multiple tags is a severe fault in a GTD system while to the second it's a confounding variable that doesn't lead to better understanding or use of the system.

Not that is all very general, useful only in the aggregate not in the specific but may explain the dichotomy between the taggers and the non-taggers.

 

[Gardener]

Programmer here, too. For what it's worth, I feel the urge to say that it's not that I THINK of things linearly. I think of things in ways that are not easily presented visually, so any effort to add structure to the visual presentation just hampers, rather than aiding, my thought process, because it's always going to be the wrong structure.

 

[Oogiem]

Programmer here, too. For what it's worth, I feel the urge to say that it's not that I THINK of things linearly. I think of things in ways that are not easily presented visually, so any effort to add structure to the visual presentation just hampers, rather than aiding, my thought process, because it's always going to be the wrong structure.

I agree, I think that is a more accurate representation of how I think of complex projects but as I recall the research indicated linear was the key difference.

Anyway, I agree, multiple tags per item are not really needed at all, at least not for me.

 

[Gardener]

I agree, I think that is a more accurate representation of how I think of complex projects but as I recall the research indicated linear was the key difference.

I want to re-interview the research subjects. I'm guessing, "A mental model too complex to present visually is best supported by the simplest possible visual presentation--which is linear." wouldn't be a theory that the researchers would anticipate.

 

[TesTeq]

I'm paraphrasing but in general those that like tags, also like mind maps, are often extroverts, do not work as well in strict linear structures. They also tend to clump rather than sort collections. Again, very broadly, those that don't like tags tend to be very verbal or written, not graphically oriented, don't typically like to see random presentations of things but tend to prefer linear, more structured presentations.

I prefer words to pictures and prefer linear, structured world. For me tags are great because they can represent orthogonal (linear) features of the object. For example I can assign AoF tag, Today tag, John tag, Andrew tag, context tag, weather conditions tag, etc. to one Project. They represent orthogonal features of the Project and multiple tags (eg. people needed) can be assigned.

 

[Ship69]

Contexts are the backbone of any GTD system. However David Allen seemed to encourage different categories of Context. As a result sometimes a task can belong to 2 (or more) different contexts at once.

In case my Contexts are about
A) Place and/or
B) Application I'll need to use. But sometimes I also like to tag things by
C) Energy Level Required I even have a couple of weird special Contexts for
E) if I have already put it off too many times ("~Frog") and the amount of
F) Time required if small ("~Tiddler"). As you can imagine it's very easy for Tasks to be in more than one of the above context...

As you can imagine all of the above are NOT mutually exclusive. For this reason I need multiple Contexts per task.

J

P.S. However for me the big problem is the actual entering the Context / tag data.

Just in case any GTD developers are reading this, this what I firmly believe we need is:

1. Multiple Context (or tags) per task
2. User-definable Hotkeys for our Context tags
3. Parsing of all task titles
4. All new Projects/Actions/standalone tasks need to inherit whatever Areas of Life is currently selected
5. All new Projects/Actions/standalone tasks need to inherit whatever Contexts are currently being selected for
6. All new Projects/Actions/standalone tasks need to inherit whatever Tags (if different from Contexts) are currently being selected for.

 

[Ship69]

By the way is there a fundamental difference between the concept of "Context" and "Tag"?

 

[TesTeq]

By the way is there a fundamental difference between the concept of "Context" and "Tag"?

"Context" in GTD describes a common environment required by a set of Next Actions.

"Tag" in Information Systems is "a non-hierarchical keyword or term assigned to a piece of information." [Wikipedia]

You can attach more than one tag to a piece of information. This method is more flexible than hierarchical folder structure.

 

[Oogiem]

Contexts are the backbone of any GTD system. However David Allen seemed to encourage different categories of Context. As a result sometimes a task can belong to 2 (or more) different contexts at once.

In case my Contexts are about
A) Place and/or
B) Application I'll need to use. But sometimes I also like to tag things by
C) Energy Level Required I even have a couple of weird special Contexts for
E) if I have already put it off too many times ("~Frog") and the amount of
F) Time required if small ("~Tiddler"). As you can imagine it's very easy for Tasks to be in more than one of the above context...

As you can imagine all of the above are NOT mutually exclusive. For this reason I need multiple Contexts per task.

I sense that you believe that software should do most of your thinking for you. Instead think about contexts being the first gate you must pass and then the lists contains most of the options. You can use your native intelligence to add the other factors. For example, Place and Application are mutually exclusive. If the Place is critical (Red Barn) then that is the context, but if the Application is critical (Scrivener) then that is the context.

I've never been successful with contexts by energy level in part because the mental and time cost of switching to different modes is far worse than having an assortment of tasks needing different energy levels in the same context. So for me energy level is meaningless as a context. Ditto for time required. When I am looking at my lists I can tell, oh, I have half an hour and I'm braindead and I want to work in LambTracker. Gee, one of my tasks is to print a list of the parents of the sheep we shore in 2016 for the wool samples documentation. That's a braindead task. All I need to do is pull up my LambTracker database, look up the days in my calendar we shore sheep, run the previously defined query to create the list of sheep and their parents that were shorn on those days and print out the lists. Will take maybe 5 minutes to search my calendar for shearing dates and another 5-10 to run the queries for each date and print the results. Once I do that I can check it off and that project (Document the 2016 wool samples) is moving forward. But if instead I say I've got half an hour and I feel bright eyed and bushy tailed and I want to work on LambTracker another one of my tasks in that context is "Write SQLite Query to calculate how many ewes lamb to first service/heat cycle". That's going to take some time and work because I don't know yet how I'm going to correlate the tables that have lambing results with the breeding tables with the dates and times of rams in and out plus the average length of a cycle in ewes modified by our own flock data. I know all the data are in the system, just not sure how to write the query to produce the report I need because it crosses more tables than most of my queries. Both are in the context of LambTracker and I use my own feelings at the time to decide which one to work on.

My equivalent of a Frog task is to flag it or create a due date for it.

So I really don't think that multiple tags or contexts are necessary at all once you really learn how to work within the GTD ecosystem.

 

[Gardener]

Just about the only time that I ever want multiple tags/contexts is for shopping or shopping-like things. ("Shopping-like" things: library books that I want, packing lists for trips, possibly also things like Recipes to Try.)

For me, this issue would be entirely solved by just extracting these things from my GTD lists and putting them in some other list manager, one that's all about lists rather than about organizing work. And that would actually be a good thing for me, because it would get a high volume of tiny "actions" out of my GTD lists.

Now that I've said that, I may go look for that list manager. In an ideal world, it would let me do intersections and unions and differences with the various lists or tags, but that may be pushing it. Hmm.

 

[Oogiem]

Just about the only time that I ever want multiple tags/contexts is for shopping or shopping-like things. ("Shopping-like" things: library books that I want, packing lists for trips, possibly also things like Recipes to Try.)

For me, this issue would be entirely solved by just extracting these things from my GTD lists and putting them in some other list manager, one that's all about lists rather than about organizing work. And that would actually be a good thing for me, because it would get a high volume of tiny "actions" out of my GTD lists.

Now that I've said that, I may go look for that list manager. In an ideal world, it would let me do intersections and unions and differences with the various lists or tags, but that may be pushing it. Hmm.

I did that but since I don't really care about intersections or unions within those lsits I just keep them as notes in my DEVONThink database under the folder GTD Someday/Maybe. I have one for Books to Read - Mystery, Books to Read - Farming, Books to Read - Sci Fi, Books to read - x where x is another 4-5 different categories because I like to have one of each type of book in work at one time, Recipes to Try, Weaving Projects and more things that are lists or menus of stuff I want to do that are all very similar where I know I won't have more than 1 active at any given time.

 

[Gardener]

I did that but since I don't really care about intersections or unions within those lsits I just keep them as notes in my DEVONThink database under the folder GTD Someday/Maybe. I have one for Books to Read - Mystery, Books to Read - Farming, Books to Read - Sci Fi, Books to read - x where x is another 4-5 different categories because I like to have one of each type of book in work at one time, Recipes to Try, Weaving Projects and more things that are lists or menus of stuff I want to do that are all very similar where I know I won't have more than 1 active at any given time.

Yep; I do have lists like this outside of GTD. I'm trying to decide whether I'd actually use the "sets" thing or if it just seems cool and would never get used.

Just as an example of what I mean, I might want "The Toyota Way, by Liker" to show up in lists:

- Books to read
- Books to get
- Amazon
- Library
- Joe
- References for Lean

The idea is that if I'm talking to Joe, I see it in the Joe list and ask him if I can borrow his copy. If I'm on Amazon and I want to fill out an order to be big enough for an add-on item, I'll look at the Amazon list to find something that I was going to get anyway. And so on.

At some point I might buy the book and read it. Then I would remove it from many of the above lists, but it would appear in:

- References for Lean
- Books I read in 2016
- Books in the den
- Books I own

Do I want this? Would I use it? I can't tell.

 

[Oogiem]

Yep; I do have lists like this outside of GTD. I'm trying to decide whether I'd actually use the "sets" thing or if it just seems cool and would never get used.

Just as an example of what I mean, I might want "The Toyota Way, by Liker" to show up in lists:

- Books to read
- Books to get
- Amazon
- Library
- Joe
- References for Lean

The idea is that if I'm talking to Joe, I see it in the Joe list and ask him if I can borrow his copy. If I'm on Amazon and I want to fill out an order to be big enough for an add-on item, I'll look at the Amazon list to find something that I was going to get anyway. And so on.

At some point I might buy the book and read it. Then I would remove it from many of the above lists, but it would appear in:

- References for Lean
- Books I read in 2016
- Books in the den
- Books I own

Do I want this? Would I use it? I can't tell.

Well in my case it does appear in 2016 Books Read, and in the files I keep for Books Owned Non-Fiction if in hardcopy or Books Owned Kindle if I got the kindle version. All of that is either in DEVONThink or linked via indexing so I can search in DT for it by name or author. If I took notes on it and included the word lean in my notes I could find it by searching for lean although I'd probably get a lot of false positives. If I could narrow the search t include a partial author name I'd find it fairly fast.

So I geuess I already have the sets stuff covered by how DT handles searches but I almost never use it that way. I almost said never but then I realized that I have on occasion used DT to search for some obscure paper I know I kept that isn't in the cleaned up section of my hard drive (that is still an on-going project) but that I could remember bits of. I was able to find it without too much wasted time.