The background on apps for Office and SharePoint

Hi, my name is Brian Jones and I'm the group program manager for the Office Solutions Framework team. I wanted to follow up on Ludo's blog post last week where he introduced the Office Storeand the new Office cloud app model. I've been working on extensibility technologies in Office for the past 13 years, and I've never been as excited to talk about a release as I am today. There are many teams behind this effort, and over the next several weeks you'll hear from program managers on my team and the other teams who have spent the past several years working on this new app model and store.

We've noticed a number of trends over the years that have influenced this new approach as Ludo already discussed. At a high level, we've all observed how solutions these days are highly collaborative, and span several workloads. Making one person more productive in Excel, for example, isn't nearly as valuable as helping an entire team meet their goals (such as replying to an RFP) and manage all the content that gets created. A solution needs to surface on a wide array of devices, backed by a rich set of web services. We recognized that it's not the individual Office applications that are the platform for these solutions… the web is the platform, where Office can provide a valuable set of endpoints and SharePoint provides a powerful set of collaborative services. We've focused on a unified model where, for the first time, the lifecycle and packaging of apps in Office and SharePoint are the same, and the APIs are all based on standard web technologies.

Our Tenets

Before I get started, I thought it might be useful to see the tenets we took on at the beginning of the release to help us stay focused as we built this new platform:

• The web is one of our platforms – While we are not be the host for all solutions, we still want Office and SharePoint to play valuable roles in how people experience those solutions. We have built around web standards such as HTML5, JavaScript, REST, OAuth, and OData, where any web based solution can easily integrate with the Office 365 services and client applications.
• APIs should be independent of the implementation – The JavaScript APIs for Office are content-based rather than application-based, which will help us reach our goal of supporting apps for Office anywhere you can open an Office document. Wewant these apps to be compatible across the Office products and the platforms where Office runs. SharePoint extensibility is now all through RESTful APIs, rather than having to install code directly on servers. Across the board we've focused on these loosely coupled models to make it much easier to build solutions.
• Simple is powerful – This is just the first step in a new direction… we look forward to learning about what we've missed, but we are also excited to work with you on how to push the limits on what we provide.
• The user should be in control… end user experience trumps all – We isolate the apps from a security, performance, and even UI perspective. This means as a customer you can buy 100 apps and not have to worry about the Office UI becoming unusable. This also means as a developer you have a higher likelihood of people trying your app. We aimed to eliminate the friction around the lifecycle of solutions including development, acquisition, deployment, and upgrade.
• Platforms are only as valuable as the ecosystem they enable – We want you all to be successful building apps on our platform, and we can't succeed without you. We've targeted a wide spectrum of people creating solutions, from end users to lightweight web developers to professional developers and from corporate IT to SIs to ISVs .

Three components of a successful platform

When we think about the overall set of investments to make developers successful, we think of three key pieces, which are all necessary for the platform to succeed:

• Services & APIs – A key goal around all apps is that they run across multiple platforms and devices, which is why we're focused completely on standard web technologies like JavaScript, HTML, CSS, REST, OAuth, and OData. Long term, our goal is that apps surface on all of your devices, and are backed by the rich set of Office 365 services.
• Distribution & Lifecycle – We made a huge investment in making it as easy as possible to deploy and manage apps. There are no heavy installation steps required, and your apps will always roam with you. We'll also handle the transactions for app purchases, so as a developer, it's very easy to build and publish an app to our store and immediately start getting paid as customers acquire your app.
• Tools & Learning – The application model is built around the cloud and web technologies, so of course we wanted to make sure the tooling experience was the same. Thanks to the investments the Visual Studio team has made in the "Napa" app, you can start building apps today directly from your web browser, and never need to install any client bits if you don't want to. Access has also been re-invented, so that it's now the easiest way for a non-developer to build and publish a cloud based app for SharePoint. We've invested in dev.office.com to get people started building quickly, prioritizing code snippets and examples over deep reference documentation.

Background

Before going into more details around the new cloud app model, I want to quickly touch on some of the existing extensibility models we have in Office. I don't want to get into a deep history lesson, but I do want to provide a bit of context that helps frame the new path we have started down, and how the existing set of technologies remain a valuable part of our overall story.

• SharePoint Full Trust Solutions – SharePoint is a powerful server application that allows people to easily collaborate with others on documents, lists, and events. It's been highly successful because of how quickly a group can get started with creating their own sites. In the first versions of SharePoint, extensibility was done by building a managed assembly and installing it directly onto the server. This meant the application was fully trusted and meant any app you installed had to go through a significant vetting process because of the full rights it had on the machine.
• SharePoint Client-Side Object Model – In SharePoint 2010, we made it much easier to build client-side logic into your solution by releasing the JavaScript libraries for connecting to SharePoint's rich set of web services. This brought a new class of solutions that didn't require code on the server and therefore were much easier to get approved.
• VBA – VBA was exciting because it gave end users the ability to become solution builders. Tools like macro-recording in Excel empowered non-developers to build powerful models that we've seen in many cases become a core piece of running a business. While it's often not thought of this way, Excel really is an IDE and runtime, where a spreadsheet can often be thought of as an app. VBA also allowed code to travel with a document, which was a bit of a double-edged sword. It allowed the solutions to easily be shared with others, which is something we also provide in the new app model… while also taking some new steps around security, governance, and sandboxing.
• COM Add-ins – Leveraging what essentially was the same object model in VBA solutions, Com Add-ins allow for application-level extensibility as opposed to document-level. It's worthwhile to note that the existing object model is tied directly to application behavior. It was designed to help automate the applications, which is what made macro-recording possible in the VBA case. But, the challenge with being tied so directly to application behavior is that compatibility and portability becomes difficult, especially when you start introducing applications on other platforms, like the Office web companions, or Office for Mac.
• Open XML – Starting in Office XP, we began to move to XML-based file formats, which allowed developers to build services to interact with Office documents. The content within Office documents is some of the most valuable data out there, so ensuring that web-based services could consume and generate documents was one of the huge motivators in our move to the Open XML formats. We've seen some powerful SharePoint solutions that leverage the Open XML SDK to automatically generate Office documents on the server, introducing an interesting new class of document-assembly scenarios.
• VSTO – For developers who wanted to write solutions in managed code, Visual Studio Tools for Office made it super easy to build and package a managed solution. It's a powerful set of tools for writing both Office and SharePoint solutions, and has been extremely successful. When we introduced smartDocs in Office, VSTO became the easiest way to build task panes that extended the Office experience.
• Access – It's really incredible when you look at the number of Access applications running within any given company. With the new version of Office, you'll see that we are going back to the roots of Access as a powerful tool for end users. Access will be the easiest way for a non-developer to build their own app for SharePoint.
• And many more… – There is a huge list of other important extensibility mechanisms in Office, like UDFs, MAPI, forms^3, etc. While we are introducing a new Office cloud app model, we also realize the solutions people have already built are extremely valuable and need to continue working and we will continue providing versions of Office that support those existing solutions.

These existing extensibility models have been very successful and are an important part of how many of our customers run their businesses today. We will obviously continue to support those solutions, but we believe that moving forward, developers should look to the new model when building new solutions.

The Model

What you see when you sign up for the Office Preview is just the first step in a new direction. You'll see that the new models don't necessarily support everything the previous models did, and there will be many solutions that you won't be able to port over to the new models. This is one of the many reasons we will continue supporting those existing solutions as well.

In certain cases, the lack of a particular bit of functionality is something we'll address in future versions. This is a journey, and we're excited to work with you all on ensuring that we provide a rich application model that lets you build killer apps that delight your customers.

In other cases though, we've intentionally avoided functionality present in the existing extensibility models. Our overarching goal is to provide customers with the best experience using apps. For example, one goal is that apps can't get in the way of the core user experiences. We expect customers will acquire dozens of apps, and we have to limit what an app can do. That's why apps for Office won't be able to change the Office UI, or cancel events. Apps for SharePoint can't execute code on the SharePoint server. Apps cannot interfere with core user experiences so, as a result, it's not nearly as intimidating when you install and try an app.

Web Standards

We realized that what developers really wanted when building apps was total flexibility. If you want to store a bunch of data for your app, you should be able to spin up SQL Azure or MySQL and store your data. If you want to have server-generated pages, you should be able to write PHP or C# on a server. We did a ton of work to provide a rich set of RESTful services in SharePoint backed by OAuth to allow developers to build apps their way. When the user installs your app, they can grant it permission to the set of content needed, and the apps you developed can run anywhere you want. If you want to get data from a list, it's this easy:

HttpWebRequest listRequest = (HttpWebRequest)HttpWebRequest.Create(sharepointUrl.ToString() + "/_api/Web/lists");

For client-side extensibility, we're focused on JavaScript for the logic, and HTML/CSS for the presentation. Write an app that surfaces in Word, Excel, Outlook, and Project simply using HTML and JavaScript, while at the same time connecting to SharePoint services via REST. We wanted building an app to feel just as easy as adding an iFrame to a webpage.

The apps for Office function just like any webpage, but they are also given access to a set of APIs that allow them to interact with the document. If your app is running in Excel, and you want to update your app based on what the user is selecting, just write a little JavaScript and you can grab the value of the selection:

Office.context.document.getSelectedDataAsync('text', function (asyncResult) {
var result = asyncResult.value;
});

The new API and services are built around content and data, rather than application runtimes. This is why the app can easily run in both the rich clients and the web companions. Code that reads and writes to a table of data in Word will work in Excel as well, without changing a thing. The same approach you take to building an app in SharePoint will also apply when you build an app for the Office clients. Even the packaging formats for the apps are the same.

Lifecycle

To help you as a developer reach as many customers as possible, we are also introducing the Office and SharePoint Store. Submit an app to the store, tell us how much you want to charge, and we'll take care of the rest. Apps for Office and apps for SharePoint use the same packaging format, and we've made it easy to combine the two to help build full solutions. An app for SharePoint can include apps for Office as well, so in the example of an app that helps folks manage their response to RFPs, you can also include apps for Word and Excel documents as a component of that single app the user acquires and installs into SharePoint.

Our teams realize that we will only succeed if you succeed, and to ensure that happens, we had to completely rethink the extensibility models so that customers feel comfortable buying tons of apps, without having to worry about whether it will degrade their core experiences. We also want it to be super easy for people to share apps with their friends and colleagues, and for those apps to roam with them wherever they are accessing their Office content. We've made it so that sharing an app will be just as easy and safe as sharing a document with someone. You'll see apps shared in ways that don't exist in other app stores.

Tools & Samples

For this next version, we've focused on the web technologies with the web developer as a new focus. This required us to rethink some of our tooling approaches, and the way we provide developer documentation. We wanted to make it as easy as possible to get started, so rather than worrying about setting up a dev environment, we've created one for you! If you go to the Dev Center available at dev.office.com, you can sign up for a developer account for free during the Preview, which will give you your own running version of SharePoint and Exchange and the Office clients. You can install the "Napa" app, which gives you an easy-to-use web-based IDE so within 15 minutes you should be up and running with your first app. It's all stored and managed in the cloud, so anywhere you go you can get to your apps and quickly make modifications/improvements. The same way you use OneDrive and the Office Web Apps for your documents, you can use the Developer Portal and "Napa" for your apps! Often you'll get to a point with your solution where you want to use a rich client for the development, and you'll obviously have the ability to open the solutions in Visual Studio as well (or whatever you're tool of choice may be). We've even done work to make debugging from Visual Studio against a remote SharePoint instance super easy, so your solution can continue to live on your dev tenant while you work in Visual Studio.

For the non-developer, we've made a big push with Access as well. It's now super easy for a non-developer to use Access to build their own app for SharePoint, where deployment and management is no longer a challenge. Everything is deployed to the cloud, including the database, which will run in SQL Azure, without any additional configuration required by the end user.

In addition to the tooling, we've taken a new approach to documentation as well. The easiest way to learn how to build solutions is to just look at a few examples, not reading deep documentation. Because of that, we've focused our content-creation team primarily on building example solutions and providing tons of code snippets for re-use. We will continue to focus on building out these solutions, and we're going to work closely with the community to understand what snippets/examples folks want to see.

What's next?

We will have a number of people from the team post to this blog going forward. The next post will focus on the opportunities the store will provide to you as a developer. After that we'll have two posts that will go much deeper into the actual model. Rolando from the Office Solution Framework (OSF) team is going to post about the anatomy of an app for Office, and Howard from the SharePoint Developer Experience team is going to post on the anatomy of an app for SharePoint.

I first started blogging about 7 years ago when we were announcing the new file formats for Office 2003. It's been a few years since I last posted, but I'm excited to start this new dialog. I had a hard time deciding what to discuss in this first post (as did Ludo), so I've aimed to cover just a few of the basics as we'll have plenty of time going forward to drill into the details. I'll end with the same apology I used those many years ago (an old Pascal quote): I'm sorry this post was so long… I didn't have time to make it shorter. Looking forward to the discussion!

-Brian

Comments

• Anonymous
  July 23, 2012
  Hi Brian. Haven't heard from you in a long while since the whole OOXML thing. What have you been up to?

• Anonymous
  July 24, 2012
  Hey Ian, good to hear from you. Hope all is well. :-) It's been a few years since I last blogged on the Open XML front. On the personal side, we have an amazing 2 year old daughter, and we now have a son on the way this fall. Work wise, I started the OSF team a little over two years ago, and have been working on crafting this new application model. Open XML is still one of my babies of course, so I stay involved there as well. With the new cloud based application model, file format transparency & manipulation is definitely an important piece. -Brian

• Anonymous
  July 24, 2012
  5 years in hibernation. Holy caca, he's back!

• Anonymous
  August 01, 2012
  Hi, I am wondering why you have not yet implemented a VB.NET/ C# document-level extension like vba has been for years.  Something that you can just write in code behind he doc and move with it. Everything seems ready for the two language to be integrated fully: optional parameters, named parameters, code editing during excecution. Is there any chance we can get them to be the two new macro languages for office? If yes no why? Thanks Pierpaolo

• Anonymous
  August 02, 2012
  Hi Pierpaolo, We've done a lot of work over the years with the VSTO team to allow folks to write managed solutions against Office. We made the decision with those solutions to have the code live separate from the document. The document can reference the code, but for governance and lifecycle management purposes we have code live separately. I definitely understand why you're making the request though, as VBA embedding in documents is obviously a super convenient way of distributing a solution. With the new apps for Office work, we've gone for the best of both worlds. The "code" is just a webpage and can be hosted anywhere. There is a huge set of developers out there whose primary languages for client side extensibility are HTML/CSS/JavaScript, and we wanted to make sure they had the ability to build apps for Office. Obviously on the server side, you have complete flexibility (.net; php; etc.). When you insert an app into a document, the document references a manifest file that lives in the Office.com store, or your own internal app catalog. This way the document can have the apps "inserted", and when they are opened on another machine, Office will look-up the manifest file and then load the HTML from the website specified in the manifest. This makes it super easy to share documents with apps, but also provides a robust way to manage the lifecycle of the apps, as everything must go through the catalog you've set up. -Brian

• Anonymous
  August 02, 2012
  Stephane, It's good to be back blogging again :-) -Brian

• Anonymous
  August 10, 2012
  will NAPA allow writing apps in vb.net, or is it c sharp only?

• Anonymous
  November 05, 2012
  Thanks!