Showing context names in "All Contexts" view
 

I'm new to OmniFocus, so cut me a break if I'm missing something easy here.

All I'd like to do is sort my contexts by due date (tomorrow, this week, etc.), but also show the context name next to the task name. This is the screen I'm talking about, with the purple showing the area where I want the task's context name to show (click for larger view):

[URL=http://img379.imageshack.us/my.php?image=omniop1.gif][IMG]http://img379.imageshack.us/img379/8514/omniop1.th.gif[/IMG][/URL]

I use the general context view to see a basic picture of what I have due this week, drilling down into different contexts if necessary. I can't see what context a task is in using this format, though (unless I'm in the context, of course).

If you select the actions of interest, then click on the focus button and switch back to project mode, you can see what contexts they fall into as well as any ordering dependancies with other actions.

But why? Why be forced to go through convoluted hoops, just to see perfectly reasonable data in your view of choice? In fact, that doesn't take you to your view of choice anyway, as you're now in project mode!

Mark

[QUOTE=MacBerry;46496]But why? Why be forced to go through convoluted hoops, just to see perfectly reasonable data in your view of choice? In fact, that doesn't take you to your view of choice anyway, as you're now in project mode![/QUOTE]

Maybe three reasons: because OmniFocus is (1) a version 1.x product (2) whose original inspiration was GTD (Kinkless) and early alpha-testers mostly GTD proponents (3) produced by a company whose primary concern is the stability of the product and security of its data, not adding new features all the time.

Ken Case has stated repeatedly that Omni Group plans future refinements to the data structure and UI--for instance, arbitrary metadata columns. But they have not been as important as syncing. It's clear that Omni listens to user feedback, as witnessed by their quick addition of an option to instantly clean up completed actions.

On the other hand, given that OmniFocus was inspired by GTD, with its distinction between project lists and action lists, I don't think the distinction between modes will disappear any time soon. But I'd be surprised if Omni doesn't add an option to show a context column in context mode by v1.2 or 1.3.

I'm afraid that makes no sense to me Brian - I'd expect an early version to be simple, with complexity to be added later on. Instead we have an overly complex programme that needs simplifying!

I've asked elsewhere for an explanation of the benefits of the two modes, which appear to do nothing but confuse new users. I accept the GTD argument, but the UI doesn't have to be confused to achieve that - it can easily have the sort of UI I suggested elsewhere, with "plan" and "do" modes added that take advantage of that UI without restricting the user.

Yes context and project lists are meant to be separate in true GTD, but as it is now I can't create those lists the way I need them to be.

Put another way, contrary to concentrating on stability and data security, OG appear to have spent a lot of time second guessing what the user may want to see, and so have ended up restricting those of us who want more flexibility. Not putting a context column in context mode while having one in projects mode undoubtedly took more work than simply making the same choices available in both modes.

If they'd spent less time doing that, and instead said "let the user decide what he/she sees", the programme would be a lot better and more flexible now.

Bottom line Brian is that I [I]keep[/I] running into brick walls that appear to have been put in place deliberately, and so far I've seen no explanation of why?

[QUOTE=MacBerry;46515]Not putting a context column in context mode while having one in projects mode undoubtedly took more work than simply making the same choices available in both modes.[/QUOTE]

I don't follow this assumption. The two views are very different, so I don't think that you can safely assume that they both come from some common view from which the Context column was removed for Context mode. I realize that you may be saying that you don't _want_ the two views to be very different. In my case, I find many of the other differences to be valuable.

In any case, while I would like the option of a Context column in Context view, I would want it to be optional - I'm already having a problem with getting enough screen width for my project names, so I wouldn't want to be forced to give up screen width for a Context column that I may or may not want in a given Perspective.

So I'd want this column to be optional, which I'd guess would be a good deal more work than just leaving it out. To me, it's a "would be nice" feature - I certainly wouldn't have considered it a drop-dead requirement before delivering the first version, and I wouldn't have put it before synchronization features.

Gardener

From where we are now I'd agree my assumption may be wrong, but from what I think would have been a logical starting point for this kind of programme, I think it's valid.

Of course the context column would have to be optional, just as it is now in project view. I think that goes without saying.

I really would like someone to explain to me the benefit of the two modes. Not so much which specific feature of each you value, as the concept behind them; when am I meant to use each; what's the thinking behind creating them? I.e. someone [I]please[/I] explain "modes" to me.

At the moment I see nothing but disadvantages to the setup, but there must be some design logic to it surely? Some explanation that would have me saying "ah, I get it now".

Mark

[QUOTE=tswartz;46486]
I use the general context view to see a basic picture of what I have due this week, drilling down into different contexts if necessary. I can't see what context a task is in using this format, though (unless I'm in the context, of course).[/QUOTE]

As you may have gathered from the ensuing discussion, this isn't currently possible. Besides Will's suggestion, two other work-arounds that you might try are:[LIST][*] Double-click the bullet next to an action to open a new window focused on the actions project and showing context information.[*] Leave the inspector open so you can see the details for the selected item.[/LIST]
Both of these are far from ideal, since you can't see the contexts for all the items at once. Be sure to use [URL="http://forums.omnigroup.com/showthread.php?t=3734"]Help --> Send Feedback[/URL] to submit your feature request.

I think that people will commonly use the sort, then click on the sidebar to see what is due for each context...

But I'll be honest, this is the first time I've seen this pointed out. So...I guess most people aren't using that particular view very much, or they're getting by some other way.

In the meantime, I'd recommend following the advice of making sure that your actions are sentences, so that even on their own its clear as to what needs to be done.

A bug has been file though, and thanks for pointing this out.

The main reason I'm asking for this: the print view. When I print the overview of my actions while in the context area (I don't want to print one particular context), I get this output:

Due today:
Name of task - Project - Due Date

Due tomorrow:
Name of task - Project - Due Date

This view is exactly how I have it setup in the Contexts area. Why can't I just add the context name? The whole concept of contexts is useless if I can't see what the context is when I print a list. You can't be saying I'm the only Omni user who prints by due dates. There's no way to tell where the action belongs.

Printing the Projects area is never going to happen either, since it'll place the whole project in the "Due today" area if ONE action is due today. Yes, I can view the context while looking at the project view, but it is not very useful because I have a ton of tasks in the "Miscellaneous" project. If one of them is due today, my whole Misc. project prints on the top of the page (regardless of due date).

And I anticipate this coming up: why do I print the list? I can't use OmniFocus at work (Windows) and don't want to deal with two programs. I don't feel like staring at my iPhone all day either. (This also leads to asking if I can print "due today" and "due within the next week" ONLY? Can't find that option either, so I get a list of every single action I have due date or no due date every time I print.)

[QUOTE=MacBerry;46515]Bottom line Brian is that I [I]keep[/I] running into brick walls that appear to have been put in place deliberately, and so far I've seen no explanation of why?[/QUOTE]

OmniFocus was inspired by Ethan Schoonover's [URL="http://kinkless.com/kgtd"]Kinkless GTD scripts[/URL] for OmniOutliner Pro. Many elements of the UI, including the distinction between context and project (later renamed planning) mode came out of Kinkless.

That's the historian's answer to the question, "Why?"

Thanks Brian, but it doesn't explain why it needs to be that way, or what the benefit is? "Because it's always been like that" isn't a good reason in my book. In fact, when that explanation starts to appear it should be a prompt to re-visit the design urgently, because it usually means people can't remember what the benefit's meant to be.

Mark

Mark, I have two responses, and then I really have to get things done! :-)

1. My point about history was to emphasize the origins of what is a [B]version 1.x product[/B]. OmniFocus has already evolved beyond Kinkless's UI, but short of a radical redesign, it's going to retain some of those UI features, especially in 1.x. Maybe 2.0 will feature a radical interface redesign. But I hope not, because:

2. I think there is a good reason for retaining the distinction: it's the distinction between commitments/outcomes/goals that can't be done in one concrete step (projects) and steps toward them (actions). In another thread you remarked that project and context views are just different ways of looking at actions. I disagree; I consider the action to be a means to accomplishing the project, and the context as a means (in a broad sense) to accomplishing the action. I find that the distinction between planning mode and context mode brings me a real benefit because it corresponds to how I conceptualize planning and doing.

And now, back to work!

[QUOTE=MacBerry;46650]Thanks Brian, but it doesn't explain why it needs to be that way, or what the benefit is? "Because it's always been like that" isn't a good reason in my book. In fact, when that explanation starts to appear it should be a prompt to re-visit the design urgently, because it usually means people can't remember what the benefit's meant to be.

Mark[/QUOTE]
Mark,

no offense intended, but perhaps your disagreement with the design choices is an indication that you're trying to force a square peg into a round hole, and would be happier with an application that didn't require so many changes to fit your needs. I recently fired up my old copy of iGTD (which features the same planning/context split), and it strikes me that it looks a lot like what you seem to be asking for (though without iPhone support, which I'm sure would be a sticking point). It also looks incredibly cluttered to me, and I don't miss it at all!

I agree that it would be nice to have an optional Context column in Context view. I just don't agree that that points to a fundamental flaw in the overall design. If you had only one view, what would that view show? When I look at the two views and try to imagine combining them into one, that seems to me to produce a lot of complexity, and inevitably lose some functionality.

Gardener

[QUOTE=whpalmer4;46675]Mark,

no offense intended, but perhaps your disagreement with the design choices is an indication that you're trying to force a square peg into a round hole, and would be happier with an application that didn't require so many changes to fit your needs. I recently fired up my old copy of iGTD (which features the same planning/context split), and it strikes me that it looks a lot like what you seem to be asking for (though without iPhone support, which I'm sure would be a sticking point). It also looks incredibly cluttered to me, and I don't miss it at all![/QUOTE]

Yes you're right - iPhone support is key. It's only because of that that I'm here in the first place!

But no, I don't think it's the wrong app. It does most of what I need. My point isn't that it doesn't suit me specifically, but that it's confusing to the wider audience that Omni (pressumably) need, and will get as a result of the iPhone version. Just take a look at many of the posts on these forums for an indication of that: very very many are along the lines of "why can't I do or see xyz when in such and such a mode"

There is no reason at all to compromise the separation of context and planning views, but there is a need to make both much more flexible. I've suggested one approach in another thread, but it doesn't have to be done that way so long as it is done.

Either way, there is a definite and urgent need to explain the point of the two modes, and the restrictions each places on the user. As it stands, I'm doing things in context view that should probably be done in planning, and vice-versa, just because I can't see the data I need to see in the "correct" mode. There are also things that I'd like to do in a combination of the two modes (e.g., when reviewing, I may want to change either context or project, so need both clearly in view in a consistent manner).

So, again, someone [I]please[/I] explain the two modes, because as I've said already, I'm more than willing to accept that I've just not understood yet.

[QUOTE=Gardener;46700]I agree that it would be nice to have an optional Context column in Context view. I just don't agree that that points to a fundamental flaw in the overall design. If you had only one view, what would that view show? When I look at the two views and try to imagine combining them into one, that seems to me to produce a lot of complexity, and inevitably lose some functionality.

Gardener[/QUOTE]

I've suggested an alternative elsewhere, but you're right that that alone doesn't point to a fundamental flaw. What points to that (at least until I hear the explanation I keep asking for) is the lack of a whole set of view options in each mode, that all restrict my ability to set up perspectives to show what I want to show. The restrictions exist, the explanation of why, doesn't!

If I'd been designing this, I'd have had one view capable of showing everything, filtered and sorted by, umm, everything, and would then have built in perspectives that set the view up to reflect the various modes. Instead we have the modes hard coded, with perspectives remaining limited by the design choices made when creating those modes.

Think of it this way - you could give someone a wardrobe containing all colours, and then help them choose the best clothes for red or green days (that'd be my approach), or you could give them a red wardrobe and a green wardrobe, and tell them that if they need anything else they can only mix and match one item! The second approach lets them deal with red and green days just as effectively as the first, but restricts them badly on yellow days.

Red and green wardrobes may be fine, so long as the benefits and the reasoning behind the restrictions are clearly explained to the user.

Mark

[QUOTE=brianogilvie;46653]I think there is a good reason for retaining the distinction: it's the distinction between commitments/outcomes/goals that can't be done in one concrete step (projects) and steps toward them (actions).[/QUOTE]
Who ever said that a more flexible UI would be at the expense of that? Why can't I have all options for setting up the views the way I want, but then have built in perspectives or modes to set that up the way you want?
[QUOTE=brianogilvie;46653]In another thread you remarked that project and context views are just different ways of looking at actions. I disagree; I consider the action to be a means to accomplishing the project, and the context as a means (in a broad sense) to accomplishing the action.[/QUOTE]
I didn't say that at all! I said that from the point of view of the user, there was no difference between something defined by metadata, and something defined another way. I don't care how the list is created internally, I'm only interested in the list!

At the level of the tool used to organise the actions, just as in DA's book, projects and contexts are no more than lists filtered or arranged by different criteria. The way you [I]use[/I] those lists may well be fundamentally different, but the benefit of the tool being a digital one should be that it is easy to set up the lists any way I want.
[QUOTE=brianogilvie;46653]I find that the distinction between planning mode and context mode brings me a real benefit because it corresponds to how I conceptualize planning and doing.[/QUOTE]
Good, then please explain how you apply that - how does planning mode let you do all of your planning, and how does context view allow you to do all of your doing? Because I can't get a "do" list that doesn't need at least some of what's only available in planning mode, and I can't get a review list that doesn't need contexts in the side bar and other features only available to me in contexts mode.

Mark,

I'm somewhat reluctant to post, expecting a sentence-by-sentence rebuttal, but here goes…

[I]Planning mode is[/I] for manipulating the [I]hierarchical[/I] representation of your projects. It is, at its essence, [I]an outliner[/I].

[I]Context mode is[/I] for viewing a cross-sectional [I]sample of actions[/I] (leaf nodes in graph theory) from your projects. It is, at its essence, [I]a flat list[/I].

I don't like to quote the gospel according to Allen, but I think chapter 8 of Getting Things Done provides some motivation for the current distinction between the modes. In particular, Allen suggests that one reviews one's lists of next actions by context on a daily basis. He suggests reviewing projects on a weekly basis. The implication is that these are, from the reviewers perspective, separate lists.

Certainly OF's distinction in modes is not strictly necessary, as the overlap in configuration options for the two modes attests. However, I'm also not yet convinced that a single view mode with sufficient configuration options to get all the current views would be any easier to understand. Perhaps a UI mockup would help me see the light. (If the academic year weren't underway here, I might try to mock up [URL="http://forums.omnigroup.com/showpost.php?p=46574&postcount=11"]the iTunes-motivated design[/URL] that I mentioned in the other thread.)

I [I]am[/I] convinced that a Smart Groups style interface would be an improvement over Perspectives. I think Omni agrees and has that in the pipeline for a future version.

(And since we're not going to see a complete UI re-design in the next few days, one tip to keep in mind: Double-clicking the bullet of an action in Context mode will display a new window focused on the action's project. With that one tip, I'm perfectly happy planning in Planning mode and doing in Context mode. Reviewing happens across a variety of perspectives and in both modes.)

Thanks Curt.

Sorry if my previous replies have seemed like rebuttals. I've re-read them, and don't really think they were because in fact I agreed with a lot of what people were saying, but I can see where the overall impression may have come from. I'm afraid one of my pet hates is asking a question and then receiving a roundabout or evasive answer, or worse still an answer to a totally different question, so when I find that happening I tend to react badly.

Your reply was extremely helpful. That combined with the fact I've been playing around with OF this afternoon (quiet day!), means I think I'm beginning to see the light! I can see the intent and benefit's of each mode, though I do still think both have limited flexibility, and wonder if the same couldn't be achieved just as well without the modes.

Maybe it boils down to a lack of enough filtering, sorting and grouping options in each mode (OF does need more). Or maybe it's to do with clarity - an awful lot of the answers to questions people ask on here are only obvious when you understand that the modes work the way you describe. So either it needs to be a lot more obvious in the programme, or there needs to be a lot more info available.

I think it's also to do with the lack of a clear "do" mode. So far I can't get a good focussed do list I'm comfortable with in either mode, which may be largely why I keep jumping around in both and trying to filter etc, 'till they fit.

Mark