As you know, Office 2013 is now available for purchase. Like all editions before it, Office 2013 is, “the best Office yet”. If it weren’t, I sure hope MSFT wouldn’t release it. I don’t think, “This version is quite as good as the last version” works as a tagline.
When you upgrade (and you will), you can choose between two license paths: 1) the traditional path, which is a perpetual license, and 2) the subscription path via Office 365. Personally, I’m using an Office 365 developer account at the moment. It’s free for now. When they switch it and force me to pay, I’m sure I will. I like Office 365. Please keep this in mind as my comments develop.
After you install Office 2013, you will have access to a brave new world of productivity via the Office App Store. You see… if you find that your favorite Office app (e.g. Word) is missing something, you will be able to visit the Office App Store and purchase an app that fits the bill. No problem. It will be there. That’s because the App Store is awesome and developers have embraced it enthusiastically.
Do you doubt me? I offer these screens shots as proof of the overwhelming developer support of the Apps for Office platform.
Well, uh, maybe not. Why are there so few apps?
Office add-in types
The new App Store is the latest in a long and otherwise successful history of Office extensibility models. From the very beginning, MSFT realized that users don’t really like to repeat the same task over and over again if they can help it. Users want to automate, so Microsoft gave us VBA and then gave us COM Add-ins, and kept right-on giving until VSTO.
Here is a brief history lesson. It isn’t meant to be a complete list… just enough to help me make a point later on (just click on the below links for details).
Microsoft took the disparate macro languages included with Word & Excel and combined them to create Visual Basic for Applications (VBA). They also decided it would be a good idea to have all Office apps support VBA. With VBA, you have access to each Office App’s object model and could do anything you darn-well pleased. Deployment was easy too as VBA was part of the file and travelled with it.
This extensibility model is a big part what made Office, well, Office! It was also an easy way to spread viruses. That was a real problem.
Today, VBA lives on but Microsoft wants it to die (and the sooner the better from what I gather). As evidence I point out that Microsoft has invested almost nothing to improve the VBA developer model over the last decade. The VBA editor hasn’t changed a bit (but it still does the job). The object models only receive updates to support the new features in Office. VBA is alive but only in a “not dead yet” way.
Granted, VBA is a toy language and not the tool for professionals. It’s the stuff of power-users and beginning developers. Serious developers wouldn’t build entire solutions with it right?
Well, with all the VBA running around in enterprises big and small, Microsoft realized they needed a better model that fit within the realm of professional development. So, COM Add-ins came into existence.
The COM Add-in extensibility model allowed developers to use professional tools like VB 6 and Delphi (and later .NET) to build a single add-in that supports multiple Office applications from a single code base (something VBA couldn’t do). This improvement was a major boon to Office developers and lots of solutions were built with it (and still are). A disadvantage is you can’t attach a COM Add-in to a document like you can with VBA. Deployment isn’t as easy as with VBA.
Visual Studio Tools for Office (VSTO) attempted to improve upon the COM model by simplifying the COM interface (IDTExtensibilty2) and embracing .NET. Using VSTO, you can write a .NET assembly and attach it to a document (aka Document-Level add-ins) or to an Office Application (aka Application-Level add-ins). Also, VSTO provides a few visual designers and other Office components.
The trouble with VSTO is you have to match the Visual Studio version with the Office versions it supports. If you want to target several versions of Office with your solution, you will need multiple code bases. Also you will need a library of virtual machines so you can maintain the correct mix of Windows and Visual Studio for each version of Office.
In recent years, we’ve seen new tools added to our Office development arsenal. They have their uses as part of a solution but are not the basis for a complete solution.
- Open XML: Microsoft finally gave us a way to stop crashing servers when generating thousands of documents. Now, we can use the Open XML SDK to generate and edit documents without Office installed on the system. It’s bad for licensing revenue but good for performance. The learning curve is steep and frustrating. But if you can hang in there, the word-on-the-street is, it’s good stuff.
- Services: Microsoft is attempting to create Office as a Service (OAAS) via SharePoint. We currently have Word, Excel, PowerPoint, and Visio services. I guess I should count Access services too but, it seems Access is lost in the wilderness these days. These services offer varying, specific features and are not the same as the Office desktop apps. Also, they require SharePoint.
Both of these technologies decouple Office technologies from the apps themselves. They embrace current trends like “open platforms” and software as a service. They also help alleviate some of the limitations imposed by Office and its COM-based world.
It should be no real surprise that Microsoft is looking to further embrace current development trends within their flagship desktop application suite. So let’s talk about current development trends within Office.
Apps for Office… we want new blood!
Mastering Office development is a frustrating and exciting experience. It’s great fun to build solutions that streamline the work processes of your users. But it’s frustrating as you navigate the various object models and their peculiarities in search of the best architectural approach.
Developers, who have never worked with Office, after being initiated into the world of Office development, always ask, “is there a way to make this easier?” The answer is yes. But the follow up questions is, “Will making it easier sell more licenses of Office?” If the answer to this last question is negative, forget about it and find a work around.
Microsoft is aware of this situation and decided to do something. They decided to add a new Office extensibility model that embraces these three web technologies. And given all the hoopla surrounding app stores, why not add an Office App Store to the mix as well? How hard could it be? Seriously, Apple has an app store and Apple wouldn’t even exist if not for Microsoft. Besides, MSFT already has app stores for Xbox, Windows, & Windows Phone. Apps for Office is a slam dunk!
This is the future of Office Extensibility: Apps of Office?!!?
What appeared to be a good idea is, instead, a hot pile of poop in its current iteration. When I first heard about this new model and its app store, I was optimistic… excited even. How great would it be to have a delivery model that allows users to immediately purchase apps that enhance Office applications?
But then, I began attempting to develop a couple of basic apps for this blog. My heart sank as I quickly realized the API doesn’t let you do much in terms of automation. Instead, the API has the core idea of “the user is in control”. What this means is you can’t do anything for the user. Things like:
- Create Outlook items (contacts, tasks, appointments, etc)
- Scan incoming email and alert you to important ones
- Navigate an Excel file and insert formulas
- Automate Word document content creation
- Automate custom business process rules of darn near any kind
It just leaves me scratching my head and repeatedly uttering…
You gotta be kidding!
The API is weak and not ready for serious adoption. I think MSFT should label it Beta. If they did, it would be easier to go easy on them. But they haven’t and they expect us, Office Developers, to take it seriously.
If you look at the Office App Store today, you will not see many apps available for sale (just look at the screenshots at the beginning of this article). By one journalist’s count, there are close to 200. And most of these apps are superfluous to existing Office features. If not superfluous, they are slimmed down versions of real add-ins that essentially serve as advertisements.
Users will not like this and will quickly view the Office App Store to be a joke… that is if they even know about it to begin with. The App Store button isn’t exactly conspicuous. I fully admit it’s early in the release cycle and I might be too quick to judge. If so, it isn’t the first time.
I think I’m right on target. Microsoft has stumbled out of the gates on this one. Even worse the Apps for Office roadmap is unknown. Who wouldn’t want to spend their days and nights building apps for a platform with an unknown roadmap and future? I know who wouldn’t… professional developers.
How to not be hip, stay happy, and avoid Office Apps
When MSFT displays their new and shiny bits it is hard to ignore them. There is so much flash… so much sizzle. It fills us with the hope of a brave new world. It makes me think of the early settlers of the English colonies in North America.
Did the marketing department for the sailing companies have slick marketing campaigns promising a better life in a new world? Did they speak of future riches just waiting to be had in a world filled with untapped resources? Did they speak of freedom and new possibilities? I bet they did.
I bet too they didn’t mention it would be a damn hard existence and wouldn’t come close to what the marketing brochures promised. The lying bastards! Some things never change.
When taking stock of a new product, service, or API… it’s best to listen to what is not said instead of what is said. In the case of Apps for Office the lack of API features and supported business scenarios shouts from the mountaintops.
If you listen, you can hear it saying:
“If there is no future in it… let’s put it in our past!”