Office has always been a gateway drug for business app development. You could start with macros, move to VBA, and then build your own apps that connect to Access and to SharePoint. Then came Visual Studio Tools for Office, which added .NET support and allowed you to build apps that ran inside the Office tools – including inside Outlook. Anyone could build and share an Office app, allowing teams to customise tools and integrate productivity apps with line of business systems.
A lot of what Microsoft is doing with development tooling in Office 2013 is familiar to anyone who’s built an app that uses web APIs – especially any Web 2.0-style mashups or a Salesforce Force.com Apex app. With more enterprise applications and cloud services offering RESTful JSON APIs, the tools and technologies that make up HTML 5 are suited to deliver user-interfaces and basic business logic, displaying external data in context of a document.
Access is the application everyone thinks of when they think about Office development, with years' worth of legacy departmental Access apps still filling PC and server disks with data. It’s still got that role, though now data has moved out of its own database files to local SQL Server stores and to SQL Azure, and user interfaces are now web pages. There’s a lot to be said for taking the Azure approach – it reduces the load on departmental hardware, and increases the reach of your code, while still letting you use enterprise authentication tools to lock down access.
Once completed, Office apps can be deployed and shared through Office’s own app store. The Office Store lets you share or sell your apps, as long as you’ve developed a generic tool rather than something specific to your own business. An internal App Catalog powered by SharePoint does much the same for internal apps, whether you’re running it on premises or using Office 365. IT departments can monitor the apps running on their networks using built-in telemetry tooling and a new Office Telemetry Dashboard.
The simplest Office app consists of an XML manifest file and a single HTML page, hosted on a web server. The manifest is the heart of an Office app, as it details where the app is hosted, what it can do, what permissions it needs, and where in Office it runs. You’ll need a webserver for your apps – either a public server for apps that are intended to be delivered via Microsoft’s Office Store, or an intranet server for apps in a local App Catalog.
Microsoft has made it easy to build new Office apps with a cloud-hosted development environment, codenamed Napa. The Napa tools install on a local SharePoint 2013 system or in an Office 365 account. You can use it to build SharePoint apps as well as Office apps. While it doesn’t support quite the full range of possible Office apps, it’s a good place to start – with tools for building apps that run in Excel, Word and the Outlook Web App.
For example, if you were writing an Outlook app to map addresses in messages, you could write a GetAddresses function that could extract address information from the addresses property of the _MyEntities object created by Outlook. That data could then be passed to a mapping API and displayed in an iframe in your application. Freely accessible mapping APIs from Google and Bing mean that you don’t need to write much code at all, and similarly you could use Salesforce’s Force.com APIs to add meeting information from a message into a CRM system.
That’s the real advantage of Microsoft’s new approach to Office development, the extensibility built into the modern web. With RESTful web APIs for services and applications your apps can be easily extended beyond the desktop, into the cloud and beyond. It’s easy to imagine a spreadsheet that can make calls via Twilio, or a Word document that plugs straight into Wikipedia – or even an email app that extends into the wider web via a service like IFTTT.