A bit ranty, proceed.

The designers of iCal did it wrong. I applaud them for including timezone support at all because of the can-of-worms I envision it being. Dates are scary in the parsing sense. For the uninitiated, here’s about how iCal works now:

You can enable timezone support (rightfully off by default as it adds clutter that 90% will never click) in Preferences and then have an editable timezone option for every event on your calendar. This part will be strange in text but I’ll try: changing the timezone on a single event will cause that event’s block of time (in week view or day view) to shift up or down by the offset between your home timezone and the event timezone. Easy-to-follow example: an event in St. Louis (Central Time) at 10:00 am appears at 8:00 am on my calendar because I’m in Pacific Time.

The right way is to allow setting entire days to a certain timezone. Perhaps this setting would be inferred from a multi-day event on your calendar or (bonus!) a feed imported from Dopplr? Tying a timezone to a multi-day event would be sweet as it could be expanded to start and stop at certain times of day, thereby satisfying even the craziest of travellers. Assuming this default would eliminate my need to micromanage my calendar.

Benefits? I could say (to my computer, with mouse clicks), “I will be in the Central timezone from February 1st until February 9th, please show those day’s events accordingly.” If an event is scheduled on a day that I’m slated to be in the Central timezone, it should always be shown as if it is in the Central timezone. Displaying everything in the current timezone just makes me do extra math.

The tradeoff in design here is day-to-day consistency versus the rate at which I can consume information from my calendar. I can understand why Apple’s designers made the decision they did but respectfully disagree. It is much easier to casually remember where I’ll be at any given time (in the macro sense) but much more difficult to remember that I must constantly do timezone math when looking ahead on my calendar.

Humanized yesterday published a eulogy for the “Save as…” icon that has for so long depicted a floppy disk. With our 20/20 hindsight it would be quite easy to shame ourselves for standardizing an icon that would be as foreign to our children as Esperanto, but how could we have known? Without digressing into a rant about the pace of technological change, Moore’s law and all its variants regarding physical storage, I will just say that physical manifestations of ideas will inevitably become obsolete.

So I would like to propose a new icon for the “Save as…” function: a brain. First, from the standpoint of potential obsolescence, I will place my faith in brains retaining their usefulness forever. In terms of connotation, brains are associated with remembering — the exact goal of the “Save as…” operation — so I think this will provide a workable substitute for the floppy disk to those of us that remember floppy disks and a straightforward association to those that do not. Generalizing a bit, a human analogy will likely have more staying-power as a symbol than the specific technology that realizes the analogy.

As I call for human analogies I cannot think of one besides the brain. In many cases, text is simply the clearest explanation of a concept that can safely be called permanent. Cutting, copying and pasting all use technologies that are bound to be replaced (scissors, glue, et cetera) and so are perhaps best left to text. URLs similarly all-too-often use cryptic strings of arguments that will probably change with the next redesign or software upgrade. Good URLs tell you what a page is about and where it is in the site. Take del.icio.us for example: page titles on del.icio.us are made up of nothing more than the URL exploded and linked to pages higher up the directory tree.

I read once on the W3C’s website that the best URLs never change. This is of course good advice for those aspiring to Internet immortality and in retrospect should have served as a warning to Adobe when they tucked their ubiquitous Acrobat Reader at http://www.adobe.com/products/acrobat/readstep2.html so many years ago. Keeping URLs about the content and not the technology (or workflow in Adobe’s case) will prevent mishaps like Adobe’s Acrobat URL.

Representing ideas, not technologies, in our text and images is how we should make things permanent. Having a standard “Save as…” icon is not a bad thing, but the choice of icon was short-sighted.