Other companies have solved this problem at the enterprise level with huge installations, most notably Lotus Notes and to a lesser extent Novell Groupware.
In the non-office space Facebook is making a strong run at the defacto group scheduler, at least among my network.
Much the same way Microsoft has Exchange as its server backend and Outlook as the client UI, Lotus has Domino as its backend and Notes as its frontend. Domino is a pretty good product. It's fast, secure, distributes well, was one of the first products to employ a document-based database, and it's backwards-compatible across something like fifteen years of its database format. Every sysadmin I know loves it.
Notes, in contrast, is now a wretched mess, having failed to correct for fifteen years' worth of poor UX decisions.
Taken as two independent entities, the calendaring in Domino is excellent. Notes makes it a pain to deal with, but Domino does a good job of solving the hard bits. So there's a good argument to be made that Lotus has made a successful go at this, but I wouldn't give Notes the credit.
There wasn't much in the way of meat in that post, unless I missed it. As far as I understood, the problem with calandering is:
- Synchronization: with potentially gazillions of users on a single network you've got a timeliness problem: User A may look free to User B, so he books User B, but actually in the interim User C books User B, so there's a conflict. Given the graph-like nature of such a network (all nodes potentially linked to each other) such conflicts could quickly ripple through the system.
Sounds interesting, I wish the author had been a little more specific about the problems.
I wouldn't think the cross-scheduling issue is actually a huge practical problem, as it requires fairly specific failure cases. OTOH if the users are disconnected, then you can't solve the problem anyhow, so you just write a consistency checker that runs while/after syncing and alerts users.
I think the real problem is sheer engineering complexity: having to support a large number of input/output formats, protocols, devices, locales, languages, countries, timezones, platforms, legacy features, backward-compatibility, tools, etc. and making it all look good on the desktop, web and mobile app.
I think the OP is saying if you multiply these together, then you're screwed, unless you're Microsoft or Google...
Either none of us gets the irony or it's simple misleading. Personally I was expecting complexity/algorithm article starting with overview of P ?= NP followed by some other less known but interesting theoretical issues.
Is it possible to create a distributed calendar system based on git? Think about it, all the plumbing is there. Represent calendar semantics in a logical way, and you also have meeting collision (i.e. conflict resolution) support.
No one pointed out that this article is actually 2 years old, but that does make a difference to me.
I kept thinking of something the founders of Justin.tv said:
We were too easily distracted and hadn't really thought through the strategic implications of owning a standalone calendaring property (hint: no one wants a calendar without email).
My product involves scheduling of reoccurring reminders, deadlines, etc. Handling of timezones in particular has been an incredible productivity black hole.
Side note: Who do I need to pay off to get a Olson timezone header added to the HTTP spec?
Why? A few lines of Javascript can tell you which timezone the user's machine is set to. Add a timezone dropdown field to the form where they enter the meeting details, and default that field to their local timezone, but let them change it. Javascript can also tell you whether the meeting date that they picked occurs during DST or not (in the local timezone), store that information in a hidden field.
Now you have everything you need to schedule the meetings and make them appear correctly for everyone involved: The date and time of the meeting, the timezone of the meeting, whether or not DST is occurring there at that date and time. Store everything in the database separately, and store all datetimes at UTC.
This is the solution I built once for an "enterprise" client†, and it worked pretty well.
† a global lawfirm, who regularly needs to schedule meetings across timezones.
I don't see it as a problem of CS, but management. It's a problem we've made all by ourselves.
Absolutely any problem involving humans where errors MUST be kept at ~0% in all cases (any you have just a bunch of variables that can combine and permute) becomes extremely hard.
If you add a ton of features to it, then it becomes intractable.
In my company, all meetings are set in GMT and a notification is sent as soon as the meeting is decided, which is never less than 3 days in advance. After that, it's not any software responsibility to attend to this meeting and it doesn't matter whether you received a reminder or not. You keep track of your local time. If your country decides to switch to the Mayan Calendar it's not my f*g problem, you keep track of GMT time. Period.
I remember that Kiko was the first YC company I really cared about and rooted for. Their approach to this challenge was spectacularly pummeled from a timing perspective by the entry of Google (iirc), and from what I understand the guys have gone on to create some other, very excellent businesses (including Justin.tv).
I think it's interesting to note that five years on, the calendar problem remains.
Edit: While I was typing Larrik made his comment. So interesting to note that 2 years ago this problem still remained, and it's worth clarifying that Google's entry wasn't the only (or even main?) reason for Kiko's end.
Probably this comes from the fact that planning appointments across timezones (especially potentially shifting ones) while trying to speak local time is doomed.
Personally I use this simple rule:
- if the meeting is local, use the meeting physical location local time.
- if the meeting is global, use zulu time.
Now that doesn't help that calendar software actually fails to allow someone to do that properly and easily, but to me that's an artifact of the time notation system we use which grew overly complicated because we insist on tying time to the sun position (for various reasons, some being legitimate, some not really).
Although I despised the marketing aspect of it I actually like the Swatch internet time concept and .beat unit. It just makes sense, is deceptively simple and while it duplicates the role of zulu it removes any source of possible timezone confusion when you write a time (and don't want to sound like a military or an air traffic controller when appointing someone at 0900Z)
Those are calendar clients. Now ask Mozilla to write a calendaring server that syncs with every mobile device on the market across 150 calendars some of which have many thousands of appointments each (with years of exceptions to recurrence) -- no mistakes allowed. Also meeting invitations.
This one issue might be what keeps Microsoft in the game.
tl;dr Calendaring is the only program that requires distributed coordination in the Microsoft office suite, so it is the hardest to make.
Can't argue with that. But all of the difficult problems mentioned in the post are difficulties with any distributed system, not specific to calendar at all!
Microsoft has probably been having those same issues with Word, Excel, even Powerpoint as they have been working on making them collaborative for a long time now...
One of the most annoying thing is getting timezones right when you try to exchange calendar invites across systems. (i.e., sending a Lotus Notes invite to Google Calendar, or an Evolution invite to Novell's Groupwise, etc.)
There is an IETF standard for the calendaring exchange, which is why it works at all (albeit badly), but unfortunately, when you are trying to coordinate a meeting schedule across multiple calendaring systems, you're very likely to have the global calendaring problem where time zones matter. :-(
I disagree. I believe MS Project is a much larger/more complicated animal - at least when using Project Server.
How do you handle exceptions when a task update is accepted by a timesheet manager, but rejected by the project manager, all while the data was written to the back-end reporting cube?
Have you ever tried to level a resource on four competing projects? This is much more complicated than scheduling meetings using a single-use resource like a meeting room.
The high profile startup Asana is attacking problems like this. One of their advisors is Mitch Kapor,
the founder of Lotus and designer of Lotus 1-2-3.
Wow, I just looked at the company profile. That's some list of advisors. They must have more money than they know what to do with, and sit on very nice chairs.
"word processors are probably the easiest" hahahaha.
Microsoft has been working on Word longer than it has been working on calendaring, and it still sucks too. I think the problem is the underlying assumption that Microsoft is the world's greatest software company.
Apple pulled Pages out of its ass in nothing flat, and it's a better word processor than Word. (Framemaker is also a better word-processor than Word, but it's kind of expensive.)
I wish this person had been more specific with respect to the specific problems with calendaring. The ones raised in this article look reasonably straightforward to me. "Thousands of machines, each one run by a human, most of whom are probably illiterate in computer skills and pretty much randomly clicking here and there willy-nilly" is pretty much the internet, right?
> But we've been working on calendaring for maybe 20 years now, and Outlook/Exchange still sucks.
I'm still not sure whether it says something about the calendaring problem, or MS software design. As much as I'm happy with outlook/exchange in general, my outlook crashes ~4 times each day. I tend to blame MS being sloppy, not calendaring being hard in that situation.
> Why is calendaring hard? Well, [...] the product requirements [...] some sort of ridiculous amount of distributed systems hackery around timeliness of updates, heterogenous network, consistency, graceful exception handling, and node availability semantics.
I'm sure Facebook, Google, Apple or Twitter can do that.
[+] [-] guelo|15 years ago|reply
In the non-office space Facebook is making a strong run at the defacto group scheduler, at least among my network.
[+] [-] omh|15 years ago|reply
Some people, when confronted with a calendaring problem, think "I know, I'll use Lotus Notes". Now they have two problems
[+] [-] bguthrie|15 years ago|reply
Notes, in contrast, is now a wretched mess, having failed to correct for fifteen years' worth of poor UX decisions.
Taken as two independent entities, the calendaring in Domino is excellent. Notes makes it a pain to deal with, but Domino does a good job of solving the hard bits. So there's a good argument to be made that Lotus has made a successful go at this, but I wouldn't give Notes the credit.
[+] [-] retube|15 years ago|reply
- Synchronization: with potentially gazillions of users on a single network you've got a timeliness problem: User A may look free to User B, so he books User B, but actually in the interim User C books User B, so there's a conflict. Given the graph-like nature of such a network (all nodes potentially linked to each other) such conflicts could quickly ripple through the system.
Sounds interesting, I wish the author had been a little more specific about the problems.
[+] [-] Maro|15 years ago|reply
I think the real problem is sheer engineering complexity: having to support a large number of input/output formats, protocols, devices, locales, languages, countries, timezones, platforms, legacy features, backward-compatibility, tools, etc. and making it all look good on the desktop, web and mobile app.
I think the OP is saying if you multiply these together, then you're screwed, unless you're Microsoft or Google...
[+] [-] temptemptemp13|15 years ago|reply
[+] [-] rednum|15 years ago|reply
[+] [-] yuvadam|15 years ago|reply
Is it possible to create a distributed calendar system based on git? Think about it, all the plumbing is there. Represent calendar semantics in a logical way, and you also have meeting collision (i.e. conflict resolution) support.
[+] [-] bruceboughton|15 years ago|reply
"Is it possible to create a cheesecake using moondust?"
[+] [-] larrik|15 years ago|reply
I kept thinking of something the founders of Justin.tv said:
We were too easily distracted and hadn't really thought through the strategic implications of owning a standalone calendaring property (hint: no one wants a calendar without email).
[+] [-] snprbob86|15 years ago|reply
Side note: Who do I need to pay off to get a Olson timezone header added to the HTTP spec?
[+] [-] bhousel|15 years ago|reply
Now you have everything you need to schedule the meetings and make them appear correctly for everyone involved: The date and time of the meeting, the timezone of the meeting, whether or not DST is occurring there at that date and time. Store everything in the database separately, and store all datetimes at UTC.
This is the solution I built once for an "enterprise" client†, and it worked pretty well.
† a global lawfirm, who regularly needs to schedule meetings across timezones.
[+] [-] muyuu|15 years ago|reply
Absolutely any problem involving humans where errors MUST be kept at ~0% in all cases (any you have just a bunch of variables that can combine and permute) becomes extremely hard.
If you add a ton of features to it, then it becomes intractable.
In my company, all meetings are set in GMT and a notification is sent as soon as the meeting is decided, which is never less than 3 days in advance. After that, it's not any software responsibility to attend to this meeting and it doesn't matter whether you received a reminder or not. You keep track of your local time. If your country decides to switch to the Mayan Calendar it's not my f*g problem, you keep track of GMT time. Period.
[+] [-] pyrhho|15 years ago|reply
[+] [-] JacobAldridge|15 years ago|reply
I think it's interesting to note that five years on, the calendar problem remains.
(Happy for the Kiko team or those who actually know them to correct my memory; and for those with no such memory - http://techcrunch.com/2006/08/16/ajax-calendar-kikocom-goes-...)
Edit: While I was typing Larrik made his comment. So interesting to note that 2 years ago this problem still remained, and it's worth clarifying that Google's entry wasn't the only (or even main?) reason for Kiko's end.
[+] [-] Maro|15 years ago|reply
http://planetlotus.org/profiles/mikkel-heisterberg_87315_why...
[+] [-] lloeki|15 years ago|reply
Personally I use this simple rule: - if the meeting is local, use the meeting physical location local time. - if the meeting is global, use zulu time.
Now that doesn't help that calendar software actually fails to allow someone to do that properly and easily, but to me that's an artifact of the time notation system we use which grew overly complicated because we insist on tying time to the sun position (for various reasons, some being legitimate, some not really).
Although I despised the marketing aspect of it I actually like the Swatch internet time concept and .beat unit. It just makes sense, is deceptively simple and while it duplicates the role of zulu it removes any source of possible timezone confusion when you write a time (and don't want to sound like a military or an air traffic controller when appointing someone at 0900Z)
[+] [-] hm2k|15 years ago|reply
* Apple released iCal in 2002.
* Mozilla announced their calendar project (Sunbird) in 2003.
* In 2003 Novell purchased Ximian and their calendar software: Evolution
[+] [-] zyphlar|15 years ago|reply
This one issue might be what keeps Microsoft in the game.
[+] [-] whatusername|15 years ago|reply
[+] [-] robfig|15 years ago|reply
Can't argue with that. But all of the difficult problems mentioned in the post are difficulties with any distributed system, not specific to calendar at all!
Microsoft has probably been having those same issues with Word, Excel, even Powerpoint as they have been working on making them collaborative for a long time now...
[+] [-] tytso|15 years ago|reply
There is an IETF standard for the calendaring exchange, which is why it works at all (albeit badly), but unfortunately, when you are trying to coordinate a meeting schedule across multiple calendaring systems, you're very likely to have the global calendaring problem where time zones matter. :-(
[+] [-] Jupe|15 years ago|reply
How do you handle exceptions when a task update is accepted by a timesheet manager, but rejected by the project manager, all while the data was written to the back-end reporting cube?
Have you ever tried to level a resource on four competing projects? This is much more complicated than scheduling meetings using a single-use resource like a meeting room.
[+] [-] Maro|15 years ago|reply
[+] [-] gadders|15 years ago|reply
[+] [-] cschmidt|15 years ago|reply
[+] [-] podperson|15 years ago|reply
Microsoft has been working on Word longer than it has been working on calendaring, and it still sucks too. I think the problem is the underlying assumption that Microsoft is the world's greatest software company.
Apple pulled Pages out of its ass in nothing flat, and it's a better word processor than Word. (Framemaker is also a better word-processor than Word, but it's kind of expensive.)
[+] [-] qntm|15 years ago|reply
[+] [-] viraptor|15 years ago|reply
I'm still not sure whether it says something about the calendaring problem, or MS software design. As much as I'm happy with outlook/exchange in general, my outlook crashes ~4 times each day. I tend to blame MS being sloppy, not calendaring being hard in that situation.
[+] [-] gulbrandr|15 years ago|reply
I'm sure Facebook, Google, Apple or Twitter can do that.
[+] [-] gatlin|15 years ago|reply
If the user says "No meeting this Thursday," don't show the meeting on Thursday? Did I miss something? /cocky youngster, question stands
[+] [-] known|15 years ago|reply