One of the biggest issues in getting started with SharePoint development are the 2091097 steps you need to go through, and the heavy duty machine you need to invest in, to create a development environment for a SharePoint and Office developer. This is not unlike the fact that creating and running a production SharePoint farm can be extremely time-consuming.

Microsoft realizes this is a challenge for companies who can be potential SharePoint customers but shy away from this huge on-ramp. To cater for this need, Microsoft has provided us with Office 365 - where you don’t need to install SharePoint yourself, you simply use it through the browser, and enhance it using SharePoint designer and Visual Studio. However, you are sharing this online SharePoint environment with others, so you can’t do everything in this environment that you can do with on-premises installations. A notable omission is farm solutions which are available for on-premises installations but unavailable in Office 365.

In Office 365, the SharePoint 2010 development story was cumbersome and crippled. However, with the advent of apps - for both Office and SharePoint in 2013, you can actually develop compelling functionality for this cloud-based environment.

Now, imagine you are a company who has invested in Office 365 and you wish to do some customization that will require code. Bang! Again, you’re back to square one - you need a SharePoint developer’s machine.

Avoiding the SharePoint Dev Machine

Setting up a SharePoint development machine is expensive and cumbersome. This is the problem/use case scenario that “Napa” development tools intend to solve. They will give you the ability to author code through the browser. You install the “Napa” development tools as a SharePoint app and they give you a user experience that developers are familiar with, except it is running in the browser. Things like code highlighting, project structure, statement completion - they are all available in “Napa” thanks to some clever JavaScript that Microsoft developers have written.

Before I dive into the details of the development experience of “Napa” feels like, I want to make two points:

  1. In its current release, don’t expect “Napa” to replace a client installed Visual Studio installation. This is for many reasons. First, Visual Studio has many, many, MANY more features. Second, JavaScript still doesn’t run as spiffy as thick client-side code. Third, there is no source control or team scenarios, etc., built into “Napa” at least for now. You get my point. “Napa” is a v1 release, it will get you started quickly, but it is not a replacement for Visual Studio. The good news, however, is that your “Napa” project comes with a button that will let you export your “Napa” project to a Visual Studio professional or above project. Clicking on that button will install an .exe file and set up a project ready to be installed and run on Office 365. So even though you will have Visual Studio installed, you don’t need a big SharePoint VM installed. Isn’t that nice!
  2. My second point is that “Napa” is definitely v1 in the sense that this product will mature a lot further. For instance, there is technically no reason why such a product cannot be made available for on-premises SharePoint installations. Now, I have no idea if Microsoft will ever do that, which is their decision. But reading the tea leaves, I can be absolutely convinced that this first foray into developing through the browser is a powerful concept, and it will mature a lot further. Fun!

Okay, let’s get rolling with “Napa.”

Installing “Napa”

In the current incarnation of “Napa,” to get started, you need to go to dev.office.com. When you get to the site it should look like Figure 1.

Figure 1: The dev.office.com site.

Click Build to go through a sign-up process. If you have already signed up for Office 365, click the Sign in link in the top right corner. Note that the SharePoint developer site may not be available immediately. You can check the status of the developer site by signing in at https://portal.microsoftonline.com/admin/default.aspx and checking the status as shown in Figure 2.

Figure 2: Wait for SharePoint to be provisioned.

Once you’re on the developer site, it should look like Figure 3.

Figure 3: The developer site.

Now it may be tempting to click on the Get tools to build apps button, but stop! The tools are installed as an app. So first, at the bare minimum, you need to setup the app catalog. In order to do so, when logged into your Office 365 dashboard, look at the top-right corner and click the Admin link and go to SharePoint admin. Then, in the menu on the left, click Apps and create a new app catalog. I created mine at /sites/appcat. This may take a few seconds to provision, so be patient. You can monitor the progress on the SharePoint administration center.

Once you have setup apps, go to the developer site once more and click the Get tools to build apps button. You will then be taken to a page that will allow you to install the “Napa” development tools for free as shown in Figure 4. Click Add it. At this point you may be asked to login to your Microsoft account. Like a dumb donkey, I kept entering my Office 365 account here. What they mean here is enter your Live ID - but since the “Live” branding is being discontinued, they call it Microsoft account, not the onmicrosoft account. Argh!

Figure 4: Adding the “Napa” app.

Anyway, the onmicrosoft account vs. the Microsoft account issue makes sense if you consider that the app belongs to you, not to your SharePoint site.

Once you have added the app, you should be able to see the app added in your site contents page as shown in Figure 5.

Figure 5: The “Napa” app installed.

Creating an App in “Napa”

Now that you have the “Napa” app installed, let’s use it to create more apps.

Click the Purple icon that says “Napa” Office 365 Development Tools, which should redirect you to www.napacloudapp.com. Here you’ll see various kinds of apps you can create. For this article I will create FancySharePointApp as shown in Figure 6.

Figure 6: Creating a new app for SharePoint using “Napa.”

As the app is created, you immediately notice a few interesting things:

  1. You get code highlighting, just like Visual Studio.
  2. You even get IntelliSense including JavaScript IntelliSense and statement completion that is smart enough to understand what JavaScript functions are in scope. This is pretty amazing because it is constantly checking the structure of your would-be page and sort of performing a pseudo compilation of your page. You can see this in Figure 7.
  3. You have a Solution Explorer and you can even upload new files or rename/delete existing files. You can see this in Figure 8.
  4. And at the very bottom, you see the toolbar shown in Figure 9.
Figure 7: Statement completion in “Napa.”
Figure 8: Solution Explorer in “Napa.”
Figure 9: Export to Visual Studio in “Napa.”

The last icon is interesting - “Open in Visual Studio.” You will find that frequently you will run into a wall as far as the capabilities of “Napa” is concerned. One big limitation is the lack of source control, which for development projects is absolutely essential. Therefore, Microsoft gives us the ability to export a project into Visual Studio, where a quick painless installation will lead you to a thick client development experience, wired to Office 365. No longer do you have to deal with the hassles of creating a big development rig.

Anyway, let’s finish our “Napa” app. I wanted to impress my friends with an app that would show funny cat pictures from Flickr. What I found out was that there is a Flickr API that I can call at http://api.flickr.com/services/feeds/photos_public.gne and pass it the necessary parameters to get cat pictures as a JSON feed. This will be a cross-domain JSON request so there are some intricacies to solve, but nothing that is out of our reach.

The first thing I need is jQuery so I can use methods such as $.getJSON. The “Napa” SharePoint project template already has a reference to jQuery 1.6.2. I don’t like that reference for two reasons:

  1. jQuery 1.6.2 is outdated.
  2. It will not auto-update when newer versions of jQuery are available.

So, I went ahead and changed that reference to,

http://code.jquery.com/jquery-latest.js

Next, I changed the “PlaceHolderMain” content place holder to as follows:

<asp:Content ContentPlaceHolderId=
"PlaceHolderMain" runat="server">
   <div id="catimages">
      Standby .. loading cats ..
   </div>
</asp:Content>

As you can see, I have a single div here that is going to show cat images. So far so good! Next, I went ahead and edited the app.js to the code shown in Listing 1.

As you can see, “Napa” is quite smart when it comes to enforcing good JavaScript. You will note that I have a “===” which is good practice in JavaScript since it does a type safe equality comparison. Change that to “==” and “Napa” will give you an appropriate warning.

One of the biggest issues in writing JavaScript is matching all those parenthesis and curly braces. “Napa” shows you matching braces as you are editing code.

Our app is now complete. Hit the Play button in the toolbar at the very bottom. “Napa” will build and install your app and then launch SharePoint with your app installed. You can see this in Figure 10. You will need to allow popups for SharePoint to launch.

Figure 10: Uploading and installing the application to “Napa.”

And soon as the application launches, you should see your first app in its full glory. You can see it running in Figure 11.

Figure 11: Our productive and useful app running in SharePoint.

“Napa” will also let you tweak this project further, and even enable you to talk to SharePoint via its permissioning model. You can tweak permissions by going to properties for the “Napa” app, and going to the properties tab as shown in Figure 12.

Figure 12: Tweaking permissions in “Napa.”

There are other kinds of apps that you can write with “Napa” as well. I leave it up to you to explore that.

Exporting the App to Visual Studio

Now that I have written such a productive and useful app, I wish to add source control to it and possibly distribute it on the SharePoint Store. In order to do so, I simply click Launch in Visual Studio, which prompts me to download an .exe file as shown in Figure 13.

Figure 13: Exporting the app to Visual Studio.

I’ll go ahead and run the .exe file, and Visual Studio 2012 launches with the project opened up nicely. In this project, there are a few things to notice:

  1. This project is running in Visual Studio, all files are local, but they are connected to the cloud equivalents. Open any file and Visual Studio will prompt you to login with your SharePoint credentials. From here on, Visual Studio will keep everything in sync both on your local machine, in your source control and in the cloud.
  2. The site url property of this project is pointing to the online cloud-hosted Office 365 site. This allows you to write apps without a big SharePoint installation locally installed.
  3. You can easily right-click the app and choose to publish it. This will give you an .app file that you can submit to the SharePoint Store or distribute it within your organization.

Now, you can take that .app file and submit it to the SharePoint Store. I tried to get my funny cat pictures app published but Microsoft rejected it. I have no idea why since it is such a useful app. But I highly encourage you to develop it and install it on your corporate intranet.

Summary

Perhaps the biggest change in SharePoint 2013 is the introduction of apps. But there is another change. SharePoint, as you know, eats RAM for breakfast and disk space for lunch. Even to develop for SharePoint 2013, you need a virtual machine with at least 12, preferably 16 gigabytes of RAM. That is a lot!

Installing SharePoint is another thing; you need serious skills and hardware. This means, SharePoint, so far, has been the domain of big companies with resources.

But there is a vast marketplace that Microsoft is itching to tap into - small businesses, or large businesses who do not want the overhead of running SharePoint. As they say, run your business, not your SharePoint server.

The investment and importance of Office 365 will continue to grow. It isn’t a stretch to say that most of the enhancements we see in SharePoint 2013 are for Office 365.

It is only reasonable that Visual Studio will follow suit. Since you can run SharePoint in the cloud, it makes complete sense to provide tools that allow you to develop them. Sure, if you need advanced scenarios, you can still tap into the power of Visual Studio. But for a quick app to solve a purpose, it is simply awesome to use an app to create an app. That is “Napa.”

In this article, I wrote an amazing app that for some reason the SharePoint Store rejected. No big deal! You can write your own.

In my next article, I will dive into other new exciting features of SharePoint 2013.

Until then, Happy SharePointing.