[jdh]

Wow, just noticed that myself. I'm sort of wondering what the logic for that was, since context lists don't otherwise provide any meaningful view of project information -- it's not like there are project headings and groupings to go by.

I would normally expect that when working in context view the most urgent actions should normally filter to the top -- that would be flagged actions and those with due dates, and I would especially expect this when the view is set to "Next Actions," since the most important next actions are those with dates attached to them.

Perhaps I'm missing something obvious that isn't part of my own workflow, but I'm not even understanding in what ways the new sort order would even be useful. My project sorting and organization in OF is somewhat arbitrary and certainly not based on any kind of priority model.

[jbrown]

Sorry for the confusion here. Normally, perspectives on the iPhone app are only available if you're syncing with the Mac version. However, you can turn on perspectives by tapping the link on this page:

http://people.omnigroup.com/kc/debug...spectives.html

You should now see a Perspectives row in the sidebar. The Due perspective gives you a list of your actions sorted by their due date. Hope this helps!

[SFF]

I agree--this change threw me for a loop. I totally understand why someone would want their actions within a context sorted by project--in fact, I had already created a perspective to do just that. However, that's why I was a little annoyed at the change. The new default context view essentially duplicates a perspective that I already created, and "overwrote" what I was using Context view for--which was to view all my tasks within a context automatically sorted by due date.

Assuming you have OmniFocus for Mac, the solution is simple--just create a new perspective in Context view and sort your actions by "Due". Save the new perspective and sync, then sync the iPhone and you should be good to go.

[jdh]

I'm not sure a new perspective really solves it appropriately, however... Unlike on the Mac, perspectives on the iPhone are single-level lists with no hierarchy to use for "drill-down" filtering. So to make this work with the same way with perspectives I would need to create an individual perspective for each context that I want to have sorted differently (which for me would amount to at least a dozen new perspectives).

I guess everyone's workflow is different, but I'm personally still not seeing what advantage there is to sorting by project in the context view. Context view is for doing things, and I would think that those tasks that have a higher priority due to due dates or flags should naturally be prioritized at the top so that one doesn't risk missing them.

With this change, it feels like the context view has just become another "planning" view.

[Ken Case]

Thanks for the feedback! I've filed this as bug #76573 (Consider restoring flagged & due sort ordering in context lists, or providing a sorting option) and added all your comments as votes there.

If anyone else would like to vote for this, please email our support ninjas at omnifocus@omnigroup.com and reference the bug number. Thanks!

[SFF]

Originally Posted by jdh

Context view is for doing things, and I would think that those tasks that have a higher priority due to due dates or flags should naturally be prioritized at the top so that one doesn't risk missing them.

With this change, it feels like the context view has just become another "planning" view.

I totally agree with this statement. It seems counter to canonical GTD to have the list of actions within a context sorted in any fashion but due/flagged at the top.

I'm sure Omni had a good reason for changing the sort order--I'd love to hear what it was!

[Ken Case]

Originally Posted by SFF

I'm sure Omni had a good reason for changing the sort order--I'd love to hear what it was!

Sorry, we didn't think it would be a controversial change. We noticed that the iPhone had a completely different context list ordering from the iPad, and we thought we should make them consistent. (Nobody had complained about either order as far as I know, so we thought nobody had a strong preference between the two.)

Once we decided to make them consistent, we were left deciding which behavior to keep. We decided to keep the iPad behavior of sorting items by project when in context lists because we already had the Forecast and Flagged lists for when those are your interest. ("If we leave them in the order they appear in your library, then they feel more stable with the way you created them. I think this is especially important when you have multiple actions from the same project; their order may be important and unless you request it, we should not be reordering them on you.") I think we figured that the iPhone ordering was a holdover from the pre-Forecast era.

We did note internally that it would be fairly easy to provide an option for the old behavior (a hidden option if nothing else), and wondered whether anyone would want that. I think we'd gotten used to thinking that if someone did care, we'd get feedback on that sort of change during our beta cycle—not remembering how much more limited our beta pool is for our iOS apps (since we can't just make them publicly available for download on our website like we can with our Mac apps).

So, my apologies! We should have realized how that change would affect some of your workflows, and even if we decided to go ahead with it we should at least have explained why we were making the change. Ideally we would have also given you some advance warning and opportunity to send us your feedback—before it shipped, rather than after.

[jdh]

Originally Posted by Ken Case

Sorry, we didn't think it would be a controversial change. We noticed that the iPhone had a completely different context list ordering from the iPad, and we thought we should make them consistent. (Nobody had complained about either order as far as I know, so we thought nobody had a strong preference between the two.)

Fair enough... At least I understand the logic behind it, even if I don't necessarily agree with it (I was just afraid that I'd missed some tenet of GTD workflow somewhere along the way :) ).

In all honesty, I've never really used the context view much on the iPad, probably because it's always been more of a planning tool for me than a doing tool -- if I'm on the go, my iPhone is the go-to device for accessing my contexts, and if I'm at my desk, I'm using the Mac version. As a result, I don't think I even realized that this was the way the iPad sorted contexts until you pointed it out. :)

Now that I see it there, I'm not sure I like it that way on the iPad either, but I also don't necessarily care as I don't really use it. However, it's also worth noting that the iPad does have one small advantage over the iPhone version in the ability to use perspectives with collapsible contexts. It's still not as useful as the ability to drill down through multiple levels from the built-in Context view, but at least it's a bit easier to focus on a specific context within a perspective than it would be on the iPhone.

We decided to keep the iPad behavior of sorting items by project when in context lists because we already had the Forecast and Flagged lists for when those are your interest.

The problem is that both the forecast and flagged lists are general views of everything, which may include tasks due in contexts that are otherwise unavailable. If I'm in a situation where I'm only able to focus on a single context, the additional "noise" of things I can't do right now gets in the way.

Don't get me wrong -- the Forecast is a fantastic feature, and I use it several times a day as an overview, but it doesn't help me focus the way that the context views do. Perhaps part of the issue is the lack of a "focus" feature on the iPhone and iPad versions, but at the same time I feel that trying to manage that would add an additional layer of complexity due to the different user interface.

I think this is especially important when you have multiple actions from the same project; their order may be important and unless you request it, we should not be reordering them on you.

I do see some validity to that point, and I had sort of assumed this was part of the logic. However, in many cases dependent items are going to be hidden anyway in sequential projects and I'd argue that a due or flagged item, even if it's further down in a parallel project should still be sorted with a higher priority. Perhaps that may leave some users scratching their heads to the sequencing, but I don't think it's too difficult to understand that a due or flagged task gets a higher priority, even if it's further down in the project.

The biggest risk, I suppose, is that dated tasks still sort to the top regardless of whether they're "due" or not, so a task in a project that has a due date of several weeks away still seems to be moved higher up the list than the three or four tasks before it that may be undated. I can see how this would be a problem, to be fair, although I still personally prefer the old behaviour even in this case as such a task should be hidden until the dependent tasks have been completed anyway.

It's also worth noting that I use a number of single-item lists, in which case the sort order is completely irrelevant compared to the flagged and due status -- new items get dropped at the bottom of the list and I rarely bother sorting them otherwise as (until now) it's never mattered :)

Anyway, I suppose a configuration option is always the best way to go about it, and it would probably make sense to simply drop it on the existing view options menu that is available in each context. This would also have the advantage of allowing it to be easily toggled on-the-fly for those who may want to view their contexts in a project-oriented order.

[Ken Case]

Originally Posted by jdh

Anyway, I suppose a configuration option is always the best way to go about it, …

Well, only if there's no consensus: every visible configuration option we add has an associated cost in perceived complexity. (OmniFocus can already be pretty intimidating—something we're trying to address.)

But if everyone agrees that the earlier behavior of sorting by Flagged & Due is better, we'll just do it that way. (Perhaps we'll extend the behavior to the iPad app as well to improve consistency—unless it would be inappropriate there due to different usage scenarios.)

[jdh]

Fair enough and that's certainly valid.... No need for additional options that nobody really needs :)

My vote is simply to revert back to the old way of doing things on the iPhone app and make the iPad app match as well. As I said, I don't really use the iPad app in that mode, but I can't see how the current project-based sort order for contexts on the iPad would be all that practical.