[squeff]

Originally Posted by gdpmumin

No, that actually is a bad thing. Compared to the way Alex and his team at WebIS respond to feature requests, Rex Wireless has much learning to do. But ToDoMatrix is an excellent, if expensive, app.

My point is that, when it's not possible to do everything, you need to be honest about what can be accomplished. Rex only agrees to do the most popular requests.

Any company that adds features because one or two people ask for it is asking for trouble. You end up with bloated software, poor quality, and needing a larger development staff/longer development cycle. In the end, if you need to hire 100 developers just to handle everyone wants, the company will go out of business.

I do agree that Rex is TOO pessimistic and that they do less in each release than some other companies.

[Drfreeman82]

Originally Posted by squeff

No. PocketDay doesn't do anything with tasks that the native app can't do (other than display them differently).

One reason why, despite the fact that I love PD, I added TDM. I have several recurring tasks and TDM handles them well. Note: It does recurring tasks that regenerate based on the original due date, but not on the actual completion date. This is fine for most things, but I've yet to see something on the BB that handles "redo" tasks. I do recall that Agengus on the Palm did support this (I think... or it may have been their competitor DateBk).

Hey squeff, can you elaborate a little bit more on the "redo" tasks vs. tasks based off the original due date.

[squeff]

Originally Posted by Drfreeman82

Hey squeff, can you elaborate a little bit more on the "redo" tasks vs. tasks based off the original due date.

This is easiest understood, I think, with some examples.

(1) Every Friday, I have to turn in a status report for the week. So, I create a repeating task called "Turn in status report" and have it set for every Friday. If I don't turn it in on a particular Friday (say I'm out sick), then the next one is still due the following Friday.

(2) Every 3 months, I'm supposed to change the oil in my car. However, if I wait 4 months to change the oil, the next change isn't due in 2 months. It's due 3 months from when I actually changed the oil. For example, suppose that the first time I change my oil is January 1. Completing this task will create another for 3 months in the future: April 1. Now, suppose I don't get the oil changed on April 1. In fact, I wait until June 30 to get the change. Using the approach described in #1, the "next" oil change after April 1 would be July 1. However, since I just got the oil changed on June 30, I'm not going to want to get it changed until September 30, at earliest.

The first one is well supported by TodoMatrix. When I complete a task, it creates the next on in the series as being one week from the original due date.

The second one is not supported.

There are actually several nuances here. For example, in #1, it's important to understand that the tasks are NOT generated from the get-go. One one task exists at a time. It requires the completion of a task for another to be generated. So, for example, if I totally miss wrtiing a status report one week, the next week's status report won't appear on my todo list until I go in say that I completed the one that I never really did. If I wait more than a week to do this, things get confusing, since the "next" one due is actually one in the past.

Bottom line is that most task programs that some recursion work this way. It works well for tasks that are regular and where you're expected to complete each occurrence on time.

Does this make sense?

[Drfreeman82]

Originally Posted by squeff

This is easiest understood, I think, with some examples.

(1) Every Friday, I have to turn in a status report for the week. So, I create a repeating task called "Turn in status report" and have it set for every Friday. If I don't turn it in on a particular Friday (say I'm out sick), then the next one is still due the following Friday.

(2) Every 3 months, I'm supposed to change the oil in my car. However, if I wait 4 months to change the oil, the next change isn't due in 2 months. It's due 3 months from when I actually changed the oil. For example, suppose that the first time I change my oil is January 1. Completing this task will create another for 3 months in the future: April 1. Now, suppose I don't get the oil changed on April 1. In fact, I wait until June 30 to get the change. Using the approach described in #1, the "next" oil change after April 1 would be July 1. However, since I just got the oil changed on June 30, I'm not going to want to get it changed until September 30, at earliest.

The first one is well supported by TodoMatrix. When I complete a task, it creates the next on in the series as being one week from the original due date.

The second one is not supported.

There are actually several nuances here. For example, in #1, it's important to understand that the tasks are NOT generated from the get-go. One one task exists at a time. It requires the completion of a task for another to be generated. So, for example, if I totally miss wrtiing a status report one week, the next week's status report won't appear on my todo list until I go in say that I completed the one that I never really did. If I wait more than a week to do this, things get confusing, since the "next" one due is actually one in the past.

Bottom line is that most task programs that some recursion work this way. It works well for tasks that are regular and where you're expected to complete each occurrence on time.

Does this make sense?

Awesome explanation, It seems that todomatrix will work well for things such as bill due dates, because those will not change. I put my oil change into todomatrix also but I automatically assumed that the software would be able to figure it out. I guess sometimes, people dont pay attention to the small things within a program. My best bet will be to try and get the oil changed on that exact day that it is do, lol. Can you answer the question of "Will PI have a solution for this? " Anyways, thanks for all of your info man, you have really been helpful.

[squeff]

Originally Posted by Drfreeman82

Awesome explanation, It seems that todomatrix will work well for things such as bill due dates, because those will not change. I put my oil change into todomatrix also but I automatically assumed that the software would be able to figure it out. I guess sometimes, people dont pay attention to the small things within a program. My best bet will be to try and get the oil changed on that exact day that it is do, lol. Can you answer the question of "Will PI have a solution for this? " Anyways, thanks for all of your info man, you have really been helpful.

While I cannot be sure, my opinion is that PI will not support "redo" style repeating tasks in the initial release.

I have no idea if Agendus will or not (the Palm version did, I seem to recall), but I doubt it. Not for the first release.

I say this about these two products, not because I have (or can share) any inside information. But because even fairly advanced programs, like TDM, don't do it. And TDM only does tasks. Agendus and PI do a bazillion other things, so one function of one feature is not going to be the priority for a 1.0 release.

[libellula]

Thank you!!!!!!!! You have saved me. I was sitting here in tears thinking I had to give up the Blackberry and go back to my old Windows Mobile device because I could not find ANY good calendar software out there. I had been spoiled by "Agenda One" for WinMo, and to switch to the standard BB calendar was awful. This conversation led me to PI and Agendus now, so now I might make it!!! Ok, emotional/nervous breakdown averted- for today. ;) Thanks!