One key aspect of Microsoft’s forthcoming Office 2013 is its support for a new app model. The idea is that rather than building local add-ins for desktop Office, you will build web applications that live in one of four places:
- In SharePoint
- Within an Excel document
- Within a Task pane in Excel or Word
- Adjacent to an email in Outlook
If you have been following Office development for a while, it is hard to supress an initial reaction of “oh no, not another development model for Office.” After all, we have had Basic macros, Visual Basic for Applications, COM Add-ins, Visual Studio Tools for Office, and in the case of Exchange, other APIs such as MAPI and Exchange Client Extensions. Further, most of this stuff still works, which is a mixed blessing as the the whole thing gets more bloated and confusing.
Even so, I can see the sense of the new Apps for Office. One key advantage is that they work in Office Web Apps as well as in the desktop applications. They are also easier to deploy and secure, since they require no executable files on the client, are sandboxed, and only interact with the local document via a JavaScript library. That may not always be sufficient of course, in which case you can stick with one of the older extension models (personally I still find VBA useful), but where it is sufficient, this strikes me as a good approach.
That said, there are plenty of gaps in the list of supported app types:
| Application | Supported types |
| Excel 2013 Preview | Task pane, Content |
| Excel Web App Preview | Content |
| Word 2013 Preview | Task Pane |
| Outlook 2013 Preview | |
| Outlook Web App Preview | |
| Project Professional 2013 Preview | Task Pane |
It would be good to see content apps supported more widely. Still, it is a start.
Office program manager Brian Jones has an excellent post on the background to apps for Office and SharePoint, which inspired me to sign up for a developer preview. Microsoft had already created an Office 365 preview account for me, but this other one is the real deal: you get to administer an entire test organization, complete with SharePoint, Exchange 2013, and all the Office 2013 preview apps.
After sign-up, it took a few minutes to provision, and then I was able to add the Napa development tools to the site. This is itself a cloud app. It is easy to get started: choose the type of app you want and you are in.
Napa is a cloud IDE, essentially a code editor with some syntax highlighting and code completion.
The real joy, if you have ever done SharePoint development, is how easy it is to deploy. Just click the Run button.
Once installed, you can launch the app with a click, provided you have enabled pop-ups on the site. An Excel content app works in the same way, but opens up the app running in an Excel Web App spreadsheet.
I am sure seasoned Microsoft platform developers will find Napa rather limiting, but there is also an Open in Visual Studio button, and all going well you should be able to do most of your coding in Visual Studio, upload back to Napa, and still get the benefit of easy test and deploy.
If you are pleased with your app you can easily offer it for sale by publishing to the Office store:
The implications for Office 365 are rather profound. It is evolving into a true extensible cloud platform, where businesses can add apps and deploy to their users using an app store model.
That said, you can argue that Microsoft is playing catch-up here. For example, Salesforce.com has had Force.com for years, and I know from visiting the huge vendor exhibitions at events like Dreamforce how strong that marketplace has turned out to be. Salesforce has also enabled its users to build apps in the cloud for many years now.
All true; but Microsoft’s approach does have the advantage of continuity. As I mentioned above, the old stuff still works, so customers can move at their own pace towards a cloud-based platform.
For more information, I recommend this overview.