Among other things, we’re designing an online calendar for a client. Originally planned with no interactivity (just a fancy display of important dates), they’re now asking if it can synch with Outlook. A cursory search turns up a lot of apps that work between Outlook and Google Calendar, iTouch, etc., but what we’re looking for seems to be a bit buried. In cases like this we tend to hit Rentacoder, but at this juncture we’re not sure what’s involved or what to tell the client (other than “sure, we can get that done for you”).
Assuming (hah!) functionality is fairly straightforward—a synch button that downloads important dates to multiple versions of Outlook—is this a fairly routine programming job that should run a day or two of a programmer’s time? Or is it likely to be more involved and we’re looking at something larger in scope? I guess we’re basically looking for a frame of reference to get a handle on what we’re in for.
Oh, and if there’s a more appropriate message board for questions like these, would you share it?
I’ve done it before. It had to be in a separate class, but I used the Office.Exchange interop. It wasn’t easy and basically had to build the XML for each request/response.
Thanks. By “wasn’t easy,” do you mean because you were figuring it out on the fly or because there were a host of problems and whatnot that kept popping up? If asked again, would you run in fear or take it on as a few hours/days/weeks or so’s worth of time? Anything we should be aware of as we start spec-ing it out?
How fancy of a sync do you need? Does it need to be able to do things like modify appointments (ie, “Monday’s 11am meeting has been moved to Tuesday at 3pm”) or just download new appointments? Does it have to be bi-directional (that is… can an individual upload appointments from the Outlook calendar on their machine to the web site?)
If it’s relatively simple - like you just need a button to download new appointments to a calendar - you can do a lot pretty quickly with iCal/vCal formatters.
If it’s more involved, then it can get complex.
In theory, it should be simple and one way only. Of course, it wasn’t supposed to be interactive in the first place. Ah, clients!
Imagine a science fair. The fair itself has several important dates/deadlines (applications due, proposals, registration, paper submission, etc.). Interspersed with these dates are fun science facts. They’re considering a button that will download the important dates to a visitor’s Outlook calendar.
If we’re going into this blind, what other questions and requests could be lurking that we should be aware of (e.g., dates probably won’t change, but if they do the ability to delete a previously synched date).
By “wasn’t easy” I mean both learning it on the fly and problems that crept up.
It was largely building an XML doc and sending it along to the Exchange engine, however the problem was that none of the Exchange XML fields were named anything sort of understandable or logical. Some fields were required by the call and some where not. You had to guess which by trial and error (and error and error)
The microsoft documentation on this isn’t the most clear, and a lot of their examples don’t even work properly. Plus (actually a minus), microsoft tends to make the easiest operations as complex as possible, while adhering to the “Microsoft Way” of doing things that defy logic.
If presented with this in the future, I’d estimate an extra 2-3 week’s (yes WEEKS) if you’re going into this blindly. Perhaps 1-2 weeks extra if your coder’s a flippin’ genius in exactly the same manner as I am not.
Google is your absolute BEST friend in these matters.