The Omni Group Forums

The Omni Group Forums (http://forums.omnigroup.com/index.php)
-   OmniFocus 1 for Mac (http://forums.omnigroup.com/forumdisplay.php?f=38)
-   -   OmniFocus 1.8 sneaky peeks are now available (http://forums.omnigroup.com/showthread.php?t=15345)

Ken Case 2010-02-16 11:30 PM

OmniFocus 1.8 sneaky peeks are now available
 
[B]First, what are sneaky peeks?[/B]
[INDENT]Sneaky peeks are our latest (unstable) internal builds. These internal builds are exactly what we see here at Omni: they're just snapshots of our development that are updated every few hours and haven't gone through any sort of vetting process—which means that you might actually be the first person to try a particular build and discover that it eats your system. (We hope that doesn't happen, of course—it would be pretty upsetting if a build were to eat any of our files when we run it—but since we won't have tested the app before giving you access we can't make any guarantees.)

In other words, sneaky peeks aren't for the faint of heart; they're an invitation to come join us on the bleeding edge of our development process.[/INDENT]
[B]Now that that's out of the way, what's new in OmniFocus 1.8?[/B]
[INDENT]OmniFocus 1.8 for Mac improves task workflow by including projects, groups, and inbox items in Context lists, Due lists, and Flagged lists. This prevents these items from slipping through the cracks, and makes it easier to check them off when they're complete.[/INDENT]
[B]Workflow Improvements[/B][INDENT][B]Groups, Projects, and Inbox items now show up in Context lists, Due lists, and Flagged lists.[/B] When actions are sorted by project, parent items follow their children (which is the natural order for completing them). Single Action Lists are not actionable, and do not appear in Context lists.

[B]Groups are now considered actionable.[/B] They can block other actions in a sequence, and are eligible to become the first "next action" for a project. Groups are blocked by their children.

[B]We've reorganized the filtering options in the View Bar[/B], separating the Availability Filter from the Status Filter and adding some new options. For example, you can now choose to show all Remaining items which are either Due or Flagged—or only those Due or Flagged items which are currently Available.

[B]Context mode can now display all actions at once[/B]: you no longer have to choose between showing Remaining or Completed actions. (This is great for viewing a list of all items by date modified, for example.)
[/INDENT][B]Synchronization[/B]
[LIST]
[*]Sync Preferences now has an option to publish an OmniFocus Reminders calendar for due task notifications.
[*]Sync settings sent through email are now compatible with iPhone OS 3.0 and later. (In iPhone OS 3.0, iPhone Mail stopped recognizing dashes in URL schemes, so we've switched to using omnifocus:///setup-sync?url=...)
[*]Edits in progress should no longer get lost when changes are synchronized from another computer.
[*]Fixed a bug where syncing a change to an action's start date wouldn't always change its context's count of available actions.
[*]Fixed a bug which could cause duplication of a repeating due project or group during synchronization.
[*]Improved sync compatibility with some Windows WebDAV servers.
[/LIST]
[B]Attachment List[/B]
[LIST]
[*]The Attachment List now sorts its attachments when it first appears (rather than only sorting when you click on a column header).
[*]The Attachment List now obeys your date format settings from System Preferences.
[*]When the Attachment List is visible, it no longer shows up twice in the Window menu.
[*]Fixed a crash seen when double-clicking on a perspective icon attachment in the Attachment List.
[*]Fixed a crash encountered on 10.4 when clicking on the column headers in the Attachment List.
[*]Fixed a crash encountered when deleting large numbers of attachments at once.
[*]The Attachment List will no longer refuse to delete attachments which it can't find in the container's notes.
[*]The Attachment List is much faster at handling long lists of attachments.
[/LIST]
[B]Miscellaneous[/B]
[LIST]
[*]Added support for omnifocus:///add URLs for adding items via Quick Entry (as introduced in OmniFocus 1.6 for iPhone).
[*]Added support for changing synchronized settings through settings links like this:
[INDENT]omnifocus:///change-setting?DefaultDueTime=22:00[/INDENT][*]Updated the built-in help.
[*]Updated the iDisk icon in Sync Preferences.
[*]Updated the flag in a number of icons.
[*]Fixed a bug where Due Soon items wouldn't always update on schedule.
[*]When a project is on hold or otherwise inactive, its actions are no longer considered to be available.
[*]Project mode can now display the Project column. (The current project is implied by the project hierarchy, but a separate column can be useful when reviewing a project and reassigning actions to different projects.)
[*]Duplicating a project from the sidebar no longer skips completed items in that project. (This matches the behavior of duplicating a project in the main outline.)
[*]The "No Context" sidebar item no longer counts items which are assigned to dropped contexts.
[*]Fixed some regressions with the application unhiding while using Quick Entry.
[*]Fixed a bug where OmniFocus could incorrectly indicate you were in a perspective when opening a related window (e.g. double-clicking on an action in the Due perspective would claim that the new window was also in the Due perspective).
[*]Checking for updates will no longer trigger an "invalid display" message to the Console.
[*]Spotlight searches support searching for completed actions.
[*]The gear button in the column header area is no longer stretched and blurry, and its border line now lines up with the scroller line below it.
[*]Fixed a crash sometimes encountered when double-clicking on Library in a focused window.
[/LIST]
You can download the latest build-of-the-day from the [URL="http://www.omnigroup.com/applications/omnifocus/download/sneakypeek/"]OmniFocus sneaky peek download page[/URL].

We look forward to your feedback!

dbyler 2010-02-17 12:00 AM

Love the update—particularly the availability/status rework. This is worth the download alone.

Minor suggestion for future release notes: [B][I]highlight[/I][/B] any changes that might affect user workflow so they're more obvious. As good as it is to know that a certain bug has been fixed, it's workflow changes (like how projects are blocked or filters are modified) that matter most.

ksrhee 2010-02-17 12:40 AM

[QUOTE=Ken Case;73441][B]First, what are sneaky peeks?[/B]

[INDENT]OmniFocus 1.8 for Mac improves task workflow by including projects, groups, and inbox items in Context lists, Due lists, and Flagged lists. This prevents these items from slipping through the cracks, and makes it easier to check them off when they're complete.[/INDENT]
We look forward to your feedback![/QUOTE]

Great improvement on workflow! Thanks for this. Now is there a way to hide this feature or at least have a way to distinguish projects in the list via style? With the addition of projects on the context/due list, I'm getting overwhelmed and confused by whether they are action items or projects.

Thanks.

Tony Stinson 2010-02-17 02:46 AM

"No Context" Items
 
Thank you for the updates, Ken!

One question: Now in Context view, all of my projects are showing up in the "No Context" list. Since Projects can not be assigned a context, how do you clear this up? Is this normal with the new changes?

Tony

cashdollar 2010-02-17 03:53 AM

Is there anyway to turn-off or filter out having projects show up in my context lists? When working in context mode, I don't want to see my projects, just my calls, errands, etc. It gives me way to much information when I want to be doing. Thanks.

marcussommer@mac.com 2010-02-17 04:20 AM

how to enable the beloved URL quickentry feature?

Arild 2010-02-17 04:52 AM

[QUOTE=ksrhee;73444]Great improvement on workflow! Thanks for this. Now is there a way to hide this feature or at least have a way to distinguish projects in the list via style? With the addition of projects on the context/due list, I'm getting overwhelmed and confused by whether they are action items or projects.

Thanks.[/QUOTE]

Same here, when having a column containing the project, it is not really necessary for me to have that extra project row below the action. My experience is: I'd perhaps like to have that row below if my action was the last one in the project, but probably only then. I would, however, prefer a pop-up saying something like "No more actions in related project/group" with three options: 1. <See entire project> (new window), 2. <Mark completed>, 3. <Close>
This pop-up feature could be default on for new projects with an Inspector tick box.

radek.salomon 2010-02-17 04:52 AM

Hello.

I am still confusing when I set the Project filter to All Projects I see also dropped folders. The dropped projects are removed by moving to archive, but not the dropped folders.
How can I fix it to remove the dropped folders?

The same situation is in context mode. The dropped context is still in the list and I cannot remove it.

Thank you for your advice.

Radek

Fireproof 2010-02-17 05:25 AM

Can we get a screenshot or two of this new feature:

[quote]
Groups, Projects, and Inbox items now show up in Context lists, Due lists, and Flagged lists. When actions are sorted by project, parent items follow their children (which is the natural order for completing them). Single Action Lists are not actionable, and do not appear in Context lists.
[/quote]

I just want to be sure I understand what you mean. Thanks!!

ksrhee 2010-02-17 05:51 AM

[QUOTE=Arild;73450]Same here, when having a column containing the project, it is not really necessary for me to have that extra project row below the action. My experience is: I'd perhaps like to have that row below if my action was the last one in the project, but probably only then. I would, however, prefer a pop-up saying something like "No more actions in related project/group" with three options: 1. <See entire project> (new window), 2. <Mark completed>, 3. <Close>
This pop-up feature could be default on for new projects with an Inspector tick box.[/QUOTE]

Yes, it would be great if we have the project show up when there is no action item associated with it (as long as there are items, even future items, it wouldn't show up), that way we can take action on the project (add a new task, hold, drop, etc.). As is, the extra appearance of the projects or groups is completely non-functional in my book since I can't really take any action on those items.

Ken Case 2010-02-17 06:02 AM

[QUOTE=ksrhee;73453]Yes, it would be great if we have the project show up when there is no action item associated with it (as long as there are items, even future items, it wouldn't show up), that way we can take action on the project (add a new task, hold, drop, etc.).[/QUOTE]

You should be able to do that now:

If you switch your Availability filter to "Available" (using View->Availability Filter->Available or the View bar), projects and groups won't appear until all their tasks have been completed.

Ken Case 2010-02-17 06:05 AM

[QUOTE=Tony Stinson;73447]One question: Now in Context view, all of my projects are showing up in the "No Context" list. Since Projects can not be assigned a context, how do you clear this up? Is this normal with the new changes?[/QUOTE]

You can right-click on a project to set its context, or just drag it onto a context on the sidebar to move it into that context.

ksrhee 2010-02-17 06:06 AM

[QUOTE=Ken Case;73454]You should be able to do that now:

If you switch your Availability filter to "Available" (using View->Availability Filter->Available or the View bar), projects and groups won't appear until all their tasks have been completed.[/QUOTE]

Ken,

This is great! Now this makes the whole workflow much more manageable and nothing slips through the cracks!

I know it took awhile, but 1.8 update has been worthwhile the wait!

Ken

cashdollar 2010-02-17 06:21 AM

I apologize for repeating myself, but is there anyway not to have the projects show up as having "no context" I can't assign a context to a project because it may include phone calls, mac work, email, etc. My real concern is in doing my GTD weekly review I go through my action lists (contexts) and catch anything I may not have assigned a context to it. I don't want to review projects until further in my review. I know that not everyone using omnifocus is implementing GTD, but for those of us who are, this makes the review a little more difficult. By the way love desktop and iphone products and how well they're integrated. Thanks

Ken Case 2010-02-17 06:21 AM

[QUOTE=marcussommer@mac.com;73449]how to enable the beloved URL quickentry feature?[/QUOTE]

I've posted some instructions on the [URL="http://people.omnigroup.com/kc/OmniFocus/SendToOmniFocusBookmarklet.html"]Send to OmniFocus Bookmarklet[/URL] page.

Ken Case 2010-02-17 06:24 AM

[QUOTE=radek.salomon;73451]I am still confusing when I set the Project filter to All Projects I see also dropped folders. The dropped projects are removed by moving to archive, but not the dropped folders.
How can I fix it to remove the dropped folders?[/QUOTE]

You can permanently remove dropped folders by right-clicking on them and selecting Delete (or clicking on them and pressing the Delete key). Same with dropped contexts.

Ken Case 2010-02-17 06:28 AM

[QUOTE=cashdollar;73457]Is there anyway not to have the projects show up as having "no context" I can't assign a context to a project because it may include phone calls, mac work, email, etc. My real concern is in doing my GTD weekly review I go through my action lists (contexts) and catch anything I may not have assigned a context to it. I don't want to review projects until further in my review.[/QUOTE]

If you don't have another context that makes more sense for a project, you can create a Review context and assign your project to it. (To assign a project to a context, see [URL="http://forums.omnigroup.com/showthread.php?p=73455#post73455"]my earlier post[/URL].)

(If you don't want to see your Review context all of the time, you can place that context on hold.)

jdh 2010-02-17 06:44 AM

Unfortunately, it seems that Single-Action Lists are being counted in the "No Context" counter, despite the release notes indicating these won't show up in the Contexts (and of course don't).

It took me a while to figure out why my "No Context" count was still up around 11, even though I couldn't seem to get anything else to appear in there no matter what view settings I picked.

For now, I've assigned contexts to all of my Single-Action lists in the Inspector just to keep that count from distracting me, but the current behaviour seems like a bug, since we're effectively showing a count for something that will never appear in that category.

Fireproof 2010-02-17 07:57 AM

[QUOTE=Ken Case;73458]I've posted some instructions on the [URL="http://people.omnigroup.com/kc/OmniFocus/SendToOmniFocusBookmarklet.html"]Send to OmniFocus Bookmarklet[/URL] page.[/QUOTE]

Sorry to be off-topic, but I have never been able to get this to work. Does it only work in Safari? I'm using Firefox.

It successfully calls up Omnifocus, but it's just whatever view I was looking at prior. There's no task created, no quick entry form, nothing.

cashdollar 2010-02-17 08:01 AM

that worked (setting the project context to "review", but it does require an extra step for each project created. Just curious why was the decision to include projects in the contexts lists, when projects can't be done, while actions can?

Thanks again

Ken Case 2010-02-17 08:03 AM

[QUOTE=jdh;73461]Unfortunately, it seems that Single-Action Lists are being counted in the "No Context" counter, despite the release notes indicating these won't show up in the Contexts (and of course don't).[/QUOTE]

Woops! Yes, that's a bug, fixed for the next sneaky peek (now posted).

jdh 2010-02-17 08:03 AM

[QUOTE=cashdollar;73466]that worked (setting the project context to "review", but it does require an extra step for each project created. Just curious why was the decision to include projects in the contexts lists, when projects can't be done, while actions can?[/QUOTE]
Well, technically projects [i]can[/i] be completed. If you've got a project that never actually ends, then either it needs more tasks entered into it (in which case the project entry is a trigger to update it) or it might be more appropriate to make it a Single Action List.

I normally set most of my projects to automatic completion after the last task, but that's not always desirable since there may be more tasks to add. Sometimes that extra step of making a conscious decision that the project is truly completed is handy. In the past I've either knocked off those empty "Done" projects during my weekly review or put a placeholder task in at the end with something like "Complete Project."

Ken Case 2010-02-17 08:05 AM

[QUOTE=Fireproof;73465]Sorry to be off-topic, but I have never been able to get this to work. Does it only work in Safari? I'm using Firefox.

It successfully calls up Omnifocus, but it's just whatever view I was looking at prior. There's no task created, no quick entry form, nothing.[/QUOTE]

It sounds like Firefox might be calling up OmniFocus 1.7 rather than one of the new OmniFocus 1.8 sneaky peeks? This is a new feature in OmniFocus 1.8 for Mac.

Fireproof 2010-02-17 08:07 AM

[QUOTE=Ken Case;73469]It sounds like Firefox might be calling up OmniFocus 1.7 rather than one of the new OmniFocus 1.8 sneaky peeks? This is a new feature in OmniFocus 1.8 for Mac.[/QUOTE]

Ahh - I misunderstood. Just installed 1.8 and it is working perfectly!! Thanks for setting me straight. Good work!

radek.salomon 2010-02-17 09:12 AM

Yes. This is current possibility. Will you implement any feature that dropped folder or context will be moved to archive and deleted from the list?

sriggs 2010-02-17 11:06 AM

Thanks for the update but.... I have to say that I don't quite understand the thought behind the projects in context lists either. I wouldn't want the default context of my project to be Review. Then all new actions would take on the context of Review. I'm assuming that the implementation of this new feature is incomplete? Or maybe I don't quite understand where it's going. Please enlighten me.

whpalmer4 2010-02-17 11:46 AM

[QUOTE=sriggs;73482]Thanks for the update but.... I have to say that I don't quite understand the thought behind the projects in context lists either. I wouldn't want the default context of my project to be Review. Then all new actions would take on the context of Review. I'm assuming that the implementation of this new feature is incomplete? Or maybe I don't quite understand where it's going. Please enlighten me.[/QUOTE]

The default context is only applied to actions when you don't supply a context yourself, so it isn't really the case that "all new actions would take on the context of Review" as you state. If you want to add a bunch of actions without thinking about the context as you do so and without getting the default context applied (whatever it might be), you can temporarily remove the default context from the project.

As I understand it, the presence of projects and action groups in the context list is in response to a long-standing desire to have them appear when the contained work has been finished. If you view your context lists in Available, that's the behavior you'll see -- when you've ticked off the items in the group or the project, the container itself will appear and you can complete it or add to it as appropriate.

Perhaps reading SpiralOcean's post [URL="http://forums.omnigroup.com/showthread.php?t=15347"]here[/URL] will be illustrative.

whpalmer4 2010-02-17 11:52 AM

[QUOTE=cashdollar;73457]I apologize for repeating myself, but is there anyway not to have the projects show up as having "no context" I can't assign a context to a project because it may include phone calls, mac work, email, etc. My real concern is in doing my GTD weekly review I go through my action lists (contexts) and catch anything I may not have assigned a context to it. I don't want to review projects until further in my review. I know that not everyone using omnifocus is implementing GTD, but for those of us who are, this makes the review a little more difficult. [/QUOTE]

Remember, you're only setting the default context -- the context given to new actions in that project if you don't supply one yourself. This shouldn't hinder GTD practice at all; assign a default context when you create a project and you're all set. If you want, you can set it to a value (like Ken's suggested "Review") to enable you during your reviews to easily spot any actions that might not have gotten a carefully considered context.

cashdollar 2010-02-17 02:07 PM

Projects can be completed, true, but they can't be done. You don't do a project. You do the actions and when you reach a preset objective the project is completed. Assigning a context to a project if not counter intuitive, it is certainly counter to GTD.

chrjohns 2010-02-17 02:38 PM

Flagged items
 
Unflagged projects are appearing in the default flagged perspective along with their flagged actions, but underneath the actions. I think it is okay for the projects to appear in the perspective, however it would be helpful to have the projects appear above their associated actions rather than below! Looks like this same behavior occurs in the context perspective.

Nikemkballer 2010-02-17 03:06 PM

Does this 1.8 sync to the calendar REMINDERS on IPHONE?
 
Does this 1.8 sync to the calendar REMINDERS on IPHONE? It seems like thats what its says under the sync is that true so in order to update the reminders you no longer have to open the iphone app and sync it?

watchit 2010-02-17 03:25 PM

OmniFocus Reminders in iCal
 
"• Sync Preferences now has an option to publish an OmniFocus Reminders calendar for due task notifications."

I have tried publishing my due task notifications via Sync Prefs / MobileMe, but I am able to tick the check box "Publish Due reminders as a calendar" but even though the button "Subscribe in iCal" is not dimmed, nothing happens why I try to click on it. I've tried Sync with iCal and Sync with Server and refreshing Sync in MobileMe but still nothing.
And I can't subscribe from within iCal because I don't know the published address.
What am I missing?

whpalmer4 2010-02-17 03:34 PM

[QUOTE=cashdollar;73490]Assigning a context to a project if not counter intuitive, it is certainly counter to GTD.[/QUOTE]

We're not talking about contexts for projects, we're talking about default contexts for the actions in the projects. There's nothing counter to GTD in that. If you think there is, could you point me to a reference?

ksrhee 2010-02-17 03:48 PM

[QUOTE=cashdollar;73490]Projects can be completed, true, but they can't be done. You don't do a project. You do the actions and when you reach a preset objective the project is completed. Assigning a context to a project if not counter intuitive, it is certainly counter to GTD.[/QUOTE]

I think it might be more helpful to view the list as items that are actionable, and as such projects can appear in the list ready to be acted upon.

In such case, you either complete the project (action), drop the project (action), hold the project (action), or add an item to the project (action). So, it makes a perfect sense for the project to appear in the list for me to act on. . .

malisa 2010-02-17 03:56 PM

[QUOTE=Ken Case;73454]You should be able to do that now:

If you switch your Availability filter to "Available" (using View->Availability Filter->Available or the View bar), projects and groups won't appear until all their tasks have been completed.[/QUOTE]



Thank you, this now makes sense. Now to see if that logic straightens out the visual that was bothering me on my iphone since the last update.

ETA: No...still don't see why un-available, grayed out actions and projects are showing on my flagged perspective on my iphone. I'll go trudge up my old thread. I want to understand why this is so.

curt.clifton 2010-02-17 04:25 PM

[QUOTE=malisa;73497]ETA: No...still don't see why un-available, grayed out actions and projects are showing on my flagged perspective on my iphone. I'll go trudge up my old thread. I want to understand why this is so.[/QUOTE]

I think that's a known bug in the experimental perspectives supporting for OF iPhone 1.6.1.

Greg Jones 2010-02-17 05:46 PM

I see that there have been several changes to the attachment list in SP 1.8. I've always wondered why the Attachment List window includes custom icons that are assigned to a perspective? I don't know if the way it currently works is by accident or design, but excluding the icons would be my preference. More nice features would be if the list also supported Quick Look, double-clicking to open the attachment in the default application, and right-clicking to reveal the attachment in the associated task.

macula 2010-02-17 11:58 PM

Based on precedent, how long does it generally take for a sneeky peek to become an official release?

Arild 2010-02-18 12:40 AM

[QUOTE=Ken Case;73454]You should be able to do that now:

If you switch your Availability filter to "Available" (using View->Availability Filter->Available or the View bar), projects and groups won't appear until all their tasks have been completed.[/QUOTE]

I have a group due today with some subtasks in it.
Now, in "No context" the badge says one "due soon" action is there, but since I only want to see actionable items (i.e. available) in my "Due" perspective, that group row/item is not listed. That is not an optimal solution for me, it took me a little while to figure out where on earth the no-context-due-soon-action could be (although I know this behaviour is the same for all actions in sequential groups/projects). However, you might want to consider at least to exclude the badge until action can be taken on it in context mode? This is in my view a sort of logical conflict which is difficult to solve in a 100% consistent manner. But you could develop some sort of test/warning text for such situations, perhaps? Maybe a double badge system, both indicating "Due" but distinguishing available (bright orange) from unavailable ones (faded orange)? It is a bit strange seeing a badge but not it's related item (yet).

Best regards,

Arild

gandalf44 2010-02-18 04:45 AM

Seeing this too. Any response? The button is not clickable.

And I assume it's the same MobileMe-iDisk path and file name as the iPhone published? (DueSoon.ics)?



[QUOTE=watchit;73494]"• Sync Preferences now has an option to publish an OmniFocus Reminders calendar for due task notifications."

I have tried publishing my due task notifications via Sync Prefs / MobileMe, but I am able to tick the check box "Publish Due reminders as a calendar" but even though the button "Subscribe in iCal" is not dimmed, nothing happens why I try to click on it. I've tried Sync with iCal and Sync with Server and refreshing Sync in MobileMe but still nothing.
And I can't subscribe from within iCal because I don't know the published address.
What am I missing?[/QUOTE]

macula 2010-02-18 05:27 AM

[QUOTE=gandalf44;73535]Seeing this too. Any response? The button is not clickable.

And I assume it's the same MobileMe-iDisk path and file name as the iPhone published? (DueSoon.ics)?[/QUOTE]

Are you sure this is the correct path to the calendar file? On my system, the correct path is [url]https://idisk.me.com/[/url][my username]/Documents/OmniFocus-Reminders.ics
[please note the capitalization]

macula 2010-02-18 05:29 AM

Does anyone know how to make the reminders calendar visible on iCal without getting duplicate reminders on the iPhone? If I subscribe to the reminders calendar both on the iPhone and on the desktop I end up getting duplicate reminders on the phone.

cashdollar 2010-02-18 05:41 AM

[QUOTE=whpalmer4;73495]We're not talking about contexts for projects, we're talking about default contexts for the actions in the projects. There's nothing counter to GTD in that. If you think there is, could you point me to a reference?[/QUOTE]

We are infact talking about assigning contexts to projects see Ken's post earlier in this thread.

"I think it might be more helpful to view the list as items that are actionable, and as such projects can appear in the list ready to be acted upon.

In such case, you either complete the project (action), drop the project (action), hold the project (action), or add an item to the project (action). So, it makes a perfect sense for the project to appear in the list for me to act on. . ."

That may be the case for you, but according to the GTD system "you can't do a project". The sample applies for "contacting" someone or "completing" something, those verbs don't work they aren't specific enough. I understand that the market for a powerful task manager is larger than the GTD faithful, but OmniFocus sought and has the blessing of the David Allen Company, because it is powerful flexible task manager that doesn't get in the way of the user. I'm offering my suggestions, because I love their products and the difference they've made in my ability to get things done. I would suggest they run this by their partners at the David Allen Co., and depending on their input consider including a preference to allow the user to automatically assign a context to a project when it's created, so they don't have to think about it if they so choose. Although this small change is far from a deal breaker for me, it does introduce a small amount of "unconscious resistance" which is the reason I rejected the other Mac based task managers.

ksrhee 2010-02-18 06:20 AM

[QUOTE=cashdollar;73538]We are infact talking about assigning contexts to projects see Ken's post earlier in this thread.

"I think it might be more helpful to view the list as items that are actionable, and as such projects can appear in the list ready to be acted upon.

In such case, you either complete the project (action), drop the project (action), hold the project (action), or add an item to the project (action). So, it makes a perfect sense for the project to appear in the list for me to act on. . ."

That may be the case for you, but according to the GTD system "you can't do a project". The sample applies for "contacting" someone or "completing" something, those verbs don't work they aren't specific enough. I understand that the market for a powerful task manager is larger than the GTD faithful, but OmniFocus sought and has the blessing of the David Allen Company, because it is powerful flexible task manager that doesn't get in the way of the user. I'm offering my suggestions, because I love their products and the difference they've made in my ability to get things done. I would suggest they run this by their partners at the David Allen Co., and depending on their input consider including a preference to allow the user to automatically assign a context to a project when it's created, so they don't have to think about it if they so choose. Although this small change is far from a deal breaker for me, it does introduce a small amount of "unconscious resistance" which is the reason I rejected the other Mac based task managers.[/QUOTE]

It seems to be that you are stuck on this concept that projects cannot be doable. If you shift your thinking a bit, you will find that this new system makes a perfect sense, but to each his own. . .

Here are some quotes you might find helpful from OminGroup and David Allen. As you can see, OG never claimed that this is strictly a GTD system, and even DA think projects can be translated into action items under certain situations. Hope this helps.

"OmniFocus is designed to quickly capture your thoughts and allow you to store, manage, and process them into actionable to-do items. Perfect for the Getting Things Done® system, but flexible enough for any task management style, OmniFocus helps you work smarter by giving you powerful tools for staying on top of all the things you need to do."

"Allen's reply: The key to your action lists is that you do not have to re-think what you can and cannot do at the moment, as you look at them. If you put sequential steps there, it dulls the attraction of engaging with the list to begin with. If there's a good chance that a project can be finished in one sitting, in one fell swoop, then probably best to label it simply a next action and put it on your action list."

macula 2010-02-18 06:36 AM

The newly introduced requirement that groups and projects be assigned to a context is a step backwards.

Frankly, it is one of the reasons I switched from Toodledo to OmniFocus. As you understand, I now feel that this malignant feature is haunting me! :-)

I hope the OF developers will remove this feature or at least make it optional in the final release.

I don't see what the problem was with the original implementation. We all review our projects regularly, so upon completing all subtasks of a group/project, and during the next review at the latest, would always find out that a "childless" parent task exists, and we would cross it out as completed.

Quite clearly, OmniFocus is not a 100% GTD-compliant system anymore. I understand that there may be a user population who find this to be an improvement. Yet those of us who adhere to GTD as a system—some of us practitioners for years—this is a step backwards.

whpalmer4 2010-02-18 06:40 AM

[QUOTE=cashdollar;73538]We are infact talking about assigning contexts to projects see Ken's post earlier in this thread.

"I think it might be more helpful to view the list as items that are actionable, and as such projects can appear in the list ready to be acted upon.

In such case, you either complete the project (action), drop the project (action), hold the project (action), or add an item to the project (action). So, it makes a perfect sense for the project to appear in the list for me to act on. . ."
[/quote]

They say a picture is worth a thousand words. Here's a picture of the OmniFocus inspector looking at a project.

[URL=http://img109.imageshack.us/i/picture4tn.png/][IMG]http://img109.imageshack.us/img109/3056/picture4tn.png[/IMG][/URL]

See how it says "default context"? That is the field Ken is suggesting you set.

[URL=http://img294.imageshack.us/i/picture5sp.png/][IMG]http://img294.imageshack.us/img294/1164/picture5sp.png[/IMG][/URL]

Here we see it in action. All it is doing is entering the value of the default context if I don't enter something myself. This is not a new feature.

Again, as I said, it's not a context for the project, it is a default context for the actions contained in the project. Ken just didn't bother to type all of that out. Projects don't have contexts, they have actions, which do have contexts.

ksrhee 2010-02-18 06:47 AM

[QUOTE=macula;73543]The newly introduced requirement that groups and projects be assigned to a context is a step backwards.

Frankly, it is one of the reasons I switched from Toodledo to OmniFocus. As you understand, I now feel that this malignant feature is haunting me! :-)

[/QUOTE]

I hate to contradict you, but this is not a new feature for 1.8. This has been the case in 1.7x. The only difference is now that projects show up in the action list under the Context view.

You don't have to assign default context to project items if you don't want to ("none").

Just want to clarify.

macula 2010-02-18 06:48 AM

Still, Bill, as I understand it, filtering my Context View by "all tasks" (i.e. including unavailable tasks) will display my project and group headings as separate entries, and alas, will do so under the context that was set as default for that project or group. That, in my view, is regrettable.

macula 2010-02-18 06:56 AM

Sorry, ksrhee, my earlier post crossed in the mail with yours. Perhaps I wasn't clear; what you mention is exactly what I meant and perceive as a misguided decision by the developers of OF. "No context" is indeed an option, but perhaps I will end up creating a "Projects/Groups" context as a placeholder for these situations.

But again, I don't see the rationale for this change. It adds complexity and conceptual murkiness in a system that should aim precisely at conceptual tidiness.

fedex 2010-02-18 07:24 AM

NOT good!
 
This new "feature" with showing projects in context lists is breaking my workflow BIG time.

Please make this a global on/off option!!!!

I'm already back to 1.7!

whpalmer4 2010-02-18 07:24 AM

[QUOTE=macula;73543]
I don't see what the problem was with the original implementation. We all review our projects regularly, so upon completing all subtasks of a group/project, and during the next review at the latest, would always find out that a "childless" parent task exists, and we would cross it out as completed.
[/quote]
Ah, so in a paper-based GTD system done strictly by the book you would have waited until you did a weekly review to notice that a project was done, rather than observing you had come to the end of your list of next actions?
[quote]
Quite clearly, OmniFocus is not a 100% GTD-compliant system anymore.
[/quote]
No offense intended, but when people start talking about things being "100% GTD-compliant" it makes it difficult to read the post due to all the eye-rolling going on, it's like trying to read on a roller-coaster :-) You can find plenty of hits in a Google search for "GTD-compliant" but none of them are on David Allen's websites. He does however have the following description:

[url]http://www.davidco.com/what_is_gtd.php[/url]

regarding which one maker of a "GTD-compliant" app list observes:
[indent]
This list is short to accommodate individual preferences, and because the David Co. official description of GTD is very broad.[/indent]
[quote]
Yet those of us who adhere to GTD as a system—some of us practitioners for years—this is a step backwards.[/QUOTE]
Maybe your last sentence might start as follows:

[quote]
Yet for [b]some[/b] of us who adhere to GTD as a system
[/quote]

Fair enough? I've also been a GTD practitioner for years, and I think Ken would likely consider himself one as well. For something that's apparently a step backwards, he's always seemed pretty enthusiastic about it :-)

sriggs 2010-02-18 07:44 AM

Maybe an example would help me understand it. So lets say that I have a project that is day job related. I have actions in this project that use the Calls, Office, Computer, Agendas:Tom, Waiting For and Errands contexts. What context would be recommended to set for the default context of the project and why would it be a good choice?

jdh 2010-02-18 07:45 AM

I think that Ken's suggestion of putting the context as "Review" on a project (or action group) makes sense if you really don't want to look at the empty project until your next review cycle.

This is what I've done, and it works better for me now that the projects show up in the "Review" context, particularly since I do my "Daily Reviews" in context view rather than project view, so it allows me to more easily see these empty projects on a daily basis and thereby decide if they're truly "done" or if there are more actions for them. In the past, I use to actually drop a final placeholder task into such projects that said "Review Project Completion" which often required an extra step.

The only real change that I'd like to see is that projects and action groups that are set to auto-complete probably [i]should[/i] be hidden from the context view. There's not much sense in displaying that extra project entry when it's going to disappear after the last task is completed anyway.

jdh 2010-02-18 07:47 AM

[QUOTE=sriggs;73550]Maybe an example would help me understand it. So lets say that I have a project that is day job related. I have actions in this project that use the Calls, Office, Computer, Agendas:Tom, Waiting For and Errands contexts. What context would be recommended to set for the default context of the project and why would it be a good choice?[/QUOTE]
Personally, I use a "Review" context for projects like these so that it comes up during my next review cycle (end of day or beginning of day, as the case may be). I can then drag-and-drop it to its appropriate context, assuming I don't manually assign one when I create the task.

Realistically, I rarely do much with default contexts anyway, and the "review" context is largely a catch-all placeholder -- new items land in the inbox and in my system don't leave the inbox until they've been assigned [I]both[/I] a project and a context. My Inbox of course gets reviewed daily.

sriggs 2010-02-18 07:53 AM

[QUOTE=jdh;73552]Personally, I use a "Review" context for projects like these so that it comes up during my next review cycle (end of day or beginning of day, as the case may be). I can then drag-and-drop it to its appropriate context, assuming I don't manually assign one when I create the task.

Realistically, I rarely do much with default contexts anyway, and the "review" context is largely a catch-all placeholder -- new items land in the inbox and in my system don't leave the inbox until they've been assigned [I]both[/I] a project and a context. My Inbox of course gets reviewed daily.[/QUOTE]

Thanks for the reply. Have you found that your workflow has improved with this new context as opposed to using the built in review perspective?

jdh 2010-02-18 09:23 AM

Well, it's too early to tell for certain, but it seems an improvement. I only use the actual "Review" perspective for my weekly reviews. I do my daily reviews in context view with a custom perspective ("Tactical") that displays all available tasks grouped by context. I start by cleaning up anything in the Review context or "No Context" section, reassigning those tasks to proper contexts. I then drill down quickly through the remaining contexts to flag critical items for the day, reassign contexts if necessary and look for anything that's on hold or otherwise stuck.

Following my review, I work primarily from a "Today" perspective that includes due or flagged items that are available, and only switch back to my full "Tactical" view (all available items by context) on the rare occasions that I actually empty out an active context and still have time or energy to do other items in that context.

macula 2010-02-18 09:34 AM

[QUOTE=whpalmer4;73549]Ah, so in a paper-based GTD system done strictly by the book you would have waited until you did a weekly review to notice that a project was done, rather than observing you had come to the end of your list of next actions?
[/QUOTE]

Indeed I don't see this as a problem, so allow me to clarify and summarize my objections once again:

First, it is conceptually untidy to categorize a project or group into a single context.

Second, I have a penchant for (re)viewing my actions grouped per context and filtered by "remaining". In this scenario, the new implementation will include my project and group titles as individual tasks to be completed. This is both redundant and misleading.

Overall, the user is now forced to adapt to the idiosyncrasies of the software, rather than the other way around.

[QUOTE]
No offense intended, but when people start talking about things being "100% GTD-compliant" it makes it difficult to read the post due to all the eye-rolling going on, it's like trying to read on a roller-coaster :-)
[/QUOTE]

Every little recess in the system has a psychological impact, so "anything goes" is not a constructive mindset.

Assigning contexts to projects runs contrary to both the spirit and the letter of GTD. "You can't do a project" (p. 155). I couldn't care less about the letter, but the ramifications in this case are non-negligible.

gandalf44 2010-02-18 09:39 AM

[QUOTE=macula;73536]Are you sure this is the correct path to the calendar file? On my system, the correct path is [url]https://idisk.me.com/[/url][my username]/Documents/OmniFocus-Reminders.ics
[please note the capitalization][/QUOTE]

You are right. I forgot to specify the full path in my post earlier.

macula 2010-02-18 09:58 AM

Possible middleground solution
 
May I suggest this as a middleground solution which could put an end to this quarrel between the "ancients" (such as me) and the "moderns" (whpalmer):

In the application preferences, under "Data > Projects and action groups," allow the user to define a default context for new projects and action groups. Given this option, I would create a "project/group" context and define it as the default context for those entities. My projects and action groups would be assigned to a context automatically, sparing me the need to change my deeply ingrained habits, with the added advantage that the particular context would make sense.

Ken, are you open to this suggestion?

whpalmer4 2010-02-18 12:15 PM

[QUOTE=sriggs;73550]Maybe an example would help me understand it. So lets say that I have a project that is day job related. I have actions in this project that use the Calls, Office, Computer, Agendas:Tom, Waiting For and Errands contexts. What context would be recommended to set for the default context of the project and why would it be a good choice?[/QUOTE]
I'd take a few seconds to think about the likely tasks in the project and pick the most common context. I wouldn't spend much time on it because I rarely rely on the defaulting mechanism -- most of my manually-created actions get created via quick entry or the inbox. As a result, I had about 200 projects with no default context assigned.

Toadling 2010-02-18 12:44 PM

[QUOTE=whpalmer4;73590]I'd take a few seconds to think about the likely tasks in the project and pick the most common context. I wouldn't spend much time on it because I rarely rely on the defaulting mechanism...[/QUOTE]

I also rarely used the default context mechanism, but I've started to now that there's more reason to do so.

In my case, I try to assign the context I need to be in to make the decision whether to complete the project/group or to add more actions. As a catchall for when I can't think of anything else, I have an "OmniFocus" context that I use similarly to the aforementioned "Review" context.

-Dennis

Toadling 2010-02-18 01:01 PM

[QUOTE=macula;73537]Does anyone know how to make the reminders calendar visible on iCal without getting duplicate reminders on the iPhone? If I subscribe to the reminders calendar both on the iPhone and on the desktop I end up getting duplicate reminders on the phone.[/QUOTE]

Yes, iPhone OS 3.1 syncs subscribed calendars from iCal, so if you subscribe to the your OmniFocus Reminders calendar on both your iPhone and in iCal, and then sync the two devices, the calendar will show up twice on your iPhone. I wrote about this last September:

[url]http://forums.omnigroup.com/showthread.php?t=13801[/url]

AFAIK, the only current workaround is to not subscribe to it in both iCal and the iPhone Calendar app. It's probably best to only subscribe to the OmniFocus calendar from your iPhone since the copy from an iCal sync is static and not updated in realtime -- it only gets updated when you sync with iCal.

-Dennis

macula 2010-02-18 01:12 PM

[QUOTE=Toadling;73595]I also rarely used the default context mechanism, but I've started to now that there's more reason to do so.

In my case, I try to assign the context I need to be in to make the decision whether to complete the project/group or to add more actions. As a catchall for when I can't think of anything else, I have an "OmniFocus" context that I use similarly to the aforementioned "Review" context.

-Dennis[/QUOTE]

Dennis' and whpalmer's suggested solutions only corroborate that the new behavior of projects and group actions in OF 1.8 forces users to use "hacks", and thus interferes with the user's thought process. I really do not want to be a nuisance by repeating ad nauseam my aversion to this revision—and indeed will spare you from further comments on this from me—but clearly, if Omni wants to ensure projects and group tasks will not "fall through the cracks," then they should come up with a genuine solution instead of forcing the user to resort to conceptual acrobatics of this sort. It should be easy for us, not for them.

macula 2010-02-18 01:17 PM

[QUOTE=Toadling;73597]AFAIK, the only current workaround is to not subscribe to it in both iCal and the iPhone Calendar app. It's probably best to only subscribe to the OmniFocus calendar from your iPhone since the copy from an iCal sync is static and not updated in realtime -- it only gets updated when you sync with iCal.

-Dennis[/QUOTE]

Thanks, Dennis, for this info.

macula 2010-02-19 01:10 AM

Hallelujah!

As whpalmer posted in another thread, it is now possible to deactivate the display of projects and group actions in context views with the following bookmarklet:

[URL="omnifocus:///change-setting?ContextModeShowsParents=false"]omnifocus:///change-setting?ContextModeShowsParents=false[/URL]

I think this answers our plea for making the new behavior optional, and everyone can be happy now.

Thank you.

macula 2010-02-19 01:22 AM

Sorry, I am breaching my self-imposed censorship on this matter. One last point if I may:

I understand the reasoning supporting the new behavior of projects and group tasks that Omni is introducing in OF 1.8. What I do not like is the implementation: Forcing the user to enter an arbitrary context or, as an equally ugly alternative, put the project/group in the "no context" black list.

Here is a possible workaround that is conceptually elegant and user-friendly: Tweak the OF code so that all projects/groups are internally assumed to belong in all contexts that the project's/group's completed and remaining actions collectively belong in. In this scenario, upon completing all children actions the parent project/group will appear as available in all contexts of the completed children.

An alternative solution—easier in terms of engineering, it seems to me—is for Omni to automatically and non-modifiably place all projects/groups in a dedicated "context" called "Projects/Groups" or something, without requiring the user to set that context or any other context as the default for each project/group.

vinyl_warrior 2010-02-19 01:46 PM

I'd like to throw my two cents in on the discussion about assigning contexts to projects. After upgrading to 1.8, I now have a modest 22 items with no context, which surprised me because I try to make sure that all of my tasks have contexts. The No Contexts bucket used to be a great tool for me to quickly identify any tasks that I didn't give a context to.

From my understanding, I'll now have to assign a context to all of my projects (a default context), just to have that bucket counter clear. That, however, completely ruins my use of the of the No Context bucket. I won't get to see the tasks that I missed assigning contexts to because the default context will make sure that nothing ever appears there.

That one change seems totally busted and inelegant. OF is essentially forcing me to assign a context, and if none of my contexts are appropriate, the given suggestion by Ken is to assign a [U]completely arbitrary[/U] context to every project I create for reasons that ultimately [U]sabotage my workflow.[/U]

[erased furious rage]

All of the other changes in 1.8 seem great, but projects without a default context showing up in the No Context bucket completely missed the mark.

[QUOTE=macula;73635]Here is a possible workaround that is conceptually elegant and user-friendly: Tweak the OF code so that all projects/groups are internally assumed to belong in all contexts that the project's/group's completed and remaining actions collectively belong in. In this scenario, upon completing all children actions the parent project/group will appear as available in all contexts of the completed children.

An alternative solution—easier in terms of engineering, it seems to me—is for Omni to automatically and non-modifiably place all projects/groups in a dedicated "context" called "Projects/Groups" or something, without requiring the user to set that context or any other context as the default for each project/group.[/QUOTE]

The first suggest seems at first brush to be unobtrusive and [B]useful[/B], two qualities that the current implementation lacks. The latter seems serviceable.

jdh 2010-02-19 02:02 PM

[QUOTE=macula;73635]Here is a possible workaround that is conceptually elegant and user-friendly: Tweak the OF code so that all projects/groups are internally assumed to belong in all contexts that the project's/group's completed and remaining actions collectively belong in. In this scenario, upon completing all children actions the parent project/group will appear as available in all contexts of the completed children.[/quote]
Unless I'm misunderstanding something, this solution appears to be potentially [i]more[/i] confusing. Very few of my projects actually only use a single context, so how would OF determine which context should be assigned in those cases?

[quote]An alternative solution—easier in terms of engineering, it seems to me—is for Omni to automatically and non-modifiably place all projects/groups in a dedicated "context" called "Projects/Groups" or something, without requiring the user to set that context or any other context as the default for each project/group.[/QUOTE]
That sounds even odder... Creating a context for projects and groups defeats the purpose of having a streamlined workflow, since the user has no control over where things [i]do[/i] appear. To create a "projects/groups" context, we might as well just switch back to planning mode.

[QUOTE=vinyl_warrior;73679]From my understanding, I'll now have to assign a context to all of my projects (a default context), just to have that bucket counter clear. That, however, completely ruins my use of the of the No Context bucket. I won't get to see the tasks that I missed assigning contexts to because the default context will make sure that nothing ever appears there.[/quote]
The more I think about it, the more I see this aspect as the crux of the problem. If I choose not to assign a context to a project/group, perhaps OF should just ensure that this particular project or group doesn't appear in context view [i]at all[/i] -- not in "No Contexts" or some new placeholder context or anywhere else.

I'd also combine this with the idea that projects and groups that are set to automatically complete should not appear in the context view either -- if they're going to be automatically marked completed when all of their dependent tasks are finished, then what's the point of showing them in context view, since in that sense they really aren't "actionable" but are rather just containers.

I'd propose the following simple change in logic:

A Project or Action Group will appear in context view if and only if the following conditions are met:

1. It has been specifically assigned a context.
2. It is NOT set to be marked completed automatically.
3. It is NOT a Single Action list (this one is already there).

This way, those who don't want their projects showing up context view could simply avoid assigning them a default context. This also means that majority of users who [i]don't[/i] want this feature wouldn't have to change a thing, since most users don't have contexts assigned to their projects anyway.

Note that this [i]does[/i] leave some murkiness around the issue of Default Context, which some users may have want to use without having to assign an actual project context. IMHO Default Context and "Project Context" should be two distinct settings, but of course that would require a second context field on every project and may be going a bit beyond the scope of our current discussion.

macula 2010-02-19 06:34 PM

[QUOTE=jdh;73680]Unless I'm misunderstanding something, this solution appears to be potentially [i]more[/i] confusing. Very few of my projects actually only use a single context, so how would OF determine which context should be assigned in those cases?
[/QUOTE]

In fact, I was suggesting that the project at hand would be displayed not under one but actually all contexts of its children. For example, if your project X includes an "errand" and a "phone call," upon completing these two actions project X would be made visible and "float" in both the "Errands" and the "Phone Calls" contexts (perhaps with a different color to indicate that this is a floating project/group rather than a genuine action in that context). I realize this requires significant modifications to the underlying logic, however.

[QUOTE]That sounds even odder... Creating a context for projects and groups defeats the purpose of having a streamlined workflow, since the user has no control over where things [i]do[/i] appear. To create a "projects/groups" context, we might as well just switch back to planning mode.[/QUOTE]

Well, it doesn't defeat the purpose in the sense that projects/groups would not risk "falling through the cracks" anymore, instead appearing in context view upon having their constituent actions completed.

[QUOTE]If I choose not to assign a context to a project/group, perhaps OF should just ensure that this particular project or group doesn't appear in context view [i]at all[/i] -- not in "No Contexts" or some new placeholder context or anywhere else. [/QUOTE]

That's a good suggestion, but again, it does not respond to the perceived need to prevent projects/action from "falling through the cracks," which motivated these changes in the first place.

[QUOTE]I'd also combine this with the idea that projects and groups that are set to automatically complete should not appear in the context view either —
[/QUOTE]

[QUOTE]Note that this [i]does[/i] leave some murkiness around the issue of Default Context, which some users may have want to use without having to assign an actual project context. IMHO Default Context and "Project Context" should be two distinct settings, but of course that would require a second context field on every project and may be going a bit beyond the scope of our current discussion.[/QUOTE]

I agree that two distinct settings would be better. In general, though, I strongly oppose the [U]manual[/U] assignment of a particular context to projects and groups. As numerous users have repeatedly written in this and other threads, this is a "hack", a conceptually inconsistent workaround, for ensuring that projects and groups will not "fall through the cracks". My intention was to counterpropose two conceptually sound solutions for addressing this need.

Toadling 2010-02-19 07:28 PM

[QUOTE=macula;73692]My intention was to counterpropose two conceptually sound solutions for addressing this need.[/QUOTE]

Interesting ideas, but I'm not convinced they're better than the current implementation for my workflow (or even that the current behavior is a "hack").

Just wanted to point out that not everyone dislikes these 1.8 changes. I'm not even sure there's a significant number of people having a problem with it. That doesn't mean the issue still can't be addressed in some way, of course. :-)

-Dennis

curt.clifton 2010-02-20 04:22 AM

Forgive me a short trip through some history…
[INDENT]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 [URL="http://forums.omnigroup.com/showthread.php?t=3642"]here[/URL] and [URL="http://forums.omnigroup.com/showthread.php?t=3649"]here[/URL]).

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 [URL="http://www.rose-hulman.edu/~clifton/software.html#VerifyNA"]Verify Next Actions Exist script[/URL] 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.
[/INDENT]
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 [I]actions[/I] 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 [I]might[/I] be. Perhaps it is as simple as it [I]can[/I] be though?

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

macula 2010-02-20 05:11 AM

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.

ksrhee 2010-02-20 05:53 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.

curt.clifton 2010-02-20 06:07 AM

[QUOTE=macula;73706]Excellent post from an "authoritative" voice :-) …[/QUOTE]

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?[/QUOTE]

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.[/QUOTE]

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.

macula 2010-02-20 07:38 AM

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 ?

sriggs 2010-02-20 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.

macula 2010-02-20 07:44 AM

There is a hidden preference, accessible via a bookmarklet, that turns visibility on and off:

[URL="omnifocus:///change-setting?ContextModeShowsParents=false"]omnifocus:///change-setting?ContextModeShowsParents=false[/URL]

Replace [I]false[/I] with [I]true[/I] in the bookmarklet to turn visibility back on.

Be warned, however, that now if an action group in a [U]sequential[/U] 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! ;-)

curt.clifton 2010-02-20 07:57 AM

[QUOTE=macula;73711]
Now, how do we make sure that the developers are aware of this suggestion? [/QUOTE]

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 ?[/QUOTE]

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.)

sriggs 2010-02-20 08:07 AM

[QUOTE=macula;73713]There is a hidden preference, accessible via a bookmarklet, that turns visibility on and off:

[URL="omnifocus:///change-setting?ContextModeShowsParents=false"]omnifocus:///change-setting?ContextModeShowsParents=false[/URL]

Replace [I]false[/I] with [I]true[/I] in the bookmarklet to turn visibility back on.

Be warned, however, that now if an action group in a [U]sequential[/U] 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! ;-)[/QUOTE]

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.

Lucas 2010-02-20 08:54 AM

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 [I]more[/I], until I track down the blocking action group showing up in the no context list - in which there are now [I]a lot[/I] of things.

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

Toadling 2010-02-20 09:15 AM

[QUOTE=macula;73711]I very much hope the Omni crew will listen to our plea, which after all seems to enjoy consensus more or less.[/QUOTE]

Whoa, wait a minute. Consensus? Let's not jump to conclusions. I count no more than a handful of commenters in this thread, and they're not even in complete agreement. There are potentially hundreds, if not thousands, of others who have not voiced opinions here. Maybe those users would agree, maybe not. But we can hardly claim a consensus! Only Omni has a true sense of the kind of feedback coming in.

Before this feature was implemented, there was an equally vocal group of users asking for the current behavior. The consensus seemed clear and Omni responded. Now that the change is up for preview, the first group is likely happily working away while the "second shift" steps in asking for the old behavior. I guess you really can't make all the people happy all the time. :-)

[QUOTE=macula;73711]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.[/QUOTE]

You seem to be projecting your firmly held belief on everyone. I'm not saying this proposal is necessarily bad, but I still remain unconvinced that it's the best solution. Perhaps others feel the same way and simply don't have the time or energy to debate it here.

Personally, I like the new blocking nature of action groups -- that seems perfectly natural and intuitive to me. I also like empty parents (i.e. projects/groups without next actions) to "bubble up" in context mode. That feels perfectly natural and intuitive to me too. I've felt it should work that way for years, although I never made a fuss about it.

The only uncertainty in my mind is the issue of what context the parent should appear in. The current sneaky peak implementation seems like a simple solution that makes use of existing functionality (i.e. the default context field), so it was an obvious first choice for getting this feature out for alpha testing. That's what the sneaky peaks are all about.

My concern with Curt's propsal of a dedicated "Parents" bin is: would I still be able to see my parents intermingled with my actions or would I only be able to see them in a separate view? I want to be able to check off actions in a group and eventually see the action group itself appear in the same view (with my filter set to available). I *do not* want to have to click on a Parents bin to find the related parent, nor do I want to Command or Shift-click on both my Contexts bin and Parents bin and end up seeing seperate sections for parents and actions. Now that seems clumsy and inelegant to me.

-Dennis

ksrhee 2010-02-20 09:41 AM

I for one likes this new feature. Initially I was against it until KC indicated in the forum that you can hide projects/groups by selecting available filter under the context view unless they are empty. This is a behavior I precisely want the program to remind me of (which mimics what happens in LifeBalance). Since I can only work tasks that are available, this doesn't bother me at all, and I want the program to tell me I need to do something on that project. Now I do a weekly review, and this is how I used to catch empty projects or groupings, but the new way makes me catch empty projects much quicker and act on it rather than wait till the weekly review.

Right now, I see the projects/groups if I select the remaining filter the availability filter bar, but I can turn this off via off/on command temporarily or sort the items such a way they appear at the bottom of each grouping rather than mixed in with others.

It seems like it's easy for OG to implement the global preference; so, I would say that would be a good compromise for now. Given what KC said in this forum and elsewhere, I don't think they will have time to revamp the whole interface in the next few months anyway.

Just my 2 cents.

vinyl_warrior 2010-02-20 11:02 AM

There are too many disparate discussions going on here for us to reach any kind of a consensus.

I, for one, don't mind groups and projects showing up in context lists when they're the next available "action". I think that will improve my workflow -- in certain custom perspectives (eg. where I view tasks grouped by project).

What I am wholeheartedly opposed to is being forced to manually assign contexts to every project so that they don't appear in the No Contexts bucket.

Give me a Projects bucket (probably similar to the proposed Parents bin) in the context sidebar and populate that with projects that don't have contexts. Then, ideally give me a way to turn it off ;) Don't mix projects with tasks.

If OG absolutely [I]needs[/I] to mix projects and tasks into one bucket, at least give me an option to automatically assign new projects to a certain context (the proposed "Review" context). I understand that this will mean that nothing will ever show up in No Context bucket, but mixing projects and tasks together already broke my workflow -- this would just allow my OCD to rest easy because there won't anything unassigned to a context.

I can't believe that I actually woke up this morning mad over this whole stupid kerfuffle.

curt.clifton 2010-02-20 11:23 AM

[QUOTE=Toadling;73720]
My concern with Curt's propsal of a dedicated "Parents" bin is: would I still be able to see my parents intermingled with my actions or would I only be able to see them in a separate view? I want to be able to check off actions in a group and eventually see the action group itself appear in the same view (with my filter set to available). I *do not* want to have to click on a Parents bin to find the related parent, nor do I want to Command or Shift-click on both my Contexts bin and Parents bin and end up seeing seperate sections for parents and actions. Now that seems clumsy and inelegant to me. [/QUOTE]

Of course you would. You see your No Context items without clicking on No Context now, don't you?

By putting the Parents in a separate bin, a sibling to No Context and Contexts, you have complete control. [LIST][*] Want to see all the actions and parents (subject to view bar filters). Then don't select anything in the sidebar, just like in the current 1.8 sneaky peeks (r126204 for posterity).[*] Want to see actions that lack contexts? Then click [I]No Context[/I] in side bar?[*] Want to see just actions and no parents? Then click [I]No Context[/I] and command-click [I]Contexts[/I].[*] Want to see just actions that have contexts? Then click [I]Contexts[/I] in the sidebar.[*] Want to see actions with contexts, plus all parents? Then click [I]Parents[/I] and command-click [I]Contexts[/I].[*] Want to see just the action groups that are blocking your progress? Then set the view bar to show available actions and click the [I]Parents[/I] bin in the sidebar. There's your list.[/LIST]
And all these combinations can be saved as perspectives. Greater power with simpler rules!

As far as I can tell, everything you want is there, Dennis. Please set me straight if I'm wrong.

I think there are only two problems not addressed by the Parents bin idea.

First, the Parents bin doesn't give us a way to view all action groups and projects that lack a default context. We didn't have that before the 1.8 sneaky peeks either, so I think it's a wash.

The tougher problem is for folks who don't like the new blocking behavior. That problem can't be addressed by tweaking the context view. It's a fundamental change in the definition of "Available". The auto-complete option makes the change less onerous, but it's still a different way of dealing with task dependencies. I personally think the new definition of Available is the right one, but the change will cause some pain for some folks. I hope that pain isn't too disruptive.

ksrhee 2010-02-20 11:36 AM

Here is my current workflow. Some of you might find it helpful.

My "working" perspectives always have "available" filter; so, the only time a project/group pops up is when there is no action attached to it (empty project). When it pops up, I have several choices:

1. Add an action item or items (I could really use a shortcut to add a subtask in the current version). If I do, then the project will disappear once again.

2. Mark complete if the project is complete.

3. Put on hold and assign the context that I created to put in all the hold project (e.g., Dormant Projects). This context is on hold; so, it doesn't show up in my working perspectives.

During my weekly review, I review all my dormant projects and then take action on those (e.g., assign more action items & take it out of dormant context or leave it as dormant).

On other perspectives (remaining filter), the projects/groups do show up, but they don't really bother me since I don't use context-based perspectives to plan or take action.

malisa 2010-02-20 12:37 PM

[QUOTE=curt.clifton;73703] After all, action groups and projects don't have a "context". They have a "default context". [/QUOTE]

I haven't played with the new features enough to have an opinion one way or the other yet, but I think this is an important distinction. I think that if there's no other major change, it would seem like at least there should be one default context for the actions which will be generated (as there is now) and a separate one that is consciously assigned to the action group or project itself (knowing what that means with the new behavior.)

Toadling 2010-02-20 01:24 PM

[QUOTE=curt.clifton;73732]Of course you would. You see your No Context items without clicking on No Context now, don't you?[/QUOTE]

I guess you're right, Curt, now that you mention it. My OCD rarely allows me to proceed without immediately assigning a context to everything that passes before my eyes. So I don't have much experience with that No Contexts bin. :-)

[QUOTE=curt.clifton;73732]As far as I can tell, everything you want is there, Dennis. Please set me straight if I'm wrong.[/QUOTE]

I must admit you're winning me over to your proposal, especially if Omni can do it with a minimum of work and it makes my fellow OmniFocus users happy.

-Dennis

jasong 2010-02-20 11:51 PM

Finally having a chance to "live" with 1.8, and I'm in the camp of those who don't like the change to have projects and subprojects show up in Contexts.

Here are the deal-breakers I'm hitting:

* I suddenly have 48 items in my "No Contexts" list. None of those items are actually actionable items without contexts; they're al projects or subprojects. For example, my "Repair hole in ceiling" shows up there, even though it has an action assigned to it.

* Even hiding the *list* of projects isn't enough because I still see the No Contexts list with "48" next to it, making me feel I should be doing something there.

* Assigning a "default context" makes no sense to me because I don't want my actions to get that default context if I forget to assign on; I want *those* items to show up in No Contexts so I can act on them properly by assigning a context.

* Sub-groups (action groups) show up in No Contexts, but it's not because they don't have a "proper context": I can't even *assign them a context* in Planning mode. I can only assign a "default context" via the inspector, for actions within that action group. See above about default contexts.

By way of example, I have a project to "Move to HDTV". It looks something like this:

* Move to HDTV (parallel)
** Make a list of all the stuff I need to buy to do high-dev TV (parallel)
*** HDTV
*** Blu-Ray Player
*** HD Receiver
*** etc.

Each item may be in different contexts, or may have additional sub-groups

In Context mode I see

No Context:
* Make a list of all the stuff I need to buy to do high-dev TV (parallel)
* Move to HDTV

Research
* HD Receiver

Amazon
* HD Receiver

Errands > Costco
* Blu-Ray Player

I don't understand why those two items are in my No Context list. I can't do anything with them and they're effectively blocked until I deal with the other items.

Switching to "Available" solves the "display" issue, but still has my "No Context" count higher than it should be, since they aren't items that *have* a context!

OF, please comment on this thread. It's very important!

mloiterman 2010-02-21 12:32 PM

So far, I don't like having to assign a context to a project or action group. But I MAY like it or grow to like it. I don't know yet, because I think the way it works and is presented is pretty confusing. I think OF needs to rethink this feature.

The blocking feature is also confusing. For example, none of my projects or action groups are adopting the style I have set for Projects or Action groups. Rather, they've all adopted the style for Blocked. I don't understand why or how to unblock them. Maybe I'm missing something, but it doesn't seem like any of my projects or action groups CAN be unblocked.

Pretty confusing.

Toadling 2010-02-21 01:20 PM

[QUOTE=mloiterman;73777]I think OF needs to rethink this feature.[/QUOTE]

By "OF", I suspect you mean "the Omni Group". OmniFocus is a wonderful piece of software, but I don't think it put much thought into developing itself. :-)

As for "rethink[ing] this feature", that's exactly what's happening in the sneaky peek process right now! Neither the feature nor the 1.8 release have shipped. Be glad that [I]you[/I] get to have an active role in shaping the outcome by trying out the sneaky peek builds with an open mind and a willingness to provide constructive feedback. There aren't many development shops that give the consumers this much input into the process!

[QUOTE=mloiterman;73777]The blocking feature is also confusing. For example, none of my projects or action groups are adopting the style I have set for Projects or Action groups. Rather, they've all adopted the style for Blocked. I don't understand why or how to unblock them.[/QUOTE]

Actually, it's not really confusing at all. It's just a slight change in behavior.

[COLOR="Gray"]**For this discussion, projects and action groups behave the same way, so let's collectively refer to them as "parents"[/COLOR].

You probably wouldn't consider a parent complete until all of its actions are completed, right? So OmniFocus treats parents as blocked if they have any [I]incomplete[/I] actions (and parents are styled accordingly).

If you set your Availability Filter in context mode to "Available", parents will be hidden from view because they are blocked, unless all their actions are completed, in which case the parent is no longer blocked.

Pretty logical and straightforward, I think. It should have worked this way all along in my view. :-)

Where the confusion comes in is how should OmniFocus sort parents in context view, which is designed to display items by [I]context[/I]? Traditionally, parents don't have contexts, only actions do.

Parents do have a "default context" field (and have had it for quite some time now), so the simple solution was to categorize parents by the value of this already existing field.

Many people weren't using the parents' default context field, though, so now many parents are showing up in the "No Context" bin in context mode.

One proposed solution has been to simply assign some kind of "review" context to your parents to keep them out of the "No Context" bin. Another is for the Omni Group to add some kind of "Parents" bin to the context mode sidebar (actions without contexts go in the "No Context" bin, parents without contexts go in the "Parents" bin).

Whether any of these are acceptable solutions and how they might be improved is still being debated.

-Dennis

macula 2010-02-21 02:26 PM

[QUOTE=Toadling;73781]
Many people weren't using the parents' default context field, though, so now many parents are showing up in the "No Context" bin in context mode.
[/QUOTE]

Toadling,

For the sake of completeness in your good overview of the issue, may I add that the problem is deeper and wider than the "migration" of existing data to the new system.

1. Users are not accustomed to using the "default context" field, so they are prone to neglecting to set it, thus accidentally adding many future parents in the "no context" bin.

2. Some users don't even like to set a "default context" for parents. They just can't be bothered. Capricious or not, this needs to be taken into account.

3. (Some) users consider it conceptually absurd to assign a single context to a parent whose children carry a multitude of contexts.

4. The new system makes "default context" quite literally a misnomer, since it now also stands for "parent's context."

5. The new system equates the "default context" (i.e. normally the context used by the highest number of children) with the parent's own context. Even if we temporarily assume that "parent's context" makes sense (though it really doesn't), we must realize that it is not necessarily determined by frequency. For example, a project titled "Write article" may consist of [B]5 children[/B] in the "errands" context…

a. Make photocopies of research notes
b. Clean up desk
c. Call publisher to request copy of guidelines for authors
d. Enter new book acquisitions in bibliographic database
e. Get "XYZ" book from library

… and only [B]2 children[/B] in the "scholarship" context...

f. Write outline of article
g. Write article

While [B]5 > 2[/B], and therefore the default context for this project would most likely be "errands," one would be hard-pressed to claim that the project "Write article" is itself an errand! Indeed, "Write article" itself belongs in no context. It seems more of a work of scholarship although, really, it is just what it is—a project.

So, clearly, the "double entendre" of the "default context" field is convenient for Omni (developers), but not convenient for us (users). [U]This is perfectly acceptable (necessary, even) as long as this is a pre-release version.[/U] But, as I said in an earlier post, it doesn't seem to me viable as a permanent solution presentable to a wider public accustomed to Omni Group's exacting standards.

Toadling 2010-02-21 02:51 PM

Thanks for the elaboration, macula. You bring in some important points to the overview. Perhaps my coverage was a bit too simple; my goal was to suggest that the real complexities of the 1.8 changes were in the parents' context issue rather than in their blocking nature.

[QUOTE=macula;73784]While [B]5 > 2[/B], and therefore the default context for this project would most likely be "errands," one would be hard-pressed to claim that the project "Write article" is itself an errand! Indeed, "Write article" itself belongs in no context. It is what it is—a project.[/QUOTE]

I understand your thinking on this matter and wholeheartedly encourage supporters of this position to send their feedback to the Omni Group.

In the case of your example project, however, I would simply assign the context I need to be in to determine if the project can be closed or needs further actions to meet its goal.

Once you've checked off your 5 actions, what resources, location, or state do you need to be in to make your final decision to mark the project complete? Maybe it's in your office, or the MacBook on which you do your writing, or your "scholarship" hat, or maybe it's something you'd do while just sitting in front of OmniFocus.

Maybe this line of thinking is too loose for GTD-purist, but it seems to make sense for me. Having said that, I don't see how adding the proposed "Parents" bin would negatively impact my workflow, so I'll support it if Omni can be convinced to play along.

-Dennis

ksrhee 2010-02-21 03:16 PM

I have to say this is amusing to say the least. The default context option has been available going back as far as I remember. So, 1.8 did not introduce this concept!

What 1.8 did was to having projects/groups show up in the context view so that folks can have the option to have it appear when there are no action items associate with it - thus you can take action on the empty project/group. Now granted that the implementation could have been smoother or more elegant, but hey it's the first try. So, let's give OG some slack.

Now this new feature does alter the workflow somewhat, but hey, that's the way change works. When something changes, you try to adapt. It seems like some people are not even willing to give a new system a try.

So, my suggestion to KC and OG is to make this a global option for those who don't like it so that they can turn this feature off. Some of us have used other system that has this feature find this new feature useful, and for us, we would simply turn the option on.

As far as changing other parts of the interface, my intuition tells me OG doesn't have the time and resources right now to do this, given all the other projects they are working on, and perhaps this is something left for version 2. This way OG doesn't rush to react to the "reactions" of some folks in this forum and could potentially make things "worse." I think this type of interface change requires more careful thinking and an incubation period.

YMMV on this issue.

Ken

mloiterman 2010-02-21 03:25 PM

[QUOTE=Toadling;73781]By "OF", I suspect you mean "the Omni Group". OmniFocus is a wonderful piece of software, but I don't think it put much thought into developing itself. :-)

As for "rethink[ing] this feature", that's exactly what's happening in the sneaky peek process right now! Neither the feature nor the 1.8 release have shipped. Be glad that [I]you[/I] get to have an active role in shaping the outcome by trying out the sneaky peek builds with an open mind and a willingness to provide constructive feedback. There aren't many development shops that give the consumers this much input into the process!



Actually, it's not really confusing at all. It's just a slight change in behavior.

[COLOR="Gray"]**For this discussion, projects and action groups behave the same way, so let's collectively refer to them as "parents"[/COLOR].

You probably wouldn't consider a parent complete until all of its actions are completed, right? So OmniFocus treats parents as blocked if they have any [I]incomplete[/I] actions (and parents are styled accordingly).

If you set your Availability Filter in context mode to "Available", parents will be hidden from view because they are blocked, unless all their actions are completed, in which case the parent is no longer blocked.

Pretty logical and straightforward, I think. It should have worked this way all along in my view. :-)

Where the confusion comes in is how should OmniFocus sort parents in context view, which is designed to display items by [I]context[/I]? Traditionally, parents don't have contexts, only actions do.

Parents do have a "default context" field (and have had it for quite some time now), so the simple solution was to categorize parents by the value of this already existing field.

Many people weren't using the parents' default context field, though, so now many parents are showing up in the "No Context" bin in context mode.

One proposed solution has been to simply assign some kind of "review" context to your parents to keep them out of the "No Context" bin. Another is for the Omni Group to add some kind of "Parents" bin to the context mode sidebar (actions without contexts go in the "No Context" bin, parents without contexts go in the "Parents" bin).

Whether any of these are acceptable solutions and how they might be improved is still being debated.

-Dennis[/QUOTE]
Yes, by OF, I meant OG.

In terms of the blocking behavior, what you're saying makes sense. I see now how it's supposed to work. Nevertheless, the way it's implemented is confusing. Especially if you're used to the previous behavior.

For the Parents bin idea, I guess it makes sense, but it seems like a "dirty" way of getting around a larger conceptual problem of some people wanting / needing to assign contexts to Projects and Actions and others not wanting / needing this behavior.

I guess the easiest way to deal with all this, if I understand everything, is a checkbox somewhere that asks if you want Projects and Action Groups to be actionable. And, maybe an additional checkbox that asks if you want to be able to assign Contexts to Projects and Action Groups. Or maybe a better way to say it, since this capability has been around for a while, is if you want the program to behave as if this is a requirement.

I'm not sure I need or want this...I just don't use the software like that because it has never worked liked that before - been using it since Kinkless and pre OF 1.0 days.

Toadling 2010-02-21 03:33 PM

This has been mentioned in other threads and earlier in this thread, but I'll point it out again. The "parents appearing in context mode" feature can be disabled using an OmniFocus setting URL.

omnifocus:///change-setting?ContextModeShowsParents=false

Replace "false" with "true" to reverse the setting.

-Dennis

jasong 2010-02-21 03:40 PM

[QUOTE=Toadling;73781]
Many people weren't using the parents' default context field, though, so now many parents are showing up in the "No Context" bin in context mode.

One proposed solution has been to simply assign some kind of "review" context to your parents to keep them out of the "No Context" bin.
[/QUOTE]

The argument against this, as others have noted before me, is that a "default context" for parents imposes that context upon its children, which breaks many workflows (my own included), because (A) not everything in a project should get that default context and (2) a missing context is valuable to find incomplete loops.

[QUOTE=Toadling;73781]
Another is for the Omni Group to add some kind of "Parents" bin to the context mode sidebar (actions without contexts go in the "No Context" bin, parents without contexts go in the "Parents" bin).
[/QUOTE]

This is certainly a potential solution, and I'd love to see it tested. After a little more living on 1.8, this appears the most viable alternative.

jasong 2010-02-21 03:41 PM

[QUOTE=Toadling;73794]This has been mentioned in other threads and earlier in this thread, but I'll point it out again. The "parents appearing in context mode" feature can be disabled using an OmniFocus setting URL.

omnifocus:///change-setting?ContextModeShowsParents=false

Replace "false" with "true" to reverse the setting.

-Dennis[/QUOTE]

That hides the entries themselves, but still pollutes the No Context item with a higher-than-reality number.

Toadling 2010-02-21 03:44 PM

[QUOTE=jasong;73797]That hides the entries themselves, but still pollutes the No Context item with a higher-than-reality number.[/QUOTE]

Good point, jasong. So maybe that setting needs to go a bit further as well.

-Dennis

ksrhee 2010-02-21 03:50 PM

[QUOTE=jasong;73796]The argument against this, as others have noted before me, is that a "default context" for parents imposes that context upon its children, which breaks many workflows (my own included), because (A) not everything in a project should get that default context and (2) a missing context is valuable to find incomplete loops.[/QUOTE]

Hopefully, you can enlightened me on this. How is (A) different from what we have today (1.75)? Even in the current version, if you assign a default context, you would be presented with the situation you say you don't want.

For (2), yes, you would not find this is the missing context, but if you assign a context such as "review" to the project or groups, then you would find the "missing" contexts items in the Review context because you didn't reassign context to the items when you created them. You would just have to find it at a different place.

I believe if people get used to the new work flow, I don't think it would matter to them that much, but YMMV.

I don't think this will impact any new users since they would not have known the previous workflow anyway.

ksrhee 2010-02-21 03:52 PM

[QUOTE=jasong;73797]That hides the entries themselves, but still pollutes the No Context item with a higher-than-reality number.[/QUOTE]

Good point. Perhaps OG can address this point once the new option to turn on/off is installed.


All times are GMT -8. The time now is 11:58 PM.

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