Sync with cloud – Today ToDo

Please don’t read this post unless you are interested in the title. It will bore the socks off you!

With that out the way, here’s what I think about the subject.

First point. Resist ALL temptation to host own service. This will invariably lead to an enormous amount of dissatisfaction with the app itself as even the slightest outage will globally affect the perception of the entire application, potentially losing an enormous number of users, reputation, etc. User data is personal, business critical, and task lists are extremely important to the everyday running of users’ lives. Even if the service runs slow for 10 minutes in one year, it’s enough to put a large section of the user-base off investing their time in ever using the software again. Even if you have the infrastructure and personnel to provide high-reliability 24/7/365 coverage, with globally distributed failover servers, this will fail unless you are Google, Apple, or someone with a proven track record (Toodledo). It can never go well for you! At least if using a third party service, the blame can be transferred. Enough said.

Now for more observations:

1. People like me are serious about using cloud services, recommending them to business associates, colleagues, managers, and cloud sync can go very well. For the same reason, it can go very badly.
2. Even some of the high reliability services (Google, Apple, Amazon, Dropbox, etc.) do not have published statistics as to their *absolute* uptime limits. It’s simply not possible as it depends on too many variables (i.e. global politics). At least if you use one of these services, their reputation is large enough to cover any problem.
3. On the matter of politics (sorry this is really boring), the most democratic way to run cloud sync service is to provide the software to anyone, open source, so they can either run their own private / personal clouds, or so small companies can start up providing free or paid services. This is less relevant to the argument, but it’s worth stating as the utopian ideal. The problem is that the liability for code vulnerability is shifted then to the developer… big pitfalls there!

Onto the issues of interoperability, usability, usefulness, and profit.

1. We all know Google is King when it comes to providing reliability of service that is free, as well as reliable APIs. Problem is they have a history of changing their APIs (in the name of development) with little or no notice, meaning you may have to be quick-off-the-mark in providing updates. In reality this isn’t an issue, their service offerings have arguably settled down of late, with the exception of new offerings such as Wave.
2. ToodleDo and other GTD/task-specific cloud-based services are a great way to reach new customers because you get a listing on their site. It would doubtless impress the majority of existing Today ToDo customers as well. I would judge ToodleDo to be the most reputable service provider, but they have their own business agenda which will impact on your users’ data. For example, unless you have a paid account, archived tasks are removed after 6 months. Therefore your users are forced to pay them a subscription charge in order to keep a perpetual log of what they have done. Many won’t care, and you could provide another way to back this up, but this would force users to remember not to forget to back up their stuff. For me this is a deal breaker. I don’t want to pay a subscription charge for keeping a task list, and I don’t want to have to make sure I back-up every 6 months. This will never happen; I’d rather use pen and paper.
3. The options with Google as far as I know are to sync with their own task list implementation OR have a custom interface using e.g. Google docs or some kind of implementation whereby tasks are stored as emails / attachments. The task list implementation provides the best usability as it’s reasonably good and supports multiple lists. Access is also good, iGoogle, Chrome and Firefox extensions, and the like. The same is true of ToodleDo. (Though it’s not as good in this sense.)
4. Dropbox or similar file-based cloud service is designed for storage of files, not custom access to their data. It could be a good way to export list summaries for printing, but then so is email. Unless you committed to providing other interfaces for users to get to their tasks on their computers using Dropbox or Skydrive you would be forced to implement some kind of flat file XML/text storage of items, and deal with the ensuing concurrency issues etc. Not nice.

Of course other services should get a look-in, like MobileMe, but they don’t really provide free options as far as I know. I don’t like the idea. As I said, I would rather use pen and paper.

My ideal solution would be for you to develop a personal PHP or ASP web server with HTTPS connection options, because anyone could host their own on a shared host for the same price as ToodleDo, but in reality this probably isn’t an option. (Is it?)

In summary I would say a clever use of Google tasks would be the most suitable and satisfying for the most users.