SHAREPOINT DEVELOPMENT ACROSS DEVELOPER SEGMENTS
Chapter 1, “Introduction to SharePoint 2013,” discussed the spectrum of SharePoint developers and the different ways in which they use SharePoint. As a reminder, you can divide this spectrum into the following:
- End users: who use the platform as an application platform
- Power users: who create and administer (and maybe brand) sites
- Designers: who brand the site and build the user experience
- Developers: who build and deploy apps
Thinking about a life cycle around each of these personas, you can imagine ways in which these people might work together or act independently on something that was created for or by them. For example, the end user is the ultimate consumer of what exists out of the box. Meanwhile, the developer builds apps and the designer brands and builds the user experience for the SharePoint sites that the power user configures, thus the end users are downstream from the development process. Further upstream, you have the developer and the designer who might work together (and in some cases are the same person) to deliver both the code and the user experience, branded or otherwise, to the power user and ultimately to the end user. The point is that a range of people interact with SharePoint — from the developer all the way downstream to the end user — you can see a representation of this in Figure 3-1.
Keeping in mind these various types of developers, this chapter is all about the different tools that you can use to develop for SharePoint and the types of apps that you would build or tasks that you would accomplish with these tools. Figure 3-2 provides an interesting way to divide up the tasks and apps that have traditionally been associated with SharePoint development tasks. On the Design side, you can see apps and tasks that would require a more lightweight toolset (for example, SharePoint Designer and Napa), and on the Develop side you see apps that require a more managed code approach (for example, Visual Studio). Each of these tools will be discussed in this chapter within the context of these developer tasks and a broader set of developer experiences.
On the Design side of Figure 3-2, you might be creating apps such as custom lists, HTML apps, master pages, and the like. You could also get into some coding activities, and more than likely that code experience will center on HTML, XML, ASP.NET, JavaScript, and other client-side languages. You might also get into some integration with Silverlight.
On the Develop side of Figure 3-2, development centers on C# or VB.NET (managed code) and possibly scripted languages as well. Using Visual Studio, you’ll also find that development efforts might be managed as a part of an application life cycle, which is more broadly called application life-cycle management (ALM), where source code is checked into team folders (in Team Foundation Server, for example), and you can add SharePoint development projects to those folders and manage them centrally. You’ll also find custom solutions that leverage other parts of the .NET Framework such as Windows Workflow (WF)–based solutions or REST-based services built and leveraged in other SharePoint apps. Using the .NET Framework is especially useful for when you build out your cloud-hosted apps using Windows Azure.
What this development paradigm results in for you, though, is ultimately choice. Depending on what you’re trying to develop for SharePoint, each of these tools offers varying degrees of usefulness for your task at hand.
The following sections walk through each of these development experiences so you can get a better sense for how you might leverage each of them in different ways.