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).

The new release contains 12 bug fixes and improvements related to features we introduced in version 0.9.

A notable feature of Things 0.9, that didn’t get enough attention last time, is the new bug reporting dialog. Things 0.9 is very eager when it comes to reporting errors. In fact, a little too much so. Every little error message was promoted to a crash. This is great for developers because we get a lot of error reports and have the chance to improve the reliability of Things quickly. On the other hand, some users who never saw Things crash now did so for the first time.

We remedied the situation in the following way. Things will still offer to send an error report even when uncritical errors are encountered. But the error report dialog no longer forces the user to quit the application.

We want to apologize for the inconvenience and thank everyone who sent error reports.