Rapid Prototyping with “Napa” Office 365 Development Tools

As a developer there are times I want to quickly throw something together to see if an idea I have is workable. I don’t need to go through all the ceremony of creating a project with necessary dependencies, good architecture, etc. if all I want to know is if I can access some service. For most things I can fire up a quick test project using either Console or Web project templates and have my answer in a few minutes. For SharePoint though, this has never been very easy.

Introducing Napa Tools

“Napa is a great way to get started building Office Add-Ins right in a browser window. You don’t need to install any tools such as Visual Studio. All you need is an Office 365 account and a supported browser.”

With previous versions of SharePoint, server-side code was really the only way to go to create custom SharePoint solutions. Developing for SharePoint was tricky as it required a local install in order to build and package solutions. This made throwing together test harnesses very slow to prove out a concept. With the introduction of client side libraries and services, extending SharePoint with custom code has become much easier.

Even though developing for SharePoint doesn’t mean server side code, it still has packaging requirements. That’s where Napa comes into play. Using an online editor which resembles lightweight editors like Sublime and Visual Studio Code, anyone with a modern browser can throw together a quick test or demo without a local install of SharePoint or even worrying about manifests and elements files. The editor provides syntax highlighting, jump to definition, basic Intellisense capabilities, and saves your work automatically.


“Napa” Office 365 Development Tools Online Editor

Quick Note on Terminology

In this post I mix the use of “app” and “add-in” a few times. This is mostly because the terms have been used interchangeably as the official names have changed. If you used the Napa tools recently you may have noticed the menu for creating a SharePoint add-in still said “App for SharePoint” though this has been renamed “SharePoint Add-in” now. MSDN documentation and even the Napa store app still contain references to the old “app” name. I try to use “add-in” when I’m specifically referencing the technology and limit “app” to referring to a general concept of a self-contained collection of things that do stuff.

Getting Started

There’s not a lot required to start using Napa. If you have a modern browser and SharePoint Online, you have everything you need to get started. No, seriously, that’s it. Don’t have access to SharePoint Online? Sign up for a free year of Office 365 with a developer account.

Once you have these two basic requirements, all you need is to install the Napa add-in.

Basic Template

The basic template is very simple with both a full page and a content part available to customize. I prefer to just play with the full page content since it’s ready to go and I don’t have to worry about any styling around a content part interfering with anything I am trying out. This basic template includes references to SharePoint style and JavaScript libraries as well as the project-specific App.css and App.js files. It also includes jQuery via a CDN reference showing that you can use externally hosted files in your solution.

Note on URL Protocols

You’ll notice all the Napa examples are using HTTPS everywhere. SharePoint Online pretty much requires HTTPS protocol for everything so this is generally seen as safe. While you can modify a package and deploy it to an on-premises install of SharePoint using HTTP, external references that are available via HTTPS should still be requested explicitly using HTTPS. You can use protocol-relative URLs but there is a possible security vulnerability doing that.

Deploying Your Add-in

Now that you have the basic parts of an add-in, all you have to do is hit the Run Project button. Your add-in will be uploaded to SharePoint Online but if you look at the URL you’ll notice the domain is different from the one in which you created your project. This is a really important piece of information if you expect to interact with your SharePoint data inside your add-in. If you’re just creating a content piece that displays data from external sites then this won’t matter to you at all. You’ll notice that even though the domain is different, the site URL from which you launched Napa is still part of the full URL.

With you add-in deployed, you can now interact with it and use your standard browser debugging tools to test out whatever you were hoping to test. In mere minutes, you have an app running on SharePoint with access to SharePoint client services and libraries and, with a bit more effort, you can even access data from your SharePoint lists.

Going Further

Add-ins created with Napa can also access and interact with your tenant data. You can download the source code for inclusion in your source control system, modifying for more powerful features or just to use your preferred editor offline. In a future post I’ll explore accessing your data via a Napa add-in using the SharePoint REST services. Spoiler: reading data is a lot easier than writing it. But I bet you knew that already if you’ve worked with SharePoint client side programming.


So far I’ve only run into two problems, both of them leading to a failure to publish an add-in. The first seems to happen when a new project is created. If you can’t seem to publish your new add-in, take a moment to visit each of the menus in the settings. You generally don’t have to change anything, just visit them. Try publishing again and it usually succeeds.

The second publish failure usually shows an error message indicating the add-in is already deployed with the same version number. This is (easily?) remedied by going to the site and deleting the app and making sure it’s not in the recycle bin. If this is still happening, check your parent site as well. If it comes down to it, visit all your sites hunting for it and make sure to remove and delete from recycle bin. I haven’t figured out what causes this problem but it might be related to having multiple tabs open. I tend to open a lot of tabs to make it quick to switch between contexts, copy code, etc. but I’ve only had this publish error happen twice.


Happy prototyping,


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s