Forget about web-based syncing and looking that up on a PDA browser (this is slow, usually costly, and BTW, syncing to which web service ? This is not standardized at all).
Come on, it’s kinda silly not to leverage your PDA’s built-in task list/calendaring/alerting functionality, the whole iCal protocol and the ready-made syncing infrastructure OS X provides.

BTW, iSync allows you to choose which iCal calendars to sync to a given PDA, which fits like a glove with the concept of contexts.

So I guess my ideal GTD software would do the following :

- Be as much open/standards compliant/iCal-iSync friendly as possible.
- Map contexts to iCal calendars.
- Sync n next actions per project to those calendars (n is a user setting, from 1 to “all”)
- Give next action higher priority than other tasks. Most PDAs/phones understand priorities and give a way to sort tasks by priority. This makes things more manageable on a single calendar phone/PDA.
- Flawless 2-way syncing with iCal: I find it crucial to be able to quickly write down a thought on the PDA/phone while on the road, or be able to collect in iCal if I prefer, and the app should just happily import it to the Inbox.

The last point may seem obvious, but I’m about to drop kGTD for that reason alone : it is stubborn on deleting whatever tasks I enter in iCal/phone instead of importing them. :(

I’d vote for the ’syncing contexts to ical calendars’ approach.

Alternatively, I’d be happy if there was just one actiontastic calendar, and preferences to choose which contexts were synced to it.

I use heavily as a calendar - both at home and at work - and I sync both ways (via icalx.com) and with my Nokia N70 phone.

What I’d like to do with the GTD stuff from actiontastic is just to export an ‘out’ context - I don’t want my full action list with me - just the ones that are actionable when I’m out and about.

My solution was to create an iCal group called @To Do and then create a calendar for each context. This way, I can turn off as many context calendars as I want, and see only those contexts I want to work within.

This works very well right now using Missing Sync and iCal with the Palm, so such a setup might be the simplest for those of us who want to sync. Actiontastic could create a calendar for each context/sync with a context calendar…and ignore project categories, because iCal and projects don’t mix very well.

One other suggestion includes making a lite/less expensive or free version of Actiontastic that doesn’t sync for people who like pretty much what you have cooked up right now, and bake something with sync and some other more complicated goodies for the full version. Think about it!

My preference would be separate calendars in iCal for each context. In my case I’m already using that to some degree, since the colour coding is useful, and the contexts generally are in line with my appointments as well (ie, I use different calendars for calls, working at my desk, visiting clients, travelling, etc so that I can take advantage of the colour codes to view where I”m going to be “at-a-glance”).

I presently use kGTD and already file my various contexts against the various calendars. However, kGTD also allows for some mapping functionality, so there are places where two contexts go into a single iCal calendar. While this may not be *pure* GTD, there are many times when I’m on the go that certain contexts are naturally combined (errands and client visits, for instance).

So, to sum it all up, my vote for the ideal solution would be one of two options:

1. Sync all Actiontastic tasks to calendars that match contexts. Ideally, setting up Context-to-Calendar matching preferences would be great, but I could live with naming my contexts to match my iCal calendars as well.

2. Less preferable, but if we’re only going to sync to ONE calendar, then there should be a choice of WHICH contexts get synced. There are contexts that are completely irrelevant to my PDA, so I could live with those not being in iCal (for example, the context for @Desk doesn’t need to be on my PDA, since I have my computer at my desk anyway). At least in this case, the PDA actually *becomes* a context in a sense.

As for the syncing of next-action items only versus ALL items, I would imagine a configurable option wouldn’t be too difficult to implement for this once the basic syncing was put in place anyway. However, if we had to choose one or the other, I’d prefer syncing of ALL items, perhaps with “Next Actions” getting today’s date, and future actions getting some future datestamp, which would allow for some inherent filtering/sorting on most portable devices.

Ultimately, the biggest problem for me with a web-based solution is that having to access a web page from a PDA defeats the purpose of having a task list. I can go to my tasks app, review it, and check off a couple of things on my Blackberry in about 30 seconds or less, while I’m running between appointments. Accessing a web-page will take an additional 30-60 seconds just to get the browser up, get to the page, get logged in, and then wait for refresh times. Further, there are still too many places where web access isn’t available (for example, I’m usually doing most of my GTD review in the subway while I’m travelling between appointments).

Thanks for thinking out loud here with me on the blog. It is great to hear about how you personally see this working/not working and the emails on top of these comments are excellent.

Regarding beta-testers for the web-service, I’ll keep in touch via our beta email list if the beta starts out as private. Otherwise, it will be announced here on the blog.

If web-based todo list access were designed very carefully for PDA screens (the resolution of my 3G Treo 750 is 240×240), and it proved to be reliable, I think it would be a very effective way of keeping up to date and I would thoroughly support it over iCal syncing. Perhaps you should stick with your instincts and release iCal syncing once people have tried the web-based version and given you further feedback?

Unfortunately, 3G data costs in the UK are still pretty ridiculous, so many of your users may well end up paying a “GTD tax,” depending on how fiendishly addicted they get to the service. It might also not prove very effective to 2G or 2.5G users; GPRS-based web access is not known for its stability or speed.

I’d much rather have one really good and reliable way of accessing my GTD info on the move (web-based) rather than two options that were hurried out slightly rough-around-the-edges due to pressure from users who haven’t even tried the web-based option.

If you need any beta-testers for the web-service, do shout up.