As the title suggests Things 0.9.2 not only brings iCal sync but more generally support for Leopards system-wide to-dos. What is the difference?

With Mac OS X 10.5, the database that stores the user's calendar data was integrated into the system. Developers got a whole new API that is simple and fun to work with. More importantly though, changes that are made through this new API propagate practically instantly through the system. To-dos will show up in iCal, Mail or any other participating application the very moment you press the enter key in Things.

On previous systems, syncing to-dos between applications was a complicated process that sometimes even had to be triggered manually. Since we wanted to provide the best experience for our users, and most of them are on Leopard anyway, it was clear that we wanted to use Leopards to-do service instead of the older slow sync. Unfortunately the new and older APIs cannot be used at the same time. Providing backwards compatibility with Tiger is a whole new development effort, which we might attempt later along with .Mac sync.

Getting Started

You turn on iCal sync from Things' preferences:

In addition to what you might recall from our previous post, we have now included an Options button. It opens a sheet (see below) where you can customize whether tasks show their associated project and tags in other applications.

These options are turned on by default. You can also add tags and projects from iCal or other applications. For example, adding "@Home" to the title of a to-do in iCal instructs Things to add the tag "Home" to it. There is no need to worry that this feature is triggered by accident, since only existing tags are used. You can safely enter email addresses for example. These won't be recognized as tags and don't trigger the creation of new tags in Things. The same goes for projects. Only existing projects are recognized and no action is taken if multiple projects with the same title exist in Things. Things is also smart enough to ignore projects that are already logged or in the trash.

We have carefully taken precautions to prevent you from shooting yourself in the foot :). It is not possible to delete to-dos from Things by deleting them in other applications. Since we have no control over applications that integrate with system-wide to-dos, we cannot prevent situations where a large number of to-dos might be accidentally deleted by badly written third party apps.

It is also not possible to delete tags, or projects from other applications. It is just too easy to accidentally type over a title deleting all meta data that might be there. And to-dos removed from their project or missing their tags might be very difficult to find. The iCal sync feature has been designed with the assumption that Things is the primary to-do manager and that other applications, like Mail or iCal, are mostly used to conveniently retrieve stuff or enter new items.

Complete Control

If you want complete control over the syncing process, choose "Custom" from the Sync menu. The dialog transforms into advanced mode allowing you to associate different lists (foci), tags, projects, and areas of responsibility with each calendar.

You do not need to worry whether the list of to-dos you sync with each calendar overlap. If they do, Things will simply sync with the first calendar in the list that matches. Of course, you can reorder the list of calendars in Things.

The criteria you associate with each calendar work both ways when it makes sense. For example, if you specify the "Errand" tag for a certain calendar, then only items having the "Errand" tag are synced with this calendar. If on the other hand you enter a new item in iCal, this item will automatically get the "Errand" tag in Things. The latter, however, only works with a single tag. If you specified multiple tags, there is no way to find out which one you would like to be added in Things. The same is true for projects and areas of responsibility.

Usage Scenarios

Here are some usage scenarios that might not be completely obvious:

• When you create a to-do in Mail using a selection of an email message, the URL for this message is added to the notes section of the corresponding item in Things. Clicking on it will open the associated email message in Mail. Please note that due to a bug in Apple Mail, it will only honor the deletion of to-dos when running. Superfluous to-dos need to be manually removed from Mail.
• You can also use iCal subscriptions. Let's assume you subscribed to the calendar of your significant other. Just activate this calendar in Things for the Next list for example. (You also need to make sure, that syncing to-dos is activated for the subscribed calendar both in your as well as your spouses calendar.) Your spouse can now send you to-dos, by simply adding them to the corresponding calendar. Note however that subscriptions are read only. There is no way for you to change such a to-do in iCal. Not even by checking it off. No matter what you do in Things that would normally cause the item to change calendars, or be entirely removed from iCal, will have no effect.
• You can use applications like Anxiety to create a HUD style Today list that is always visible.

Chris did a great job in testing the new iCal sync feature. But with a feature like this, that can be used in so many different ways, it is quite likely that it is not yet void of bugs. Hope for the best, but expect the worst :).

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.