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 > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
Showing contexts in "All Contexts" Thread Tools Search this Thread Display Modes
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:
Originally Posted by MacBerry View Post
Bottom line Brian is that I keep running into brick walls that appear to have been put in place deliberately, and so far I've seen no explanation of why?
OmniFocus was inspired by Ethan Schoonover's Kinkless GTD scripts 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 version 1.x product. 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:
Originally Posted by MacBerry View Post
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,

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:
Originally Posted by whpalmer4 View Post
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!
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 please explain the two modes, because as I've said already, I'm more than willing to accept that I've just not understood yet.

Last edited by MacBerry; 2008-09-08 at 02:53 AM..
 
Quote:
Originally Posted by Gardener View Post
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
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

Last edited by MacBerry; 2008-09-08 at 03:20 AM..
 
Quote:
Originally Posted by brianogilvie View Post
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).
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:
Originally Posted by brianogilvie View Post
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 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 use 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:
Originally Posted by brianogilvie View Post
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.
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…

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

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

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 the iTunes-motivated design that I mentioned in the other thread.)

I am 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.)
__________________
Cheers,

Curt
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
"Active Contexts" showing with no "available" actions? jasong OmniFocus 1 for Mac 28 2013-08-29 09:03 AM
"Nearby" location-based contexts return incorrect results endoftheQ OmniFocus for iPhone 11 2010-07-31 12:19 PM
Feature request: "Pairing" contexts with Bluetooth devices an WLAN srudersdorf OmniFocus for iPhone 0 2010-02-27 08:43 AM
Toggle from "Contexts" to the "Project the Entry belongs to"?? jkrytus OmniFocus 1 for Mac 1 2008-01-17 01:46 PM
"Projects" view + "Contexts" view are slightly mis-named / misconceived RobTrew OmniFocus 1 for Mac 31 2007-08-23 07:19 PM


All times are GMT -8. The time now is 06:54 AM.


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