Sunday, January 29, 2006

"That's not a calendar... THIS is a calendar"

Have you noticed how many "calendars" on the 'Net are really just passive representations? An awful lot of them are just HTML or PDF versions of what you used to get in paper newsletter- a static "printout" of dates and times, that isn't of any use to anything else on your computer.

On the other hand, some organizations do make an effort, providing each event with a link that causes the event to open in your local calendaring program, usually by providing a link to an iCalendar file.

The difference in usability between the two is really painfully obvious: picture yourself going to the school website of your kid, and on that website you find a link labelled "school calendar". Great, you think, I'll add all of Little Johnny's football practices to the family calendar. You click the link, only to find out that it's a PDF, and if you want to add those items, you're going to have to retype each and every one of them. Not very customer-friendly, I'd say. If they had opted to provide the "active" link to an .ics file, you could select ech of the events and add them to your calendar where they'd be most useful.

Vendors are starting to get serious about 'shared calendars" and this is a small but important step - they need to provide ways for all of the organizations in our lives to easily give us these active calendar links.

Wednesday, January 18, 2006

Why subscribe??

If you've read my profile, you know I work with mainframes. In most cases (and in this one), it means the person involved has a lot of years under their belt. I happen to have worn many hats during that time period, one of which was supporting communications.

That experience leads me to question the current model of "subscribing" to things like calendars and RSS feeds. It's not subscribing in the e-mail / mailing-list sense, at all. Instead, it's what we used to call "polling". In polling, one device wakes up every so often, and sends a signal to the other to say "do you have something for me?". If the other end has something, it sends it, otherwise it replies basically "no, try later". The former is called productive polling, and the latter of course is non-productive polling. Non-productive polling is bad, because it uses network bandwidth to little effect. The trick, however, is to get the polling frequency "right" - too slow, and response time of the application is bad; too fast and you just increase the proportion of polling which is non-productive.

Non-productive polling is already happening with RSS feeds, with people setting their aggregators to check their favorite feeds too often. The underlying protocol is basically an HTTP version of "has there been an update?" (do you have anything for me?) and "not yet" (no, try later). It is multiplied by the fact that sometimes there are thousands of these aggregators asking per hour. There are also aggregators which are poorly implemented and which retrieve the latest feed over and over again even if it has NOT been implemented - which means they ignore the "efficiency" of "no, try later" and retrieve the entire piece of data again, over and over. One site owner, Glenn Fleishman, even studied some of these effects and wrote some code to deal with them that helped, but of course it didn't eliminate the source of the issue.

Calendar subscriptions, I fear, may in fact have the same problem, as people's calendaring tools keep checking to see if their favorite calendars have been updated. Given some people's desire to constantly be "up-to-date" they may set their tools to check even more frequently than they check RSS feeds, driving up the proportion of non-productive "polling".

Contrast this with a mailing list subscription. A mailing list uses bandwidth only when there's information to send. It of course requires a central mailing list service, which retains the addresses of the subscribers. There is some "polling" involved - your e-mail client checks regularly to see if "You've got mail!" which is a polling activity- but I don't think people generally set it to run so frequently.

Maybe we could combine the two to improve efficiency: when you subscribe to an RSS feed or calendar, it would send via e-mail some XML representing the new information, in a MIME segment with the proper Content-type, and e-mail clients would pass this to the local (desktop) aggregator or calendar client. This would work well in calendaring tools that already layer on top of e-mail, such as Notes and Outlook, wouldn't it?

Outlook 12: is WebCalendaring an implementation of CalDAV, or something else?

I "hear" that Outlook 12 will have a "Sharing Server", and that among other things it supports a new function named "WebCalendaring".

Could it be that Microsoft is implementing CalDAV (a calendar-specific sharing protocol based on WebDAV)?

Or are they just providing compatibility with Apple's iCal calendar publishing and subscribing?

Monday, January 16, 2006

The time has come to get back to posting!

I've really been remiss in keeping this up. I'm going to try to do better, and I'll start with some interesting news.

Hans Bjorhdahl, who refers to himself as "the calendar guy" for Micrsoft Outlook, says in some comments on his comics site Bug Bash that Microsoft Outlook will include a new, better UI, but also improved support for iCalendar. It looks as though Microsoft is getting serious about iCalendar interoperability, and practically nothing could be better for us as users of calendar products. Even if you don't use Outlook, you're sure (like I am) to need to interact with someone who does. Improvement of the situation can only benefit all of us. They still need to join the Calendaring & Scheduling Consortium, though.

Secondly, I just learned of the When 2.0 conference which was held in December, organized by Esther Dyson. Ms. Dyson (someone correct me and let me know if she prefers to be called something other than "Ms. Dyson") is a leading thinker whose opinions are highly respected in technological circles. When she and her group become interested in a topic, it can generate a lot of good "buzz", these kinds of things are generally very helpful at keeping momentum going, or starting something for that matter.

Even though we've been seeing a lot of progress in the calendaring field lately, I'd like to quote one phrase from the page linked to on that When 2.0 page:
With the growing use of cell-phones, GPS devices and local search, location has come to have meaning on the Net. But we still ignore time - even though computers already "understand" it far better than they do space.
That's exactly right - we've let our calendar tools be "good enough" for far too long, adopting the attitude that as long as they work for us personally, we don't neeed to worry (yet) about making them work with others' calendars.

That's the latest I have right now. I'm going to try to be more prolific in my posts going forward.