[dancingbrook]

Originally Posted by Toadling

You can. Just move an item to the top of the list, it turns purple, designating it as the next action.

I want to move many things to the next actions list, because when I leave in the morning (without the computer) I hope to accomplish more than just one item from any given project, even if they are sequential. Even if I am in front of the computer, I might logically want to see the next 2, 3 or 4 items in a list as they may all be linked and thus I would try to do all of them if I had time, without having to check one off to se the next.

How are action groups anymore "artificial" than folders or any other logical collection of information?

What's artificial is the idea that they have to be either sequential or parallel. Almost no group of actions I do are just one or the other.

Besides, they give the added benefit of being able to fold them out of sight to save space, add extra notes, batch-toggle flagging and completion states, etc.

What? I don't need an "action" folder to do that. I could simply have a folder called next actions, or any other set of folders for that matter (like is already there), The point being why either sequential or parallel?

I suppose each individual action could have its own parallel/sequential attribute. Ones set to parallel could then just be ignored for determining order and would always be available as a next action, regardless of what order they actually appear in the list. But that seems like it would be visually confusing.

Or you could simply just let the next actions be the ones you choose to be next. If they are parallel, they all already appear in the next action list (assuming that action group is the next action). I my scenario, I select what's going to appear in my next action lists, including groups if I want.

And without nested groupings of some kind, you'd lose the ability to build more complex sequences. For example, you couldn't require that some parallel actions be completed before making some other parallel actions available (a sequential list of parallel groupings). In fact, it seems like your example shelving project would be impossible to build with what you're proposing.

I have no idea why you reach that conclusion.

The more I think about it, the more it seems actions groups are a better approach. I really think Omni Group did their homework here and has thoroughly thought this out.

Good for you

I would agree that "app cooperation" is the way of the future, but not necessarily "app convergence". The idea of one monolithic application that does everything goes against the very nature of Unix and distributed systems. It's much better to have many, specialized apps that are really good at one thing (or maybe a couple things) and that play together nicely.

I said convergent. You said monolithic. I didn't because I meant what I said.
Information from apps is what converges.

Apple's iLife and iWork suites are an excellent example of this. The Omni applications are also already headed in that direction. We can see it with LinkBank support in OmniOutliner, for example (hopefully, it'll eventually come to OmniFocus as well). And there's been lots of talk about tighter integration between OmniFocus and OmniPlan in the future.

Exactly (re iLife and iWork). LinkBack just provides an active link; the data created in app A doesn't change the data created in app B. Changing the data in app A gets reflected in app B. That's not the same thing as data syncing as seen in iCal and OF. Thus OF is more advanced than OO. What would you use LinkBack for in OF? I'm not sure what you refer to as lots of talk. I've seen nothing, yet it should have been planned from the start. Active data syncing is what I mean, so I can change the data in app A or B and it gets reflected back to the other app, just as it would in a monolithic app, which I am not asking for (though easy transitions between apps is fine with me, which is all a good monolithic app should be).