A growing number of people will be keeping their work calendars in Microsoft Outlook and their family calendars elsewhere, say on Google. How can they cross-publish their work and family calendars? It’s possible, but the conceptual hurdles are formidable. Here’s what I found when I did the experiment.

I started by subscribing a work calendar in Outlook 2007 to a family calendar on Google. From one perspective it was easy and just worked. From another perspective, I marvel at the amount of tacit knowledge required for me to have that experience. You start here:

The Manage calendars link in Google Calendar leads to the second tab of this four-tab screen:

The Shared: Edit settings link goes to the second tab of a two-tab screen:

This tab is for sharing within the Google realm, but that’s not the scenario I’m going for. It shouldn’t be necessary to sign into Google to see a family calendar hosted there, it should be possible to subscribe directly from Outlook 2007. And you can, but this is the wrong place to do it. You have to switch over to the first tab:

The private URL is what we’re looking for. And in particular, the iCal flavor of the private URL. That’s what other calendar programs, including Outlook, can latch onto to subscribe to this calendar. The URL that Google produces starts with http:// and, when you plug it into Outlook 2007, bingo, there’s the family calendar nicely merged in with the work calendar. Easy, but only if you’ve mastered a whole bunch of concepts.

Now let’s go the other way. How can a family member using Google Calendar subscribe directly to a work-related Outlook calendar? Let’s start by right-clicking a work calendar in Outlook and selecting Publish to Internet:

Hmm. Office Online or WebDAV server? Let’s start with the former. Now the choices are:

This seems analogous to the Google Calendar situation, but only partly. The invited users option is indeed analogous to the Google counterpart. Here those invited users will need to have Windows Live IDs in order to use the sharing URL that’s produced. But the other choice doesn’t produce a private URL, it produces one that’s discoverable in Office Online. (Or, I guess, will be when calendar search is implemented there.) So while the sharing URL that’s produced in both these cases looks like a private URL — that is, it includes the kind of random character string that often functions as a password embedded in the URL — in this case you’d be wrong to use it as though it were a private URL.

What about WebDAV? Now we’re in geek territory. You have to know what a WebDAV server is, and have one at your disposal. (I do, but I’m an outlying data point.) When you publish your Outlook calendar to WebDAV and then try to subscribe from Google Calendar, you’ll fail if the calendar is secured with HTTP basic authentication. (However, Apple iCal will succeed in this case.) If you instead allow anonymous access to the WebDAV-hosted calendar it’ll work in Google Calendar, but only if you alter the sharing URL produced by Outlook, changing webcal:// to http://.

There’s just a whole lot going on here. Even though I’m familiar with all this stuff, it was a real struggle for me to understand what works (and why), as well as what doesn’t (and why not).

The other day I heard a phrase I like a lot: concept count. It refers to the number of distinct concepts people must hold in their heads in order to do things, and it’s closely related to my recent item on conceptual barriers. Let’s step back and inventory some of the concepts involved in this calendar cross-publishing scenario.

Subscription. There’s a fundamental distinction between static and dynamic exchange of calendar information. On the static side, we use words like import and export and snapshot. On the dynamic side, we use words like subscription and feed. Most people have direct experience with the former, but few as yet with the latter.

Subscription URL. If you do have direct experience of subscription, you’ll know that a subscription URL is a magical thing. It doesn’t point to a thing, it points to a process that always yields new things. But if you haven’t yet experienced live subscription, there’s a conceptual barrier. The difference between one kind of URL and the other is abstract. As in a related example about click-to-load versus right-click-to-save, the URL itself is an overloaded construct that people have to disambiguate.

Private URL. Lots of services nowadays use this technique. Yes, it’s only security by obscurity. Anyone who knows the URL has access, so it’s a weak form of protection, similar to but more convenient than a shared password. Shared passwords have their uses, and so do private URLs. But how many people realize that private URLs are analogous to shared passwords, can evaluate the security tradeoffs, and can recognize a private URL when they see one that’s been produced by Google Calendar or Amazon S3 or another service? The URL does not wear its intended purpose on its sleeve. Google and Amazon and others are beginning to define expectations that private URLs are unguessable but, as we see with the public calendar URLs at Office Online, an URL that looks unguessable may in fact be discoverable through search.

iCal. For ages we’ve had Internet calendaring software that uses protocols and formats associated with the word iCal, but the concept mostly hasn’t sunk in yet. Here’s one reason why:

Various iCal URI schemes including webcal:, webcals:, http:, https:. In the course of this experiment I encountered examples of all of these. The concept that https means secure http may be fairly well understood at this point, though I’m not convinced of that. But I’m sure that webcal: isn’t yet, and that’s hardly surprising. In principle an alternate URI scheme is just the sort of cue that would help people understand the difference between a generic resource and a calendar resource. In practice it hasn’t worked out that way. Partly that’s because there are so few alternate URI schemes in use that people haven’t internalized what they can signify. And partly it’s because the webcal: scheme has been very haphazardly implemented. Some sharing services emit webcal: (or webcals:) URIs that must be transposed to http: or https: in order to work, and vice versa. If SSL is involved, there’s another conceptual mapping between webcals: and https:.

Authentication. A calendar-sharing URL may or may not require authentication. If it does, you may or may not be able to tell, by looking, what kind is needed. If the calendar URL comes from Google or Office Online, it makes sense that you’d use a Google account or a Windows Live ID. But what if it comes from a WebDAV server? There may or may not be a straightforward way to know (or find out) what kind of credentials that server will require.

Scope of visibility. I think this is the toughest concept of all. Blogs and video sites notwithstanding, sharing anything at all on the web will be a new thing for most people. Thinking through what will be visible to whom is non-trivial. On the corporate side, Outlook 2007 distinguishes between calendar sharing and Internet publishing. Each defines the bedrock concepts of user, group, and world in different ways. On the personal side, there are yet other ways to construe these fundamental scopes of visibility.

All this only scratches the surface. We could elaborate a whole lot more of these conceptual underpinnings. Bottom-line: support for standards is necessary but not sufficient. Even when products comply with standards like iCal, people struggle mightily to use those products interoperably. It’s the conceptual barriers that get in their way. It’s really hard to figure out how a concept expressed in one system maps to the same (or a similar) concept in another system. To make that easier, technology providers will have to agree on more than just protocols and file formats. We’ll also have to work together to minimize conceptual clutter and normalize core concepts.