1. SharePoint Development Across Developer Segments
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 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 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 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 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.
2. Web-Based Development in SharePoint
One can
define SharePoint development in a number of ways. As a power user you
might leverage more of the native SharePoint features to do development
through the Web-based environment. Power users typically have escalated
permissions on a SharePoint site and are able to accomplish tasks such
as the following:
- Creating and managing site collections and site permissions
- Configuring a new theme to the site
- Adding a new app to the site
- Creating and deploying multimedia for site-wide consumption
- Configuring and customizing searches
- Creating external data lists
Although some might argue that these are merely tasks
that a power user or IT pro might perform, one thing about SharePoint
is that the lines are sometimes blurred where one user persona starts
and another ends. For example, with many of the Web-based functions
that you can perform when developing for SharePoint a direct
relationship exists to a development task. That is, you might see the
SharePoint Web interface as an endpoint
to the development experience. For example, if you create a custom app
you will need to add it from an organizational-wide gallery (for
example, a corporate catalog). If you’re working with a designer to
create a new master page, you’ll need to associate that new master page
with a specific site through the site settings of that SharePoint site.
The types of Web-based tasks that you can perform go on and on (and
you’ll likely evolve from the more Web-based tasks to the more
difficult coding tasks as you get deeper into SharePoint development).
To some people these Web-based tasks are
more centric to power-user features, and to others they are inclusive
within the development process. However, the main takeaway is that a
developer will interact with the Web-based features with SharePoint as
well as potentially leverage other tools discussed in this chapter. A
power user might also leverage these same Web-based features. In either
case you require escalated privileges on the SharePoint site, and a
connection exists to the development process (that is, a power user
creates a site to which a developer drops his custom app). Thus,
SharePoint development comprises a broad spectrum of activities and
tools.
