Users who opened Things after last Friday were in for a surprise. Instead of seeing their tasks, they were greeted with this expiration notice:
If you were unlucky enough to open Things too early on Friday (depending on your time zone of course) downloading the new version from our web site didn’t even help. It stubbornly kept displaying this dialog. What were we thinking??? It is with shame that we must admit: there was not much thinking involved...
Here’s the scoop: all of this happened completely unintentional. The dialog was displayed by mistake, due to a wrong date that has been left unaltered in the application code. Later on Friday, we fixed this and downloading the new version resolved the issue.
Why do we have an expiration date in the first place? Some time ago when we began to release public development versions of Things, we figured that we didn’t want those development versions still be in use after stable release versions would have become available. And we did what every developer does with public development versions: we put an expiration date into the application. We used a very distant future date to make sure the release version would be available long enough to allow users to switch to the release version. Or so we thought... The reason why Things will be released later than we initially thought deserves a blog post on its own – iPhone anyone?
The dialog above is kind of OK. It tells you what happened and what you can do about it. It even offers to take you straight to our web site. But to tell the truth, we didn’t expect many people to see this dialog at all, which might explain why we didn’t take as much time and effort as we did for other dialogs. If we did, we would have made sure that a manual download wasn’t necessary. After all, we do have an automatic update mechanism, don’t we? Another shortcoming is the fact that it is not clearly stated that the user’s data is not affected at all. It wasn’t made clear that applying the update wouldn’t change the user’s data in any way, let alone delete it! This has certainly led to confusion among some of our users. Which brings us to an important topic.
Even though the whole thing was a mistake, there were quite a few users that were locked out of their data for several hours. From our point of view, this is one of the worst things that can happen. While Oliver Starr from GTD Times wrote a rather harsh article (and another one), speculating whether we are "insensitive" to our users need to have a “trusted system”, the exact opposite is true. We thought about this very aspect a great deal during the design phase of Things: How will users be able to access their data? What if they wanted to stop working with Things? How will they be able to export their data? And so forth.
All of this really boils down to one question: Who owns the data? There is only one correct answer to this question and it is obvious: only the user owns the data. Taken seriously, this answer implied that we as developers had to choose an approach as open as possible to store the user’s data. And indeed, this was a key priority for us from the beginning. We stated it on Things’ primary landing page even before this blog, the wiki, and the forums came into being.
To state this again very clearly, the release version of Things will save its data in an open, easy to understand and well documented, plain-text XML format. We chose XML because it is the most widely accepted file format for exchanging data between all sorts of software components. But at the same time, using modern style-sheet technology, ordinary users without any programming skills will be able to view these files nicely formatted in any web browser. It will be super easy for third parties to interoperate with the Things library by simply reading or writing small snippets of plain text files from and to the hard disk. Contrary to other solutions, like Apple Script for example, Things doesn’t even need to be running for this to work.
The development version currently available does not make use of the final file format yet. It does use a plain-text XML format, but a generic one (derived from Apple’s CoreData technology) which is easy to adapt for new Things features, but very difficult to use for third parties. The only reason it exists, is because it serves us well during the phase where Things’ data model is not yet fully complete. Of course, we have been working on our own easy to use file format all along and will roll it into future development versions as soon it makes sense.