blog.edwilde.com - The Blog of Ed Wilde

I recently partook in a big switch of digital work patterns. Actually, to tell the truth, I initiated the change in order to reduce the amount of time spent messing around with things I cannot fix.

For the past 4 years, the sculpture foundation has used iCal sync’ed between all of the machines to plan peoples whereabouts, tasks, meetings etc. This system worked fine, with only a few hiccups every so often. Recently, something has changed with isync, it was rewritten for tiger and has never been quite as good. We have three machines on tiger, three on panther as every new machine we buy comes preloaded with the new os (and I refuse to downgrade). Things are not synchronising properly, they say they are…but events are missing, notes get lost, and the situation seems to be getting worse.

The technical reason for this, as far as I can ascertain, is that the sync utility seems to require a secure connection. The hardly known fact about secure connections is that they are slow as hell on satellite internet, due to the time (latency) of the packets to travel to the satellite and back. They also seem to get corrupted far more than a cabled connection. So in the sculpture estate where adsl is still a dream rather than a possibility, the synchronisations often fail. Panther seemed to be able to deal with this…tiger cant!

The most important aspect of synchronised calendars is that the information must be reliable, otherwise we might as well use paper and a pen. People were generally noticing that more often than not, an event they added was not showing up on other peoples ical calendars. As yet this hadn’t created any really embarrassing conflicts, but it was only a matter of time. A change was needed…

Luckily an alternative arrived, Google Calendar, which I must say I am very impressed with, was released. It presents the information in a nice-ical’y way, however, in a direct comparison with ical it is stronger in some areas than others.

Obviously, speed is the biggest factor…no matter how fast a web-based calendar is, it will never be as fluid as a local application. Unusually, it also doesn’t seem to display changes made to the calendars in real time. As far as I know this can be achieved fairly easily using ajax, perhaps it is the load they are worried about. The final factor is planning for the situation where the internet connection fails, using google, all the calendars fail too. With these things and a strategy to overcome them in mind, the switch went ahead.

The first method of implementation I tried was to have one login for everyone to use. I then remembered that some people only like to view calendars directly related to them, the problem here is that if someone turns off a calendar on one computer it will be turned off when the calendar is refreshed on all of the other computers. This would most likely lead to frustration and rejection of the new system.

So multiple logins had to be created, the system I chose was one each for the office staff, arguably the power users (in a relative sense) and one generic login for computers used by floating staff, such as freelancers and grounds staff. Each login has its own base calendar, which as I found to my dismay cant be cleared without deleting the account completely…oof!

To perform the switch, all of the calendars were exported from ical, then imported into their respective logins…fairly simple and painless process, they have obviously spent time on this.

The generic calendar holds a few more than the rest, although this doesn’t seem to make much of a difference. Once the calendars were created and imported, they then had to be shared with the other calendar users. This was an incredibly easy process and simply involved adding the username to the list of users who could use the calendar. There was a small buggette during this though, the default share mode is read-only and I need read-write for everyone. Because each calendar has to be shared individually, I had to run through adding five different logins for eight calendars, it was pretty inevitable that during the addition of 40 bits of info, coupled with the speed increase possible with the nifty ajax auto-complete that I would add a couple of shares as read-only. Once they were added, and I had noticed my mistake, I simply had to change them to read-write…simple…except google calendars couldn’t seem to do it, each time I pressed save after editing the options I got an error message telling me to try again. I tried again, and again and again then eventually gave up trying to edit the records and chose to delete the login and started again from fresh, making sure I did it properly first time, it worked fine after that.

One well documented problem with google calendars is that it doesn’t work in safari, this problem is however presented in a nice way…first it tells you in an alert box it wont work, unlike most systems which would just stop you, leaving the contrary suspicion, gcal allows you to continue at your own risk…sure enough, they are right, it really doesn’t like safari. This had held me back from trying to implement it when it was first released, as all the machines use safari for all web-browsing.

After reading the Google Calendar Tips on Stopdesign, I decided to implement it in the delightfully sideways method suggested, using firefox as an exclusive gcal application, by removing it’s navigation, status and address toolbars.

It has been in use now for almost a week, and the feedback was so good that performed the final part of the switchover strategy. I added all of the google calendars as private subscriptions to ical, replacing the existing calendars. This means that if the internet connection goes down or if anyone needs really quick read-only access to the calendar information, perhaps while on the phone, the information is there and ready to use without having to refresh or wait for it to load.

Sweet…