I see where Daryl is coming from, but I am cautiously optimistic this will work.
It would be nice to be able to mark a tree of tags as only allowing one from that tree. That would allow a Contexts tree of tags that behaved the classic way and also allow new tags from other fields. If that tree could be color-coded, then the Context could be visually distinctive. Interested to see how the final implementation looks.
Couldn’t agree more strongly. Keep contexts and add tags.
You are correct, I don’t lose anything, but I also don’t gain anything. If I just use tags just for contexts, then I still have a nice organized list of my contexts under tags. However, if I start taking advantage of the fact that I can assign multiple tags to a task (which I want to do) and use them for other things, I get one big cluttered list of tags that could represent things from people to energy level to priority. There is no place I can go to just see my list of contexts anymore. That’s why I think it makes sense to have both.
Yes, your message really gets to the heart of my concern. Really what I’m asking for is the ability to group tags, so I can filter/organize my tasks by a subset of them. I could have one group for Context, one for Energy Level, one for Priority, one for Area of Responsibility, etc… Even if they just kept context around, I would still have the issue with cluttered tags for these other groupings – I’d just be more apt to accept it since I most commonly filter things by context.
If my memory serves me correctly, the GTD book does not ever actually say “one and only one context [per task]”. It might be more appropriate to realize that GTD has not aged with the times (i.e. it was cultivated prior to the information technology age and was geared more towards paper-based systems). Tags are the natural evolution after contexts. The terminology change is irrelevant to the actual functionality (they could be called contexts, tags, labels, categories, classifications, etc. but they are all the exact same thing).
GTD aficionados, as you call them, are not the only user group Omni has in regards to their sales mix. Omni needs to care about all of their user groups and make sure their application stays relevant considering that a lot of other task management software programs have a feature similar to (or exactly called) tags while Omni has consistently failed to deliver such a feature for years to their paying customers who have repeatedly asked for the feature.
I am on the side of Omni needs to step away of being a pure GTD program and come into the next generation of task management with other systems that are as good or better compared to GTD. Also, they need to make a profit and GTD is not that popular anymore nor is it a “buzzword” for productivity anymore.
Just my thoughts on this. I cannot wait for OmniFocus 3 as I (and many other users) have completely disregarded OmniFocus 2 as being all but irrelevant for effective modern day productivity. Hopefully, OmniFocus 3 changes my perspective (pun intended).
Multiple tags (or contexts) add functionality, and also complexity. Both things come together. You could create a tag as a different category as contexts, or make tags a subcategoty whithin each context, but again this is more complexity. I suppose you could have a parameter in preferences to opt in or out of multiple tags feature, though I don’t see much gain from it.
What I’m trying to say is that I think we ‘lose’ simplicity to be able to gain flexibility. It will take us some time to adjust, but in my opinion we gain more than we loose.
Lets wait to see how this is finally implemented and hope for the best
I agree. I was in favor of keeping Contexts and adding Tags as a field. I would plan to use them differently. It’s more than just a terminology change, it’s a philosophy change. I will probably adjust to it fine, but my vast preference would be just to add tags as an additional field.
You’ll be able to do this because Tags will have hierarchy just as Contexts do now. You can create a top-level for Context, another for Goals, etc.
Cool, that works for me! Will I be able to assign a color to each tag hierarchy to make it easy to identify when looking at the task?
This is exactly how I hoped it would work. After several false starts over the years (yes, that long), I found Context structure that has lasted me almost a year and it is heavily hierarchical. Happy that I can continue in this way, or try out what I suspected I’d like and go with a much flatter list.
Colors and other customization aren’t in the app currently (we never had anything like this for Contexts); we’ll be watching customer feedback closely during TestFlight.
Emoji has made ALL the difference in making my contexts useful.
I am really looking forward to multi-tag fuctionality, and I am very pleased to hear that hierarchies will be preserved. Bravo! I echo daryl’s call for colors, although I would prefer them to be free-form (manual and scripted) settings rather than being tied to levels of hierarchy.
To me, the success of multi-tag will depend on how they can be used in searching, filtering, reminders, and perspectives. I do have confidence in this Omnigroup team!
I argue that contexts didn’t need color before because they represented a single dimension. The context always appeared in the same place on the task and you knew it was a context, since that is the only “tag” that was supported.
With support for multiple hierarchies of tags that can each represent different dimensions, ideally I would have some way of quickly identifying what tag type I’m looking at when scanning a list. It doesn’t have to be colors, it could be a custom icon or some other way to differentiate – but ideally it would be easy to differentiate between tag types.
I could love color in the form of conditional background highlighting of task items!
So, for example, if you had a #high_priority tag, the background could be shaded automatically. This would mean that instead of having #high_priority items requiring its own list or group, #high_priority items could be highlighted in every group it’s in. It would provide an immediate visual cue that an item in any list needs special attention.
However, I think it should extend to projects as well, or other criteria, e.g., I want every task in my home remodeling project to have a yellow background; or I want all tasks that are less than ten minutes in duration to be highlighted with a blue background; all tasks associated with cost of some sort should be green; etc.
Juts returned here after flirting with ToDoist for a year (back on OF now) Tags are powerful and with anything powerful comes the option to abuse and misuse.
For me I will stick with one tag initially I think, to keep my system working, but I am sure I will expand the system as cleverer people than me come up with good systems.
Let me say I have never read GTD or really have any plan to, from seeing a lot of people have an almost religious zeal for it( that alone would put me off) it appears that it has not as someone stated above worn that well in terms of technology moving on, I will now duck and await the flack.
GTD is wildly misunderstood and often misrepresented… it’s wholly platform agnostic. It is supposed to be guidance. The essence ie the five steps; capture, clarify, organise, engage, reflect are universal… it doesn’t dictate any more. Contexts are introduced as a method of subsetting that list (if it’s too big!) - why would any efficient system present you with tasks that you can’t feasibly do?.. if the context is at parents house, no point me seeing that in my active tasks to do right now. It’s no more or less… it’s intended to be a palette from which you choose the colours that work for you… even if you don’t ‘do’ GTD you will be doing GTD… unless of course you are keeping it all in your head, not clarifying, are not organising, don’t bother reflecting and end up disengaged 😉
Not to derail the original topic, but I wanted to clarify the statement “[GTD is] wholly platform agnostic” as I think this a misrepresentation of the methodology from an objective standpoint. While yes, David has, many times in fact, deflected advocating for one platform or another with respect to GTD and its implementation; he, however, also has only really shown the prevalence of GTD in regards to a paper-based system. The book strongly steers towards this type of implementation (if not explicitly stating so) with phraseology such as “automatic file labeler”, “file folders”, and using the context “At Computer” (i.e. it is redundant to have “At Computer” as a context if you are using your computer to view your lists) ergo David is suggesting to use paper based lists / system and that he uses(ed) such a system. This is also further illustrated throughout several places in the book but suffice it to say that GTD is not a “platform agnostic” methodology per the original “tactical manual” as David calls it despite the best intentions and efforts to assert that it is.
However, do not get me wrong, because I am not saying GTD does not add value to a prospective reader or productivity enthusiast, but I would recommend, as I stated earlier, to move beyond GTD (or even “pure GTD”) and research or utilize other productivity methodologies / best practices. GTD has a mix useful information and not so useful or relevant information. I have never taken much into GTD as a pure system (I do say I implement GTD, but I never say that I practice in devoutly with perfection…as I do not think any productivity system or methodology is that good).
I am glad the OmniGroup is moving towards a “productivity system & methodology agnostic” line of thinking and product development as it will only help them. Now, if they would only start creating Windows counterparts to their Mac products they could tap a large mass of unmet customers / customer needs. Cross-platform software is not an optional goal today, it is a requirement with almost everyone else being able to do so via various frameworks and platforms. Ah well, here’s looking at you kid (i.e. Ken Case).
Another note, for those citing an increase in the complexity of such a change (most likely being GTD aficionados as the OP referred to), I would refer you to David Allen’s argument about information overload and nature. It is not that it is introducing complexity into a system, but rather that you do not know where or how many of the snakes and bears are hiding in the jungle of tags you created for yourself. As someone who has a 125+ tagging system, and uses a mixture of approximately 20 +/- 5 per day per next action / task (note, I do not follow the Next Action -> Project model per strict GTD), I can tell you that it makes my storage and retrieval of to-do’s so much more efficient and dynamic because I can adapt to the ever changing world around me and come out surfing on top of my workload without any problems. Having “one and only one” context would lead to crashing and burning in the fast paced world of today.
I look forward to seeing what OmniFocus 3 has to offer (assuming it ships in the first half of this year).
no flack from me. i think the days when the app. belonged to GTD zealots have long gone. how many contexts (within the strict GTD definition) now simply boil down to ‘@ devices’ or ‘@ online’ for example. I for one am quite excited (within limits - i do actually have a life) about the prospect of the flexibility of tagging.
For my fellow GTDers - and I recognize many people who use OF are not necessarily GTDers–I offer my refined thinking on this issue.
I was a little troubled before (as you can see from my post above) about the deprecation of the term “context,” but I realize where I might have been mistaken. First, I was concerned that the role played by contexts would be diminished in OF such that the symbiotic pairing of project and context was being fundamentally re-thought. After seeing @wilsonng’s post on this (The OmniFocus 3 for iOS TestFlight preview), it is clear to me that the importance that contexts has as an OF dimension remains the same under this new concept of tags, and only the name has been changed.
Second, I was concerned that the re-imagining of contexts as tags was fundamentally changing the concept of contexts in ways that would be incompatible with GTD. I re-read the sections of chapters 7 and 9 of Getting Things Done dealing with contexts. Doing so has made me realize that this tags feature is perfectly “compliant” with GTD contexts. David Allen’s conception of contexts is more flexible than most of us (myself included) seem to have been treating the subject. While I agree the concept of contexts is sacred, as @daryl noted, the sacredness comes from the function it performs not by the name we call it. (“A rose by any other name…” and all that.) Here are some helpful excerpts that I discovered.
When I refer to a “list,” keep in mind that I mean nothing more than a grouping of items with some similar characteristic. A list could look like one of at least three things: (1) a file folder or container with separate paper notes for the items within the category; (2) an actual list on a titled piece of paper (often within a loose-leaf organizer or planner); or (3) an inventory of items on a list in a software program or in a digital mobile device.
Excerpt From: David Allen & James Fallows. “Getting Things Done.” iBooks. https://itunes.apple.com/us/book/getting-things-done/id888011802?mt=11
Over many years I have discovered that the best way to be reminded of an “as soon as I can” action is by the particular context required for that action—that is, either the tool or the location or the situation needed to complete it.
Excerpt From: David Allen & James Fallows. “Getting Things Done.” iBooks. https://itunes.apple.com/us/book/getting-things-done/id888011802?mt=11
As you begin to implement this methodology consistently, you will invariably find inventive ways to tailor your own contextual categories to fit your situation. Though sorting by the tool or physical location required is most common, there are often other uniquely useful ways to filter your reminders.
Before I go on a long trip, I will create “Before Trip” as a temporary category into which I will move everything from any of my action lists that must be handled before I leave. That becomes the only list I need to review, until they’re all done.
Excerpt From: David Allen & James Fallows. “Getting Things Done.” iBooks. https://itunes.apple.com/us/book/getting-things-done/id888011802?mt=11
Most importantly, on this topic is this admonition from Allen:
There is no “right” way to structure your Next Actions lists—only what works best for you, and that part of your system will likely change as your life does.*
Excerpt From: David Allen & James Fallows. “Getting Things Done.” iBooks. https://itunes.apple.com/us/book/getting-things-done/id888011802?mt=11
The goal of tags is to batch tasks, to make sure you are looking at tasks you can actually do in a given environment, and to reduce the amount of tasks you are looking at to a manageable amount. The new tags feature (again based on what I’ve seen in @wilsonng’s post) is a much more robust tool for accomplishing this.
Would I have still preferred OF retain the word “context”? Yes. I’d be lying if I expressed otherwise. I’ve been using the term context (and enjoying the functionality of contexts) for about 13 years now. Old customs and habits die very hard. But I think tags covers broader territory than contexts. On that basis, I can have context based tags: phone; errands; home; office. But I can also have tags for people, for specific devices, for energy level (not likely something I will use). I have contexts for those now, but it never made sense to me that some contexts were places, some were tools, some were people. Now I can have multiple channels. Contexts as an organizing principle is more limited than tags are. And tags are more flexible.
Bottom line for me is that even as at pretty strict GTDer, I am at peace with both the functionality and terminology of tags in favor of contexts.
P.S. With the power of custom perspectives, we probably could create a perspective called contexts and have it configured pretty much the same way as it exists right now, anyway.
