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.
I want to introduce shared calendars in my org, but it’s too complicated at this time. I use my family for a test bed, we use Outlook 2002/2003, various phones/smartphones and Google Calendar. Google Calendar quick add is a dream to use and the interface works well for the family. Getting Outlook and Google Calendar to do two-way sync is an unfulfilled dream right now. I’d drop Outlook calendar completely if all the devices could sync to Google.
Hi John
Nice post, it’s good that someone has been through this curve publicly, as many others could use this info. Couple of comments:
1) Apple’s platform Calendar also has problems see : http://blog.spanningsync.com/ which is a project whose purpose is to solve such problems, I believe there maybe outlook equivalents to this project but I could not find them via a brief search.
2) If I was to explain this problem to my daughter she would say (with regard to either outlook or Apple ical) Whats the point of having a calendar that your friends can’t see.. such is the generation gap for those that haven’t lived through desktop/internal software era!!
3) I regularly hack GCal (see blog) and have some interesting uses for it, as such it has now become indispensable to myself and the company I run. It really has changed thing for us and I will be writing more about this in the near future.
4) I have also experienced a number of issues around Webcal and not just with GCal, I guess the specs are too ambigous.
regaards
Al
AFAIK, You cannot modify a Google calendar from within Outlook, Sunbird/Lightening or any other iCal consuming endpoint, which is a shame. One nice calendar sharing solution (aside from WebDAV) that allows for free time querying is using Sun’s calendar server along with the open-source build of Lightening that supports CalDAV, which -again, AFAIK, is the only server that supports WCAP.
Towards minimizing concept clutter — What I would love, in my simplistic way, is I go look at a calendar, I paste that URL in my location bar (not the secret URL) into an email, someone clicks it on the other end and a box pops up that says would you like to a) go to this site, b) import into Outlook.
I know there are some problems with that technically (how does it know to give you access, for example). But the experience after you click the link could help you navigate that. If it’s private, for example, you get prompted for a password, and a correct password constructs the URL of the feed. If you choose the option to share it, it walks you through the consequences (and yes, there is the “Don’t show me this again checkbox there”.
Mailing links around is the killer interface. I think that REST was responsible for the much of the success of the Internet — I think we need to build on that idea, rather than constructing hidden tabs in multiple interfaces. If I’m on the calendar I want to get into Outlook, why can’t I just mail what’s in my location bar to me and click it?
Hey Jon,
Just a note to say that we can push calendaring uses to our partners here in Montreal if you come up with any really concrete suggestions. We have 120 hotspots in cafes + restaurants where 600 users/day sign in through location-specific portal pages (through http://www.wifidog.org) . So we can jumpstart a calendering ecosystem here if you have any suggestions that might work.
FWIW, for subscribing from GCal to Outlook, I’ve settled on using my WebDAV server and creating a kind of private URL by slightly obfuscating an otherwise unauthenticated URL. I’d rather that GCal would handle HTTP basic authentication so if I’m missing the reason why it doesn’t seem to I’d like to be enlightened.
But anyway it all does work. I can see both calendars (work, family) in both applications (Outlook, GCal).
Can you please share how you used WebDAV server? Did you remove the authentication (login and password)?
>>FWIW, for subscribing from GCal to Outlook…
Speaking of concept clutter, good description, but event though I know the meaning of all the words it still all becomes noise by the end of the description.
I want easily shared calendars – check, Google Calendar solves that one. I want reliable two-way sync for my personal calendar that works on my desktop and on my portable device/phone for creating, viewing and editing items. Outlook works well for the device sync, but it’s not web-enabled and the sharing is a nightmare. Back to Google Calendar, how to get the devices working?
Possible solutions:
http://www.syncmycal.com/
http://rareedge.com/gmobilesync/
http://oggsync.com/
http://www.gcalsync.com/
http://iterat.ive.ly/index.php/2006/12/13/gcalendarsync-v02-release-source/
All of these have their bugs and quirks right now. Hopefully one of them will stabilize and I can get the calendar solution I’ve been hoping for since the first Palm Pilot.
Almost forgot this Outlook/Google Calendar sync project: https://sourceforge.net/projects/remotecalendars/
“Speaking of concept clutter, good description, but even though I know the meaning of all the words it still all becomes noise by the end of the description.”
I know! That’s exactly the point. When I articulate the thought process I went through in order to make this happen, it’s just overwhelming.
I’ve had way too much fun trying to get calendaring working the way I would like:
http://rasterweb.net/raster/2006/01/05/calendar-woes/
http://rasterweb.net/raster/2006/01/10/calendar-woes-part-2/
http://rasterweb.net/raster/2006/08/15/calendaring-still-not-there/
http://rasterweb.net/raster/2006/08/15/events-to-go/
Sadly, my current system is in danger of falling over with the next upgrade of my operating system, any application in my chain, or when I get a new mobile phone.
Smithee covered a lot of the bridges between Google calendars and Outlook. One other is iFreeBusy.com, which shares FreeBusy information. FreeBusy is good for scheduling in a business environment, where you’d only want to publishes your availablity at a given time to allow scheduling without publishing the details of what you’re doing each minute of the day.
I found the same thing you did – iFreeBusy.com makes it as simple as possible to set up, but I still had a heck of a time getting a small, very technical group set up to share their FreeBusy information via Outlook, and it never quite worked for some users depending on Outlook service packs, etc. Outlook 2007 hasn’t helped, either.
I know it’s crazy talk, but the Outlook team should release an add-in (without waiting for the next release) to simplify sharing calendars in order to keep relevant in the Google Calendar age.
Hi Jon,
Have you ever looked into Trumba Connect? The Seattle Time Company just selected Trumba Connect to provide new functions for its online event calendar. The New York Times is using Trumba Connect to power its online automotive and career events calendar. It’s a great technology and lets users easily add events to their personal calendars like Google or Outlook.
“Have you ever looked into Trumba Connect? The Seattle Time Company just selected Trumba Connect to provide new functions for its online event calendar.”
Yes, the Trumba folks demonstrated that product to me.
“It’s a great technology and lets users easily add events to their personal calendars like Google or Outlook.”
In the case of this cross-publishing scenario, I suppose I might have used Trumba as an intermediary between Outlook and GCal. However in the end, I got the pairwise combination working to my satisfaction.
Whether using Trumba as an intermediary would make that process easier for an average person is an interesting question. My guess is that, based on all of the conceptual hurdles listed above, it probably would not have.
Hi Jon, this is a great piece of work and some interesting responses too. We are researching use cases for a group calendaring web service and thus would welcome rants. Its an open source project, before we re-invent the wheel it would be good to hear as many feature and functional requests as possible… though it seems to me that most folk responding to Jons excellent entry here just want outlook to work with google and in turn synchronising with their hand held toys, we will be giving that some thought of course, but would also welcome all kinds of suggestions for a calendaring service. What versions of outlook have folks been using?
Ahh, normalizing concepts. I spend my work life in the realm of healthcare, specifically in knowledge representation and interoperability. The phrase “normalizing concepts” conceals a vast ocean of complexity. It was this problem that finally broke Palm Inc.
Just came across this via Digg:
http://www.daveswebsite.com/software/gsync/
Good post, however your statements about Amazon S3 are somehwta misleading.
S3 does not use link obscurity as a primary means of securing data. While S3 URLs may look like that’s what they are doing, closer inspection of the S3 API reveals that the security model is actually more complex than that.
To generate an S3 URL for protected content, the content owner must sign the request and include the signature in the URL. Without the content owner’s signature, there is no way to access secure content. Furthermore, the signature is time limited, so if as a content owner I sign a URL allowing access to an object I have stored on S3, that URL is only valid for the time period I specify… Yes, during that URL lifetime security is only handled through obscurity of the fully signed URL, but this is in no way anywhere nearly as un-secure as the “private URL” issue you originaly brought up.
“Yes, during that URL lifetime security is only handled through obscurity of the fully signed URL, but this is in no way anywhere nearly as un-secure as the “private URL” issue you originaly brought up.”
You’re quite right. It’s been a while since I created one of those private URLs, and I neglected to mention the time limit. Thanks for reminding me.
Jon, I’ve been trying to follow your instructions… but I’m still not able to subscribe, from google calender, to a calendar which I’ve published to Office Online. Maybe I’ve misunderstood your post here. Were you ever able to figure that out?
Hmmm. Thought-provoking, Jon. In 1911, Alfred North Whitehead said “Civilisation advances by extending the number of important operations which we can perform without thinking about them.” It looks like we’re going backwards.
the best way to simplify cross platform calendar publishing is to keep the number of systems you employ at a minimum.
one system is axiomatic, Outlook, since almost all of us use to for business purposes. apart from this we need a web calendar – through which we can access our calendar on any internet enabled computer. thirdly, we need to be able to access our calendar on our mobile. these three calendars should be kept in automatic synch and preferably should also be sharable with our team mates.
there are many all in one solutions which let you access you calendar online, on your mobile, synch it with your Outlook calendar, AND also share your calendars. for example we use Hyper Office
in conclusion, the fewer the systems the lesser the clutter.
Hello! Just had to leave a comment. I honestly liked your post. Keep up the phenomonal work.
This is a train wreck waiting to happen. Crossing calendars will lead to some personal info being published publicly, mark my words.