[QUOTE=ksrhee;73799]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.[/QUOTE]

The difference is that in 1.8, my No Context list is polluted unnecessarily if I don't assign a default context, or all my items get a default context that may not match reality and lead to open loops.

[QUOTE=ksrhee;73799]
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.[/QUOTE]

And if I did want to use an *actual* default context for some reason? Then I have to track down the item with the "wrong" default context, which should have a different default context, leading to the "loss" of items by placing them in the wrong context.

[QUOTE=ksrhee;73799]
I believe if people get used to the new work flow, I don't think it would matter to them that much, but YMMV.[/QUOTE]

I think it depends on how you use OF, Contexts, Projects and so on. For some, this is clearly a welcome change, because they previously had to deal with lost actions, open loops or ugly workarounds.

For others, this is a terrible change, because it has the potential for losing actions, creating open loops or implementing ugly workarounds.

Can't win for losing.

I don't tend to use default contexts, because I want to chance to review my items with no context and ensure they're properly categorized. It destroys my workflow to put everything into a default "Review" (or whatever) context, because that means items without a context no longer show up on "No Context", they show up in "Review", and I have to look at possibly dozens of projects and actions, mixed together, only some of which are actually actionable.

Hiding the projects, and using Available instead of Remaining may be a workaround. The inaccurate number of items in a context remains an issue, and disturbs my attempts at "mind like water".

Is anyone else experiencing Action group styling issues? I tried to set it to green so i could visually discern the action grouped tasks, but they don't change color.

[QUOTE=MutantSquid;73808]Is anyone else experiencing Action group styling issues? I tried to set it to green so i could visually discern the action grouped tasks, but they don't change color.[/QUOTE]

I can confirm that action groups set to be styled a different color are so styled in 1.7.5 but not in the latest 1.8 sneaky peek. Just to clarify, however, only the action group header is styled, not the actions contained in it.

Hmm, I see the project itself is being styled differently as well, wonder why that is...

[QUOTE=jasong;73807]The difference is that in 1.8, my No Context list is polluted unnecessarily if I don't assign a default context, or all my items get a default context that may not match reality and lead to open loops.

And if I did want to use an *actual* default context for some reason? Then I have to track down the item with the "wrong" default context, which should have a different default context, leading to the "loss" of items by placing them in the wrong context.

I don't tend to use default contexts, because I want to chance to review my items with no context and ensure they're properly categorized. It destroys my workflow to put everything into a default "Review" (or whatever) context, because that means items without a context no longer show up on "No Context", they show up in "Review", and I have to look at possibly dozens of projects and actions, mixed together, only some of which are actually actionable.

Hiding the projects, and using Available instead of Remaining may be a workaround. The inaccurate number of items in a context remains an issue, and disturbs my attempts at "mind like water".[/QUOTE]

I can see how you find this not helpful since you do have to change the workflow.

This is something I used to do when I used LifeBalance, and now I can implement this in OF.

Every project gets the default context that matches most of actions in the project - this way I don't have to enter the context again.

I put filter to things that are available in the context area so that I can only see things I can work on. Even Next action filter should block projects.

The only time projects will show is when it's empty. If a project shows up, I decide to act on the project itself: add more action items; put project on hold and assign a new context (such as Review), mark the project complete, or drop it.

If I add more action items, the project will no longer show in the context view; so, the problem solved.

If I drop the project or complete it, it's done.

Now with the project on hold and with a new context, I can set up the perspective to track these pretty easily.

Let's say I decide to reactivate the project (take it out of hold) and add a new item, but I forgot to change the default context (i.e., it remains as Review). Then the new action items in the project will inherits "Review" as the context, and that's not what I want. However, if I look at what's under Review, I should be able to find the new action item pretty easily. [Right now I believe there is a bug in the context view under remaining that complicates the matter.] Then I can change these items' context easily.

Yes, this does require you to change your workflow, and some people may not like it, and thus, the option to disable this completely (& fixing the bug on counters of course).

However, as some of us have said, I find this feature extremely helpful when using another program (nothing falls through the cracks and I get stuff done earlier than my periodic review would allow); so, I welcome the change in OF.

Now one new feature that might solve your issue might be to have the ability to assign a different contexts to projects/groups themselves that are different than default context (e.g., projects or action groups), that way, we can track these easily in the context view if they show up.

Again, YMMV.

[QUOTE=whpalmer4;73810]I can confirm that action groups set to be styled a different color are so styled in 1.7.5 but not in the latest 1.8 sneaky peek. Just to clarify, however, only the action group header is styled, not the actions contained in it.

Hmm, I see the project itself is being styled differently as well, wonder why that is...[/QUOTE]
I ran into this too. It's because the action group is marked as "blocked" until all the actions within the group are completed.

This gets to the heart of why this is so confusing.

The one thing I'm still seeing, that I believe is a bug, is the same behavior with projects. Projects are still styled as blocked, even if everything within the project is complete. Bug or user error, I'm not sure, but it appears to be a bug.

One additional reason why the new behavior is, in my view, problematic. You look at your actions in planning mode, and see at least one [B]available[/B] action within an [B]unavailable[/B] group. How inconsistent and disconcerting! Available actions under unavailable headings… That's a lot of mental turbulence.

Scrap that textbox?
 

I don't know if this has been brought up already in this thread—if so, please disregard and accept my apologies.

It seems to me that the source of all evil is the ability bestowed upon the user to keep a parent "pending" (i.e. not ticked off) while all its children are completed—I'm referring to that insidious option at the very bottom of Preferences>Data. That's how the dilemma that the Omni developers faced emerges: Shall the action following the parent be released anyway (whereby the parent risks "falling through the cracks") or kept unavailable until the parent is ticked off (whereby your project risks stalling with the user possibly in oblivion or confusion)?

It is reasonable and laudable that Omni tries to address this problem. However, the solution they are suggesting in 1.8a is, as many of us in this thread believe, at least as confusing and introduces lots of conceptual and usability problems.

So much confusion, and so much debate pitting two imperfect approaches against each other, just in the name of "flexibility": Allowing the user to keep a parent open even if all its children are completed. In my view, [U]this is too high a price to pay for a damn check box in the preferences![/U]

Here is my somewhat radical suggestion then: Remove the check box altogether and hardcode this behavior whereby a parent will be automatically marked as completed when its children are completed. Then also remove all this "1.8 baggage", most of all the assignment of contexts to parents, which has sparked so much lively debate among both devoted and new users.

The cost will be minimal: If you want to add a further action to a completed parent, just make a perspective to display completed parents and do your thing.

The benefit is maximal: Nothing falls through the cracks, and everything is kept simple, clear and tidy. No conceptual acrobatics. No mental turbulence.

As an added benefit, this suggestion only requires pruning of the existing code, rather than augmentation.

I'm not really a fan of the idea of having projects automatically complete without my intervention, simply because they [i]will[/i] fall through the cracks. A perspective to view completed projects doesn't help this, as I could have dozens of completed projects, and going through all of the ones that are [i]actually[/i] closed and done to find the one or two that may need to be re-opened is going to be cumbersome at best.

For what it's worth, I think there are two critical issues here that may be quite easy for the Omni folks to solve: The appearance of unassigned parent items in the "No Context" section (or in context view at all), and the new double-meaning for the "Default Context" field. I propose the following:
[LIST][*]Projects and action groups get [i]two[/i] fields: Default Context and Parent Context. [*]The Default Context behaves exactly as it did pre-1.8 and has no effect on the appearance of projects or action groups in context view.[*]The Parent Context field handles the new functionality introduced in v1.8.[*]Projects and Action Groups without a "Parent Context" assigned simply do not appear in action lists [i]at all[/i]. No Context continues to be used only for [i]actions[/i] and not projects or action groups.[*]Projects and Action Groups with a "Parent Context" behave in the same way they do right now in 1.8 with the Default Context.[/LIST]The above would allow users who don't like the new functionality at all to completely ignore it by simply not assigning "Parent Contexts" to any of their projects or action groups (which would also be the default state). Those users who know what they're doing and want to take advantage of projects and action groups as actionable items can assign "Parent Context" entries as necessary. Unlike a global option, this also has the very useful advantage of allowing a mixed-mode scenario. For example, I would very much like to see some of my Action Groups be actionable items in context view, but I don't really like the idea of seeing my actual [i]projects[/i] appear there.

Although we're talking about adding an extra field, this solution actually strikes me as elegantly simple since it leaves the new functionality "off" by default -- the "Parent Context" field is blank on all existing projects and action groups until the user explicitly specifies one, and only those users who want to use the new feature are going to be bothered doing so.

[QUOTE=macula;73831]
Here is my somewhat radical suggestion then: Remove the check box altogether and hardcode this behavior whereby a parent will be automatically marked as completed when its children are completed. [/QUOTE]

Uh, no thanks! That would require complete planning of all actions in a project before starting, or additional time hunting down completed action groups and projects to see if something more should be added. The former definitely isn't something that would be put forward as a GTD precept, and the latter is a big waste of time.

jdh,

I'll have to think about it some more, but your suggestion sounds good to me at first hearing. I like the ability to use the functionality only some of the time (which is how I use the auto-complete feature), too. I think "parent context" might be a confusing name for some, however, especially when dealing with action groups.

No doubt, whpalmer, you have a point too.

It all comes down to different tastes and priorities, obviously. For me, simplicity is about having clear and unambiguous conceptual categories. For others, simplicity is about visual presentations. For others still, it boils down to minimizing the number of clicks to access your information.

It seems overall that Curt's suggestion (projects and action groups being actionable and automatically placed in their own "bin") makes both camps happy. If no such "bin" is implemented, at least there should be a "default context" setting for projects and groups in the app's preferences. That way we can create our own bin of sorts by having a special "Projects/Groups" context automatically assigned to parents.

[QUOTE=whpalmer4;73838]jdh,

I'll have to think about it some more, but your suggestion sounds good to me at first hearing. I like the ability to use the functionality only some of the time (which is how I use the auto-complete feature), too. I think "parent context" might be a confusing name for some, however, especially when dealing with action groups.[/QUOTE]

It doesn't have to be called "parent context"—which of course would look appalling and irrelevant on screen. Instead, as I wrote above, it can be a "bin", just like the inbox, perhaps even placed immediately below the inbox on the sidebar, which would be titled "Projects and Action Groups." And [U]that[/U] can be hard coded—automatically assigned to projects and groups, or assigned to them by default, with the capability of it being overriden by the user.

I think you may have missed what I was suggesting... While I agree that there is definitely better nomenclature than Parent Context, my earlier post was suggesting that each Project and Action Group have an extra [i]field[/i] to allow the user to specify a [i]specific context[/i] (separate from the "Default Context") if they so desire.

While adding a new field may [i]seem[/i] more cumbersome, it's one of those things that's useful if you want it, and can easily and safely be ignored if you don't. Nothing extra is needed in context view except to ensure that projects/action groups [i]without[/i] a context simply don't appear [i]at all[/i].

I'm personally not in favour of the idea of putting an extra "bin" in context view, since that tends to defeat the purpose of context view IMHO. Having a "bin" with unassigned projects/action groups seems cumbersome regardless of whether they're listed under "No Context" or some other place. I'd rather they appear where they're specifically assigned or not appear at all.

I agree that a project's default context for its actions and its context in which I might want to see it in context mode are two wholly different things. Cramming both into the same field makes little sense. I second the idea that, if this new functionality is going to be added, a new field will need to come with it.

[B]jdh and Craig,[/B]

That sounds fine, thank you. I would only add that there should be a global default setting for the parent's context in the application preferences (with the possibility, obviously, to override that context for each parent individually via the inspector). This arrangement will also satisfy those users who don't want to bother with manually entering a context for each parent, but at the same time don't want the parents to be hidden away.

I think jdh's proposal has merit, especially if the context for parents could be set to default to something like "Review" (or whatever the user chose). That default would essentially replace the Parent bin that I suggested.

It's not clear to me which would be more understandable. One difference with jdh's proposal is that it exposes in the UI that there is a distinction between the context of a project and the default context for actions in that project. That gives the user the ability to set the two independently. With the Parent bin proposal the context of a project effectively would always be Parent, though Parent would be called out in the UI as a special context.

For extra credit, suppose that contexts for projects could be automatically set in the preferences. What do you call that setting to distinguish it from the default context field of a project that will be used by new actions?

(I have to say, I'm enjoying the discussion about the best way to resolve this. Thanks for all the interesting opinions. I know the folks from Omni are watching the thread.)

[QUOTE=macula;73831]Here is my somewhat radical suggestion then: Remove the check box altogether and hardcode this behavior whereby a parent will be automatically marked as completed when its children are completed. Then also remove all this "1.8 baggage", most of all the assignment of contexts to parents, which has sparked so much lively debate among both devoted and new users.[/QUOTE]

IMO that works for groups, but not for projects. I definitely don't want to have to plan all my projects in detail in advance to keep them from being automatically marked "Done" when they're nowhere near it!

[QUOTE=curt.clifton;73847]For extra credit, suppose that contexts for projects could be automatically set in the preferences. What do you call that setting to distinguish it from the default context field of a project that will be used by new actions?[/QUOTE]

Review context?
Completion review context?
Check completion context?
Context mode context?

Dunyet context? :-)

[QUOTE=curt.clifton;73847]I think jdh's proposal has merit, especially if the context for parents could be set to default to something like "Review" (or whatever the user chose). That default would essentially replace the Parent bin that I suggested.[/QUOTE]

At that point, what's the difference between this Review context and the existing Stalled filter/perspective that's already available in 1.7, other than whether it shows up in planning or context mode?

Am I understanding this right, that the only purpose of showing parents within context views is to keep them from stalling by alerting the user that a parent's last unfinished action was just finished? If so, why not just alert the user directly by putting up a dialog when the last available action is checked "done" or deleted? That way contexts are kept uncluttered and conceptually clean.
The dialog could offer to open a window focused on the parent that's at risk of stalling. Click "OK" or hit Enter to go to that window and add more actions, or click "Cancel" or hit Esc to dismiss the dialog and continue doing something else.
Conceptually, defining new tasks for a project belongs in planning mode anyway, where of course it's already available in 1.7 via the Stalled project filter.

[QUOTE=eurobubba;73848]IMO that works for groups, but not for projects. I definitely don't want to have to plan all my projects in detail in advance to keep them from being automatically marked "Done" when they're nowhere near it![/QUOTE]

I feel the same way about groups as you do about projects.

Versus squeezing a yet another field into action groups with a function that is at least not immediately obvious, plus another default in the preferences, is all of that [I]really easier[/I] than just adding an action to the end of groups that you so choose to review them and make sure they’re done?

I know that’s not built in or “hard coded” or whatever, but this sure seems like a lot of complexity and cruft for pretty minimal added efficiency.

[QUOTE=Lucas;73853]Versus squeezing a yet another field into action groups with a function that is at least not immediately obvious, plus another default in the preferences, is all of that [I]really easier[/I] than just adding an action to the end of groups that you so choose to review them and make sure they’re done?

I know that’s not built in or “hard coded” or whatever, but this sure seems like a lot of complexity and cruft for pretty minimal added efficiency.[/QUOTE]

If this were Facebook I'd be clicking the "Like" button.

[QUOTE=eurobubba;73850]At that point, what's the difference between this Review context and the existing Stalled filter/perspective that's already available in 1.7, other than whether it shows up in planning or context mode?[/QUOTE]
I guess the short answer is the place where it's reviewed and actioned. I do most of my work in context mode, switching back to project mode only during planning phases where I need to expound upon a specific project, or during my weekly review.

IMHO, this new behaviour is more useful for Action Groups than Projects, although it works for both. It's easy to pick up on closed/completed/stalled projects in the Planning mode, but action groups can be a lot murkier since they're in-line with everything else.

[QUOTE=eurobubba;73851]Am I understanding this right, that the only purpose of showing parents within context views is to keep them from stalling by alerting the user that a parent's last unfinished action was just finished? If so, why not just alert the user directly by putting up a dialog when the last available action is checked "done" or deleted? That way contexts are kept uncluttered and conceptually clean.[/quote]
IMHO it's a bit more complicated than that. What if I don't want to complete a project, or more importantly an action group, right away simply because the last task is completed? Frankly, if I [i]do[/i], then OF has already had that option for some time in the form of the 'Auto-complete' checkbox for any given Project or Action Group. However, leaving the parent item around in a more appropriate context until the next time it can be "actioned" can be very useful in a number of scenarios.

To put it another way, a dialog box requires an immediate response, which is much different than leaving an action in-place that can be handled at a more appropriate time.

Likewise, often it's important to note that a project is completed and/or awaiting more actions more immediately than simply waiting for the next time you're in planning/review mode.

[QUOTE=Lucas;73853]Versus squeezing a yet another field into action groups with a function that is at least not immediately obvious, plus another default in the preferences, is all of that [I]really easier[/I] than just adding an action to the end of groups that you so choose to review them and make sure they’re done?[/QUOTE]
This is what I've done in the past and it mostly works well enough. However, this new method has a couple of advantages that I can see:

Firstly, it avoids requiring yet-another-task in the project as a placeholder that needs to be managed. This extra task can be very inconvenient if you're regularly updating the project, especially via methods like quick-add or even simply drag-and-dropping items in from the inbox -- they'll end up [i]below[/i] that placeholder task, which you'll then have to repeatedly move downward during your regular reviews to keep it at the bottom, or risk thinking the project is "complete" while there are still other tasks below it.

Secondly, it's even less efficient for somebody who wants to take the approach that the majority of their projects or action groups are actionable and completed separately. A placeholder task works fine as a one-off on occasion, but having to insert them into dozens or even hundreds of projects can quickly get unwieldy compared to simply having the software handle that for you automatically.

[QUOTE=eurobubba;73848]IMO that works for groups, but not for projects. I definitely don't want to have to plan all my projects in detail in advance to keep them from being automatically marked "Done" when they're nowhere near it![/QUOTE]

I understand. As you may have noticed, my subsequent posts implicitly revoke that rather radical proposal I made.

I am fully aligned with what Curt suggests (the "bin" idea). I would also be equally happy with Craig's proposal provided that a global "default context" setting for groups/projects is available in the application preferences.

What's really annoying is I thought that we could now actually assign PROPER REAL contexts to projects and groups

I mean, REALLY assign contexts to them, not just set each one a default context for the actions you create in them

I began coming up with all kinds of interesting 'areas of responsibility' type uses for this idea, and other new contexts I could create just for organising my projects

And then I realised it's just a default setting for actions you haven't yet made in the project / group and not project specific contexts at all

Pah.

Actually, "Default Context" is not what's new here -- that's been there for quite some time (1.5? I can't remember exactly when it first showed up). The only difference is the Default Context is [i]also[/i] being used to assign an "active" context to the Projects themselves, so it's serving double-duty, and not in a way that would be practical for many users.

The new 1.8 behaviour does what you're suggesting, it just seems that it uses the wrong field to actually [i]do[/i] it.

[QUOTE=jdh;73862]The new 1.8 behaviour does what you're suggesting, it just seems that it uses the wrong field to actually [i]do[/i] it.[/QUOTE]

I like jdh's proposal. It seems to give the most flexibility without overloading the meaning of the existing default context field.

In projects and groups, maybe the existing field should actually be called something like "Default Child Context" and the new field simply called "Context", just like actions.

A parent's context field could then be displayed in the context column of the main outline. That way you save yourself a trip to the inspector to set it for a group; just tab to the context column and enter a value using smart match. Of course, the Default Child Context field would still only appear in the inspector.

-Dennis

[QUOTE=Toadling;73864]
A parent's context field could then be displayed in the context column of the main outline. That way you save yourself a trip to the inspector to set it for a group; just tab to the context column and enter a value using smart match. Of course, the Default Child Context field would still only appear in the inspector.
[/QUOTE]

It sounds perfectly fine to me but let me repeat what Curt and I have suggested, among others: If this sort of system is implemented, we need a "default" setting for the parents' context field. Many of us will actually create a dedicated context for parents, a context acting as "bin" for parents, so having a global default for that field would ensure that parents would not… well… fall through the cracks!

[QUOTE=macula;73866]If this sort of system is implemented, we need a "default" setting for the parents' context field. Many of us will actually create a dedicated context for parents, a context acting as "bin" for parents, so having a global default for that field would ensure that parents would not… well… fall through the cracks![/QUOTE]

I can live with that suggestion as well. It's more stuff crammed into the prefs interface, but in this case I think it's worth it.

-Dennis

[QUOTE=ksrhee;73811]

Now one new feature that might solve your issue might be to have the ability to assign a different context to projects/groups themselves that are different than default context (e.g., projects or action groups), that way, we can track these easily in the context view if they show up.

Again, YMMV.[/QUOTE]

It seems like there is a traction to this idea; so, let me add some more to this. The beauty of this system is to give users the flexibility one needs to manipulate context views. This is one feature that is possible in LB and I have fully took advantage of this feature (although LB still uses the top-level context for all children views, but you can change those manually). So, if OG implement this feature, it would be even better.

This will give people the ability to separate out projects from actions, hide the projects from certain context views (by putting the context on hold), separate out active projects from stalled projects in the context view (by assigning "review" or other context labels to stalled projects), etc. In other words, in LB, I used the outline view to plan my actions, but I've always used the todo view to act. In other words, during the day, my main view will be my context view (in OF terms), and I would never have to worry about anything falling through the cracks, missing, etc even though I never looked at my outline view in LB (e.g., Project view in OF). In OF, I have to keep going back and forth between two views during the day to ensure this did not happen.

So, hopefully, Omni folks are listening.

Can we start getting updates in the release notes between builds, so we can know what's changed?

Hmmm… new seed released today. Judging from the release notes on the update window, it seems that the developers are sticking to their decisions and not implementing any of the suggestions in this thread. Of course, it's early in the development cycle, and this is only an alpha (or beta?). I'm eager to see how this controversial (among users) build will evolve.

Here are a few of my observations based on past sneaky peek cycles. Interpret them as you will.
[LIST=1][*]The Omni Group seems to work across all versions of a product simultaneously (Mac, iPhone/iPod, and now iPad). The build process between them seems to be automated and connected. Sometimes updates in the app for one platform triggers an update in all platforms, even though there are no recognizable changes in the other platforms.

[*]Sometimes the release notes lag behind the code changes.

[*]Release notes often seem to come in bursts, where you might suddenly see all kinds of stuff added over the past week.

[*]Big changes (like adding a context field to parents) impacts all versions of the product. So I don't think it's likely we'll see a sudden change here until a corresponding iPhone app is also ready.

[*]I'm sure Omni is aware of this issue and, as Curt mentioned, they are probably keeping an eye on this thread. But it pays to thoroughly think things through before rolling out a big change and introducing unnecessary churn. We need to be patient.[/LIST]
-Dennis

What Dennis said. Basically, it's not at all uncommon to see several sneaky peek builds come out with no updated release notes -- it's happened with pretty much every sneaky peek over the past year.

In fact I seem to recall Omni actually stating outright that the builds are generated automatically and sometimes [i]nothing[/i] changes because they're all part of the same code base.

You can hide incomplete projects by changing the Availability Filter to "Available".

for me it doesn't work...

(Remember, projects themselves are not considered available until all of their tasks have been finished—at which point you probably want to review a project's status anyway.)

all the project related task are finished and the project (having changed the filter to available...!) stays boldly there...

quite confused, sorry

Alessandro

If you've finished all of the available tasks, then the project [i]should[/i] be appearing to prompt you to take further action on it.

The earlier comments refer to the fact that the projects will appear in context view when "Remaining" is selected in the same way as any other blocked tasks. When the filter is set to "Available" the projects are hidden in the same way as other unavailable tasks. Once you complete all of the actions in the project, the only "action" left is the project itself, so you need to check that off to complete it if you're truly finished the project, after which it should disappear.

Alternatively, you can enable the option to "Mark complete when completing last item" in the project properties (in the inspector) and the project will automatically be marked completed as soon as you check off the last item, thereby not showing up in the context view available filter since it's already marked as completed at that point.

thanks,
it was different...
if a project has a due date even with no action it is visible (also with [I]Available[/I] as filter...

thanks

Alessandro

Quick post to clear up any confusion: this is a great thread. Big thanks to everyone that's participating; we [I]are[/I] paying attention. The suggestions here will help us determine how this should work in the final release of OmniFocus for Mac 1.8.

We're working really hard on iPad apps right now, and we expect that to continue for a while. Since the various apps share code, our iPad app work can cause the build system to put out a new sneakypeek release of the Mac app, even if we haven't directly worked on that project.

In the meantime, folks contributing to this thread should not be discouraged. It's going to be a while before 1.8 is finalized, but when that happens, it's going to reflect the suggestions and ideas here.

Since we do plan to change things before going final, the folks that don't like the new behavior of groups/projects in context mode won't miss out on anything if they switch back to 1.7 for a while. We'll be sure to update the forums when we revisit this.

Thanks again, everyone!

[quote]Fixed a bug which could cause duplication of a repeating due project or group during synchronization.[/quote]

OMG! This has been killing me for months (literally, 2-4 projects a day were being duped. So happy you got it.

BZ

Did you remove CMD+W? Because if I close it by CMD+W it wan't reopen, if I click on the icon or in the menubar - I've to close the App and restart it.

Hmm, are you sure about that? If I close all my windows via repeated cmd-W, clicking on the dock icon brings up a new window (this under SL). What happens if you do File->New Window?

[QUOTE=whpalmer4;74364]Hmm, are you sure about that? If I close all my windows via repeated cmd-W, clicking on the dock icon brings up a new window (this under SL). What happens if you do File->New Window?[/QUOTE]

Hey,
no I'm sure - I'm on 1.8 and SL and if I close OF bye CMD+W and click on the dock-icon nothing happens. If I'll go to File -> New Window, it works. Menubar works too (right above in the corner, left beside the clock).

How odd -- I wonder what the difference is that makes it work for me and not for you. I would contact the support ninjas directly (Help->Send Feedback) rather than hoping that they will see your post on the forum...

[QUOTE=whpalmer4;74381]How odd -- I wonder what the difference is that makes it work for me and not for you. I would contact the support ninjas directly (Help->Send Feedback) rather than hoping that they will see your post on the forum...[/QUOTE]

Thank you :)

Since nothing much has been changing in the sneaky peek builds on the Mac side lately, I've been skipping the last few updates. This morning, however, OmniFocus basically "expired" on me, forcing me to go visit the web page or RSS feed to download the latest sneaky peek.

In the process, I noticed that the RSS feed is actually about three weeks old -- the last version showing up in the feed is from March 2nd, and isn't even available for download any more. The web site had the latest version, so I was able to download that and proceed with no problems.

I'm also wondering why the app can't just download the latest update in this case using the normal update method rather than forcing me to visit the web site to get it? Obviously if I had not skipped the previous update yesterday it would have downloaded it automatically for me, however it doesn't seem to make much sense once I'm past the "expiry" date that I have to go out and get the latest build and install it manually rather than just being able to use the same auto-update process (perhaps with the "Skip" button greyed out).

Yeah, it'd be nice if the software updater warned you that your current build was going to expire before the next time the software updater was going to check, and I don't really understand why upon detecting that your current build has expired, the software updater can't be used to download the latest version.

There is a message emitted to the console log when the app is launched that mentions how many hours there are until build expiration, if I recall correctly, but that's pretty low visibility for most users, I think :-)

It also seems like bumping up the shelf life on the builds before turning away to work on iPad matters would have been a thoughtful move. The stated purpose of the expiration has been to keep us from encountering and reporting bugs in older versions which might have been fixed in newer versions, but when you know there aren't going to be any substantively different newer versions, there's no point.

I'm sure OG and especially KC are busy trying to put the finishing touches on their iPad applications. My emails to OG folks including KC haven't answered in several days, but I understand. It's only a few days left for them if they want to release the applications on 4/3.

OF for iPad will be the first application I'll by for my iPad once I have it on Monday (4/5). No Saturday delivery to my organization I'm afraid.

From some comments I saw earlier, I'm not sure that OF will be coming to the iPad immediately at launch. I seem to recall KC mentioning that they wanted to give priority to apps like OmniGraphSketcher that aren't already available in an iPhone OS version.

That said, I do fear that the iPhone version of OF is going to look pretty weird on the iPad.

[QUOTE=jdh;75053]From some comments I saw earlier, I'm not sure that OF will be coming to the iPad immediately at launch. I seem to recall KC mentioning that they wanted to give priority to apps like OmniGraphSketcher that aren't already available in an iPhone OS version.

That said, I do fear that the iPhone version of OF is going to look pretty weird on the iPad.[/QUOTE]

I was pretty sure OF will be available on the day if not immediately after the iPad launch. Here is what KC said in OG's blog: "This is a big undertaking, and we can't do it all at once. We started working on iPad adaptations of OmniGraffle and OmniFocus as soon as the SDK was made available Wednesday afternoon, and we're hoping to get started with OmniGraphSketcher for iPad within the next few weeks."

I also assume all the new builds we are seeing is part of iPad version build they are doing since nothing is being done on Mac or iPhone side.

Ken

No, OmniFocus on the iPad will be the current iPhone/iPod touch version initially, according to Ken's more recent statement here:

[url]http://twitter.com/kcase/status/10373468929[/url]

The original comments I remember seeing from Ken were on Twitter, [url=http://twitter.com/kcase/status/10373468929]here[/url] and [url=http://twitter.com/kcase/status/10374692598]here[/url].

Further, from what Ken said during [url=http://www.macnn.com/articles/10/02/12/four.apps.likely.by.years.end/]an interview at Macworld[/url], apparently OmniFocus will only be available as a "resized iPhone app" with a "fully-developed OmniFocus due by year's end."

I suppose this implies that OmniFocus will at least appear properly on the iPad in full-screen without ugly pixel-doubling, but the current UI will likely still look kind of strange when increased to an iPad screen size. Personally, I'm more excited to see what OF 2.x brings, both to the iPad and the iPhone, but it sounds like that's still a bit of a while out.

Perhaps Ken can clarify further in this thread assuming that he actually has any time to read the forums these days.... :)

I reserve the right to change my mind when I see it, but I think an iPad-sized version of the iPhone app might have a pretty nice feel. The current screen size makes for a bit of a cramped layout, particularly if you get two or three-digit counters, detailed project/action names, notes, etc.

[QUOTE=jdh;75057]The original comments I remember seeing from Ken were on Twitter, [url=http://twitter.com/kcase/status/10373468929]here[/url] and [url=http://twitter.com/kcase/status/10374692598]here[/url].

Perhaps Ken can clarify further in this thread assuming that he actually has any time to read the forums these days.... :)[/QUOTE]

Yes, I would welcome that. If the initial iPad application is only pixel doubling, then why are so many builds of OF produced lately?

I asked Ken whether they plan to release another version of iPhone OF soon since there are still bugs existing for perspectives in 1.61, but I haven't heard back.

Ken

No, I don't think it will be just pixel-doubled -- the comment was a "resized" iPhone app, implying that it will run at native resolution on the iPad but won't necessarily be redesigned specifically to take advantage of the new iPad UI options or even change the existing layout all that much.

Just because they're not doing a major redesign doesn't mean that they don't still need to test OF on the iPad platform and with OS 3.2, so that would explain all of the builds. It also sounds as if the initial iPad-compatible release will be universal and will therefore probably just be an update to the existing OF for iPhone that brings iPad support with it. So this might also be the OF 1.62 update. Keep in mind that there are no "sneaky peeks" for the iPhone version due to Apple's testing restrictions, so we don't get to see the iPhone builds either.

I think Ken mentioned on Twitter that OF 2.0 [i]might[/i] end up being a separate app for the iPad, but of course it would be fully designed to take advantage of the iPad UI as well.

[QUOTE=jdh;75069]No, I don't think it will be just pixel-doubled -- the comment was a "resized" iPhone app, implying that it will run at native resolution on the iPad but won't necessarily be redesigned specifically to take advantage of the new iPad UI options or even change the existing layout all that much.
[/quote]
Right -- it will look as it would have on an iPhone or iPod that happened to have had a 1024x768 screen. You'll be able to see more text on each line, more lines on the screen, probably some tweaking of layouts but it will still look like the current app, just on a bigger canvas.
[quote]Keep in mind that there are no "sneaky peeks" for the iPhone version due to Apple's testing restrictions, so we don't get to see the iPhone builds either.
[/quote]
A developer can let up to 100 devices use an app without going through the App Store. Unfortunately, they can't reset the list very often (sounds like the list lasts for a year, and once you've used a slot, you can't assign it to another device), and there are a lot of people (and more devices) at Omni who are naturally pressed into testing duty. For the most recent round of iPhone/iPod changes, Omni did do some external testing, but there were only 4 of us on the outside because most of the 100 spots are already gone. I'm a bit apprehensive that I'll be sitting on the sidelines for the next dance, as I had to trade iPods with the Apple Store the other day after my display failed, and now my UDID no longer matches the certificate. You are correct that they can't do a wide-open "sneaky peek" program on the iPhone OS devices like we are used to with the desktop app. Apple wouldn't be assured of getting their cut of the revenue (or the control they enjoy) without that limit.

I just noticed a bug in the 1.8 betas: Action groups containing at least one flagged action invisibly inherit the 'flagged' property. Therefore, filtering by 'flagged items' displays those action groups even though they themselves are not flagged.

Just a heads up for the developers for when they resume Mac development.

Thank you.

Any bug reports should be submitted with Help->Send Feedback to make sure they are actually seen by the developers. The development database is their "trusted system", not the forum :-)

[QUOTE=ksrhee;75054]I was pretty sure OF will be available on the day if not immediately after the iPad launch. Here is what KC said in OG's blog: "This is a big undertaking, and we can't do it all at once. We started working on iPad adaptations of OmniGraffle and OmniFocus as soon as the SDK was made available Wednesday afternoon, and we're hoping to get started with OmniGraphSketcher for iPad within the next few weeks."[/QUOTE]

I apologize for the confusion! As I said in that same blog post, our plans can and will change—which, in fact, they did: since OmniFocus for iPhone already runs on iPad, we decided to prioritize our other apps which aren't available there yet. And since we didn't want to delay the upcoming Mac releases of either OmniOutliner or OmniPlan, we decided to start with OmniGraffle and OmniGraphSketcher.

I'm among those who are glad to hear that the behavior of groups/projects in context mode will be changed before 1.8 goes final.

In the discussion, I've especially appreciated the suggestions from [URL="http://forums.omnigroup.com/showpost.php?p=73703&postcount=71"]Curt[/URL] and [URL="http://forums.omnigroup.com/showpost.php?p=73832&postcount=108"]jdh[/URL]. As I read through the thread today, I wondered if maybe the best solution would be to have a combination of the two - jdh's solution, but [I]also[/I] (optionally?) a parents bin at the top.

And then Curt said:
[QUOTE=curt.clifton;73847]I think jdh's proposal has merit, especially if the context for parents could be set to default to something like "Review" (or whatever the user chose). That default would essentially replace the Parent bin that I suggested.[/QUOTE]

Alright... that seems good... maybe. But suppose someone manually sets a parent's context to something other than the default - and it turns out not to be the one that is most intuitive or useful when all of the children are complete? Isn't the parent then at risk of "falling through the cracks"?

In other words: Some users may want certain parents to show up in a particular context when the children are complete - if they tend to plow through a perspective which shows a single context. Misjudging what context should be applied may result in a stalled project, and some difficulty in tracking down the culprit. A hard-wired parents bin (which displays [I]and counts[/I] parents according to the applied filters) would help here.

Am I off-base? Or missing something?

[QUOTE=Hope;75116]Alright... that seems good... maybe. But suppose someone manually sets a parent's context to something other than the default - and it turns out not to be the one that is most intuitive or useful when all of the children are complete? Isn't the parent then at risk of "falling through the cracks"?

In other words: Some users may want certain parents to show up in a particular context when the children are complete - if they tend to plow through a perspective which shows a single context. Misjudging what context should be applied may result in a stalled project, and some difficulty in tracking down the culprit. A hard-wired parents bin (which displays [I]and counts[/I] parents according to the applied filters) would help here.[/QUOTE]
The problem is that there's no computer program that can (or should) ever take full responsibility for ensuring nothing falls through the cracks. OmniFocus is a great tool, but it can't replace being used as part of an effective review system. Any task could potentially be set to a context that the user wouldn't normally check and therefore result in a stalled project -- I don't think that parent action groups or projects are necessarily a special case here (nor should they be treated as such IMHO).

Keep in mind that pre-1.8, projects don't appear in context view [i]at all[/i], meaning that they will effectively "fall through the cracks" anyway unless you pick them up as part of your weekly/daily review, which is done in planning mode. Further, I don't think there's any proposal that has the "Auto-complete" going away in 1.8, so projects that don't need to be reviewed manually upon completion can still be set to be completed automatically.

[QUOTE=macula;73825]One additional reason why the new behavior is, in my view, problematic. You look at your actions in planning mode, and see at least one [B]available[/B] action within an [B]unavailable[/B] group. How inconsistent and disconcerting! Available actions under unavailable headings… That's a lot of mental turbulence.[/QUOTE]

With last night's changes, planning mode will render parents as available whenever they contain available actions. Hope that helps!

[QUOTE=jasong;73807]Hiding the projects, and using Available instead of Remaining may be a workaround. The inaccurate number of items in a context remains an issue, and disturbs my attempts at "mind like water".[/QUOTE]

Did last night's change to the "No Context" counter help with this?

[QUOTE=Ken Case;76223]Did last night's change to the "No Context" counter help with this?[/QUOTE]

I'm not sure, as I'm seeing some odd behavior I can't quite explain, and don't have a non sneakypeek to validate.

At the very least, I still have my No Contexts view saying I have 42 items in them, though those items don't show up except under "Any Status".

The odd behavior is that with Remaining Projects and Active Context Filter set, and with Availability Filter set to "Any Status", items that are Dropped are showing up in my list.

For example, I have a Project "Use my Interval International "Search First" credit", and it's Dropped

[ATTACH]1359[/ATTACH]

It shows up under my No Contexts grouping

[ATTACH]1360[/ATTACH]

Many other Dropped projects are showing up under No Contexts also. I don't think that's supposed to be true.

I wonder whether the developers are still considering implementing a more elegant solution for making groups and projects actionable, along the lines of the lively debate that unfolded around post #110 or so. I am quoting a related idea that gained considerable support below:

[QUOTE=jdh;73832]
For what it's worth, I think there are two critical issues here that may be quite easy for the Omni folks to solve: The appearance of unassigned parent items in the "No Context" section (or in context view at all), and the new double-meaning for the "Default Context" field. I propose the following:
[LIST][*]Projects and action groups get [i]two[/i] fields: Default Context and Parent Context. [*]The Default Context behaves exactly as it did pre-1.8 and has no effect on the appearance of projects or action groups in context view.[*]The Parent Context field handles the new functionality introduced in v1.8.[*]Projects and Action Groups without a "Parent Context" assigned simply do not appear in action lists [i]at all[/i]. No Context continues to be used only for [i]actions[/i] and not projects or action groups.[*]Projects and Action Groups with a "Parent Context" behave in the same way they do right now in 1.8 with the Default Context.[/LIST]The above would allow users who don't like the new functionality at all to completely ignore it by simply not assigning "Parent Contexts" to any of their projects or action groups (which would also be the default state). Those users who know what they're doing and want to take advantage of projects and action groups as actionable items can assign "Parent Context" entries as necessary. Unlike a global option, this also has the very useful advantage of allowing a mixed-mode scenario. For example, I would very much like to see some of my Action Groups be actionable items in context view, but I don't really like the idea of seeing my actual [i]projects[/i] appear there.

Although we're talking about adding an extra field, this solution actually strikes me as elegantly simple since it leaves the new functionality "off" by default -- the "Parent Context" field is blank on all existing projects and action groups until the user explicitly specifies one, and only those users who want to use the new feature are going to be bothered doing so.[/QUOTE]

just curious, has the extra blue hidden window bug in expose been taken care of..?

I'm using the OF sync server and when I installed the latest 1.8 build (using auto update feature), the sync settings get deleted

What I would like to see is a sort option to input a text string. ie. I have multiple websites and since we can't setup perspectives on projects, well adding a code to a next actions or task would suffice if I could sort by it. For example, "update html code on the sidebar @nmt" and then I would be able to input my "@nmt" in the text field alongside the other criteria and it would work, or better yet, enable Perspective Projects :) cheers OF team

When are you guys going to add "sync flagged" to the sync prefs? Folks were asking for a year... This is where Things shines, making it easy to sync Today to a calendar, which then can be propagated to things like Anxiety. For those who use Flagged for select actions Today, "sync flagged" would accomplish the same.

[QUOTE=braver;80990]When are you guys going to add "sync flagged" to the sync prefs? Folks were asking for a year... This is where Things shines, making it easy to sync Today to a calendar, which then can be propagated to things like Anxiety. For those who use Flagged for select actions Today, "sync flagged" would accomplish the same.[/QUOTE]

Omni considers the number of requests submitted officially (i.e. through OF>Help>Send Feedback) in their features development...

[QUOTE=hypotyposis;81038]Omni considers the number of requests submitted officially (i.e. through OF>Help>Send Feedback) in their features development...[/QUOTE]

So I did submit mine and invited other folks to do the same. I suggested then, and now too, that folks who believe it's useful submit it also!

Clipping broken in latest sneaky peek releases
 

Since the last couple of sneaky peek releases, I can no longer clip from Safari or Mailplane, or anything else for that matter. Is this a bug or is there something I can do to reset clipping?

Clipping has been working fine for me, just verified it with the latest build. I don't have Mailplane, however.

What happens when you try to clip? Is the OmniFocus: Send to Inbox option listed in the services menu item when you've got something selected for clipping? Is your keyboard shortcut still set?

Thanks. It was in fact Services that was the issue. Somehow Services wasn't loading properly. Rebooted my machine and away we go again - including clipping.