What’s new in Outlook ‘12’ Extensibility
Phew... things have been amazingly busy since I posted about PDC last month. We've been pushing to get the new extensibility improvements ready for Beta 1 which is getting very close now. I've been rather quiet, but I promise it was for a very good reason.
Last month at PDC05 we revealed the first public look at the changes coming in the Outlook ‘12’ extensibility platform to very positive reviews. We’ve introduced several new feature areas in the Outlook object model for the next release including a lot of functionality that I know the community has been asking to see for a while.
In particular, the team focused on the following five pillars for our improvements in Outlook ‘12’:
- Security & Trustworthiness
- API Unification
- Performance
- Form Customization
- Innovation
In each of these areas we’ve delivered a great deal of improvements and I’m really looking forward to the Beta 1 release where these improvements will be available for developers to start working with. Let me break down the particulars of what we’ve worked on in each area.
Security & Trustworthiness
In the security area, we migrated the Outlook Security Settings Form over to group policy settings. This provides two key benefits: Outlook ‘12’ can be locked down in ways not previously possible (e.g. without an Exchange server in the profile), and Outlook security settings are now all available from a single management point. This should make IT security administrators pleased as they won’t be required to learn anything about deploying Outlook custom forms to lock down Outlook.
API Unification
One of the biggest headaches about developing solutions for the Outlook platform was that the Outlook object model didn’t provide enough access to the core functionality of MAPI to ensure that you use the object model alone to develop a complex and deeply integrated solution. Often developers would need to use the OM in combination with CDO (collaborative data objects) or Exchange Client Extensions (ECEs) to get the API richness they desired.
For Outlook ‘12’ we’ve taken the most requested functionality from ECEs and CDO that was missing in the object model and incorporated similar functionality into the Outlook object model. This enables solution developers to build on just one API, the Outlook object model, and still have the API richness they desire. We’ve included support for many of the ECE events that were helping in tracking item modifications and lifetimes, support for the “Select Names” dialog, hidden messages, and the ability to access MAPI properties from CDO. We’ve also includes other pieces from these APIs, but I’ll go into more detail on this in a future post.
Performance
Developers would often use CDO in place of the object model because of performance reasons as well as API richness. Outlook only featured the Items collection which meant iterating over individual items and could be potentially slow. In addition it wasn’t clear when Outlook would be required to load the full item into memory, which caused an additional performance hit.
For Outlook ‘12’ we now include a table object. The table is a lightweight read-only wrapper over the MAPI table which can be used to retrieve data from folders with only the columns you are interested in. When using the table to retrieve data, a developer can be sure Outlook won’t go loading the full item unexpectedly while working with the results. In our preliminary testing, this indicates a good level of increased performance (more on this when I get actual numbers).
Form Customizations
Outlook has included the ability to customize forms for quite some time, but there have been a few limitations and issues that developers have always struggled with: forms cache fragility, missing Outlook controls, look & feel issues, etc. For Outlook ‘12’ we’ve done a major investment in a new form customization method we’ve named Outlook Form Regions. Form Regions should be relatively easy for the developer who has worked with Custom Forms and Outlook add-ins in the past.
New Form Regions are designed in the same manner as the legacy Custom Forms features, although once the form has been designed the similarities end. Form Regions, instead of using VBScript, are powered by a COM add-in that lives behind the form. Using an add-in provides a form developer the ability to use a powerful IDE (like Visual Studio) with rich features to develop the business logic and code running behind a form. This is a much better story than trying to use VBScript and a text editor to develop this logic.
Form Regions deployment is also different. Form Regions are deployed with the add-in instead of being published to an organizational forms library. Since these forms are deployed with an installed add-in, they do not depend on the Outlook forms cache and won’t be affected by cache fragility issues. Large corporations can use the various tools (SMS, group policy, etc) they already use to push add-ins down to the desktop to deploy Form Regions as well.
Form Regions also reduce the cost of customizing a form by allowing “adjoining form regions” to be created. An adjoining form region adds a form to the bottom of an existing form, providing space for additional fields and functionality to be added to existing forms without the need to rebuild the entire form. This is particularly useful when a solution just needs to add a few extra fields to one of the built-in forms.
Additionally Form Regions allow a developer to customize the Preview Pane, a space that previously wasn’t available for custom forms. We’ve also included all of the built-in Outlook controls, like date/time pictures, contact photo, the InfoBar, and several others that allow custom forms to have the richness and fidelity of the built-in Outlook forms. Also, new Form Regions automatically pick up the Windows theme, so they look like the rest of Outlook. I’m certain that anyone who’s done custom form work in Outlook is going to love all of the new features we’ve included in Outlook Form Regions.
Innovation
The innovation bucket catches all of the other improvements we’ve made to the object model, including new members for working with Outlook UI and data. For instance, we’ve included an object model around Outlook views, which provides a more robust and rich way to work with Outlook views than the ViewsXML support from previous versions of Outlook. We’ve also added object model for several other areas:
- Rules
- Navigation Pane
- Sharing
I’ll post more about these improvements and how to work with these APIs when the Beta 1 bits are out. Until then, if you want to know more and you weren’t able to attend PDC (or didn’t catch Randy’s talk), you can still download the slides from Randy Byrne’s presentation from the PDC Commnet (scroll down to OFF312). The video from the session is also available on the conference DVDs if you have those available.
After Office ‘12’ Beta 1 has been released, I’ll post more about the new extensibility improvements we’ve made in this release, and I’ll work on posting sample code and walkthroughs of the various feature areas to help out developers working with these new features.
Comments
- Anonymous
October 18, 2005
I hope Microsoft(/you) are looking at posts in Newsgroups and Forums before finalizing any design decisions with regard to the object model. They are full of the same questions over and over again. It's hard to say what the over all problem is but it seems to be just being able to do simple things are just not obvious or simple. This should tell Microsoft that the current object model for Office is not good, but no doubt has remained for backwards compatability. Hopefully this new version will be better. I look forward to seeing the new version.
P.S. The problem when accessing certain information like contacts in Outlook and presenting the user with a dialog asking for confirmation seems to come up all the time. Microsoft's solution to this 'spam' problem was, I thought, a temporary solution. Perhaps add-ins can be considered 'certified' in someway and therefore be allowed to do anything. Comments?
yours,
Stewart Whaley - Anonymous
October 18, 2005
The comment has been removed - Anonymous
October 19, 2005
Hi Ryan,
How about internationalization ?
i.e Addins for Outlook with MUI should be able to change itself according to language of Outlook UI.
In my case, I used VB6 to develop UI for the add-in & faced lots of limitation to be able to build a international GUI (could not make it).
OOM needs to provide some of its own methods/classes/infrastructure to support it from ground.
It looks weird to have MsgBox with english text on a japanese MUI
In a nutshell, how add-in developers can be helped to make it international ?
Kalpesh - Anonymous
November 29, 2005
Feeling a bit disaapointed by the fact that the .NET programbility remains limited to VSTO. The same for Exchange server. - Anonymous
November 29, 2005
What about winform support in Form Regions? Also will we be able to show any form we want in the preview pane? - Anonymous
December 14, 2005
Kalpesh, for localization you can actually refer to Application.LanguageSettings.LanguageID(msoLanguageIDUI) to determine the LCID for the UI language of Outlook. You can then use this information to load the correct localized resource from your add-in and display the dialog in the proper language.
If you are using managed code, this process is much easier because you can use satellite assemblies which automatically get loaded based on the UI language of the user. For VB6 add-ins you will need to do a lot of this work yourself since VB6 doesn’t have a lot of help for localizing your add-in.
As we release more sample code for Outlook 12 you can except to see all of our samples written in a mechanism that will support localization (using string resources, etc). - Anonymous
September 26, 2006
PingBack from http://blog.cronberg.dk/PermaLink,guid,7e934ce8-4f6a-47ed-a938-39bdea4881f6.aspx - Anonymous
July 16, 2008
Ryan Gregg, an Outlook 12 PM, gives an enticing preview of the enhancements and new features of the Outlook