Things 0.9.3 brings dock badges, more compact Next and Today lists, 8 bug fixes, and a new "Cancelled" status for To Do items. While the latter is obviously
a new feature, the deeper reason behind it, was to remedy a limitation in previous versions.
Previously, when a project that still contained incomplete items was checked off and eventually got moved to the Logbook, the incomplete items still remained
in the Next or Today lists. While this is not entirely wrong, it is probably not what the user wanted. Either the user forgot to check off those items, in
which case there should be a warning, or there was a deliberate decision to leave those items incomplete.
Of course, obsolete to-dos can always be deleted. But sometimes it is interesting to keep a record of tasks that were once considered interesting (by a client
or co-worker for example), but got axed nonetheless. It is now possible to state that a task got cancelled by using the corresponding new menu command from
the "Items" menu.
Also, if a user attempts to check off a project that contains incomplete items, there is warning dialog that lets the user choose whether the remaining items
should be marked as completed or as cancelled.
We also introduced an option to show a dock badge. In Preferences you will find a new menu which allows you to select which count will be attached to Things'
dock icon.
Please consult the Release Notes for a full list of bug fixes.
We have all seen how the iPhone enabled applications that weren't possible before on any mobile device. Wouldn't it be cool if you could carry all your to-dos
in your pocket? Wouldn't it be cool if you had a powerful responsive task manager wherever you go?
A resounding "Yes" was the answer we gave to ourselves some time ago when we began developing what will become Things touch. Honestly, will
any mobile device that you carry around ever be complete without a personal task manager? We didn't think so either :)
The iPhone and iPod touch are a huge opportunity for developers and an equally huge challenge too.
The opportunity
iPhone and iPod touch constitute a whole new platform with a new distribution model as well - the iTunes app store. These devices are used by many people that
have never owned a Mac before and some of them may never will. For a developer there is the potential of reaching a whole new group of customers. Customers
that may not know Things already, or are not able to use it because they are on Windows, or may not even bother to use the desktop version at all because
Things touch is already more than they bargained for.
Challenges abound
The iPhone user interface is completely different from what we have become accustomed to from the desktop. Naturally, we had to recreate the code for the
Things touch user interface from scratch. No way to reuse a single line from the desktop version.
Due to the unique limitations of the iPhone OS we couldn't even port the data model code. Yes you assume correctly, a complete rewrite was necessary too.
Fraser Speirs has an insightful article on how the market's ability to establish
a fair price for iPhone applications will eventually determine whether there is a sustainable business model for creating them. I bet that we are not the
only developer having a hard time determining a price point for our iPhone application. A price point that will enable us to aggressively evolve and support
Things touch for a long time to come.
While developing Things touch does draw significant amounts of resources from the desktop version, it is in fact rather beneficial for it too. Recreating Things
for the iPhone made simplicity even more predominant. We learned a couple of things from the process that will help us to make the desktop version even better.
The same goes for the data model code. Having had the opportunity to incorporate all the lessons we've learned from the desktop version resulted in a fresh
new code base that will find its way back into Things, providing an even better foundation for its future development.
In the weeks to come, we plan to write more about how Things touch will look like. But if you'd like to get a glimpse of where we are headed, you may want
to peek at Chris' desk :)
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.
