Microsoft's Office 2013 app-maker cloud drenches developers
It was in 1994 that Microsoft declared Office a development platform, and released the Office Developer’s Kit 1.0 for coders to turn out useful utilities.
Using Visual Basic and COM automation, programmers could control Office applications using software. Automating, say, document editing in heavyweights Word and Excel in the fragile and resource-constrained environment of Windows 3.1 was unwieldy, but in some scenarios was a great timesaver.
In 2003, the company came up with Visual Studio Tools for Office, in which COM automation was wrapped with .NET libraries, allowing Office to be controlled using C# and other .NET languages. Microsoft also came up with a variety of methods for extending Office: templates, COM add-ins, Smart Tags, Action Panes, custom ribbon tabs, and more.
Then there is Visual Basic for Applications (VBA), the macro scripting language that will not die. Lightweight and effective, VBA still exists in Office 2013, the new release currently in preview.
The problem with all these odds and sods is that they run in the client and (VBA macros aside) have complex dependencies. They do not translate well to the cloud-with-device model, in which Office may be running on a locked-down Windows RT ARM tablet or in the browser on an Apple iPad using Office Web Apps.
Hiya Napa: Is Microsoft's Office cloud IDE an island paradise?
Programmers can get started with Apps for Office by signing up for an Office 365 developer pass. One advantage of this approach is that you can use Napa - Microsoft’s cloudy IDE for Office and SharePoint client apps. Napa is itself an app, and once installed you can create a new App for Office in a couple of clicks.
Napa is a simple affair, but it does support syntax highlighting, code completion, error highlighting, and search and replace. More importantly, it makes deployment for testing a snap. Hit the run button, and Napa packages and deploys the app to your Office 365 SharePoint and lets you launch it in the relevant Office application, such as Word or Excel, or in the browser for a pure SharePoint app.
Frustration comes baked in
There are a few annoyances in the current preview. Launch Excel 2013, for example, and it shows an “Enable editing” button thanks to Microsoft’s cautious attitude to potentially booby-trapped web-sourced documents, and then displays a sign-in prompt even though you have already signed into Office with your account.
Still, it works. Unfortunately the ease of use, in the current preview at least, soon falls apart. There is an “Open in Visual Studio” button that works nicely, once it has grabbed a ton of dependencies from the web. Once these are downloaded, the app is opened in Visual Studio 2012, the project is disconnected from cloud-based Napa, and changes are saved locally. It is also not obvious how to get an app from development in Napa through to deployment in the Office 365 app catalogue without using a full installation of Visual Studio.
Editing Excel: building a spreadsheet for Office 2013
It would make sense for Napa to link to a hosted Team Foundation Server, Microsoft’s source code control system, but there is no sign of this in the preview, which means Napa lacks features developers take for granted such as version control. Currently Napa is no more than an interesting experiment, and there are much better cloud IDEs out there from the likes of Cloud9, but with its Office 365 integration Napa has the potential to become useful.
There are a few limitations:
- Apps for Office require XML-based file formats such as .docx and .xlsx
- Web service calls are subject to same-domain security restrictions, so you may need to use a proxy
- There is no access to the Office COM object model and apps run in their own individual sand boxes, which limits capabilities compared to other Office development techniques
- The range of Apps for Office types is small. Only Excel lets you embed apps in a document
- Email apps only work with Exchange 2013
SharePoint 2013 is not required for deployment, though clients need to access an XML manifest hosted either on a SharePoint 2013 app catalogue or on a network file share, so it appears that SharePoint is a requirement for internet-accessible deployment.
Microsoft Office 2013 is beyond mature, but Apps for Office is completely new and the tools and documentation reflect that. Although it does bring Office development into the world of cloud-with-device, it feels unfinished in places, and is a difficult transition for developers used to richer technologies such as Visual Studio Tools for Office.
It is worth persevering, since the prospect of Office apps that work seamlessly locally or on the web is compelling. ®