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.

Creating a new design always involves a recombination or evolution of existing design patterns and styles. It happens ever so often that one is inspired by another site’s design and that certain aspects are carried over into the new design – albeit in a transformed and adapted way.

This is the reason why web design galleries exist and we are both proud and flattered that our current design has been featured in numerous galleries last summer, for example here, here, here, and here.

A different matter, however, are pixel by pixel rip-offs. The software developer Panic, for example, has gathered a whole collection of those.

Yesterday one of our users (thanks Vitor!) pointed us to a complete rip-off of our current web design. It turned out to be the most blatant one I had ever seen. See for yourself:

I not only had quite some fun dissecting what the plagiator did do or rather didn’t do, I also learned a lot in the process. I am happy to present to you today our new tutorial:

Learn how to become a kick-ass rip-off artist in 8 easy steps.

1. Be sure to use the same color scheme. This makes Cultured Code users feel right at home.
2. Pay attention even to the smallest of details, like the little silhoutte icons in the navigation bar, the smaller dollar sign... Only cowards cover their tracks.

   

3. Treat inconsistencies with respect. The original designer must have had a reason to use Helvetica in the navigation bar and Lucida Grande for everything else. (Which reminds me of something I forgot to update when I changed the whole website to Lucida Grande...)
4. Don’t even think about changing one pixel of an icon. You don’t want to mess up someone else’s work. Also, keeping the same filename makes maintenance a lot easier in case the original website updates their graphics.

   

5. Paying hommage to Panic’s Transmit truck is a must for every serious rip-off artist.

   

6. If the original website doesn’t have a contact form to copy, create your own. It’s not that hard. You can do it!

   

7. And for those who still don’t get it: Leave one link unchanged to prove beyond any doubt, that you must have completely copied the entire source code.

   

8. Claim a copyright.

   

What can we learn from all of this? The bold variant of Lucida Grande looks kind of nice in the sidebar. We should try that too.

We have just finished the user interface of our new iCal sync feature (or more precisely, support for Leopard’s system wide to-dos) and would like to share some screenshots.

The screenshots are taken from a private development version. But before moving to the screenshots let us give you an idea of what it is like to implement a new feature.

Here is a list of steps we usually take when tackling a major new feature. We ...

1. Evaluate all related feature requests.
2. Decide what will actually go into the new feature. This is a quite complicated step. We try to look at common usage scenarios. We also try to guess what the majority of users would need. Sometimes we postpone features because their implementation would take too long. An example is providing foldable pocket layouts for printing. We’d love to have it, but it didn’t feel right to make everyone wait longer than necessary before a fundamental feature like printing even shows up.
3. Try to find a unified point of view if the results of step 2 are too varying or divergent.
4. Try to think of ways how we could clearly communicate the ideas of 3.
5. Create Photoshop mock-ups of the user interface.
6. Start with the actual implementation of the interface and test it. If necessary, go back any number of steps and start all over again.
7. Create the engine or logic that makes the feature work.
8. Test-drive a functional implementation of the new feature for the first time. Go back any number of steps if necessary and start all over again.
9. Extensive bug testing and fixing.
10. Seed the new version and watch for related emails and forum posts. Fix bugs and make notes for future improvements.

With iCal sync we are now ready to move to step 7.

We had two requirements for iCal sync. On one hand, turning it on should be as simple as turning a switch. On the other hand, we wanted to take advantage of the existence of multiple calendars and make it flexible enough for usage with mobile devices and apps like Anxiety or Apple Mail. This requires that users are able to restrict syncing to different parts of Things like Focus lists, to-dos that have certain tags, Areas of Responsibility, or even projects. Obviously having both simplicity and flexibility seems contradictory. Here is how we are doing it.

When you select iCal in Things’ preferences for the first time you will see the simple variant of the dialog.

There you have it: the On/Off switch. Well, it is actually a menu and looks like this:

The most common requirement is to be able to export either all active to-dos (Next) or the currently pending items for today (Today), and to be able to import new to-dos created in other applications. When selecting either "Today" or "Next" from the sync menu this is exactly what you get.

If you need the full power of the underlying engine then choose “Custom” to transform the simple variant of the dialog into the advanced one:

The text fields offer auto completion and only accept valid input. It is possible to drag tags, projects, or areas to these fields.

We believe that the advanced variant of the dialog puts an amount of flexibility at your fingertips that compares rather favorably with the competition. However, there are still more feature requests related to iCal which didn’t make it into this version. But never worry, Things will continue to be improved at full speed well beyond the 1.0 release.

If you would like to comment, instead of sending us email, consider to use the comments section of this article or even better the forums. Your feedback will be much more valuable if your fellow users are able to read it too and respond to it.

The biggest new feature of Things 0.9.1 is native printing. Until now we only had Mac OS X’s built-in printing support. But since Things’ to-do lists are optimized for the screen rather than paper, the results were less than desirable.

When choosing Print from the File menu, Things 0.9.1 will construct a dedicated print document which is displayed in an extra window. Before continuing with Mac OS X’s standard print dialog users get a chance to customize the document in the following ways:

• Decide whether to print the entire list or just selected items.
• Change the font size. Note that since the print document on the left does not (yet) represent the actual width of the paper, the text may appear to be larger than the actual result on paper.
• Decide about the visibility of notes. If your list contains long notes that you do not want to print entirely, you can also choose to limit them to 8 lines of text.

Clicking the Print button will then invoke Mac OS X’s standard print dialog. Particularly interesting is the Layout pane. Using the Layout pane you can arrange multiple pages on one sheet of paper.

As an improvement we plan to combine our dialog with some options from the standard print dialog to create what Apple calls the Simplified Print Dialog. The idea is to have one single simple and uncluttered dialog that suffices in most situations.

Things 0.9.1 also contains the following fixes and improvements (from the Release Notes):

• Repeating items. Fixed a bug that resulted in “after completion” option not working properly.
• Repeating items. Resuming a previously paused item no longer crashes Things.
• Quitting Things before closing an edited item no longer results in loosing the most recent changes.
• The Things library is writen to disk more often now (after each edit).