More MV integration with Microsoft Outlook
What happened with NebulaManager?
It was great software and I’ve been told by a few people that it was just ahead of its time. Have a look at the (no longer advertised) product page and you’ll see it has a lot of nice features. It was written somewhere between Outlook 2000 and Outlook 2003, and it was very tough to code some parts. It was written with VB6, just when .NET was getting more popular and powerful. I didn’t want to go to market with old technology that would need to be re-written soon. Deployment was a real pain for any Office addins. So while it was very neat in what it did, there was no extensive demand for the features, and it was too troublesome to support the limited market that existed at the time.
Today, creating addins for Office products is much easier with Visual Studio Tools for Office (VSTO). This toolset handles the interface between Office apps and developer components in a way that makes them less foreign to Office, and therefore much more stable. I’m not saying development is easy, just easier. And while we don’t need to manage the entire assortment of registry entries and pre-requisite components manually, we do need to know what they are in case something goes missing in our projects – and that does happen.
One step at a time
So now, rather than trying to go to market with one big product that allows you to create appointments, journals, contacts, notes, and tasks, I’m going to approach these all as unique components. You may not care about creating calendar entries for what’s going to happen, like when the next meeting is, but you may be very interested in what has happened, like what were today’s sales numbers, how many units shipped, etc – and that’s an application for journal entries. Or you may not be interested in any of that, but you do want contact info uploaded to everyone in the field as soon as new data is available. If we get requests for that, I’ll offer it as a separate product that builds on existing infrastructure.
Rather than NebulaSync, why not just call the new components something like NebulaManager Calendars, NebulaManager Journals, NebulaManager Contacts, etc? I dunno, but that’s a good idea, thanks for bringing it up. 
Details
There are a number of things the code doesn’t do yet, but I’ve only been working on it a couple days, and I can easily pull in parts from other projects and move this quickly if required. For example, there is a configuration page you access with menu>Tools>Options that allows you to enter a user ID, and that can be used to retrieve only information for a specific user. That will need to be expanded to allow a single user to be associated with different groups – so the sales manager should get appointments for management, and for sales events. I haven’t fully debugged multi-user concurrent access. There is no provision for updating existing calendar entries with updates.
There is also no provision for updates made to appointments going back to the server. This last bit is a real treat because it really can’t be automated. Imagine if 5 people added comments and moved a single appointment around for some reason. One person might set a reminder, another flags a meeting as private, and others innocently add notes or categories in anticipation of the meeting. So if we send that back to the server, who is going to decide what the right version is? I’ll be happy to send updates back but app developers will need to decide how they want to manage this sort of thing.
With appointments, there is not that much reason for several people to change the data, but if we’re pushing contact info from the server to field people, it’s quite reasonable to expect people to change that data as they get updates – or at least to add notes. In this case, there can only be one right answer – a company’s address is this or that, it can’t be both. So it would be much easier and practical for an app developer to pull contact updates back to the server, merge/purge the data, and push out new updates – while being careful not to delete anyone’s notes.
As you can see, this can all get very involved, but it doesn’t need to be. For the simplest application there’s nothing wrong with generating event or contact data on the MV server and pushing it out to people with the expectation that if there are any updates, they will be communicated back to someone in the office and perhaps the data might get pushed back out to everyone.
I’m looking for a little vision
Not for myself but from you. I think Microsoft Outlook has been around since 1995. To this day it remains one of the least understood applications on our desktops. Most people think Outlook = Email. But as we see here there is soooo much more. And the core application is only a shell of what it can be. As we see, I’ve added interfaces to allow people to do much more with it – and there are lots (tens of thousands?) of developers worldwide who build upon Outlook and other Office apps as a platform. I encourage people who read this to look around to see what people are doing with Outlook, beyond email. There are entire contact relationship management packages built around it, and entire scheduling applications. Microsoft has Exchange and SharePoint and other server products that build on the "basics" of Outlook. I’m really hoping MV developers will get their heads out of their green screens and recognize what mainstream users are using for their primary desktop tools. Once you see how people are using the tools, you can figure out ways to give them your MV server data in their UI of choice. That translates to sales, new products, consulting engagements, and other benefits for you.