We seem to have a Catch 22 type situation.
In order for some significant functionality upgrade from OmniFocus 1 to OmniFocus 2, the database structure behind OmniFocus has to change.
If the backend database changes, OmniFocus 1 will no longer work.
Therefore, in order for OmniGroup to change the backend database, most users must migrate from OmniFocus 1 to OmniFocus 2.
However, many user don’t want to upgrade from OmniFocus 1 to OmniFocus 2 until there are significant upgrades in function, which won’t happen until user migrate from version 1 to version 2…
An endless loop.
With that said, has anyone heard any rough estimate about when such a backend structure change might take place? 2015? 2016?
For some odd reason, your post has made me smile slyly to myself.
AFAICT, any loss of functionality for OF 1 -> OF 2 is not due to a weakness in the existing database structure. It is instead because OG did nearly a ground-up rebuild of the code. Features that were left out can still be built back even now.
Perhaps you mean “In order for NEW functionality to be incorporated in OmniFocus, …”. This statement I can agree whole-heartedly with.
Oh. You presume that OG will not be pre-emptive and/or unilateral. Just as they were not when they updated from OF 2.0/(Mavericks or Yosemite) to OF 2.1/Yosemite? Hmmmm … ???
I’d be willing to bet that results show more users are on OF 2 than are on OF 1. IOW, I would be willing to bet that this is not a major factor in OG’s decision-making processes.
Yep. But …
Not really. Speaking from strong experience as one who empathizes fully with the “still on OF1” crowd, the features that OF 1 users want in OF 2 are those that have yet to be built back in to it when the code base was rebuilt. Their needs have nothing to do with a need to change the database structure.
I have not heard. Personally, I would wish that OG had preemptively just went ahead and changed their database structure back when they were all hot and bothered with flashy news about an OF 2 release some years ago (with videos and Webinars and so on). By now, we might be fighting realistically about getting multiple contexts or tags in OF rather than wearily running in circles about left/right checkboxes and colors bleeding over distractingly in to the left-most pane.
But then, I wish OG would do a lot of things differently with OF that seem to have no consequence in what really happens down the road.
I don’t buy the premise of this thread.
The look and feel of the app keeps me on OF1. In a dozen ways I can see what I need to get done more clearly in OF1. Providing user definable colors and fonts wouldn’t affect the backend database. The OmniGroup hasn’t indicated that there’s a structural reason this can’t be put into the code base.
However, somewhere along the way the development focus seems to have moved from getting things done to getting the app to look like Yosemite.
Fix the customizability of the app, and people (like me) who’ve purchased OF2 will start using it.
I completely agree with your views on the look and feel of the OF2. OF1 was more flexible in this regard, to be sure. I really loved the style of the version 1 of the OF for iPad, but then the Omnigroup drank the iOS 7 Kool Aid that said everything had to be stark, boring and white, white, white, and the Mac version then followed suit.
I agree, also, with your view that the fuctionality in OF1 could have/can be put into OF2 without a change in structure, yet that wouldn’t constitute new functionality.
Frankly, I just want to be able to set “Due Soon” to mean “Due Today” (and not in tomorrow) and I’m told by Omnigroup developers that that would require a change in the backend structure (source: a response on Twitter from Ken Case).
I think this would be a new feature over either OF1 or OF2.