This article is more than 1 year old

Microsoft's Office 2013 app-maker cloud drenches developers

Visual Basic macros are dead! Long live JavaScript macros!

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.

Apps for Office themselves also show promise. The application model avoids traditional Microsoft technologies including ActiveX and even .NET: all the code is JavaScript, although you can call web services written on any platform. Possible uses include Mail apps that look up customer details and order history; Excel apps that create charts or analyse data; or apps that validate form data in Word or Excel. You can deploy apps privately or offer them publicly in the forthcoming Office Store.

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. ®

More about

TIP US OFF

Send us news


Other stories you might like