More on Custom Forms...
Adam asked some great questions on my last post about custom forms and Outlook, and I thought I'd provide direct answers for these questions in another post for everyone to benefit from. I encourage anyone who is interested in the platform to post comments or shoot me an e-mail using the email link. While I won’t be able to get back to you with technical help on how to do something (you should use standard product support channels for that), I’ll certainly read your mails and potentially spin up more blog posts with answers to the big questions.
Q1. What is the future of Custom Forms in Outlook? I really like that ability, but the problem is 1) hard to deploy 2) the Office 2K3 "ide" for form code is really bad 3)hard to get them to work with OWA 4) have no support with ActiveSync.
We’re certainly standing firmly behind the concept of custom forms in Outlook. For Outlook 2007 we’ve introduced a new extension to make custom forms easier to work with for developers by supporting better integration between add-in and form, and reducing the amount of work necessary if you just want to build additional UI elements on to our built-in forms (now possible through adjoining and separate regions).
For form regions, you can now use whatever IDE you want because form business logic for form regions is written as part of your add-in, and thus can be developed in Visual Studio 2005 or your favorite other IDE.
As far as custom forms in Outlook Web Access or on mobile devices, unfortunately we haven’t improved the story with form regions. The same conditions apply as before. One positive note here is InfoPath forms, which will have a slightly better experience in OWA because of the embedded down-level HTML-based form.
It hasn’t been an overwhelming number of customers that have requested to be able to have a “design it once and it works everywhere” experience for Outlook custom forms. If this is something more of you would like to see for the next release of Outlook, I’d love to hear about it and what types of scenarios you are trying to solve.
Q2. Does you envision people actually using custom forms very often? If so, in what kind of context?
My personal vision for custom forms in Outlook sees them moving more towards a developer tool for providing rich integrated solutions with Outlook UI that really feel like they are part of Outlook, blurring the line to where some users may not be able to tell that the solution features are not just part of the Outlook product. We’re getting closer with form regions, where we have similar layout logic for forms, and these forms take on the look and feel of Outlook with themed controls and proper colors.
I think the end user experience for design forms will be migrating into other technologies, like using InfoPath forms for one-off surveys, information gathering, reporting, and similar uses.
This is of course all just my opinion though. What I’d like to hear is more how you want to use custom forms, and what you want to accomplish by using custom forms. It’s been pretty clear from feedback I’ve received in the past that the vision of forms we have today is pretty consistent with what customers are asking for.
Q3. How do you create a custom form in Outlook 12? Is there a specific developer add-in or can you just click Edit somewhere?
Working with custom forms can be a bit confusing for someone who hasn’t worked with them before. Both styles of forms, form regions and classic custom forms, are designed inside Outlook. Classic custom forms (also called Outlook 97-2003 custom forms) can be designed and deployed entirely through Outlook, with VB Script for business logic behind the form. Form regions on the other hand need to be deployed through an add-in and your organization’s processes for deploying software to the desktop.
To get started, you can open Outlook, and from the Tools menu, select Forms, and then Design a Form. Outlook will prompt you for a base for to begin with, and you can go from there. If you want to design a new form region in Outlook 2007, you begin the same way, but then use the form region buttons to create a new blank form region and to save the form region to a file.
Around the end of the month, we’ll be published some new technical articles to MSDN to cover various aspects of the extensibility platform in Outlook. One of these articles focuses on designing a form region and hooking up an add-in to work with the form region. This article provides a great step-by-step reference for how to get started designing a form region, so if you are interested in this technology, I’d encourage you to be on the lookout for that article (or just keep reading on my blog, I’ll post links when they are available).
Q4. How do you reconcile people using Word for email creation in relation to custom forms?
I’m not sure there is much to reconcile here. In Outlook 2007, everyone is using Word as their e-mail editor, and Word is actually hosted in-process with Outlook. Even customers who are running standalone Outlook without Word installed are able to take advantage of some features of Word when composing mail.
Custom forms pick up this benefit as well. By using the Message field or the “body” control on a custom form, the form automatically benefits from the use of Word and will display the rich Word editing surface where this control is placed on the form. This is different from Outlook 2003, where it was often difficult to rectify using Word as the e-mail editor and custom forms, but everything works a lot smoother in Outlook 2007.
