The Office 2013 Developers’ Model: Fourth Time’s the Charm?
Develop | Posted September 11, 2012

With all of computing being re-made around the principle of small, adaptable, networkable, ubiquitous apps, it would appear there’s no room left in the picture for a glorified Excel macro or a homemade PowerPoint transition. That won’t stop Microsoft, however, from promoting Office 2013 as a development platform, this time literally as an alternative to HTML for the deployment of embedded Web apps.

If you don’t think of Microsoft Office as a development platform like Java or the .NET Framework, it’s not for Microsoft’s lack of trying. Microsoft earned a reputation for its ability to leverage one platform’s strengths to build another, but has been working - and not especially succeeding - to gather a sizeable community of developers around something BASIC-ish for Office since 1988.

The idea was mine — or, at least, the folks at Microsoft with whom I was talking to on the phone at the time gave me reason to believe it was. The year was 1986, and some engineers were talking me through an exclusive, confidential preview of a concept called Dynamic Data Exchange (DDE). It was an unprecedented mechanism (for its time) for sharing functionality between two simultaneously running applications, which, in the midst of the MS-DOS era, was also unprecedented. DDE let you embed a spreadsheet into a word processor document, and then edit the spreadsheet from within Word without having to open Excel and re-save the spreadsheet first.

In an article series I had just begun for Computer Shopper, I led with, “English is my first language. Microsoft BASIC is my second.” So I asked these fellows, “Wouldn’t this be a superb way to re-introduce Microsoft BASIC into the mix?” One engineer responded that they’d thought of that, and that they were working DDE support into WordBasic and the Excel macro language.

I said, “No, go further: Create a new BASIC interpreter that speaks one language for both programs. Have the interpreter run on a command line that’s embedded in both places. But the user wouldn’t have to know the interpreter was a separate program; it would just be embedded there. Then, whenever you create a new application, you could simply embed the interpreter there too like it was brand new.”

What followed was the longest and most beautiful pause I’d ever receive in a response during any interview, broken only by a perfunctory cough, a carefully phrased acknowledgment of what a good idea that really was, and a promise that, um, if they ever go that way, I’d be the first to know. And I was.

Being able to manipulate the behavior and characteristics of a complete, functional application is a concept that has always appealed to me, and that I had hoped would captivate maybe more than a dozen others. Microsoft Office is, in the end, the main reason businesses use Windows. (No, you don’t have to remind me again that there’s Office for Mac, and hopefully I don’t have to remind you how little training or other resources are available for it by comparison.) With as few businesses that are entirely satisfied with Office applications the way they are, and with many of them now employing at least someone in their IT department with proficiency in Java, JavaScript, Perl, PHP, Python, or C#, you’d think it would be a trivial matter for that person to adopt the language and methodologies needed to alter and adapt those applications into whatever the business needed them to be. (I published two books on this subject.)

But in most businesses’ perception, Office has never been an adaptable, extensible platform. Over a quarter-century after my invention of the concept and Al Gore’s subsequent creation of the Internet, businesses today are often surprised by the revelation that Office apps are open to adaptation, either by the embedded Visual Basic for Applications interpreter (VBA, the second generation of the Office platform) or by so-called line-of-business apps written for the .NET Framework runtime (LOB, the third generation).

With Microsoft, I have often said the third time's the charm. But this is try #4: a new and even more daring effort to present Office as a development platform in the same league as the Web.

Backing Up to Go Forward

“Today, a lot of application solutions are being built on the Web,” explains Brian Jones, group product manager for Microsoft’s Office 2013 Developers team. “The majority of developers out there use Web technologies in the solutions they build; 75% of developers are making use of HTML5; we’re seeing more and more companies exposing data through RESTful APIs. One of the big motivators there is the ease of deployment. If you’re going to go out and build a solution — especially an internal app, or something you’re going to distribute to customers — when you build it as a Web app, it’s breezy. You just go pass around a URL to people, and now they all have access to that application. You don’t need to go install anything on their machines.”

This time around, Microsoft is not trying to reinvent the wheel with respect to developing apps (which, for purposes of this discussion, are the programs you build for use with Office applications like Word and PowerPoint). Instead, it’s trying to retrofit Office applications with existing wheels that you might not have thought would fit. With Office 2013, the company is introducing a JavaScript API — a lexicon for incorporating Office applications’ functionality into the existing framework of Web apps. These apps may then be deployed on a network and accessed using URL calls, but this time the client doing the accessing is the Office application rather than a Web browser.

It’s a different principle, which is in many ways not at all the same as Office development as it has come to be known. In fact, both the third and fourth generation systems remain present and active in Office 2013. VBA worked through a classic Microsoft runtime interpreter, which addressed Office applications individually by way of COM class libraries entered into the System Registry. These class libraries provided objects with their own methods and properties, like Application.Selection.Characters.Count, to return the number of characters highlighted by the cursor in Word. The methods could make the application perform any action the user could do manually; for example, the Find.Execute method dispatched Word’s find-and-replace system.

In a somewhat different context, Office 2007’s line-of-business apps were programs written in Visual Studio, typically using one of the more common .NET languages like C# or Visual Basic (not VBA). They too had access to the applications’ COM class libraries, but these programs were either launched separately or as add-ins to the Office applications, rather than being embedded within documents. But because Microsoft also premiered the Ribbon UI controls with Office 2007, it only allowed those add-ins to be displayed through a special Developer tab, which was not displayed by default. Some businesses cited this reason alone as cause for not embracing this development model.

The Office 2013 developers’ model could be perceived as serving an entirely different purpose, and maybe even a separate audience - not that the earlier audiences were exactly blockbusters. As Brian Jones explains, the new JavaScript API is limited to fulfilling RESTful functions, most notably and most often acquiring data from the open document, especially what’s currently being highlighted.

The embedded app can then be used to extrapolate new information from the data, as in the above example from Excel 2013. Here, the embedded app is on the right of the worksheet, but it behaves like a typical chart. It reads whatever data is presently highlighted or chosen, and then produces a chart based on that data — although in this case, it first polls Bing Maps online. The result in this case is an instant heat map whose bubbles are relatively sized according to the values in the second column and superimposed over geographical locations ascertained from the first column.


In this more complex example (obviously demonstrated to me while the London Olympics were taking place), live victory tallies from a site called Medal Tracker were re-interpreted and repackaged in a way that their data could be live-inserted into a worksheet, both as values and bubble charts. Here, the embedded app maintains a constant connection so the worksheet always reflects current values. Jones admits this is a slower, simpler example of the classes of functionality that can be embedded in documents. Imagine company prospectuses with live stock values, for instance.

This much simpler example from Word 2013 shows how an embedded app can reside in a pane, much like the Navigation or Styles pane. With very few instructions, whatever the cursor has highlighted is forwarded to Bing News, with the search results shown in the pane. (You might think there isn’t much news going on these days with the Roman Empire, but evidently the Huffington Post has a correspondent at the scene.)

Jones tells me the new API calls do not map to the old COM class library, partly because the API is new, partly because there will be one Office API across the board rather than a separate subclass for each application.

“But there’ll be other areas where we actually don’t plan on bringing certain things forward,” he says. “This API is designed much more for portability across platforms, and even across the applications. For example, if you’re going to interact with a table of data, it’ll work exactly the same in Word as it does in Excel, and it’ll work in both the Excel rich client and the Web companion.”

Here, Jones is using temporary terminology for the standalone application, which is installed in the traditional manner, and the new online version obtainable through the revised Office 365 license. Permanent, cooler sounding terms are likely in the works.

“The easiest way to think about the new API,” Jones continues, “is that it’s more about content/data, as opposed to each application’s runtime. The old COM APIs map more to the applications’ runtime behavior, so it was more of an automation API where you could go and drive all the behaviors of the application — everything the user could do with his mouse. It was all just client-centric, all about deploying DLLs on the machine, and everything ran in the context of the machine. We’re now moving to a multi-tiered model, where you would do things [like creating tables] through Excel Web Services.”

Nothing more clearly demonstrates the completely revised principle of where each user’s licensed copy of Office actually runs than the following fact: Certain API requests will actually be fulfilled not by the user’s local copy of an application (which, let’s face it, may not even be present) but instead by a copy running in Microsoft’s cloud. So, whereas with VBA, having the app create data may require the invocation of an Office app on the client side, with the new API the creation of the same data may require a call placed to Web Services on the server side. The user may not notice a difference unless she realizes she’s running a system where Office is not installed, or where the app in question is actually running in the browser.

Jones notes one other benefit of the new model: Since no app under the new model can take over an Office application on the client side, there’s no possibility of a security breach.

Attention Shoppers


Following the de facto principle that all online ecosystems are driven by an apps market of some sort, soon after Office 2013 is released to manufacturing Microsoft will launch a separate apps store — complete with a purchasing mechanism — exclusively for Office. Users will find a button in the Insert tab of the ribbon for each application, marked Apps for Office. There, a panel like the one shown here will let the user browse for functions that may resolve an issue or provide a function she needs.

Although these apps will be tailored for Office, Jones says Microsoft will allow developers to sell apps here, with the company keeping 20% of sales at time of purchase.

And in keeping with the company’s strategy of leveraging one platform to promote another, a business will be able to launch its own Store departments, exclusive to its own employees, as extensions of its SharePoint site. So, the company can publish its own apps locally, enabling workers to find functionality that may only pertain to their business or their employer, under the My Organization tab of the Apps for Office Store.

 

subscribe-to-our-blog

 

Colossal Development Server No Longer Required

At the time of this writing, the preferred method for client-side Office apps development is yet to be determined. Visual Studio 2012, which was just released, does include a project class for Office apps, though with the API still in the development stage, that class may yet be presumed incomplete. Developers had been concerned that Microsoft might choose to limit its forthcoming free Express editions of Visual Studio to WinRT only, the new class of “Modern-style” apps for Windows 8. That fear was allayed last June when the company’s Server and Tools chief S. Somasegar announced there would be a new and separate class of Express 2012 editions for Desktop apps development.

But that doesn’t necessarily mean there will be an Express environment that works for Office apps. Not all Office apps projects will - or should - be monumental undertakings worthy of marketing and promotion in online stores. And with that in mind, businesses will weigh any expense, however small, made toward the production of essentially a quick fix or a cool add-in.

Microsoft does offer a free Web development platform called WebMatrix, which is used by JavaScript and HTML developers to build portable Web apps using standardized (i.e., non-Microsoft proprietary) languages. Brian Jones declined a response to my inquiry over whether WebMatrix could be adapted for Office 2013.

However, the company is promising that a newly overhauled Office developers’ site will be launched with updated documentation and support. As Microsoft’s SharePoint product group director Richard Riley tells us, “We kinda took a different look at it, and what we decided to do was to create a brand new SKU for Office 365 called the Developers’ Site.” When you sign up to be a developer on that site, you register for the Store, give Microsoft your payout details, and are provisioned with an Office 365 account and a developer kit. The SDK includes SharePoint, a click-to-run version of Office so you can stream Office down to your desktop in under a minute, Exchange 2013, and Lync 2013, “all models of server- and client-side products to develop apps for Office and SharePoint,” says Riley.


It was here that Riley revealed the biggest surprise of all, certainly for me, a fellow who’s all too accustomed to client-side development on the client side. The Office Developers’ Site will actually contain a development environment for Office apps — a specialized edition of server-side Visual Studio, code-named Napa. So, once you register as an Office apps developer:

  • You don’t need to install Office applications on your desktop client.
  • Your apps don’t need to call a client-side Office API.
  • You don’t need to install and run any client-side IDE.

Put another way: You could do the whole thing from a tablet (maybe one of those new Windows RT jobs) that you keep in your handbag. “Within 15 minutes of signing up,” adds Riley, “you could be writing and debugging that first app.”

Is There, At Last, Enough Leverage?

I wish I could say this was my idea; I admit to brooding over ways to claim it. However, in the end, my more rational side (which only comes out to play on very rare occasions) concludes that whether this new Office apps ecosystem finally succeeds, after three decades of searching for the right formula, depends on whether the following questions are resolved:

Will the creation of apps that run in Office actually improve the apps themselves? Would it be equally convenient for the same functionality to be attainable through a browser-based app?

Imagine for a moment not just the Olympic medal count scenario, but real-time financial trading data. Would it really be more convenient for you to see the live data in the context of the worksheet you’re using? Or would it actually be better to have it separate, and actually contacting the worksheet through the browser? If it’s the latter, developers and their businesses may not perceive Office app development as a function in itself.

Do stored documents need embedded apps?

Let’s face it: If a Web app is an embedded URL anyway, is it more convenient to get that URL in an Office document or in an e-mail? Or in a tweet?

If companies’ IT or DevOps departments will be building the functionality that could comprise Office apps anyway — in whatever form they eventually choose — then do they really need a fun little iPhone-like store for promoting them? Or would they simply prefer that their admin install them remotely and e-mail a note to their employees with instructions?

If the new Store doesn’t take off, the new Office 2013 functionality might not get noticed any more than the existing VBA and LOB models have been throughout the last decade.

I think I’ll wait to see how these issues are resolved this time around before I take credit for anything new.

See also:

 

codecollaborator7-w3bba7e2

Close

By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox