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

 
OmniFocus 1.8 sneaky peeks are now available Thread Tools Search this Thread Display Modes
Forgive me a short trip through some history…
Coming from Life Balance back in the OF 1.0 sneaky peek days, I was expecting action groups and projects to show up in context view when their child actions were complete. The proper behavior was vigorously debated back in the day (see threads here and here).

I considered the OF behavior, which persisted through the 1.7.x releases to be a bit of a hack. In particular, it struck me as very ad hoc that an incomplete action group in a sequential project would not block subsequent actions. That ad hoc design decision was made to prevent projects from grinding to a halt due to an incomplete action group—a worthy goal but an arbitrary distinction between actions and action groups.

My Verify Next Actions Exist script was my work-around for the ad hoc behavior. The script identifies action groups and projects that are incomplete but lack incomplete actions. The introduction of an auto-complete setting for action groups and projects made the script less critical to me, but still important for identifying places where I still needed to think of a new next action.
Given that background, I was expecting to like the change in 1.8 to show action groups and project in context mode. Unfortunately, the problems with No Context and with action groups not being styled as such, mean that the current sneaky peek design messes with my OCD-tendencies.

Like vinyl_warrior, I want to make sure every task has a context. Like several others, I don't want to assign a default context to action groups and projects. GTD theology aside, I've found that I need to consciously decide the correct context for each action. Even if a default context is correct for most of the actions in a project, I still want my system to force me to make a conscious decision. Otherwise I'll end up with a mis-filed action throwing rocks in the water of my mind.

I think the goal of the design should be to arrive at a simple set of rules that users can learn. Having a parent appear in the context of every one of its children, as macula suggested, is intriguing. I think it might work well for those of us who wise in the ways of the Focus. On the other hand, I'm afraid it may be confusing.

I wonder if it would be any clearer to add a Parents bin to the sidebar in context mode. The existing No Context bin and badge would just show actions that lack a context, but never action groups or projects. After all, action groups and projects don't have a "context". They have a "default context". The new Parents bin and badge would show all the action groups and projects, subject to view bar filtering.

This Parents bin proposal gives similar behavior to Ken's suggestion of setting a special default context like "Review" for action groups and projects. It moves action groups and projects out of the No Context bin and into a specific, identifiable bin. The Parents bin has a couple of other advantages: the default context field isn't forced to do double duty and the user doesn't have to set an arbitrary default context.

The biggest drawback of adding a Parents bin seems to be in handling action groups and projects that have a default context set. Some users will expect these action groups and projects to appear in the bin of their default context. Others will expect them to appear in the Parents bin. Still others will expect them to appear both places. I would argue that the Parents bin is the correct place, since the action groups and projects don't have a context of their own. But the fact that there is room for debate means my proposal isn't as simple as it might be. Perhaps it is as simple as it can be though?

I've submitted this as formal feedback to Omni. I'd love to hear others thoughts on this proposed design.
__________________
Cheers,

Curt

Last edited by curt.clifton; 2010-04-23 at 04:56 PM.. Reason: grammar
 
Curt,

Excellent post from an "authoritative" voice :-)
It is perhaps fateful that it literally turns a new page in this thread :-)

Let me say for what it's worth that, unlike you, I did not consider it "ad hoc that an incomplete action group in a sequential project would not block subsequent actions" in earlier versions of OF. Actually it seemed to me perfectly normal and intuitive, as well as conceptually sound. I never think of action groups as anything other than visual indentations in my list of actions required to complete a project. In that sense, I would ideally not even want a checkbox marking a group action as "completed." Does this make any sense to you?

This aside, assuming that the verdict is final and projects/action groups will now be actionable, I am in favor of your suggestion. It seems pretty much what I also suggested as an alternative solution in my post #66 above. (I agree that my other idea of having the project/action group float in all its children's contexts upon their completion may be confusing to novices, although I still think it is the most intuitive, speedy and foolproof in terms of preventing project stalls).

So, yes, a hard-coded "projects/groups" bin in the sidebar would be a satisfactory solution to this significant new problem.

If adopted by Ken and the rest of the developers, it would be wise to combine it with a special sidebar icon for stalled projects (just like there is one for future projects and projects on hold). This way, if the user neglects to take a look at the "projects/groups" bin, and fails to tick off an incomplete group blocking its project, he will at least be visually alerted by the "stalled project" icon in planning mode.

I would be happy to know what you think about all this.

Last edited by macula; 2010-02-20 at 05:16 AM..
 
Thanks for great ideas and suggestions here. I have a different perspective though. I have also used LifeBalance quiet a bit, and it has its advantages/disadvantages. Having projects show up when their action items are great, but if there are no action items at the moment, I had to assign a different place and close it so that it doesn't keep appearing in my to-do list. Of course, next time I assign an action item, I need to make sure their places (contexts in OF term) is changed back . . . This might be similar to KC's suggestion of assigning "review" contexts to projects. The difference is that LB allows you to hide certain places (contexts) so that it's out of your visual cue.

One of the biggest complaints I have heard about OF from people is that it's too complex. I think some of your suggestions might be great for power users, but more confusing to most users.

The solution to turn it on/off globally using the preference set is a step forward, but I wonder if we could make that perspective specific. In other words, that option is stored at the perspective level, and users can control whether they want to turn it on/off based on their needs for the particular perspectives. I don't know if this is feasible or not to program, but I thought I threw in the idea.

For now, I have a macro that turns the option on/off before it fires off the perspectives so that I can have more control.
 
Quote:
Originally Posted by macula View Post
Excellent post from an "authoritative" voice :-) …
Thanks.

Quote:
Let me say for what it's worth that, unlike you, I did not consider it "ad hoc that an incomplete action group in a sequential project would not block subsequent actions" in earlier versions of OF. Actually it seemed to me perfectly normal and intuitive, as well as conceptually sound. I never think of action groups as anything other than visual indentations in my list of actions required to complete a project. In that sense, I would ideally not even want a checkbox marking a group action as "completed." Does this make any sense to you?
I think so. You're using action groups as an organizational device, not necessarily as a device for controlling task dependencies.

I learned project management with GANTT charts back in my days as a project engineer in the manufacturing business. GANTT charts are all about task and resource dependencies. OmniFocus gives remarkably powerful control over task dependencies simply by combining the outlining metaphor with parallel and sequential groups. In fact, OF can handle any dependency scheme apart from those based on relative dates or resource balancing.

However, for these dependencies to work an action group in a sequential project needs to block the task that comes after the group. The pre-1.8 solution that I called ad hoc, limited the power of action groups as a dependency mechanism. The only work around was an external script.

Quote:
This aside, assuming that the verdict is final and projects/action groups will now be actionable, I am in favor of your suggestion. It seems pretty much what I also suggested as an alternative solution in my post #66 above.
Ah, yes. I see that now. I was thrown off the scent by calling that new bin a "context". I think treating it as a separate bin, between No Context and Contexts in the sidebar would be clearer. It also allows a user to just click on Contexts in the sidebar and hide all action groups and projects, which seems more discoverable than a separate preference.
__________________
Cheers,

Curt
 
Curt,

Thinking some more about the whole thing, I believe your suggestion is optimal—both simple for beginners and powerful for those folks who rely on the software for complex projects.

I very much hope the Omni crew will listen to our plea, which after all seems to enjoy consensus more or less. Really, all we are asking for is a hard-wired bin for projects and action groups. Omni produces very elegant software, and pretty much everything is well thought-out; I am sure they realize that the present situation is not tenable in the long term. It's analogous to a stunning Armani shirt with a thick spaghetti sauce stain near the collar.

Speaking of GANTT graphs, in another life I'd had formal training in operations research—and like you subsequently worked as a project manager—so I understand what you mean. That was back in the mid-90's, long before OmniPlan, I believe :-)

Now, how do we make sure that the developers are aware of this suggestion? And can we hope that it will say the light of day before 1.9 ?

Last edited by macula; 2010-02-20 at 07:40 AM..
 
I've looked over how 1.8 works and I've thought carefully about how I might be able to use the new feature of parents and inbox items in the context view and for me the solution is simple.
Please make the visibility of inbox items and parents in context view optional for both the mac and iphone clients. That way the power users can have what they are looking for and I can have what I want also.

I want to be able to throw ad hoc ideas into my inbox and not be bothered with them till I'm ready to process my inbox. (seeing inbox items in context view is distracting and it makes the no context container useless as a method of catching the actionable items I may have missed)

I want to be able to plan in project view. I don't want to plan in context view. I want to be able to burn through a list of things to do. If I want to focus on a project, I'll switch to project view and work from the project list.

I never use default context for projects or action groups.

I have tried my best to understand the new logic but having to specify a default context completely turns me off. Plus it seems to give default context a dual meaning. It's now a context for the project/action group and a default context for the actions.

My vote is to make the visibility of projects, action groups and inbox items in context view optional and for the sake of the folks that don't hang out on the forums and have no idea what's coming, please make the default setting to be off.
 
There is a hidden preference, accessible via a bookmarklet, that turns visibility on and off:

omnifocus:///change-setting?ContextM...sParents=false

Replace false with true in the bookmarklet to turn visibility back on.

Be warned, however, that now if an action group in a sequential project is forgotten and left incomplete after all the children of the action are completed, the project will stall. So, visibility in 1.8 is more important than it was in 1.7.

And that's why we would like it to be well done! ;-)

Last edited by macula; 2010-02-20 at 07:49 AM..
 
Quote:
Originally Posted by macula View Post
Now, how do we make sure that the developers are aware of this suggestion?
Use Help → Send Feedback to submit the suggestion. I sent my long post in that way, with a link to this thread as well.

Quote:
And can we hope that it will say the light of day before 1.9 ?
Your guess is as good as mine. My sense is that the underlying architecture could probably support a Parents bin in the Context View sidebar, so that makes the change more likely. On the other hand, plates are full at OmniGroup these days. But on the third hand, showing parents in context mode is a significant change. Such changes are a big reason for doing sneaky peek releases, so I suspect ears are open for feedback on this issue.

(Disclaimer: I know nothing about the actual implementation of OF beyond what's been posted on the forums.)
__________________
Cheers,

Curt
 
Quote:
Originally Posted by macula View Post
There is a hidden preference, accessible via a bookmarklet, that turns visibility on and off:

omnifocus:///change-setting?ContextM...sParents=false

Replace false with true in the bookmarklet to turn visibility back on.

Be warned, however, that now if an action group in a sequential project is forgotten and left incomplete after all the children of the action are completed, the project will stall. So, visibility in 1.8 is more important than it was in 1.7.

And that's why we would like it to be well done! ;-)
Thanks for the tip! I've gone back to 1.7 for the time being and I have sent my opinion via Send Feedback. I have quite a lot on my plate right now and don't have the time to reorganize my projects. I'm watching this thread though to keep an eye on what will happen with 1.8. I am relieved to hear that there is quite a lot of very intelligent discussion around the new context view feature and I hope that it will be well implemented on final release.
 
I do remember back in the day when this action group or subproject thing was added it functioned in several different ways during the beta and the behavior that was settled on for version 1 was described as a compromise. I think that the version 1 behavior, whether a compromise or whatever, ended up being more flexible than the current behavior.

Without a doubt, some action groups that are part of sequential projects are incompletely planned and so the action group itself has to be completed before the project can move on. The way that I’ve handled such circumstances until now is to have an action at the end of the group to review the group and make sure that nothing else needs to be done. This new solution instead puts an avalanche of action groups, not to mention projects, into the No Context group; makes the default context of the action group or project have two purposes, as sriggs pointed out, which are not always in alignment; and causes sequential projects, which I, at least, had been counting on moving forward, to apparently stall more, until I track down the blocking action group showing up in the no context list - in which there are now a lot of things.

Honestly, to me, it seems like the medicine is worse than the disease.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
OmniFocus 1.7.5 sneaky peeks underway! Ken Case OmniFocus 1 for Mac 1 2009-10-21 01:34 PM
OmniFocus 1.7 sneaky peeks have begun! Ken Case OmniFocus 1 for Mac 56 2009-08-27 04:37 PM
OmniFocus v1.6 sneaky peeks! Ken Case OmniFocus 1 for Mac 32 2009-02-26 01:12 AM
Sneaky Peeks gone? Smithcraft OmniWeb General 5 2007-10-25 05:10 AM
CPU use in sneaky peeks hardcoreUFO OmniWeb Bug Reports 7 2007-08-31 02:23 PM


All times are GMT -8. The time now is 09:44 PM.


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