The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > Applying OmniFocus
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Why OmniFocus v1 didn't support multiple contexts per action Thread Tools Search this Thread Display Modes
Quote:
Originally Posted by digitalagua View Post
@Cypher
Thank you for the reply and that does work. It still seems more of a work around than functionality though. I guess I am more curious as to why multiple contexts are so taboo, and why Omni Group doesn't just add them in.
As a programmer, my guess - and I could be wrong - is that adding them in would drastically increase the complexity of OmniFocus's codebase, gobble up months' worth of programming resources that could be used to add other features, and increase the complexity of the codebase and the test and support resources that it requires, and quite possibly the effort required for other new features, forever after. So that it wouldn't be "just" add them, but a huge effort, because contexts affect everything.

Now, I would think (also guessing) that adding searchable tags that _don't_ act like contexts wouldn't be as much of a nightmare, but then I'd guess that we'd all grumble that we really wanted them to have all the cool features of contexts.

So I can certainly see that as long as Omni isn't convinced that multiple contexts have value, they're not gonna add them. I may disagree on the point of whether they have value, but I can certainly agree that if they don't, they're too big to add just in case.
 
Quote:
Originally Posted by Brian View Post
but when there's a conflict between what's comfortable and what's productive, we really want our software to err on the side of productivity.
You should put on shoes one size smaller and try to run around for a day "being productive". By the end of the day you'll understand that only time you can be productive, is when you have a comfortable working environment.

Quote:
Originally Posted by Brian View Post
This seems similar to the "I need to show Cindy a machine in a certain place" example on the first page - if the action can't happen without the person, we'd recommend that it go in the person's context. Check that context every time you see/meet them, and you'll be able to check it off when you're in the right location.
Ok. I'm collaborating with approximately 80 people. For about 30 of them I have collaborations on private and work matters.
Sometimes I need to call them, meet them, e-mail them. Very often things that can go to e-mail can be resolved when I'm talking to the person instead of sending e-mails.
I'm doing e-mails in timeslots: i.e. "next pomodoro I'm going to spend reading/answering e-mails". E-mails are quite often a part of particular project.


My need is: I must be able to pull up list of related questions for the person when I'm face-to face with them and e-mail items for any person, when I'm working in the timeslot.
My second need: If some topic comes up during the conversation, I want to pull up all the relevant items from my list

What I would want ideally: "Send an #e-mail to #Brian, tell him that #OmniFocus tags are good and small shoes are bad." => 30min,Prj:"Find good #gtd software to replace #omnifocus"
When I start search: #B - it lists #Brian (1), #Bob (4) as a hint with counters for number of items under each. Other #B-tags are not listed, because there are no open tasks with them.
When I'm typing: "#e-" results in a #e-mail hint.

If I would be able to create perspectives based on that - even better.

Question: What is faster: "command-option-F #Br<enter>" or "command-2, find necessary context, click" ???
 
How about just having an Agenda context?

An agenda context for the following:

Agenda:Search Committee
Agenda:Annual Summer Bash Party Committee
Agenda:Employee Evaluation Committee


Then put the tasks into one of these agendas. Go through them and you can decide whether to just call someone, e-mail someone, or delegate it to someone else.

I'd probably eliminate e-mail contexts and phone call contexts and just call it agenda contexts. With so many different variations of contacting someone, it's pointless to just use e-mail, Facebook, phone, etc.

I usually have a pretty good idea of who are the members of each committee. So I don't worry about who I'm supposed to be talking to. In any case, I just CC: everybody in that committee. I already create e-mail groups in Mail.app or use a collaborative program such as Google+ circles or Facebook groups.

I don't worry too much about contact method and just figure out on the fly. I don't need OF to tell me which methods I should use. I know that some people respond better to Facebook than e-mail. Some folks just prefer an SMS message. I don't really like to spend time doing multiple tags when I just want to contact someone.

So maybe the next pomodoro shouldn't be about e-mailing. Rather the pomodoro should be titled "followup on agenda items."





I usually check my contexts once every quarter just to see if there is a context I can add or delete.
 
Interesting to note that Apple are introducing system-wide tags in OSX 10.9.

Time to reconsider them in OmniFocus perhaps?
 
Thank you for this, Brian! The lack of tags in OF has frustrated me greatly over the years, and was my main reason for migrating to Things. It was good to finally get a comprehensive account of your thinking on this matter.

I have one main objection to your argument: For contexts specifying place only, I agree that your current approach works. However, David Allen has himself suggested using contexts for more than just place, e.g. energy level required to do a task (e.g., braindead chores vs. demanding reading).

If I want my contexts to span these two dimensions, place and energy, I have a hard time seeing how I could implement that in OF.
 
I think what it amounts to is that there *are* valid reasons why one task could validly be on more than one context list. The easiest example to provide is a situation where you have phone calls that you want to make in the office, phone calls that are personal (home) calls, then calls that might be validly be made either at work or at home.

I donít think it would invalidate David Allenís system by allowing tasks to be on more than one context list. In fact, Iíd argue that Allen would say the advantage of automated tools like OmniFocus over paper lists is that you can easily have one task fit in more than one context. Because we are stuck with one context in OmniFocus, we are left with workarounds that never quite satisfy userís needs.

Brian, I appreciate your taking on this issue head on in one thread, but what it sounds like to me is excuses for avoiding a many-to-many relationship in the OmniFocus database, which would likely hurt performance and make it a lot more difficult to develop. Letís face it, messing with the OmniFocus database structure wouldnít just affect one program, but three (OmniFocus for Mac, OmniFocus for iPad, OmniFocus for iPhone). I think most of us would be happy just to have the long-awaited version 2.0 arrive on our Macs. :-)

I believe itís disingenuous to say that the OmniGroup doesnít want to implement multiple context tasks because it adds unnecessary complexity and the added complexity prevents users from getting things done, as stated in one of your original posts. True, that added complexity would make it more difficult for the *OmniGroup developers*, but if there is one thing Iíve learned after reading all these workarounds is that these workarounds themselves add unnecessary complexity.
 
Quote:
Originally Posted by Fermey View Post
I think what it amounts to is that there *are* valid reasons why one task could validly be on more than one context list. The easiest example to provide is a situation where you have phone calls that you want to make in the office, phone calls that are personal (home) calls, then calls that might be validly be made either at work or at home.
I realize that I'm responding to a specific case that you're using to illustrate a general point, but this one seems fairly straightforward to me. I'd create separate, non-nested contexts for Phone, Home Phone, and Work Phone. In my Work perspective I include Phone and Work Phone; in my Home perspective I include Phone and Home Phone.

I realize that you may see this as a workaround, but I actually see it as easier. I only have to set up the perspectives and define the contexts once, and then each time I create a phone action--something that should happen far more often--I only need to choose one context.
 
Quote:
Originally Posted by Gardener View Post
I realize that I'm responding to a specific case that you're using to illustrate a general point, but this one seems fairly straightforward to me. I'd create separate, non-nested contexts for Phone, Home Phone, and Work Phone. In my Work perspective I include Phone and Work Phone; in my Home perspective I include Phone and Home Phone.

I realize that you may see this as a workaround, but I actually see it as easier. I only have to set up the perspectives and define the contexts once, and then each time I create a phone action--something that should happen far more often--I only need to choose one context.
Precisely, just trying to illustrate a situation where one task could legitimately live in two contexts, though there are dozens of better examples throughout this thread.
 
In my case, I would kinda sorta _like_ to be able to apply more than one context to a task, but I have yet to find a sitution where the lack of that ability genuinely inconveniences me. So if the answer really is, "No, that would be too expensive and you wouldn't get any other features for eighteen months," that answer would be fine with me. No multiple contexts. I'll be fine. There are features that I want much, much more.

I suppose the situation where I would most like multiple contexts is the "shopping list" scenario. For example, to use a simple personal Next Action, right now I need a hook closure for a skirt. There are six convenient stores that might have one, and one less convenient and generally unpleasant and icky store that certainly will.

It would be handy if I could walk into my handy knitting store and check a context or perspective that shows all of the things that might be bought there (the hook closure, a button that I need for another garment, a copy of Threads) and none of the things that I'm absolutely not going to find there (butter, fire starters, my dry cleaning.)

But when I enter "buy skirt hook closure" as an action am I *really* going to go through all of my "store" contexts and add all of the possibly relevant ones, one by one by one? Or am I instead going to create a Crafty Store context and put the item there, and if I see an entry for yarn while I'm in the bead shop, so be it? If I'm going to do that, then I don't need the multiple contexts.

Now, if I want to have both the Crafty Store context AND the Icky Store context, because I'd be extra anoyed if I went all the way to Icky Store and forgot the hook, OmniFocus already supports that--I create a Crafty Stores context and make Icky Store a subcontext. I apply Icky Store, and that will make the item also show up when I'm looking at the more general Crafty Stores. This does mean that I have to remember to check the Icky Store context, specifically, when I'm there, to make sure I'm not distracted by other items. But I think that the multiple-context request assumes that we're checking the specific context; I assume that's the point.

But now let's imagine that I sew for a living and that I get to The City once a quarter to buy supplies, hundreds of items, and if I miss anything or run out of time I pay a premium to have items shipped. Imagine that I pre-research everything--I can get THOSE buttons at any one of those four places, and THOSE patterns at any one of three other places, and so on. Imagine that I really want clear-cut lists that show exactly who has what.

If I do that, then I'm probably going to just buy some sort of app optimized specifically for that, and take all that out of OmniFocus, and probably nag whoever writes that app to provide some sort of "shopping trip analysis" that tells me that I can get ninety-three percent of my items by going to these three stores, as opposed to ninety-eight percent of them by going to eighteen different stores, but that the first option will cost me thirty percent more for the items that the two options have in common. I could check off or eliminate items and it could optimize my shopping agenda on the fly. I like it! Somebody write it?

Anyway. This is similar to the fact that my bug list for programming doesn't live in OmniFocus, but instead in a separate database that I treat as project support material, because there are just too many fields that OmniFocus doesn't offer--and shouldn't offer; it's not a bug tracking system. Or the fact that some people are going to use contact manager apps even though they also use OmniFocus. For me, there's a level of complexity where the data exits OmniFocus and becomes Project Support Material. And that may be a philosophical conflict, re how one uses OmniFocus.

In my professional-sewing-shopping scenario above, OmniFocus would Next Action me through entering and organizing everything into the shopping app, and through making my travel and lodging plans, and throw a tickler to remind me to check whether ButtonsNThings is going to have their usual January sale, and remind me to follow up with the employee that I delegated to double-check the prices in the shopping app and to confirm that my wholesale buyer paperwork is still good, and tell me to inventory and double-check each day's shopping each night, and so on. It just doesn't handle the nitty-gritty of two gross of semi-translucent white shirt buttons; the shopping list app does that.

So I can't find a situation, for me, where I need multiple contexts that (1) don't already have a hierarchical relationship and (2) aren't so complicated that I want a task-specific app anyway. I struggle to find a situation where they would even really be useful. If Omni Group really does mean "it's too complicated to program/support" rather than "It would be wrong", well, I might want them to be more straightforward, but I still support that decision.
 
I found this thread by doing a search. OF is exceptionally useful to me. It would be even more useful to me if it supported multiple contexts.

The first couple of posts by the fellow at OF reflect two typical thinking errors, thinking that because something works for you it should work for others, and placing too much emphasis on thinking there is a "right" process. It's hilarious reading his analysis of why he doesn't think people need multiple contexts and how he will "help users resolve problems applying a single-context approach". The perfect example of a religious convert that thinks they've seen the light, and over minutia at that, and needs to help other people see it. Heck, he even thinks he's protecting some sacred values by not implementing it, and is willing to "lose out on sales", how admirable!

Different people process information in different ways, and a lot of people are going to find multiple contexts useful. Everything else is largely noise.

If we were talking about a business where it's sometimes crucial that everyone is following the same process, this might be a more important discussion. But OF is for individual users and here, the main questions should be:

1. Would giving people multiple contexts be useful to a lot of users (regardless of whether some people think they've found sacred productivity truth and know that single contexts are best).

2. Could it be implemented without making the software more complicated for users that don't need multiple contexts.

IMO the answer to both questions is yes.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
OmniFocus 2 Ė Multiple Contexts or TagsÖ? [A: Not in the foreseeable future.] effective OmniFocus 1 for Mac 17 2013-02-08 12:56 PM
One action, multiple contexts dp1 Applying OmniFocus 23 2010-07-03 05:09 AM
multiple contexts and multiple projects mind full of water OmniFocus 1 for Mac 7 2008-06-23 09:31 AM
Multiple Activites for Multiple Contexts Journey OmniFocus 1 for Mac 12 2007-12-27 01:03 AM
Multiple contexts per action? pasentcom OmniFocus 1 for Mac 15 2007-11-28 06:37 AM


All times are GMT -8. The time now is 08:22 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.