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
- Form Customization
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.
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.
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).
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.
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:
- Navigation Pane
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.