Extending Office to the Web

The Office 365 launch in Bryant Park, New York. Credit:Microsoft

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.

Now with the release of Office 2013, Microsoft is introducing a whole new application development model. Taking advantage of cloud services and widespread adoption of HTML 5 and JavaScript, the new Office Apps are designed to be built by anyone familiar with the web – while a mix of cloud-hosted and IDE tooling means that successful user apps can be taken into a controlled development and deployment environment.

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.

Credit: Screenshot
Office Apps in the Office Store

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.

That web approach is the heart of the new Office extensibility model. A JavaScript API gives access to applications – with support for data, functions and events, and for working directly with content in documents. Apps themselves are best thought of web applications, only running in Office rather than a browser. They’re able to work in task panes or in content (or in the case of Outlook, in mail messages or calendar entries). Task pane apps are best thought of companions to document content, either delivering information from other applications, or using services to add extra detail to data in a document. Content apps go a step further and actually display their results in your document.

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.

Credit: Screenshot
An Office App HTML template in the Napa online development environment

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.

Working with Napa is easy enough. You start by choosing the type of app you want to build, and Napa will generate code to help you get started – including CSS and JavaScript. You don’t need to worry about creating the manifest, all you need to do is fill in a couple of forms and tools in the Napa editor will handle everything for you. Much of your code will be JavaScript, just using HTML as a template to format and display results. Apps built in Napa can be exported to Visual Studio, where you can add server side code for apps that run on Azure or on your own Microsoft web servers.

Credit: Screenshot
Start a Napa app development by choosing the type of Office App you're building.

As Office Apps are JavaScript apps you can use libraries like JQuery to simplify writing code, especially if you’re working with external data sources and web services. Microsoft’s Office JavaScript library will also help with your code, as it can work with Office functions to extract specific information from a page.

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.

Join the discussion
Be the first to comment on this article. Our Commenting Policies